All Anthropic (Claude) models available through the API

Choose a Claude model by its documented capabilities and by the work your application needs to complete. Keep the exact API identifier alongside the family name when evaluating a change.

Model families at Anthropic

The catalog groups current Claude models into named families and describes their supported inputs, output and tool capabilities. Open an individual model record for the actual API identifier. Official documentation.

Evaluate a candidate on the same saved examples before promoting it. For a coding task, check the resulting change and its failure explanation; for extraction, check missing evidence and invented fields.

Begin the shortlist with a task definition that another reviewer can understand. For a coding assistant, specify the kind of repository change, the checks that must pass and the explanation expected when a change is unsafe. For document extraction, define the fields, evidence requirements and behavior when a value is absent. A family description should guide the shortlist, while these task definitions decide whether a candidate is acceptable.

Use a consistent evaluation pack across candidates. Include ordinary work, ambiguous inputs and failures that the application must surface clearly. Review the outputs before looking at the price ranking so a low rate does not bias the definition of success. Keep a record of model identifier and prompt revision with each result; otherwise a later migration can erase the baseline you need.

Anthropic’s published family positioning is provider evidence, not an independent benchmark of your workflow. If you refer to it in a decision, label it accordingly and keep it separate from your observed results. A useful model comparison makes this distinction visible instead of combining every claim into a single unsupported strongest label.

All models

Read the status as well as the name. An entry that remains in a catalog for reference is not necessarily the right choice for a new deployment. Use the official identifier and source link to inspect the actual model record. If the model appears only in a table because a required field is unverified, treat that as an evidence gap rather than a broken promise of a complete model page.

Keep the provider host in your application inventory. The same model family can appear through different platforms with different identifiers and access arrangements. Do not construct a platform-specific identifier by guessing a prefix or suffix. Copy it from the documentation for the host you are using and preserve it in configuration.

When comparing records, distinguish model capability from application implementation. A documented tool capability does not mean your application has implemented a correct tool loop. A supported input type does not mean your media preparation is reliable. Treat both layers as testable parts of the integration.

Cheapest / strongest / longest-context

These numerical rankings describe price and context. They do not establish a universal strongest model. Use documented capability fit and your own evaluation results for that judgment.

Use the price ordering to find candidates worth evaluating, then compare their results on the same fixture pack. Keep input and output behavior separate: an application that generates a long patch has a different workload shape from one that extracts a short label from a document. The cheapest candidate by one charge category may not produce the lowest cost per accepted task.

Use the context ordering as a capacity filter, not a retrieval-quality score. Prepare examples where relevant evidence appears among distracting material and verify whether the model finds and attributes it. Compare that behavior with a more selective input pipeline. Supplying everything is a design choice that needs evidence, not an automatic improvement.

For a strongest recommendation, state the task and the evidence. If the available data only establishes documented capabilities, say that the candidate fits those requirements and leave the quality judgment open. Do not manufacture a benchmark score or infer intelligence from a model’s price.

Deprecations and replacements

The official catalog links to model lifecycle information and migration guidance. Preserve the identifier that produced your baseline before changing an alias or retiring a deployment. Official documentation.

Create a migration record before changing a production identifier. Save representative inputs, accepted outputs and the application checks used to validate them. Identify optional request fields and response handlers that depend on the current model. This makes it possible to test the replacement deliberately rather than discover differences through customer reports.

Review the provider’s lifecycle notice for the actual host and identifier. A replacement recommendation is a starting point for evaluation, not proof that every previous request will behave identically. Test difficult examples, output constraints and any tool behavior your application depends on. Preserve the old configuration while it remains available so rollback is a conscious option.

After adopting the replacement, update the model inventory, cost assumptions and operational documentation together. Keep a dated record of why the migration was accepted. This helps later maintainers distinguish a deliberate upgrade from an unexplained identifier change in a deployment file.

Naming and versions

Anthropic documents platform-specific identifiers and model versioning separately. Copy the identifier for your actual API host rather than constructing it from the display name. Official documentation.

Compare the resulting workload on the pricing page and confirm the model’s capacity constraints.

Use the AI API cost calculator to turn the model and workload you are considering into an estimate.

Separate the human-friendly family label from the string sent to the API. The display name belongs in a user-facing explanation; the exact identifier belongs in code, request logs and evaluation records. If the provider documents an alias, decide whether the convenience of that alias fits your need for reproducibility.

When reviewing an example copied from another project, inspect the identifier before running it. Confirm that it belongs to the direct Claude API and that the intended account can access it. Do not replace it with a familiar name merely to silence an error; find the documented candidate and rerun the evaluation that matters to your application.

Keep the model selection in a single application configuration point and make changes reviewable. A hidden identifier embedded in an example, worker or scheduled task can leave part of the application on an older model after an apparent migration. Inventory those consumers before treating a model change as complete.

Last verified 12 Sep 2026 · Source ↗

Frequently asked questions

Sources

• Claude API overview ↗
• Get started with Claude ↗
• Models overview ↗
• Claude pricing ↗
• Rate limits ↗
• API errors ↗
• Prompt caching ↗
• Batch processing ↗

Last verified 12 Sep 2026 · Source ↗