Comparing LLM Cost Tracking Tools on Team-Level and Model-Level Spend Granularity

Most LLM cost tracking tools answer a question nobody in production is actually asking: what did we spend last month? The question that matters when a bill spikes is which team, which model, which project, and which key drove that spend, right now. Provider billing is built for the first question, not the second. A dashboard from OpenAI or Anthropic breaks spend down by project, model, or API key at most, never down to the individual feature, customer, or request that caused it. When teams call multiple providers directly, each one holds its own key and produces its own isolated fragment of billing data, with no shared place to add the numbers up or break them apart by team. So when the bill spikes, the investigation to find the cause takes days, not minutes, and by the time anyone has an answer, the money is already spent. The tool that matters is the one that prevents that investigation from ever needing to happen.

The four attribution dimensions that separate adequate from useful

Real cost attribution rests on four dimensions: team, model, project (or feature), and API key. All four need to be visible per-request, in real time, not reconstructed weeks later from an invoice. Per-request granularity means knowing the cost of every single API call, with the team and feature that triggered it attached at the moment the call happens, not inferred afterward from logs. Team attribution means spend gets allocated to the group that actually incurred it, so an engineering manager or a finance lead can see their own footprint without parsing the entire company bill. Model-level attribution means you know which model consumed which tokens, and once you run more than one model, you need this to compare cost against task type. With key-level attribution, virtual keys get scoped to a specific team or project, so you can find a leaked or runaway key and shut it off without touching anyone else's service. And all of it needs to happen in real time: a report that lands after the billing cycle closes can explain an overspend, but it can't stop one. These four dimensions, held together, are the bar the rest of this comparison measures every tool against.

The architectural split that determines what granularity is even possible

Two architectures define this market, and which one a tool uses sets a hard ceiling on what it can ever report. Gateway-layer tools sit directly in the request path. Every call passes through them, so they can tag spend the instant it happens, check a budget before the provider is ever reached, and reject a request from a team that has run out of allocation. Overspend isn't flagged after the fact with this kind of architecture, it's structurally prevented. A gateway that only meters and never blocks defeats its own purpose: the dashboard still shows the overspend only after the money is gone.

Observability and FinOps tools work differently. They read from billing APIs or capture calls through SDK instrumentation after the request has already gone out. That makes them faster to deploy and adds no extra latency to any request, but it also means they cannot intercept a call or enforce a budget before the provider gets paid. The trade-off isn't only enforcement versus reporting, either. A gateway adds a hop in the request path that has to be built, tested, and maintained. A billing-API reader stays outside the request path. Neither approach is wrong on its own terms. The right one depends on whether a team needs to prevent overspend or simply needs to see it clearly, and whether the team is ready to route production traffic through a gateway to get there.

LiteLLM: strong key-level attribution in open source, governance gated behind enterprise

LiteLLM is an open-source Python proxy, and it puts you behind a single OpenAI-compatible API across more than 140 model providers. Because it sits directly in the request path, enforcement is structurally possible, not bolted on. The open-source tier already includes virtual keys, budgets, rate limits, and spend tracking by key, user, team, and organization, which covers three of the four attribution dimensions out of the box.

Governance is where the free tier stops. SSO and SCIM, audit logs, organization and team admins, secret managers, IP allowlists, per-team logging, and multi-region support all sit behind LiteLLM's enterprise license. Running LiteLLM in production also means running PostgreSQL and Redis alongside the proxy, infrastructure the team has to provision, scale, and patch itself. In March 2026, a supply-chain incident gave self-hosted deployments a concrete reason to keep up patching discipline. None of this makes LiteLLM a weak option. It is the strongest free-tier enforcement story in this comparison. It just comes with real operational weight attached.

Langfuse: request-level tracing gives strong attribution, but it observes rather than enforces

Langfuse is an open-source LLM observability platform where cost tracking lives in the tracing layer. Every LLM call becomes a trace, and that trace carries token counts, cost, model, latency, and user attribution with it. Attribution at the level of individual requests, users, and sessions is genuinely strong, and model-level and user-level granularity hold up well. Team-level and key-level attribution depend on how an application tags its own calls, because Langfuse doesn't enforce a schema for that.

The ceiling is enforcement. Langfuse can alert when a budget threshold is crossed, but it does not block the request that crosses it. ClickHouse acquired Langfuse in January 2026, but the core features stay under an open-source license, so teams weighing long-term roadmap stability against adoption today can factor that in. Langfuse can be self-hosted or run as a cloud service, and that flexibility survives the acquisition.

Datadog LLM Observability: deep enterprise APM integration, model and tag attribution, enforcement not documented

Datadog estimates cost per LLM call broken down by model and token type, and if you want custom tags such as prompt version or team, you apply them manually through the cost_tags parameter. For a team already instrumented in Datadog, that's meaningful attribution without standing up a separate tool. Auto-instrumented tracing covers OpenAI, Anthropic, Gemini, Vertex AI, and AWS Bedrock, while automatic cost estimation extends to OpenAI, Anthropic, Gemini, Hugging Face, and OpenRouter.

The natural fit here is obvious: teams running Datadog for infrastructure observability already can extend existing dashboards to LLM spend with no new platform to adopt. What isn't documented is budget enforcement. Datadog's published cost-control mechanisms cover metric monitors on cost metrics, soft and hard quota alerts, and trace sampling, but none of them can block a request before it goes to the provider. That's consistent with the architectural ceiling described earlier: Datadog is an observability tool, and observability tools report, they don't intercept.

CloudZero and Vantage: FinOps-layer visibility that catches spend Datadog and gateway tools miss

CloudZero and Vantage solve a problem that sits one layer up from both gateways and request-tracing tools: connecting AI API spend to the cloud cost allocation methods finance teams already use. CloudZero frames itself as a financial control plane for AI economics, and that positioning speaks to a finance audience more than to an engineering team looking to enforce limits in code.

Vantage connects directly to the OpenAI and Anthropic billing APIs in addition to major cloud providers, so when a team calls model APIs directly rather than through a cloud provider's managed service, Vantage captures that spend where cloud-native integrations would miss it. Vantage attributes to project, workspace, key, model, and service tier, which is solid for FinOps reporting, though it offers budget alerts only, with no inline enforcement. The role both tools play is structural rather than competitive with gateways: a gateway tags and attributes LLM spend per request, but it doesn't reconcile that spend with the rest of the cloud bill. FinOps tools fill that specific gap and pair with gateway attribution.

TokenShift and PointFive OS: a distinct granularity problem for AI developer tooling spend

AI coding tool spend is its own cost category, covering tools like Claude Code, Cursor, GitHub Copilot, Codex, Devin Desktop, and other coding agents. Neither LLM gateways nor FinOps billing-API tools capture this spend, because coding assistants authenticate and bill through their own paths rather than routing through an application's LLM gateway. TokenShift, from PointFive OS, tracks this spend by developer, team, model, and session, which maps cleanly onto the dimensions that matter for engineering leadership watching a developer tooling budget.

This is a narrow tool for a narrow problem: for organizations where AI coding assistants are a fast-growing line item, this spend is invisible to every other tool covered here. TokenShift completes the landscape.

How the tools compare on the four granularity dimensions

Measured against team, model, project, and key attribution plus real-time enforcement, no tool in this comparison covers all four dimensions and enforces budgets without some kind of gate, whether that gate is architectural or a line on an enterprise price sheet. LiteLLM attributes spend to key, user, team, and organization, and it enforces budgets in its open-source tier, making it the strongest enforcement option available for free, but governance features like SSO, audit logs, and per-team logging require an enterprise license, and self-hosting adds real operational weight. Langfuse attributes to model, user, and session with strong tracing-level visibility, but it only alerts, it never blocks, and the ClickHouse acquisition is a variable worth tracking on its roadmap. Datadog attributes to model, prompt version, token type, and custom tags including team, and fits best for teams already living in the Datadog ecosystem, though enforcement isn't documented anywhere in its published cost controls. Vantage attributes to project, workspace, key, and model, catches direct-API spend that cloud-native tools miss, and offers budget alerts without inline enforcement, oriented more toward finance than engineering. CloudZero carries the financial control plane framing and works best paired with a gateway's attribution to reconcile AI spend with the broader cloud bill. TokenShift attributes to developer, team, model, and session specifically for coding-tool spend, covering a category every other tool in this comparison misses. Across all of them, the same pattern holds: observability and FinOps tools deploy fast and add no latency, but none of them can block an overspend before it happens, while gateway tools can enforce in real time but require a hop in the request path and, for full governance, either an enterprise license or a managed service.

What real-time enforcement requires

Visibility into spend after it's already happened is useful, but it can't prevent anything. A team that needs to actually stop overspend, rather than just explain it afterward, needs a gateway sitting in the request path that checks budgets before the provider is ever called. The failure mode of reporting-only tools is consistent: the dashboard shows the spike after the money is gone, which helps with a post-mortem but does nothing to stop the next one.

Inline enforcement means a team that has used up its monthly allocation gets rejected at the gateway, before the provider bills a single token. That's prevention by design, not detection after the fact. The moment a team actually needs this shows up predictably: a second model requires routing logic, a second team requires per-team budgets and attribution, a second provider requires fallback handling, and a second compliance question requires centralized keys and audit logs. If a team puts off the gateway decision, it tends to pay for that by rebuilding these controls, inconsistently, across every service that calls a model directly. There's an operational payoff too: a gateway that handles fallback routing turns a provider outage into a brief latency blip instead of a failed application, since a chain of providers can absorb requests that would otherwise return errors. When teams manage provider keys independently, each account produces its own billing fragment, and a cost spike becomes a days-long forensic investigation; a unified gateway that routes all inference through a single attribution layer can answer which team, model, project, and key drove the spend within minutes.

Where Concentrate fits

Concentrate is a managed gateway, and it delivers the real-time enforcement and four-dimension attribution that this comparison shows only gateway-layer tools can provide, without the operational cost of running PostgreSQL, Redis, and patching cycles that a self-hosted option like LiteLLM demands. It connects you to more than 130 LLM models through a single unified API, keeping provider complexity in the infrastructure layer. Real-time spend visibility is broken out by organization, team, project, key, model, and provider, which answers the team, model, project, and key attribution this article has used as its bar throughout.

Real-time per-request attribution across team, model, project, and key depends on every call being tagged at the moment it enters the system, before the provider call goes out, and Concentrate implements this by sitting in the request path itself, so spend is tagged and enforced before a bill is ever incurred. PII redaction, role-based access control, and baseline audit logs are available to teams of any size without an enterprise tier, but extended logging and longer audit retention need an enterprise contract. There are no per-token platform fees stacked on top of provider pricing, so teams pay provider rates for tokens. If a fast-growing team's AI usage outpaces its internal governance, it can use managed controls like team workspaces, SSO, and RBAC without rebuilding the stack from scratch. Gateway-layer tools in this position are set up to prevent overspend structurally: the budget check happens in the request path, before the provider call goes out, so a team that has used its allocation gets blocked rather than billed and flagged after the fact, which is the exact capability that observability and FinOps tools, reading from billing APIs after the call has already happened, cannot offer.

Choosing a tool by team need

The right tool follows directly from the question a team needs answered. A team that needs to observe spend that has already happened and reconcile it against the cloud bill is better served by CloudZero or Vantage, since neither changes the request path and both produce finance-compatible reporting. A team already instrumented in Datadog and looking for tracing-level attribution tied to its existing observability setup gets the lowest-friction path from Datadog LLM Observability, with minimal new tooling to adopt. A team that wants open-source, self-hosted enforcement with team and key attribution, and is willing to take on patching discipline and infrastructure ownership, finds the strongest free-tier enforcement in LiteLLM, with governance features gated behind its enterprise license. If your team wants request-level tracing and user-level attribution but doesn't need inline enforcement, Langfuse gives you strong observability and an open-source core, with alerts in place of blocks. If your team is specifically trying to track AI developer tooling spend across coding assistants, TokenShift gives you a purpose-built option, covering a category none of the others touch. And a team that needs real-time enforcement across team, model, project, and key, without taking on the overhead of running its own gateway infrastructure, finds that covered by a managed gateway such as Concentrate.

None of these choices are mutually exclusive. A FinOps tool and a gateway tool solve adjacent problems and pair well together: the gateway attributes and enforces spend per request, and the FinOps tool reconciles that attribution against the broader cloud bill for finance. The teams most exposed to risk are the ones who delay the gateway decision past the point where it still fits easily, past a second provider, a second team, a second compliance question. Governance retrofitted under pressure, after the spend has already scattered across a dozen individually billed services, costs more in engineering time than it would have cost to build in from the second team onward.