Agent cost includes the calls you never wrote

A run's bill includes provider calls your own code never issued. A safety scan in front of the model call, an embedding written into an agent's memory, a retry inside a client, a rerank on a retrieval result — each is a billed request, each belongs to the run that triggered it, and none of them appears at a call site you wrote. If your cost per run is assembled from the places your code calls a model, the overhead calls are where it disagrees with the invoice.

A safety check is a billed call

LiteLLM spent this week repairing how it sends oversized requests to Bedrock's ApplyGuardrail API, and the defect list in the pull request reads as a catalogue of ways a defensive layer costs money. The line that matters here:

Chunking split requests AWS accepted, tripling billed calls and latency

The scan is not the model call. It is the check placed in front of it, and a splitting rule that fired when it did not need to turned one billed unit into three. No prompt got longer and no agent changed behaviour, so the token counts read off the completion response are identical before and after the bug. The same list notes that the setting meant to bound this was "parsed, shown in the UI, then ignored" — a configured limit on an overhead call is even easier to leave unenforced than one on the call you were watching. LiteLLM is MIT-licensed and free, and this is a maintainer team enumerating its own cost defects in public, which is more than most projects do.

Memory bills in a different shape

CrewAI added a Cosmos DB memory backend with vector, full-text and hybrid search. A vector store has to be filled before it can be queried, and both sides of that are embedding requests to a provider. Indexing a corpus is thousands of small calls with their own price table, priced nothing like the completions in the same run — and a metric built on completion tokens will not show them at all.

The reverse case landed the same week: CrewAI also added a self-hosted sandbox tool that runs agent-authored code on container infrastructure you already operate, with "no API key, no per-execution cost". That cost did not disappear, it moved onto compute you pay for by the hour. Same run, different ledger — which is worth knowing before you compare two runs on their provider spend alone.

The calls are made by code you did not write

According to Capsera's July 2026 scan of 133 public Python agent repositories, 82 of the 133 had no directly scannable LLM calls: most agent repositories call providers through a framework rather than directly. That was a finding about what a static scanner can see, but the same property decides what a runtime wrapper can see. If attribution comes from wrapping the lines where you call a model, then every request a library issues on your behalf sits outside it — including the ones a framework makes to keep a context under the model's limit, which are among the largest.

This is the part that turns into an argument with finance. Spend that carries no owner has to land somewhere, and how big that unattributed remainder is decides whether anyone trusts the per-team numbers next to it. That is a property of cost attribution in general: coverage first, then decomposition.

Identity has to travel with the call

An overhead call that is captured but anonymous is the same defect one layer down. A LiteLLM fix this week promotes caller metadata into the fields its logging callbacks read, because on one endpoint the caller's metadata never reached the logging callbacks as trace-level fields — the resulting trace arrived with its session id, user id and metadata all null, and calls sharing a session collapsed into one record. The requests were seen. The cost was computable. What went missing was the answer to whose spend it was. Langfuse is free and open source and its cost calculation is careful work; this class of bug lives in the plumbing between a call and the identity it should carry, which is exactly where tracking tokens stops being the same as tracking cost.

Four checks on your own traffic

1. Count requests per run, then count the call sites in your own code. If the ratio is above one, the remainder is overhead. Name what it is before you decide whether it is waste.
2. Ask where your attribution is produced. A wrapper at your call sites can only attribute calls you make; capture inside the client attributes calls the library makes too. The difference shows up as coverage, not as an error.
3. List every billed surface in the run that is not a completion. Embeddings, guardrail and moderation services, rerankers, transcription. Each has its own unit and its own price table, and a dashboard summing completion tokens is silent about all of them.
4. Reconcile once against the provider invoice. One month, one number, per provider. The gap between your total and theirs is the size of what you are not attributing.

Where Capsera sits

capsera.init() patches the provider clients in your process, so capture does not depend on who wrote the line that made the request: a call issued from inside a library, several frames below your code, is recorded like any other. Attribution comes from a context variable rather than the call site, so a request made by framework code inside a function decorated with @capsera.agent is attributed to that agent, and a sub-agent's calls inherit the chain above it.

Two limits are worth stating plainly. Capture covers the surfaces we patch — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so an overhead call to a separate service, such as a guardrail API, is not among them and has to be counted on its own. And embedding calls are recorded and costed but bypass budget enforcement, so a blocking per-agent budget will not stop an indexing run; guard that one in your own code. Capsera stores hashes and token counts, never prompt or response content, which is why the answer to "what was in that call" is always a shape and never a payload.