Claude Sonnet 5.5 under scrutiny: what its speed, cost and performance figures mean

A review of claims, not a launch announcement

Anthropic presents Claude Sonnet 5.5 as a clear improvement over Claude Sonnet 5: it says the model runs more than 30% faster and costs up to 30% less for most work. These are the manufacturer’s claims. The available sources confirm that Anthropic makes them, but do not provide the protocol, data or conditions needed to reproduce them independently.

That distinction matters. An official page is a primary source for what a company says about its product, but a claim does not, by itself, amount to an audited experimental result. To interpret a speed difference, readers need information such as the task measured, the metric, the comparison model, the configuration and the workload. To understand a cost reduction, they also need to know whether it refers to the price per token, the total expense per task or an estimate based on selected uses.

This analysis is limited to the sources supplied. The excerpts identify pages from Anthropic, OpenRouter and Amazon Bedrock, but do not include the full contents of their tables, documentation or evaluations. We therefore distinguish between information that can be attributed directly to a source and information that remains to be checked. We do not present specific prices, detailed technical limits, model identifiers or independent results as verified when they do not appear in the available material.

The practical conclusion is not that the figures are false, nor that they have been proven. It is that the available information is enough to describe Anthropic’s promise, but not to turn it into a reliable forecast of performance or budget for every organisation.

How to interpret “30%+ faster”

Anthropic’s published wording compares Sonnet 5.5 with Sonnet 5 and says it is more than 30% faster. The supplied excerpt does not define what “speed” means. It could refer to latency, response time, generation throughput or the duration of an entire task; it would not be appropriate to choose one of those interpretations without consulting the original method.

The excerpt also does not say whether the percentage is calculated as an average across several tasks, as an improvement in a specific case or as the result of selected workloads. The way results are aggregated can change how they should be read: an average may conceal slower performance on some tasks, while the measurement of a single interaction does not necessarily predict how long a workflow involving tools, retries or human review will take.

The comparison also needs like-for-like conditions. For the claim to be informative, a team would need to know whether both models were tested with the same input, the same output limit, equivalent parameters, comparable infrastructure and identical completion criteria. The supplied material does not confirm these details or establish whether the claim refers to Anthropic’s API, a third-party platform or a particular configuration.

The figure can therefore be treated as a hypothesis to test during planning, not as a guarantee that a specific application will be 30% faster. In a coding assistant, for example, total time may depend as much on running tests and reviewing code as on model calls. In an agent, tool calls and the steps the system chooses to take may also affect the result.

What does “up to 30% less cost” mean?

The official claim combines a limit—“up to” 30%—with a generalisation—“for most work”. The available excerpt does not explain how the savings are calculated, which tasks are included or what the cost baseline is. It does not support the conclusion that every user will pay 30% less, or that the per-token rate has fallen by that amount.

The cost of a task can include different components: input and output tokens, tool use, retries, external computing time and review work. A lower unit price does not guarantee an equivalent reduction in total spending if the new model produces longer responses or requires more steps. Conversely, a model with a higher unit price could reduce the cost of a task if it completes it in fewer calls; that would need to be measured against the actual use case.

The supplied sources identify an OpenRouter page as a secondary reference for prices and benchmarks, but the available excerpt contains no specific rates or numerical results. Amazon Bedrock documentation is described as a source for checking model details, supported features, pricing and regional availability within that service. That description does not confirm Anthropic’s direct price, and no current figure is provided here. The excerpt from Anthropic’s official Sonnet page refers to pricing, but does not include complete billing conditions.

With the supplied material, it is therefore not possible to publish a verifiable official unit rate or compare total costs across models. Before preparing a budget, teams should consult the current rate for the chosen access channel and check which charges it covers. Terms for an intermediary platform or cloud provider may not be interchangeable with those for direct access.

Described capabilities and results that still need context

The excerpt from Anthropic’s page titled “Claude Sonnet” says that Sonnet 5.5 can recheck details against source documents and catch errors that Sonnet 5 missed. It also mentions 2.4 times greater accuracy “compared to the last model”. The wording points to document review and a comparison with the previous version, but the excerpt does not define the task, dataset, accuracy metric or evaluation conditions.

That figure is not enough to claim that Sonnet 5.5 is 2.4 times more accurate in general. Accuracy is meaningful only in relation to a task and a definition of correctness. A data-extraction test, a reference check and a reasoning evaluation are not equivalent. Without information about detected errors and false positives, it is also impossible to determine whether the result would suit a process that requires high reliability.

The OpenRouter source describes the model as a Sonnet-class option for well-scoped everyday work and as the successor to Sonnet 5. That description helps explain how the model is positioned on an API provider’s page, but it is not a benchmark and does not demonstrate a specific capability. The supplied sources do not include a body of independent results that would allow Anthropic’s statements to be checked against outside evidence.

For coding, agents or knowledge work, the cautious approach is to treat general capability descriptions as reasons to design an evaluation, not as proof that the system will perform equally well in every environment. Quality may depend on the clarity of instructions, access to data, integrated tools and how an application verifies responses. The supplied sources do not describe those conditions for Sonnet 5.5 in enough detail.

Access, identifiers and service limits

The supplied sources identify an Anthropic page about the model, an overview of models on the Claude platform and an Amazon Bedrock model card. The platform overview is described as a place to consult the catalogue and official model identifiers, but its excerpt does not show Sonnet 5.5’s specific identifier. It would not be rigorous to infer or publish it without checking the full documentation.

The Amazon Bedrock model card explicitly concerns using Sonnet 5.5 through Bedrock and is said to provide information about supported features, pricing and regional availability. Based on the material supplied, this supports the existence of model documentation for that service; it does not establish which regions offer the model, which limits apply or whether the terms match Anthropic’s direct service.

The excerpts also leave technical and operational limits unconfirmed. They do not state context windows, output limits, quotas, regional availability, tool restrictions or usage policies. Such details can vary by platform and date. Before integrating the model, a team should check the documentation for the specific access channel rather than automatically applying general Claude-family limits to a particular version or provider.

Operational checks should include the exact model name and identifier on the chosen platform, availability for the intended region and account, request and token limits, and what happens when those quotas are reached. If using an intermediary, it is also worth confirming who processes requests and which terms govern the service. None of these details is resolved by the summary available here.

Safety: a system card is identified, but the summary is not enough

The sources include a system card specific to Claude Sonnet 5.5. The excerpt says it reports results from pre-deployment evaluations in seven areas, including evaluations related to the Responsible Scaling Policy and the cyber domain. Anthropic’s general system-card page explains that these documents cover capabilities, safety evaluations and deployment decisions.

This supports saying that Anthropic identifies safety documentation for the model and that the card covers several areas of evaluation. It does not support summarising the results or claiming that the model passed specific tests: the excerpt provides no scores, criteria, methodology or detailed conclusions. Nor does it establish that the evaluations cover every risk relevant to a particular application.

If consulted in full, the system card is an important primary source for understanding the tests the provider says it conducted. Even so, a pre-deployment evaluation does not replace integration testing in a production environment. Behaviour can vary with tools, instructions, permissions, data and external controls. For sensitive applications, safety analysis should cover the complete system, not just the model in isolation.

Based on the available material, specific safety details that cannot be verified include the quantitative results for each area, test limitations, described mitigations and any changes from Sonnet 5. The responsible formulation is that a system card has been identified, while the supplied summary does not allow its findings to be assessed.

What a team can decide—and what it should test

The publicly available information summarised here allows teams to understand how Sonnet 5.5 is positioned and record the manufacturer’s main claims: an improvement over Sonnet 5, more than 30% greater speed and up to 30% lower cost for most work. It also identifies a specific claim about document review, an access reference for Amazon Bedrock and a system card for the model. It is not enough to calculate a budget, predict a latency gain or conclude that a specific capability will be reproduced in a team’s own workflow.

A team considering adoption can proceed without treating the claims as performance commitments. First, it should select representative tasks and define quality and safety criteria. It can then compare Sonnet 5.5 and Sonnet 5 under controlled conditions, record both outcomes and total cost, and repeat the test with reasonable variations. For tasks with significant consequences, human review should be included, and errors should be measured alongside speed.

The test should reflect the access channel that will be used in production. Rates, availability and limits may depend on the platform. A result obtained through one interface should not automatically be assumed to apply to an API, a cloud provider or an intermediary. Likewise, any economic calculation should use rates checked at the time of contracting, not an isolated percentage from an informational page.

The most useful reading is therefore conditional: Anthropic announces improvements that justify an evaluation, but the sources summarised here do not provide enough detail for teams to validate their magnitude independently. The claims can guide what to measure; they cannot replace measurement. The current official price, applicable identifier, service terms and safety results should be confirmed in the complete primary documentation before deployment decisions are made.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.