Mohdel 1.0 computes per-call cost from a price catalog you maintain yourself

The two code samples in the release post can be checked against each other. The result example reports 42 input tokens, 128 output tokens and a cost of 0.002046 USD ^[5]. The catalog entry for the same model lists inputPrice 3 and outputPrice 15 ^[13]. Read those as dollars per million tokens: 42 x 3 / 1,000,000 is 0.000126, and 128 x 15 / 1,000,000 is 0.00192. The sum is 0.002046 ^[22]. The post never names the unit.

That same shape documents outputTokens as visible output only, excluding thinking, with thinkingTokens as its own field ^[5]. The catalog example carries no price for thinking tokens, and nothing in the post says whether cost adds them at the output rate ^[23]. On a reasoning model, that gap decides whether result.cost is a number you can bill a customer from.

The adapter layer absorbs the differences that normally leak into application code: max_tokens versus max_output_tokens, a top-level system field versus instructions, and five different usage shapes ^[6].

Catalog upkeep is what that USD figure costs. No provider exposes prices as data; according to the release post the source of truth is a marketing page with a table and a footnote about cached reads ^[15]. So the cost field is downstream of somebody's HTML. The handling is procedural: the coding agent writes a candidate file and never the catalog itself, check validates schema, types and required fields, and apply prints a full diff and waits ^[16]. Entries record the URL the numbers came from and the date they were read, and the brief tells the agent to leave a field out rather than guess it ^[17]. OpenRouter needs none of this, because it publishes per-token prices in its own model list, and setup offers to add every free model in one keystroke ^[18].

I would want the cross-process path in anything long-running. A Rust supervisor called thin-gate owns a pool of session subprocesses, the app talks to it over a unix socket, and the provider SDKs run outside the app process ^[10]. An adapter that hangs, leaks or panics takes down one session; the supervisor respawns it and the caller gets a recoverable error ^[10]. The in-process path has no supervisor, and the post recommends it for scripts, CLI tools, tests and single-process services ^[9]. Running the gate also gets you sessions alive and respawned, calls by provider and status, a call-duration histogram, and cooldown, quota and policy rejections, with per-model and per-provider rate limits living in the catalog ^[20].

The operating history is the strongest thing in the post and the hardest to use. It is the author's own account of one deployment, and the post carries no measurement and no feature-by-feature comparison with LiteLLM ^[24]. For that history to tell you anything about your own service, the providers you call have to sit among the thirteen it names ^[3], and your call types have to be the ones routed through the single call shape, which the post lists as tool calls, streaming, vision and speech to text ^[7].