Your Team Is Using AI Coding Agents. You Have No Idea How Much.
Claude Code and Codex ship with built-in OpenTelemetry support. Here's how to start collecting that data, what it tells you, and the cross-domain insights you unlock when AI usage meets your git history.
The $120K Blind Spot
Your engineering org is spending real money on AI coding tools. Anthropic API seats, Codex usage, maybe Copilot licenses on top of that. Across a 40-person team, you are probably looking at $80K to $150K per year. And if someone asked you right now how many engineers actually use these tools daily, what they cost per developer, or whether AI-assisted code ships faster, you would not have an answer.
This is not a hypothetical. Talk to any VP of Engineering running a team of 30 or more, and the conversation follows the same arc. “We bought AI tools. Engineers like them. We think things are faster. No, we can’t prove it.” The irony is that two of the most popular AI coding agents, Claude Code and OpenAI Codex, already emit detailed telemetry about every session, every token, every tool call. The data exists. Nobody is collecting it.
The gap between what’s available and what teams actually track is striking. Most orgs have CI/CD dashboards, sprint burndown charts, DORA metrics pipelines. But AI agent usage? It lives in a black box on each developer’s laptop. There is no central view of adoption, cost, or impact. And as AI becomes a larger share of how code gets written, that blind spot becomes harder to ignore.
The Telemetry Your Agents Already Produce
Both Claude Code and OpenAI Codex have native OpenTelemetry support. This is the same open standard used by Datadog, Grafana, Honeycomb, and every other observability platform. The agents emit structured metrics and events over the standard OTLP protocol. They just need somewhere to send them.
Claude Code emits 8 metrics and 5 event types. Every session, every API call, every token consumed, every tool invocation, every code edit decision, every commit and pull request created during a session. It tracks cost per model, input and output tokens separately, cache hit rates, and the split between developer interaction time and CLI processing time.
Codex emits a similar set of signals with its own structure: API request durations as histograms, SSE event details with token breakdowns, tool call counts and latencies, and full trace spans for response processing. It does not track cost directly, but token counts per model are enough to compute it.
The key insight is that this is not sampled data or heuristic guesswork. These are exact counts, straight from the agent runtime. When Claude Code reports 4,200 input tokens on a claude-sonnet-4-6 call that cost $0.03, that is the actual number from the API response. When it reports a tool_result event for an Edit tool that took 45ms and succeeded, that happened. The telemetry is precise, granular, and automatic.
Setting Up Claude Code in Five Minutes
Collecting this data requires no code changes, no SDK integration, and no agent modifications. Claude Code uses standard OpenTelemetry environment variables. Your org admin generates one API key, and each developer adds six lines to their shell profile.
That is the entire setup. Add those lines to ~/.zshrc or ~/.bashrc, open a new terminal, and use Claude Code normally. Telemetry starts flowing on the next session. The developer does not need an account on any analytics platform. Identity is resolved server-side from the email address attached to their Anthropic account.
The API key authenticates the organization, not the individual. One key per org, shared across the entire team. This is important because it means onboarding 50 developers is the same effort as onboarding one: share the snippet in Slack, and you are done.
# Add to ~/.zshrc or ~/.bashrc
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://otel.acticly.com
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer act_key_xxxxx"
Two optional variables control what gets included. OTEL_LOG_USER_PROMPTS=1 sends prompt content (useful for understanding workflow patterns, but off by default for privacy). OTEL_LOG_TOOL_DETAILS=1 includes bash command details and MCP tool parameters. Both are controlled at the org level: even if a developer enables the env var, the server-side privacy settings determine whether the data is actually stored.
Setting Up OpenAI Codex
Codex uses a TOML configuration file instead of environment variables. The setup lives in ~/.codex/config.toml:
[otel]
environment = "production"
log_user_prompt = false
[otel.exporter."otlp-http"]
endpoint = "https://otel.acticly.com/v1/logs"
protocol = "binary"
[otel.exporter."otlp-http".headers]
"Authorization" = "Bearer ${ACTICLY_API_KEY}"
[otel.trace_exporter."otlp-http"]
endpoint = "https://otel.acticly.com/v1/traces"
protocol = "binary"
[otel.trace_exporter."otlp-http".headers]
"Authorization" = "Bearer ${ACTICLY_API_KEY}"
Set the ACTICLY_API_KEY environment variable to the same org key, and Codex starts sending logs, metrics, and traces. Codex is the only major agent that emits full OTel traces with span-level detail, which means you get latency breakdowns (time to first token, inference time, tool execution time) that Claude Code does not yet provide.
Both agents use the same ingestion endpoint. Your team can run Claude Code, Codex, or both, and the data lands in one unified view. The platform detects the agent type automatically from the OTel resource attributes and handles the different schemas transparently.
What Happens to the Data
Once telemetry starts arriving, three things happen on the platform side.
First, identity resolution. The OTel data carries the developer’s email from their AI tool account (say, alice@company.com). The platform matches this against your connected VCS identities. If Alice’s GitHub account uses a different email, an admin can create a manual mapping in the settings page. This link is what ties AI usage to the developer profiles you already see in your VCS analytics.
Second, hourly aggregation. Raw metrics and events are rolled up into daily summaries per developer: total sessions, cost in USD, token consumption by type, lines of code added and removed, tool call counts and failure rates, edit acceptance rates, and active time split between developer interaction and CLI processing. These rollups are what power the dashboards and the chat assistant.
Third, and this is where it gets interesting: VCS correlation. When Claude Code creates a commit during a session, it records the commit SHA in the telemetry. The platform matches that SHA against your synced git history and tags the commit as AI-assisted. This works automatically, no labeling convention required. And once commits are tagged, the PR they belong to inherits the tag. Suddenly you know, for every pull request, whether AI was involved.
The Questions You Can Finally Answer
With AI telemetry flowing alongside your existing GitHub and Jira data, the platform can answer questions that no standalone tool can touch. The difference is the cross-domain join. GitHub knows about PRs. Your AI tool knows about tokens. Only a platform that has both can tell you the cost per pull request.
These are not theoretical queries. They work through the same conversational chat interface used for all other analytics. Ask “how much are we spending on AI this month, broken down by team?” and you get a table with cost per team, cost per developer, model breakdown, and a daily trend. Ask “are AI-assisted PRs merging faster than regular ones?” and you get a comparison of cycle times with statistical context.
The five chat tools that handle AI telemetry queries are designed around the questions engineering leaders actually ask. Usage summaries for adoption tracking. Cost breakdowns for budget planning. AI-assisted commit ratios for impact measurement. Tool usage patterns for workflow optimization. And impact analysis that correlates AI adoption with delivery metrics like sprint velocity and PR throughput.
The metric registration system also means every AI data point is available in the custom dashboard builder. Want a chart showing AI cost trend alongside sprint velocity for the backend team? That is one prompt.
The Adoption Curve Is Steeper Than You Think
Teams that start collecting telemetry consistently see the same pattern. Week one, the data trickles in as early adopters configure their environments. By week two, word spreads through the team and adoption jumps. Within a month, you have a comprehensive picture of AI usage across the org.
The compounding effect is what makes this worth setting up sooner rather than later. Historical data matters for trend analysis, before-and-after comparisons, and building the ROI case that leadership will eventually ask for. The team that starts collecting in March has six months of data when the annual planning review comes around in September. The team that starts in September has nothing.
There is also a feedback loop. Once developers can see their own AI usage stats, they tend to experiment more deliberately. An engineer who sees that 40% of their Claude Code edit suggestions get rejected might adjust their prompting approach. A team lead who notices one engineer spending 3x more on tokens than the team average can have a targeted conversation about workflow efficiency.
Privacy Without Compromise
A reasonable concern with any developer telemetry is privacy. The platform handles this at multiple levels.
By default, prompt content is never stored. The system records that a prompt happened, how long it was, and what tools were invoked in response, but not what the developer actually typed. Bash command contents and MCP tool parameters are stripped the same way. Organizations can opt in to storing prompts and tool details if they want workflow-level analysis, but the default is privacy-first.
Visibility controls determine who sees what. Every developer can see their own data. Team leads see their team’s data, either as aggregates or individual breakdowns depending on the org setting. Org admins see everything. This mirrors how VCS analytics visibility already works, so there is no new mental model to learn.
The ingestion pipeline itself is stateless and holds no data. It validates the API key, strips any sensitive fields based on org settings, and forwards the cleaned records for storage. Developer data never passes through a system that does not enforce the org’s privacy policy.
What if you could just ask:
"How much are we spending on AI coding tools this month, and which team has the best cost-per-PR ratio?"
...and get the answer in seconds, pulled from your connected AI telemetry and GitHub data.
The teams that get the most out of AI tooling are the ones that measure it with the same rigor they apply to deployment frequency or sprint velocity. They do not rely on vendor marketing claims or gut feelings about productivity. They collect the data, build the dashboards, and let the numbers guide their decisions on tooling, training, and team investment.
The telemetry is already there. Claude Code and Codex are generating it on every session, on every developer’s machine. The only question is whether you are collecting it.
The setup described in this post takes about five minutes per developer and requires no code changes. If you’re curious what your team’s AI usage data actually looks like, the signals are already flowing from every coding session. You just need to start listening.