Model Attribution Check

The complaints this comes from

> "Cursor Auto-Switches to Composer 2.5 After API Limit Is Reached, Causing Context Window Loss" > "Agent overrode Task Models settings and billed Claude tokens instead of Cursor Grok" > "Cursor Cloud not use the model i select and change it to another model in the middle of chat"

Every provider and every agent harness has a fallback path — on rate limit, on capacity, on a model deprecated mid-week. Almost none of them fail; they substitute. You asked for one model, a different one answered, and the only record is a model field in the response body that approximately nobody reads.

Three consequences, in increasing order of how long they take to notice

1. Quality. Your eval measured one model; production answers with another. Every number you have describes a system you are not running. A "prompt regression" can be a routing change.

2. Billing — and the direction people forget. Everybody guards against being downgraded. Nobody guards against being quietly served the expensive model. The invoice arrives three weeks later with no way to attribute the difference. Upgrades are reported here at the same severity as downgrades.

3. Silent truncation, the worst of the three.

  reconcileCall({ requestedModel: "big-200k", servedModel: "small-32k", promptTokens: 100_000, … }, catalog);
  // { severity: "critical", truncationRisk: true,
  //   detail: "asked for big-200k, got small-32k, and the 100000-token prompt exceeds
  //            small-32k's 32000-token window — the request did not fail, it was CUT,
  //            and the answer is derived from whatever fit" }

Nothing errors. The answer is confident and based on part of your input. This outranks the substitution itself in severity, and it is flagged even when there was no substitution — you can exceed the window of the model you correctly received.

No fuzzy name matching, deliberately

big-200k and big-200k-20260101 are different models unless your catalogue says otherwise. A substitution is a name change, and a matcher generous enough to forgive a suffix is generous enough to hide a swap. If your provider pins dated snapshots, put both ids in the catalogue.

An unknown model is an unchecked call, not a passing one — reported at high severity and excluded from the "served correctly" count.

The number nobody currently has

  auditAttribution(calls, catalog);
  // { fidelity: 0.5, substitutedInto: { "small-32k": 2 }, costDeltaCents: 1475, truncated: [...] }

fidelity — the fraction of requests that actually ran the model they asked for. Worth a dashboard tile, because nothing else on your dashboard will tell you when it drops.

fallbackSafe() checks a fallback chain before you send: if any configured fallback cannot hold the prompt, falling back to it truncates silently, and refusing to send is better.

What it does not do

| not included | why | |---|---| | Calling any provider | it reconciles records you already have | | Maintaining a model catalogue | prices and context windows change weekly; supply your own | | Token counting | true-token-ledger, context-window-packer | | Choosing a model | model-router |

Tiers are your own capability ordering, not a benchmark. If you do not supply them, every substitution reads as lateral — which is still reported, just without a direction.