My Local Token Prices Were Wrong. It Was Just a Name

Last night I opened the token-saver dashboard before bed and stopped at one line: the local-coding route, the model I use for daily coding, was priced like some budget-tier model I had never picked. Small numbers, consistent, and completely wrong.

My first guess: the catalog changed its prices. I opened the pricing page, compared numbers, nothing had moved. Only after reading the plugin code did I find the cause: local-coding is a gateway route name, not a model id in any catalog. The tracker found no match, so it fell back to family-level pricing, and the family it picked was simply wrong.

From a hook to a dollar figure

The plugin is token-saver, a Hermes plugin that turns local token usage into a simulated dollar cost, as if the inference were billed at hosted prices [4]. It hooks into one point: post_api_request. The Hermes docs list it as an observer that fires after each successful provider request, carries a usage dict, and ignores the return value [2]. Pure observer, it cannot interfere with the agent loop.

On hosted providers that usage dict is trustworthy. Local servers are another story. Ollama, for instance, is partially compatible with the OpenAI API: the api_key header is required but ignored [3]. Usage fields for local models are often empty, so the plugin estimates tokens from byte length. Not precise, but far better than no number at all.

A public catalog and a matcher that refuses to guess

For pricing, the plugin keeps no hardcoded rate table. It pulls OpenRouter's public catalog from the Models API without an API key, and every price there is in USD per token; the docs' own example is "prompt": "0.0000025", multiplied by a million for the per-million figure [1]. Hosted responses also carry a usage object with input and output token counts automatically [1].

The model-name matching is layered: exact id first, then common provider prefixes, then a unique substring. When the result is ambiguous, it refuses to guess [4]. I respect that design: an empty number beats a confident wrong one. If a model truly is not in the catalog, only then does it fall back to per-family prices: qwen, deepseek, claude, gpt, and friends [4].

The problem: local-coding is not any family. Even the substring matcher cannot help, because the name is not a model name at all. So my dashboard kept computing numbers from the wrong family. Consistently. Every day.

The fix was one line, the lesson was not:

MODEL_ALIASES = {
    # gateway route name -> the upstream model id actually in use
    "local-coding": "z-ai/glm-5.3",
}

With that alias table, the plugin translates the route name to the upstream model id before looking up a price. My dashboard turned honest instantly: per-million input and output prices now follow the model that actually serves the requests, not a fallback guess.

A yardstick, not an invoice

One more thing I only understood while digging through this: OpenRouter's Usage Accounting docs note that every response carries detailed usage automatically, including cache tokens read, cache tokens written, and reasoning tokens [5]. A simulator that only multiplies prompt tokens by completion tokens misses all of that. So the number on the token-saver dashboard is a yardstick: useful for feeling "what would this cost if I paid for it", not a photocopy of an invoice.

The decision I took away changes a habit: any non-standard name that flows into a tracker needs an explicit alias. The layered matcher is good at filtering candidates, but it still needs one human-written line at the exact point where a gateway name and a model name speak different languages. A scientific-looking number computed from the wrong model is more dangerous than no number at all.

Sources

[1] OpenRouter Docs, Models API
[2] Hermes Agent Docs, Event Hooks
[3] Ollama Docs, OpenAI compatibility
[4] Hiutaky/token-saver on GitHub
[5] OpenRouter Docs, Usage Accounting