The Model Call Was Logged. Its Cost Was Blank.
A logged model call can still have an unknown cost. Route labels, token counts, fallback calls, and unpriced requests make the gap visible.
In PenForge, my writing application, a model call can have a blank cost. The call still gets logged.
The pricing map didn't recognize the model. I got a blank cost in the log and a billed call from the provider.
That matters when a bill rises and I want to know which part of the application caused it. An invoice can group spending by project, API key, or model. Those views help, but they may leave me staring at a model name when the change I need to investigate is in draft generation.
PenForge's calling code passes a route label to a shared cost meter. The label identifies the endpoint or function doing the work and stays with the call's model, token counts, estimated cost, and elapsed time.
Now I can group known costs by route and ask whether a rise came from more requests, larger requests, or a different model. I use request counts to see how often the work ran, then token counts to inspect the size of those requests.
A token is a piece of text the model counts, sometimes a whole word and sometimes part of one. Think of it like breaking a sentence into puzzle pieces before the model reads it. The short question a person sees may travel with a system prompt, tool definitions, retained conversation, documents, and tool results. All of that can count as input. An earlier answer counts again when the application includes it in a later request.
That's how a forty-token question can sit inside a request containing thousands of tokens.
One model can fail and trigger a second call. Now one generation attempt has two entries in the log. PenForge records the attempt's outcome separately as successful, fallback, or failed. The fallback call receives a route-label prefix that keeps it tied to the same work while making the second path visible.
I record that as one attempt with a fallback call.
If code bypasses the shared meter, I won't see that call in the route total. Comparing the logged estimate with the provider invoice can expose a gap, though matching totals can't prove complete coverage because separate errors might offset each other. Inspecting every provider-call path is how I look for work the meter never saw.
In my experience, the unknowns matter more than a pretty total. PenForge uses a hand-kept pricing map. When the model or price is absent, the call remains unpriced. I'd put the count of those calls beside each route's known total.
If a route shows ten dollars and one hundred unpriced calls, I still don't know what that route cost.
I also choose which price the estimate uses. When a provider offered an introductory rate with an expiry date, PenForge kept the standard price. A cautious budget check may stop work sooner than the discount requires, but it doesn't depend on remembering the day the discount disappears.
Caching can add separate prices for creating an entry and reading it later. I use the usage fields the provider returns and the price that applied to that model at that time.
A turn limit constrains how long an agent can continue. It doesn't make every turn equally expensive.
When I review a route, I want the request count, token count, known cost, and unpriced-call count on the same screen. Ten dollars beside one hundred unknown calls is still an unknown bill.
Sources: Anthropic Usage and Cost API; OpenAI usage and cost review; Anthropic prompt caching.