Anthropic Models API `line`: stop parsing model IDs

Anthropic added a `line` field to its Models API on October 1, 2026. `GET /v1/models` and `GET /v1/models/{model_id}` can now state the family a model belongs to—such as `opus`—without applications parsing the model ID. This is useful for model pickers, inventory views and routing candidates, but it is only taxonomy. It does not prove a model supports a tool, fits a risk policy or should receive production traffic. Use `line` to group; use the API's explicit capability and token-limit fields plus your own approved-model policy to decide.

The official release note gives October 1 as the event date. Anthropic's List Models reference says `line` can be null, warns not to infer a line from `id`, and says more line values may be added. The architecture below is an engineering recommendation derived from those documented contracts, not a description of Anthropic's private routing system.

What changed—and what did not

Before this field, an application that wanted to group models into families might split a string such as `claude-opus-...`. That logic silently turns naming conventions into an API contract. A new family, alias format or provider-specific identifier can break filters, analytics and permissions even though the model itself is valid.

The new field makes family membership machine-readable. The API reference currently defines values including `haiku`, `sonnet`, `opus`, `fable` and `mythos`, while reserving the right to add more. A model that belongs to no line returns null. Correct clients therefore treat the value as an open string-or-null, not a closed enum compiled into business logic.

Nothing about `line` says which release is newest, whether an alias moves, when a snapshot retires, or which features are enabled. The same API response separately exposes `id`, `display_name`, `created_at`, `max_input_tokens`, `max_tokens` and a `capabilities` object. Keep those meanings separate.

Family, capability and approval answer different questions

A model family answers: which product line groups these releases? Capability metadata answers: can this model accept a PDF, use code execution, produce structured output or support a thinking mode? Token limits answer whether a request fits. Your application policy answers: has this exact model been evaluated and approved for this tenant, region, workload and risk class?

Do not replace one dimension with another. Two models in the same line can differ in context limits, tool versions, latency, price, availability or breaking behavior. Conversely, models from different lines may both satisfy the same capability requirement. A safe router intersects all constraints, then selects from an explicit allowlist.

Treat aliases and snapshots deliberately. An alias is convenient when you want a provider-managed upgrade path; an exact snapshot is preferable when reproducibility and rollback matter. Discovery may tell you what exists, but production policy should decide whether a newly visible model enters shadow testing, a canary or no traffic at all.

Build a normalized catalog, not live request-time discovery

Fetch the Models API in a background control-plane job, paginate until complete, validate the response and write a normalized catalog. Preserve the provider record and the time observed. Reject only malformed records; quarantine unknown fields or line values for visibility instead of crashing the refresh. Keep the previous known-good catalog when refresh fails.

{
  "provider": "anthropic",
  "model_id": "approved-model-id",
  "line": "opus",
  "capabilities": {"structured_outputs": true},
  "max_input_tokens": 1000000,
  "observed_at": "2026-10-06T04:00:00Z",
  "policy_state": "evaluated"
}

This is an application schema, not a verbatim Anthropic response. It deliberately separates observed provider metadata from internal policy state. Do not overwrite the last known record merely because a transient response omits a field; compare revisions, alert on meaningful changes and require approval before a change affects routing.

Cache discovery with a bounded TTL and jitter. Model inventory changes much less often than inference traffic, so calling `/v1/models` on every user request adds latency and a new failure dependency without improving safety. Refresh on a schedule and allow an operator-triggered refresh after a documented launch or deprecation.

Route through explicit gates

Start with workload requirements: input types, output contract, context budget, required tool classes, data policy, latency target and maximum accepted cost. Filter the catalog by explicit capabilities and limits. Apply tenant, geography and compliance policy. Then restrict candidates to models that passed the current evaluation bundle. Family can guide ranking—for example, prefer an approved model from one line for a class of work—but it must not bypass the gates.

Resolve the candidate to an exact ID before the inference call and record that ID, catalog revision, route-policy version and fallback reason on the trace. This makes an incident explainable even if an alias later points elsewhere. Never log sensitive prompts merely to make routing observable; task class, counts, policy decisions, model ID and validated outcome are usually enough.

When no model satisfies all gates, fail closed for high-risk actions or move to a documented human path. For low-risk drafting, a fallback can be allowed only if it independently passes the same capability and policy checks. `same line` is not a sufficient fallback rule.

Handle null and future values safely

A null line is valid. Keep the model discoverable under an `unclassified` presentation group, but do not invent a family from the ID. An unknown non-null value is also valid under the forward-compatibility warning. Display the provider's human-readable model name, store the unknown line verbatim and let policy decide whether the model remains unavailable until reviewed.

Avoid exhaustive switches that throw on the first new value. UI colors and ordering can use a default style. Metrics should preserve a low-cardinality normalized value but retain the raw value in controlled catalog data. Authorization must never depend only on a friendly family label.

Schema changes deserve contract tests. Save representative fixtures with null, known and unknown line values; absent optional fields; pagination; duplicate IDs; and a capability that your current client does not recognize. Verify that refresh remains idempotent and that the previous catalog survives network, authentication and validation failures.

Best uses and anti-patterns

The field is best for grouping a model picker, summarizing inventory, defining broad evaluation cohorts and expressing preferences after hard requirements are satisfied. It also removes brittle regular expressions from dashboards and configuration tools. Teams operating several model releases can compare outcomes by family without normalizing IDs themselves.

Do not use it to infer price, intelligence, release order, safety level, tool support or retirement. Do not automatically authorize every model that appears under an approved line. Do not silently rewrite a pinned production model when discovery sees a newer sibling. And do not block the request path on a live catalog refresh.

Search or static configuration can be better than dynamic discovery when an application supports one carefully pinned model and changes only through releases. A database-backed catalog earns its complexity when several products or tenants need different approved sets, model pickers, scheduled evaluations or coordinated deprecation work.

Rollout and evaluation

First replace ID parsing in a shadow catalog and compare its grouping with the old implementation. Differences are evidence to inspect, not values to auto-correct. Then add capability filters and policy state while keeping production routing unchanged. Run contract tests against stored API fixtures and a controlled live refresh.

Evaluate each candidate on workload-shaped tasks. Measure accepted outcome rate, critical failures, latency percentiles, tokens, tool errors, fallback rate and cost per accepted result. Canary the routing policy—not just the model—behind a stable tenant or request cohort. Predefine rollback thresholds and keep the previous catalog revision and route bundle deployable.

Alert when a routed model disappears, a capability changes, a token limit shrinks, a line changes, an unknown line appears or a model approaches a documented retirement date. Discovery should surface changes early; it should never convert provider metadata directly into a production release.

Production decision

Adopt `line` anywhere you currently parse Anthropic model IDs for grouping. Preserve null and future values, cache a validated catalog and separate discovery from the request path. Use capabilities and token limits for technical compatibility, and use an evaluated allowlist for product and risk approval.

The update is small, but the design lesson is durable: identifiers identify; taxonomy groups; capabilities describe; policy approves. Keeping those four contracts separate makes model routing safer as providers add families, releases and features. For the broader deployment process, connect this catalog to the Claude Sonnet 5.5 migration playbook and the portable AI evaluation contract.

Prepared by: Noor Yasser