The line in the response object
You call the API. You pass model: “claude-fable-5”. You get back a completion, a token count, and a field that reads “model”: “claude-opus-4-8”.
Nothing errored. Nothing retried. The request was classified before generation began, matched a sensitive category, and was handed to a different set of weights entirely. Anthropic documented this when it brought Fable 5 back on July 1: blocked requests are sent to Opus 4.8 instead, and the user is notified. The switch happens at the API layer, and the response object names the model that actually ran.
That is the well-behaved version. It is also, as far as I can tell, the only version in wide deployment that tells you the truth in-band.
Two weeks later, Cursor shipped Router: a classifier trained on 600,000-plus live requests that reads each query’s context, complexity, and domain and dispatches it to whichever model it judges best with three early-access accounts reporting 30–50% savings against routing everything to Opus 4.8. Cursor published its routing rules but did not name a specific model per task type.
And underneath both, at the aggregation layer, OpenRouter warns that some providers serve quantized weights at lower prices, that output can differ from what full-precision weights would have produced, and that your logs will not tell you this happened.
Three products. Three different answers to the question what is a model. Zero cases telling us which one the law will accept.
Three ways a name can stop meaning a thing
Model identity is fracturing along three independent axes, and they are not usually distinguished:
- Substitution – A different architecture, different weights, different capability profile – dispatched by a classifier. Fable 5 → Opus 4.8. Cursor Auto → whatever the router picks this turn.
- Degradation – The same model, served at reduced precision. OpenRouter exposes a quantizations parameter precisely because quantized endpoints may perform worse on certain prompts, and by default requests are load-balanced across providers ordered by price. Same name in your request. Different arithmetic on the other end.
- Drift – The same name pointing at silently updated weights. Every -latest alias in production is an unversioned dependency you would never tolerate in a package manifest.
The engineering community treats all three as reliability problems. They are also identity problems, and identity is what contracts, warranties, disclosures, and evidence rules are built on.
So what did you actually buy?
Start with the oldest question in commercial law: was the description a term of the deal?
If an API call were a sale of goods, this would be near-trivial. UCC §2-313(1)(b) makes any description of the goods that forms part of the basis of the bargain into an express warranty that the goods will conform to it. India’s Sale of Goods Act, 1930, §15 does the same work through the doctrine of sale by description.
But an inference API almost certainly isn’t goods. Courts have generally treated hosted software as a service, which pushes you out of warranty statutes and into common-law contract — where the answer depends entirely on what the documentation said and how specifically the buyer bargained. That is precisely where the ambiguity lives. Enterprise agreements price per-model. Model cards are model-specific. Compliance artifacts name model versions. And then the routing layer treats the name as a hint.
The cleanest way to see the stakes: if your code pins a model ID rather than expressing a capability requirement, behaviour can shift materially without any error ever firing. A contract drafted the same way has the same defect. If you bargained for a name, substitution is breach. If you bargained for a capability, substitution is fine — and now you need a definition of “frontier quality” that survives cross-examination.
Nobody has written that definition. Cursor’s is instructive: Router was evaluated in an online A/B test optimising for user satisfaction as the reward signal. That is a sound engineering choice and a strange contractual one. Satisfaction is not conformity. A user who never noticed the swap is evidence of a good router, not of a delivered specification.
The disclosure gradient
Under FTC deception doctrine, a representation is actionable when it is material and likely to mislead a consumer acting reasonably; objective performance claims additionally require a reasonable basis before dissemination. Both halves bite here.
On the routing side, the three products sit at very different points. Anthropic notifies and returns the served model in the response. Cursor publishes rules but not per-task model assignment. OpenRouter’s quantization variance is disclosed in documentation and controllable by parameter but it is opt-out, and the default path is the cheap one.
Disclosure buried in a docs page, defaulted against the user, is exactly the fact pattern regulators have been calling a dark pattern in every other consumer vertical.
On the substantiation side, the exposure is the claim, not the routing. Commentators have already flagged that a “60% cheaper, no quality loss” claim arrives without published methodology, and Anthropic’s own disclosure is a model of what candour costs: it stated plainly that the retrained classifier flags benign requests more often during routine coding and debugging. That sentence is a liability shield. The vendors who don’t write it are the ones to watch.
There is a competition-law tail here too. Working papers on vertical foreclosure in inference markets are already proposing a conduct framework built on routing transparency, quality-of-service parity, and FRAND-style non-discrimination. A router that is also a first-party model vendor is a self-preferencing engine wearing a cost-optimisation costume.
The part nobody is looking at: authentication
This is where I think the real fight lands, and it has nothing to do with billing. Federal Rule of Evidence 901(b)(9) authenticates output by describing the process or system that produced it and showing that the process produces an accurate result. FRE 902(13) and 902(14) go further, letting records generated by an electronic system, or data verified by hash, self-authenticate on certification. India’s Bharatiya Sakshya Adhiniyam, 2023, §63 does the analogous work, conditioning admissibility of an electronic record on a certificate identifying the record and the manner of its production.
Every one of these provisions assumes you can name the system.
Now run the scenario – A lawyer files a brief with a fabricated citation. Sanctions proceedings begin. The court asks which model produced it. The firm’s logs say fable-5. The provider’s logs say a classifier fired and Opus 4.8 answered. Or the request went through an IDE router that selected a model the firm cannot reconstruct, at a precision it never specified, on a version that has since been retired.
The chain of custody breaks at the router. Not at the model at the dispatcher. And it breaks in both directions: the party trying to authenticate its own output can’t, and the party trying to attack the other side’s output has a free-standing reliability argument that no expert can rebut.
Add the discovery problem. Routing decisions are now dispositive facts. That means router classifier logs, per-request model assignments, and precision metadata are discoverable from a vendor who currently has no obligation to retain them.
The fix is a signature, not a clause
You cannot draft your way out of this, because the representation you need is about a runtime event, and contracts are static.
What the law will eventually ask for is attestable model identity: a signed assertion, returned with each response, binding the completion to a tuple of served model identifier, weights hash, precision, and system-prompt hash signed by a key rooted in hardware attestation, which confidential-computing GPU platforms already support.
The primitive is half-built. Response objects already carry the served model name. What is missing is the property that makes it legally useful: that it cannot be asserted falsely, and that the buyer can verify it without trusting the seller. A hash in a response header does for model identity exactly what FRE 902(14) already does for copied data turns a contested factual question into a certificate.
Routing is good engineering. It is also, right now, an unlogged, unsigned, unverifiable substitution of the thing you bargained for. The model ID has quietly become a legal identifier. It is time somebody decided what it identifies.
Sources:
- Cursor, Introducing Cursor Router (22 July 2026) — cursor.com/blog/router
- MarkTechPost, Cursor Releases Cursor Router: A Request-Level Classifier Delivering Frontier Coding Quality at 30–50% Lower Cost (22 July 2026) — marktechpost.com
- Anthropic, Redeploying Claude Fable 5 (30 June 2026) — anthropic.com/news/redeploying-fable-5
- Espressio, Claude Fable 5 Safeguards: The Opus 4.8 Fallback Explained (22 June 2026) — espressio.ai
- Digital Applied, Why Claude Just Got More Cautious About Your Code (2026) — digitalapplied.com
- OpenRouter, Provider Routing — Provider Selection (docs) — openrouter.ai/docs
- OpenRouter, Lowest-Cost LLM Inference: The Complete OpenRouter Guide (12 June 2026) — openrouter.ai/blog
- OpenRouter, How OpenRouter Model Routing Works (12 June 2026) — openrouter.ai/blog
Aabis Islam is a student pursuing a BA LLB at National Law University, Delhi. With a strong interest in AI Law, Aabis is passionate about exploring the intersection of artificial intelligence and legal frameworks. Dedicated to understanding the implications of AI in various legal contexts, Aabis is keen on investigating the advancements in AI technologies and their practical applications in the legal field.
