Skip to main content

Claude Sonnet 4.6 chat from Anthropic through an OpenAI-compatible endpoint. It takes up to 1,000,000 tokens of text and image context and returns up to 64,000, with temperature and top_p control, up to 128 tool definitions and SSE streaming.

Input $3Output $15per 1 million tokensCached input $0.30Cache write $3.75

Workbench

Claude Sonnet 4.6

What can Claude Sonnet 4.6 help with?

Related models and next tasks

Missing the model you need?

Tell us what to add and where you would use it. Requests go to the people who decide what gets onboarded next.

Build stable message flows for a million-token window at the Sonnet rate, sampling controls intact

Sonnet 4.6 takes the 1,000,000-token window and keeps temperature and top_p, at the Sonnet rate rather than the Opus one. Against its 4.5 sibling the only change is the window; against Opus 4.6 the change is the price and a 64,000-token reply ceiling instead of 128,000.

Open the chat playground
Build stable message flows for a million-token window at the Sonnet rate, sampling controls intact
Model
Claude Sonnet 4.6
Good for
a million-token window at the Sonnet rate, sampling controls intact
Message shape
System rules → evidence and state → current task → output contract
Fact boundary
Capabilities, controls, and price come from the live schema

Integration principle

Validate with the smallest message set, then add necessary context. Separate facts, assumptions, and constraints, and design interruption, retry, settlement, and review paths.

Build repeatable workflows for a million-token window at the Sonnet rate, sampling controls intact

Sonnet 4.6 takes the 1,000,000-token window and keeps temperature and top_p, at the Sonnet rate rather than the Opus one. Against its 4.5 sibling the only change is the window; against Opus 4.6 the change is the price and a 64,000-token reply ceiling instead of 128,000.

  • Long window, Sonnet rate

    1,000,000 tokens in

    The same context depth as the Opus routes, at roughly 60% of their price per million.

  • Sampling controls kept

    temperature and top_p

    No migration away from a temperature-tuned prompt library, unlike the Sonnet 5 route.

  • 64,000 per reply

    Half of Opus 4.6

    Enough for long structured output; a 100,000-token document needs a route with a 128,000 ceiling.

Where Claude Sonnet 4.6 wins on task cost and interaction shape

Test one real task for quality, verifiability, latency, and sale-price fit instead of relying on a general leaderboard.

  1. Choose Sonnet 4.6

    Long inputs, ordinary difficulty

    Large context is the requirement; the deliberation of an Opus route is not.

  2. Choose Sonnet 4.5

    Your inputs are well under 198,000

    Same controls and family rate over a smaller window — simpler to reason about when the size is known.

  3. Choose Opus 4.6

    A single reply must exceed 64,000

    Same window and controls, double the reply ceiling, at a higher rate per million.

Turn Claude Sonnet 4.6 into concrete work, not generic labels

Every scenario needs input boundaries, verification, and recovery; official capabilities, benchmarks, and tool support are never invented.

  • Code in, judgement out

    Whole-repository questions

    Code in, judgement out

    A million tokens at the Sonnet rate is what makes repository-scale questions routine rather than occasional.

  • History that does not get trimmed

    Long conversation memory

    History that does not get trimmed

    Sessions can keep their full history in context without the rate deciding when to summarise.

  • Many files, one verdict

    Document set review

    Many files, one verdict

    Read the set and return findings, without building a retrieval layer to work around a small window.

  • Adult characters, clear boundaries

    Unrestricted narrative work

    Adult characters, clear boundaries

    Long continuity over an existing body of text, with the temperature you already settled on. We add no content filter.

Organize context into an inspectable Claude Sonnet 4.6 input

Objective, evidence, state, constraints, and output contract need distinct jobs so requests can be compressed, debugged, and reproduced.

  1. Order

    Rules, then evidence, then task

    Over long inputs an instruction in the middle competes with the material around it.

  2. Caching

    Stable prefix, variable tail

    Cached input at about a tenth of the input rate is where a long-context integration actually saves money.

  3. Sampling

    Pin it before you tune anything else

    The window changed, the sampling behaviour did not — carry over the value you already validated.

  4. Output

    Design for one turn of 64,000

    If the deliverable is longer, split it deliberately rather than letting the ceiling cut it.

Prove a repeatable Claude Sonnet 4.6 case before product integration

Confirm live schema, quote, streaming, and error behavior before reusing the normalized request.

  1. 01 · Baseline

    Validate the smallest request in Playground

    Check message layers, output shape, streaming, and current controls.

  2. 02 · Boundaries

    Exercise failure, cancellation, and retry

    Verify timeouts, interrupted streams, oversized input, regeneration, and duplicate submission.

  3. 03 · Integrate

    Copy the normalized API request

    Use the public model id and messages contract; read model controls from the live schema.

  4. 04 · Operate

    Meter usage and keep evaluating

    Store state, final usage, failure reasons, and quality feedback; quote expensive calls first.

Bring Claude Sonnet 4.6 into a clear API contract

Playground, API examples, request states, and usage records stay aligned from evaluation through production integration.

  • Unified contract

    One shape for messages, streams, and errors

    Keep request structure, state handling, and error recovery consistent when changing models.

  • Live schema

    Use the current endpoint controls

    Playground and API examples expose available fields, limits, and default behavior together.

  • Observable lifecycle

    Every request has a clear state

    Submission, streaming, failure, cancellation, and usage use inspectable public semantics.

  • Portable integration

    Reduce work when models evolve

    A clear contract keeps product code focused on inputs, results, and user experience.

Claude Sonnet 4.6 API boundaries to confirm before integration

All Claude models10