Your Cost Table Is Empty and Both the Parser and the Router Are Correct

You think there are two. There are three.

Adding a new agent harness to per-agent cost tracking looks like two jobs.

A parser for that CLI's usage format
A routing rule that sends its sessions to the tracker

Both obvious, both easy. And then there is a third wiring point.

It is whatever fires the "start tracking this session" kickoff when an agent is spawned. In our system that kickoff was gated on an explicit list of harness names.

A new harness landed. Parser correct, routing correct, absent from the kickoff list. So no tracker was ever created. Zero cost rows.

The usage data sat perfectly intact in the session files the whole time.

You cannot find this by reading the parser or the routing code, because both are correct.

The diagnostic fingerprint

The symptoms are distinctive enough that once you know them, this takes minutes.

First — everything else looks fine. Events fire, ticket outcomes get recorded. Only the cost table for that harness is empty. So it does not read as "data collection is broken." It reads as "is that harness just cheap?"

Second — new spawns lose data but reconnections do not. This asymmetry is the tell.

Cold-boot reconnection paths usually pass the model through from stored state, so they accidentally take a different branch. Cost appears after a restart and vanishes for anything freshly spawned.

When you see that asymmetry, stop reading the parser and look at the entry path.

The rule — one list, one place

Make the set of cost-tracked harnesses a single source of truth that the parser, the router, and the spawn kickoff all read.

A harness list that appears in three places will differ in three places. No exceptions. Counting how many places your list currently appears in is a complete audit on its own.

Unregistered model IDs invent charges

There is a quieter failure in the same area.

If your price lookup returns a default rate for an unknown model ID, every model you have not registered gets billed at that default.

Here is what that does: a free local model accrues a mid-tier hosted price. Then your routing learns from that number and optimizes to avoid the cheapest thing you own.

An unknown model ID is a zero-with-a-warning, or a hard error. Never a silent default price.

Fix this before onboarding free or local models. Fix it after and the fake costs have already poisoned the decisions built on them.

Where local models break the cost model

One more trap that actually bites.

A :cloud-suffixed model is not local. Those are the vendor's hosted tier on a paid plan with concurrency limits. Treating them as marginal-cost-zero poisons any cost model you build on top.

The names are similar enough that they end up in the same catalog row. One suffix decides the billing character.

Subscription vs. metered is decided by the auth method

Working on cost, you end up classifying vendors as subscription or metered. We got that wrong once too.

We dropped a vendor as "pay-per-token" on the strength of its public API pricing page. Wrong. That vendor's CLI authenticates in the browser against an account plan — exactly like the first-party CLIs. The pricing page described a different product from the same company.

Classify by the auth flow, not the pricing page. Browser or account login means a subscription harness; an API key pasted into an env var means metered billing.

Summary

Where	Symptom	Rule
Spawn kickoff list	Only that harness has zero cost. New spawns lose data, reconnections do not	One list, read by all three
Unknown model ID	Free models accrue charges; routing learns to avoid them	Zero-with-a-warning, never a silent default
`:cloud` suffix	Hosted tier counted as marginal-cost-zero	One suffix decides billing character
Vendor classification	Pricing page misreads a subscription as metered	Read the auth flow

Rather than wiring cost attribution yourself, Marblo shows what each model spent per ticket in its Usage tab. The subscription covers orchestration only and AI usage is billed by each provider you connect, so those numbers point at the same thing your invoices do.

The full write-up is public in the Fleet Operations knowledge pack — what we measured, and what we got wrong.