How Claude’s API balances model upgrades, cost and safeguards

The Messages API is the foundation developers use to build with Claude: it combines user and assistant turns with tool calls. Its controls also change how the model behaves. The team says the same model at high and low effort can feel substantially different, while defaults reflect what Anthropic has learned works well.

The platform team works closely with researchers and incorporates their findings into the API. The defaults in a basic request aim to provide a good starting experience, while controls such as effort let developers customize behavior in ways prompting alone may not achieve.

Ideas flow both ways. Researchers noticed Claude was getting better at using computers, which eventually led to computer-use tools in the API. Customer requests also inform what researchers train into future models, rather than changing models already released.

Two apparently small changes make a practical difference: changing effort and system prompts during a conversation. Previously, changing them could break prompt caching, forcing developers to choose between adjusting behavior and retaining the cost savings from reused context.

For example, an agent may work at high effort and then encounter an easier request. Switching to low effort used to invalidate the cache, undermining the saving. Being able to change effort mid-conversation gives developers more flexibility; the video description notes this capability is in beta.

A feature must be evaluated as it moves from idea to launch. The team also recommends that each customer test new controls against their own tasks: a general-purpose API cannot substitute for tests of an individual product and its particular requirements.

Model releases add another dimension to API versioning. A model identifier effectively acts as a version alongside the API version and other switches. The team says improvements in model capability can make developers willing to adjust their applications, but those applications still need tests for token use, capability and task outcomes.

Adding capability is easier than removing an option people depend on. The move from extended thinking to adaptive thinking illustrates the tradeoff: the team saw stronger evaluations for the newer approach but kept the older setting available for a transition, alongside mechanisms that give developers time to update.

Some deprecations eventually become necessary when newer models are no longer trained for an old method. Keeping an API option that no longer does what it promises would mislead developers, so the team tries to provide a gradual migration across model generations.

When a model changes, developers should reevaluate the whole workflow around it, not just replace a model name. A scaffold that helped a weaker model may become a constraint on a more capable one. A new feature may also make better caching and lower costs possible.

The team calls prompt caching one of its largest cost controls. During an agent workflow, successive requests often append information to a shared prefix. Caching blocks that have already been processed can reduce repeated work; the speakers describe a 90% cache rate as an aspirational target, not a guarantee.

The more useful comparison is cost per completed task, not merely price per token. A more capable model may consume a different number of tokens or solve a task that a cheaper model cannot. Developers need evaluations that compare outcomes and total cost under the settings they actually use.

The reverse can also occur as models improve: a less expensive model may become capable of a workflow that previously required a stronger one. The speakers recommend revisiting the choice rather than assuming that an earlier model selection remains optimal.

The team balances giving researchers and other customers access to capable models with concern about misuse. It describes safeguards and classifiers as part of how the API manages that tradeoff.

According to the speakers, Mythos and Fable use the same model weights but differ in access and safeguards. Fable is available without the full verification process described for Mythos; the video notes that Mythos access goes through the Cyber Verification Program.

The speakers also worry about distillation: another model can be trained from a capable model's outputs, potentially producing a powerful model without the same safeguards. They say recent thinking-protection changes are intended to reduce that risk.

Safety decisions are tested against many internal alternatives, the team says. As models improve, some evaluations become too easy to distinguish performance, so the tests themselves have to become harder.

With each new model, the team reruns tests on prototypes and features that previously fell short of its quality bar. It encourages customers to revisit tasks that were close to working before: improved capabilities may change which designs are viable.

Much of the API is designed around agent workflows. Developers can use their own tools or Anthropic's client-side tools, and controls for thinking and effort affect which tasks an agent can complete. Claude Managed Agents offers a higher-level way to build such systems.

Claude Managed Agents is built on the Messages API. The team says building both layers in-house helps it identify needs from managed agents and add improvements to the underlying API, where developers building directly on Messages can also use them.