AI Model Routing Raises Legal Questions Over What Users Actually Receive
Key Takeaways
- •AI providers and aggregators increasingly route user requests to alternative models or quantized weights to reduce inference costs and manage network safety.
- •Model identity precision is compromised by three distinct engineering issues: model substitution, degradation through quantization, and silent weight drift.
- •Substituting an AI model at the routing layer introduces ambiguities in commercial contracts regarding whether a buyer purchased a specific model name or a general capability.
- •In legal proceedings, AI routing disrupts the chain of custody, potentially preventing parties from authenticating which AI model generated a specific piece of text.
- •Experts suggest utilizing cryptographic signatures to establish an unforgeable record of the exact model, weights, and precision used for every API response.

The model named in the response object
A user calls an API and passes model: “claude-fable-5”. The response returns a completion, a token count, and a field that reads “model”: “claude-opus-4-8”.
No error was thrown, and no retry occurred. Before generation began, the request was classified, matched to a sensitive category, and routed to an entirely different set of weights. Anthropic documented this process when it brought Fable 5 back on July 1: blocked requests are sent to Opus 4.8 instead, and the user is notified. The substitution takes place at the API layer, and the response object identifies the model that actually produced the output.
That is the transparent version. It also appears to be one of the few widely deployed approaches that tells users, in-band, which model actually ran. Request-level routing has become more common as inference costs have scaled with larger models, pushing providers and intermediaries to match each query to the cheapest model that can handle it.
Two weeks later, Cursor shipped Router, a classifier trained on more than 600,000 live requests. Router reads each query’s context, complexity, and domain, then sends the request to the model it judges most appropriate. Cursor said three early-access accounts reported 30–50% savings compared with routing every request to Opus 4.8. Cursor published its routing rules, but it did not specify a particular model for each task type.
At the aggregation layer, OpenRouter warns that some providers serve quantized weights at lower prices. It also says output may differ from what full-precision weights would have produced, and that user logs will not show that this occurred.
These three products provide three different answers to the question of what a model is. No court has yet resolved which answer the law will accept.
Three ways a model name can lose precision
Model identity is splitting along three separate axes, which are often discussed as if they were the same issue.
Substitution occurs when a classifier dispatches a request to a different architecture, different weights, or a different capability profile. Examples include Fable 5 being routed to Opus 4.8, or Cursor Auto sending a request to whichever model its router selects for that turn.
Degradation occurs when the same model is served at reduced precision. OpenRouter exposes a quantizations parameter because quantized endpoints may perform worse on certain prompts. By default, requests are load-balanced across providers ordered by price. The same model name may appear in the request, but different arithmetic may be used on the other end.
Drift occurs when the same name points to silently updated weights. A -latest alias in production is an unversioned dependency, similar to a package manifest that does not pin a version. Model providers have commonly used dated snapshot identifiers alongside aliases, but aliases themselves do not carry a deprecation or change log unless the vendor publishes one.
Engineers typically treat substitution, degradation, and drift as reliability problems. They are also identity problems, and identity is central to contracts, warranties, disclosures, and evidentiary rules.
What was actually purchased?
The commercial-law question begins with whether the description was a term of the deal.
If an API call were treated as a sale of goods, the question would be close to straightforward. UCC §2-313(1)(b) makes any description of goods that forms part of the basis of the bargain an express warranty that the goods will conform to that description. India’s Sale of Goods Act, 1930, §15 performs a similar function through the doctrine of sale by description.
An inference API, however, is unlikely to be treated as goods. Courts have generally characterized hosted software as a service, pushing the issue out of warranty statutes and into common-law contract. When a transaction mixes goods and services, US courts apply a predominant-purpose test that examines the substance of the deal rather than its label. Under that framework, the answer depends on what the documentation said and how specifically the buyer bargained. That is where the ambiguity arises. Enterprise agreements price services per model. Model cards are specific to models. Compliance artifacts identify model versions. Yet the routing layer may treat the model name as a hint rather than a fixed instruction.
The stakes are clearest in software terms: if code pins a model ID rather than expressing a capability requirement, behavior can change materially without triggering an error. A contract drafted in the same way has the same defect. If the buyer bargained for a name, substitution may be a breach. If the buyer bargained for a capability, substitution may be permissible — but then the parties need a definition of “frontier quality” that can withstand scrutiny.
No settled definition exists. Cursor’s Router illustrates the problem. It was evaluated in an online A/B test that optimized for user satisfaction as the reward signal. That may be a reasonable engineering choice, but it is a difficult contractual measure. Satisfaction is not the same as conformity. A user who did not notice a model swap may show that the router worked well, not that a specified product was delivered.
The disclosure gradient
Under FTC deception doctrine, a representation can be actionable when it is material and likely to mislead a reasonable consumer. Objective performance claims also require a reasonable basis before they are disseminated. Both concepts are relevant to AI routing.
The three products sit at different points on the disclosure spectrum. Anthropic notifies users and returns the served model in the response. Cursor publishes routing rules but does not disclose per-task model assignments. OpenRouter discloses quantization variance in its documentation and allows users to control it through a parameter, but the setting is opt-out and the default route is the lower-cost path.
A disclosure located in documentation and defaulted against the user resembles fact patterns that regulators in other consumer markets have described as dark patterns.
On substantiation, the legal exposure attaches to the claim rather than the routing mechanism itself. Commentators have already noted that a claim such as “60% cheaper, no quality loss” would require published methodology to support it. Anthropic’s own disclosure shows the cost of candor: it said plainly that the retrained classifier flags benign requests more often during routine coding and debugging. That sentence functions as a liability shield. Vendors that do not provide similar specificity may face closer scrutiny.
The EU AI Act, which entered into force in August 2024, adds a parallel transparency track. Its provisions on general-purpose AI models require providers to publish technical documentation and keep it updated, and to cooperate with downstream deployers so they can understand a model’s capabilities and limitations. How those obligations map to a routing layer that may swap models per request has not yet been tested.
There is also a competition-law issue. Working papers on vertical foreclosure in inference markets have proposed conduct frameworks built around routing transparency, quality-of-service parity, and FRAND-style non-discrimination. A router operated by a first-party model vendor can become a self-preferencing mechanism presented as cost optimization.
Authentication may become the central dispute
The most important legal issue may not be billing, but authentication.
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 by allowing records generated by an electronic system, or data verified by hash, to self-authenticate through certification. India’s Bharatiya Sakshya Adhiniyam, 2023, §63 performs analogous work by conditioning the admissibility of an electronic record on a certificate identifying the record and the manner of its production.
Each of these provisions assumes that the system can be named.
Consider a scenario in which a lawyer files a brief containing a fabricated citation and sanctions proceedings begin. The court asks which model produced the text. The law firm’s logs say Fable 5. The provider’s logs show that a classifier fired and Opus 4.8 answered. Alternatively, the request may have passed through an IDE router that selected a model the firm cannot reconstruct, at a precision the firm never specified, on a version that has since been retired.
In that situation, the chain of custody breaks at the router — not at the model, but at the dispatcher. The break works in both directions. A party trying to authenticate its own output may be unable to do so, while a party challenging the other side’s output gains a reliability argument that may be difficult for an expert to rebut.
Discovery adds another problem. Under US civil procedure, the duty to preserve potentially relevant information attaches when litigation is reasonably anticipated, not when a subpoena arrives. Routing decisions can become dispositive facts. That makes router classifier logs, per-request model assignments, and precision metadata potentially discoverable from vendors that currently may have no obligation to retain them.
The proposed fix is a signature, not just a contract clause
Contracts alone may not solve the problem because the representation at issue concerns a runtime event, while contracts are static documents.
The legal system may eventually require attestable model identity: a signed assertion returned with each response, binding the completion to a tuple that includes the served model identifier, weights hash, precision, and system-prompt hash. That assertion would be signed by a key rooted in hardware attestation, a capability already supported by confidential-computing GPU platforms such as NVIDIA’s Hopper architecture with its Confidential Computing feature.
Part of the primitive already exists. Response objects can carry the served model name. What is missing is the property that would make the information legally useful: the assertion must not be falsifiable, and the buyer must be able to verify it without trusting the seller. A hash in a response header could do for model identity what FRE 902(14) already does for copied data: turn a contested factual question into a certificate.
Routing can be sound engineering. At present, it can also amount to an unlogged, unsigned, and unverifiable substitution of the thing a user believed they had selected. The model ID has quietly become a legal identifier, and the unresolved question is what, exactly, it identifies.
Sources
Cursor, “Introducing Cursor Router” (22 July 2026) —
MarkTechPost, “Cursor Releases Cursor Router: A Request-Level Classifier Delivering Frontier Coding Quality at 30–50% Lower Cost” (22 July 2026) — https://www.marktechpost.com/2026/07/22/cursor-releases-cursor-router-a-request-level-classifier/
Anthropic, “Redeploying Claude Fable 5” (30 June 2026) —
Espressio, “Claude Fable 5 Safeguards: The Opus 4.8 Fallback Explained” (22 June 2026) —
Digital Applied, “Why Claude Just Got More Cautious About Your Code” (2026) —
OpenRouter, “Provider Routing — Provider Selection” (docs) —
OpenRouter, “Lowest-Cost LLM Inference: The Complete OpenRouter Guide” (12 June 2026) —
OpenRouter, “How OpenRouter Model Routing Works” (12 June 2026) —