Agent Pulse vs LiteLLM spend tracking
LiteLLM's AI Gateway, often called the LiteLLM proxy, tracks spend and enforces budgets of its own. Agent Pulse can also record through that proxy. This page separates the two: what the proxy does by itself, what Agent Pulse adds when it records through the proxy, and when each is enough.
Everything said here about LiteLLM is from its own documentation, linked beside each statement and listed at the end, as reviewed on 23 October 2026. Where this page interprets, it says so.
What LiteLLM's gateway does by itself
LiteLLM describes its AI Gateway as a self-hosted server that gives applications one OpenAI-compatible endpoint for over a hundred providers (AI Gateway). Its own spend tracking and budgets work like this:
- Virtual keys. Each user, team and project can get a virtual key, and each key has its models, budgets and rate limits (AI Gateway).
- Spend tracking. The gateway records the cost of each request, priced from its model cost map, and tracks spend for keys, users and teams, for end users passed as the request's
user, and by tag. Spend is kept in its own database, which, with virtual keys, has to be set up first (spend tracking). - Budgets. A budget can be set on a key, an internal user, a team, a team member or an end user, with a duration after which it resets. Over its budget, a request fails with an error (budgets).
- Reports. Spend can be read from endpoints such as
/global/spend/report(spend tracking). - Logging. Logs and metrics can be sent on to other tools (AI Gateway).
For traffic that all goes through the gateway, that covers a lot: who spent what, by key, team and end user, with limits that refuse requests.
What Agent Pulse adds through the proxy
Agent Pulse records through LiteLLM with one line in the proxy's config, and every model and service behind the proxy is recorded with no change to the services (LiteLLM proxy guide). It is a callback in your proxy, not a second proxy.
- Who each call is for. Services pass LiteLLM's
userfield and Agent Pulse keys in the request'smetadata: the request, the customer, a project inside the customer, the session and the part of your product (LiteLLM proxy guide). - Budgets checked before forwarding. The proxy asks Agent Pulse before forwarding each call. A stopped call gets a
403, marked not to be retried, and a budget set to downgrade sends the call to its cheaper model from the same provider instead (LiteLLM proxy guide). - The LiteLLM SDK. A service using the SDK, not the proxy, registers the callback once. The SDK has no hook that can stop a call, so a budget stops one only when the service asks first (LiteLLM proxy guide).
| LiteLLM gateway on its own | Agent Pulse, recording through the gateway | |
|---|---|---|
| Where spend is kept | The gateway's own database (spend tracking) | Agent Pulse, one record per call, never changed once written beyond the billed figure added later (what is recorded) |
| Spend broken down by | Key, user, team, end user and tag (spend tracking) | Customer, user, request, project, session, agent, model and the part of your product (LiteLLM proxy guide) |
| How cost is worked out | Each request priced from LiteLLM's model cost map (spend tracking) | Priced on the server from token counts, at the rate in force when the call was made (how cost is calculated) |
| Budgets on | Keys, internal users, teams, team members and end users (budgets) | The organisation, an agent, users or workspaces, which can be divided among workspaces (budgets) |
| At the limit | The request fails with an error (budgets) | A 403 not to be retried, or a cheaper model from the same provider; or a warning only (LiteLLM proxy guide) |
| Calls outside the gateway | Not seen by the gateway (interpretation: it records what passes through it) | Recorded from your code and frameworks too (LLM cost tracking) |
What the table leaves out
- They run in the same proxy. Agent Pulse is a callback added to the proxy you already run, so LiteLLM's own spend tracking and budgets stay LiteLLM's to configure. Where both set limits, which one refuses a call first is something to test in your setup rather than assume.
- Spend outside the proxy. A gateway sees what is sent through it. Agent Pulse also records from model clients, agent frameworks and OpenTelemetry, so spend from services that do not use the proxy appears beside the proxy's (LLM cost tracking).
- More than a total per key. Agent Pulse can open one request and show every call in it, keep spend on failed calls apart (find what is failing), price an agent's own calls against cheaper models (compare cheaper models), and check your Google bill against what was recorded (check your bill).
- No content. Agent Pulse records counts, identifiers and timings from the proxy, never prompts, responses, tool arguments or tool results (what is recorded).
Which should you choose?
LiteLLM's own spend tracking is enough when every model call goes through the gateway, you can run its database, and budgets on keys, teams and end users answer your questions.
Add Agent Pulse when spend has to be read by customer and request, including calls that never pass through the proxy; when you want budgets that can downgrade a call or only warn, beside ones that stop it; or when you want failure spend, cheaper-model estimates and a bill check from the same records.
This is an interpretation of what each documents, not a measurement. To see what Agent Pulse would show for your own code before connecting anything, assess your codebase. What a meter should record about each call is on AI agent metering.
Sources
LiteLLM's documentation, reviewed on 23 October 2026: