Most teams start with a model ID pasted into an environment variable and a spreadsheet somewhere that says what the model supports. That works until a model is deprecated, a limit changes, or someone fat-fingers an ID that returns a 404 in production. The Models API — the /v1/models endpoint — is the programmatic answer: it lets you list the models available to your account and inspect each one's properties before you send a single inference request.
What it returns
Per Anthropic's models documentation, model capabilities and token limits are queryable via the Models API, and responses include max_input_tokens, max_tokens, and a capabilities object for each model. That is exactly the data you would otherwise hard-code: how large a context the model accepts, how much output it can generate, and which features it supports. For the full response schema, check the official API reference — but those three fields alone are enough to replace most static model tables.
from anthropic import AnthropicAWS
client = AnthropicAWS() # Claude Platform on AWS
for model in client.models.list():
print(model.id, model.max_input_tokens, model.max_tokens)
Where it works — and where it doesn't
This is the part that matters for a 3P audience: the Models API is available on the first-party Claude API and on Claude Platform on AWS. It is not available on Amazon Bedrock, Google Vertex AI, or Microsoft Foundry. Each of those platforms has its own mechanism for discovering which models are enabled — Bedrock and Vertex AI expose model catalogs through their own consoles and cloud APIs, and Foundry manages models through deployments — so consult your cloud provider's documentation for the equivalent. If you are building a multi-platform abstraction layer, plan for model discovery to be per-platform code, not a shared call.
Remember too that IDs themselves differ by platform: Bedrock prefixes model IDs with anthropic. (for example anthropic.claude-opus-4-8), Google Cloud uses bare IDs with an @date form for older models, and Claude Platform on AWS uses the same bare IDs as the first-party API. A model list fetched on one platform does not translate literally to another.
Understanding what an ID means
Model-selection logic needs one piece of background: every Claude model ID is a pinned snapshot. Starting with the Claude 4.6 generation, IDs use a dateless format (claude-opus-4-8, claude-sonnet-5) that is still a pinned snapshot, not an evergreen pointer that silently changes underneath you. Pre-4.6 models pair a dated ID (claude-haiku-4-5-20251001) with a convenience alias (claude-haiku-4-5) that resolves to it. So listing models is safe from the "did the model change under me?" worry — a given ID always names the same model.
Building selection logic that stays current
A practical pattern for enterprises:
Validate at startup. On deploy, list models and confirm every ID your configuration references actually exists and that its max_input_tokens and max_tokens satisfy what your workload assumes. Failing fast at boot beats a 404 at 2 a.m.
Gate features on capabilities, not on ID string-matching. Code that decides "this model supports X" by parsing the model name breaks with every new release. Reading the capabilities object keeps the decision data-driven.
Cache the response. The model catalog changes on the scale of weeks, not seconds. Fetch it at startup or on a slow refresh interval rather than per request.
Pair discovery with deliberate pinning. Discovery tells you what is available; it should not auto-switch production traffic. Keep the production model ID in configuration, and use the Models API to detect drift — for example, alerting when a configured model stops appearing in the list, which is a strong hint to read the deprecation notices.
Where to go next
Model discovery pairs naturally with deprecation planning and with the ID differences covered in why model IDs differ across platforms. For choosing between tiers, see the model lineup explained.