Claude Code Monitoring: How to Track Coding Agents
TL;DR
- Coding agents authenticate directly to a model provider by default, so a team running Claude Code and Cursor has no single place where usage, cost, or prompts can be read.
- Routing coding agents through an AI gateway makes every request observable without installing anything on a developer's machine: Claude Code is configured with two environment variables, Cursor with a base-URL override.
- Bifrost captures input and output messages, tool calls, token counts, cost, and latency for every agent request, and exposes
bifrost_cost_totalin USD plus per-model token counters at a Prometheus/metricsendpoint. - The
x-bf-dim-*header injects custom labels at runtime, so metrics can be sliced by developer, repository, or cost center without changing the agent. - The 2025 Stack Overflow Developer Survey found 84% of respondents are using or planning to use AI tools in their development process, up from 76% the year before.
Coding agents such as Claude Code and Cursor send requests straight from a developer's laptop to a model provider, which means a platform team gets a monthly invoice and no per-user breakdown behind it. Claude Code monitoring is the practice of capturing those requests centrally, with cost, token counts, model choice, and prompt content attributable to a person and a project. Bifrost, the open-source AI gateway built in Go by Maxim AI, sits between the agents and the providers so that record exists without an agent on every machine. This post covers what to capture, the three architectures teams use to capture it, and how to configure Claude Code and Cursor to route through a gateway.
Why Coding Agents Are Hard to Track
Coding agents are difficult to track because each one holds its own credential and talks directly to a provider. There is no shared control point, so usage data lives in as many places as there are tools. Consolidating it is an infrastructure problem, not a reporting one.
Four properties make ad-hoc tracking break down:
- Credentials are per-developer. An engineer logs into Claude Code with their own account or key, so provider-side billing aggregates at the organization level with no attribution below it.
- Tools multiply. A team running Claude Code in the terminal, Cursor in the IDE, and a CLI agent in CI has three separate usage surfaces with three different export formats.
- Prompt content never leaves the client. Provider dashboards report token counts, not what was sent, so a security review of what source code went to a model has nothing to read.
- Model choice is invisible. Agents switch models per feature and per task, and the cost difference between them is large enough that aggregate spend tells you almost nothing about cause.
The 2025 Stack Overflow Developer Survey found that 84% of respondents are using or planning to use AI tools in their development process, up from 76% the previous year. That shifts coding agents from an individual preference to infrastructure needing the same treatment as any other production dependency. The broader control problem is covered in this guide to governing AI coding agents at scale across Claude Code, Cursor, and Codex.
What Claude Code Monitoring Should Capture
Claude Code monitoring should capture five things per request: which model was called, how many input and output tokens it consumed, what the request cost, how long it took, and which person or project it belongs to. Anything less answers usage questions but not cost-allocation or security questions.
A useful record has three layers, and the first is the one usually built alone:
| Layer | What it answers | Typical source |
|---|---|---|
| Metrics | How much is being spent, by whom, on which models, over time | Counters and histograms scraped into Prometheus or a similar store |
| Traces | Where the time went in a multi-step agent run, and which tools it called | OpenTelemetry spans exported to an existing collector |
| Logs | What was actually sent and returned, including tool calls and their arguments | A request log store with searchable metadata |
Metrics alone will tell a finance team the number. Traces and logs are what let an engineer explain why a single refactoring session cost forty dollars, or let a security reviewer confirm which repository contents were sent to a provider. The Bifrost AI gateway produces all three from the same request path, and its built-in observability captures complete conversation history, model parameters, output messages, tool calls, function results, latency, and token usage without any change to the agent.
Three Ways to Monitor Coding Agents
There are three practical architectures for monitoring coding agents: read the provider's own analytics, install a local telemetry exporter on each machine, or route every agent through a gateway. They differ in coverage, effort, and what they can see.
| Approach | Coverage | Attribution | Prompt visibility | Setup cost |
|---|---|---|---|---|
| Provider dashboards | One vendor only | Organization or seat level | None | None |
| Local telemetry exporters | Per tool, per machine | Per machine | Varies by tool | High: every developer, every tool |
| AI gateway | Every tool that speaks OpenAI, Anthropic, or Gemini APIs | Per virtual key: person, team, or project | Full request and response | Low: two environment variables, or a base-URL override in the IDE |
Anthropic publishes native Claude Code monitoring and analytics for teams on its own plans, and that is the right starting point for a single-vendor shop. The limitation is structural rather than a gap in the product: it covers Claude Code, so a team also running Cursor against OpenAI models still has two disconnected views and no way to compare them on one axis.
The gateway approach is the one that generalizes, because it moves the observation point from the tool to the network path every tool already uses. Teams weighing that decision in more detail can work through choosing an AI gateway for Claude Code.
Claude Code Analytics Versus Gateway-Level Data
Claude Code analytics reports usage for Claude Code against Anthropic models. Gateway-level data reports usage for every agent against every provider, keyed to whatever identity the gateway issued. The two are complementary, and the second is what a multi-tool team needs for allocation.
The practical difference shows up in three questions a platform team is usually asked:
- "Which team spent the most on coding agents last month?" A gateway answers this from budget hierarchy; a per-tool dashboard answers it only for that tool.
- "Did anyone paste customer data into a prompt?" A gateway holds the request bodies; provider dashboards do not expose them.
- "Would switching the Cursor tab-completion model to a cheaper one save anything?" This needs per-feature, per-model token counts across tools in one place.
Bifrost as a central control point answers all three, because usage is recorded against a virtual key rather than a provider account. Virtual keys carry independent budgets, token and request rate limits, and provider access rules, and they roll up through a hierarchy of customer, team, and virtual key, so budgets and limits can be set at whichever level the organization actually plans against.
How to Route Claude Code Through Bifrost
Routing Claude Code through Bifrost takes two environment variables and no plugin. Set ANTHROPIC_BASE_URL to the Bifrost endpoint and ANTHROPIC_AUTH_TOKEN to a Bifrost virtual key, and every request the agent makes is logged, budgeted, and rate-limited before it reaches a provider.
Using ANTHROPIC_AUTH_TOKEN is the configuration to prefer. Claude Code sends that token in the Authorization: Bearer header, the open-source Bifrost gateway recognizes it as a virtual key, and no Anthropic account login is required on the developer's machine, because authentication and billing both run through the key. The alternative, passing x-bf-vk via ANTHROPIC_CUSTOM_HEADERS, works but leaves Claude Code falling back to standard Anthropic account authentication for the Authorization header, so the login is still needed.
Two configuration details are worth handling up front on the Claude Code integration:
- Remove the
modelfield fromsettings.json. It overrides environment-based model selection and produces behavior that looks like caching. - Widen the allowed headers. Since Claude Code 2.1.212, Anthropic enforces
anthropic-versionand severalx-stainless-*headers, so add them under Settings > Client Settings or set the allow-list to .
Once traffic is flowing, the same virtual key can carry MCP tool filtering, a deny-by-default allow-list of which MCP clients and individual tools the agent may call. That side of the setup is covered in this practical guide to using an MCP gateway with Claude Code, and the terminal workflow in how to use the Bifrost CLI with coding agents.
Cursor Analytics From the Same Gateway
Cursor analytics through a gateway works the same way as Claude Code, using Cursor's OpenAI-compatible settings. Override the OpenAI base URL to point at the Bifrost endpoint, enter a virtual key in the OpenAI API Key field, and Cursor's requests join the same log store and the same budget hierarchy as the terminal agents.
Cursor needs a publicly reachable Bifrost URL, since the IDE calls the endpoint directly. Models are added in provider/model-name form, which is what makes cross-provider tracking possible: anthropic/claude-sonnet-4-5-20250929, openai/gpt-5, and groq/llama-3.3-70b-versatile all resolve through one endpoint and appear in one dataset.
The per-feature model assignment is where the cost data becomes actionable. Cursor assigns models separately to Chat, Agent, Inline Edit, and Tab Completion, and tab completion typically runs at far higher request volume than the rest. Routing a fast model to completion and a stronger model to Agent mode is a straightforward change once the Cursor configuration is in place, and the gateway data is what shows whether it worked. For a wider comparison of the two tools and running them side by side, see Claude Code vs Cursor.
Metrics, Traces, and Claude Code OpenTelemetry Export
Bifrost exposes coding agent activity through three export paths: a Prometheus /metrics endpoint, OpenTelemetry traces over OTLP, and a queryable request log store. Teams that already run an observability stack do not need a new dashboard, because the data lands in the collector they use for everything else.
The telemetry plugin publishes counters and histograms that map directly onto the questions above:
bifrost_cost_total, a counter of upstream provider cost in USDbifrost_input_tokens_totalandbifrost_output_tokens_total, labeled by provider and modelbifrost_upstream_latency_seconds, a latency histogram per provider and modelbifrost_cache_hits_total, split by direct and semantic cache typebifrost_request_retries, observed once per request across buckets of 0, 1, 2, 3, 5, and 10
Attribution comes from custom labels. Declare the label names once in Bifrost's prometheus_labels config, and the x-bf-dim-* header then injects their values at runtime, so a wrapper script or CI job can tag requests with a developer ID, a repository name, or a cost center without any change to the agent.
Traces follow the same path. Bifrost's recommended trace type, genai_extension, follows OpenTelemetry GenAI semantic conventions, so an agent run correlates with the rest of an application trace instead of sitting in a separate tool. Setting group_traces_by_session groups a long agent session into one readable trace, and Bifrost recognizes the session headers Claude Code, Codex CLI, and OpenCode already send, falling back to x-bf-session-id when none is present. Where prompt content must not leave the gateway, disable_content_logging drops message content from exported spans while keeping the structural record. The full configuration is on the OpenTelemetry integration page, and the metrics side on the Prometheus page.
Governing CLI Coding Agents, Not Just Watching Them
Monitoring answers what happened; governance decides what is allowed to happen. Once coding agents route through a gateway, the same virtual key that produces the usage record can also cap spend, restrict which models are reachable, and limit which tools an agent may call.
Three controls do most of the work for CLI coding agents:
- Budgets with reset periods. A virtual key carries a maximum spend and a reset duration, and budgets nest through customer, team, and key, so a per-developer cap and a per-team cap can both apply.
- Provider and model allow-lists. A key can be restricted to approved models, which prevents an expensive model from being selected by default in an IDE setting nobody reviewed.
- Rate limits. Token and request limits per period bound the damage from a runaway agent loop.
For regulated environments, Bifrost Enterprise adds role-based access control, data access control that scopes which logs a given role can read, and in-VPC deployment so agent traffic and its record stay inside the organization's own network.
The security-specific treatment of these controls, including what a coding agent should and should not be permitted to reach, is in this guide to AI coding agent security for Cursor, Claude Code, and Copilot.
Choosing Tools to Monitor Coding Agents
The right tool for monitoring coding agents depends on how many tools and providers are in play. A single-vendor team can rely on native analytics. A team running several agents against several providers needs a shared control point, and the evaluation should focus on coverage rather than dashboard features.
Five criteria separate options that will still work in a year from options that will not:
| Criterion | Why it matters |
|---|---|
| Protocol coverage | Anthropic, OpenAI, and Gemini API compatibility determines how many agents can be pointed at it without modification |
| Attribution model | Per-key identity is what makes cost allocation possible; seat-level billing is not attribution |
| Export destinations | Prometheus and OTLP mean the data joins an existing stack instead of creating a new silo |
| Latency overhead | Anything in the path of an interactive agent has to be measured, not assumed |
| Enforcement, not just reporting | Budgets and allow-lists prevent the overspend that reporting would only describe afterward |
On the fourth criterion, Bifrost adds 11 microseconds of overhead per request at 5,000 requests per second on a 4 vCPU instance in published benchmarks, with logging and telemetry collection running asynchronously outside the request path. The open-source build handles roughly 3,000 to 5,000 requests per second on a single instance. Cost-focused comparisons of gateway options are collected in this roundup of LLM gateways for monitoring Claude Code token spend.
Frequently Asked Questions
How can I monitor my Claude Code usage?
Set ANTHROPIC_BASE_URL to a gateway endpoint and ANTHROPIC_AUTH_TOKEN to a virtual key issued by that gateway. Every request then carries a token count, a cost figure, and an identity. Anthropic also publishes native usage monitoring for Claude Code, which covers Anthropic models only; a gateway covers every provider the agent can reach.
How can I monitor Claude Code agents across a team?
Issue each developer or team a separate Bifrost virtual key and configure their agents to use it. Usage, cost, and prompt content are then recorded per key rather than per organization, and budgets set at the key, team, or customer level apply automatically. No software needs to be installed on individual machines.
What are coding agents?
Coding agents are AI tools that read a codebase, plan changes, and execute them through tool calls rather than only suggesting completions. Claude Code runs in the terminal, Cursor runs as an IDE, and both call model providers directly and invoke tools such as file edits, shell commands, and MCP servers during a single task.
Can I track coding agent cost per developer?
Yes. Issue one virtual key per developer, and cost accrues against that key with an independent budget and reset period. For finer breakdowns, the x-bf-dim-* header adds custom Prometheus labels at request time, so the same traffic can also be sliced by repository, branch, or cost center.
Start Tracking Your Coding Agents
Claude Code monitoring stops being a reporting exercise once the agents route through a control point that sees every request. Bifrost gives coding agents a single endpoint, a per-key identity, budgets that apply before spend happens, and metrics, traces, and logs that land in the observability stack a team already runs, at 11 microseconds of overhead per request.
To see how Bifrost fits an existing Claude Code and Cursor rollout, book a demo with the Bifrost team, or start from the CLI agents documentation and point one agent at a local instance first.