Skip to main content

Claude Sonnet 4.5 chat from Anthropic through an OpenAI-compatible endpoint. It takes up to 198,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 $2.70Output $13.50per 1 million tokens10% below the publisher's list priceCached input $0.27Cache write $3.30Anthropic official priceInput $3Output $15

Workbench

Claude Sonnet 4.5

What can Claude Sonnet 4.5 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 mid-rate drafting with temperature inside a 198,000-token window

Sonnet 4.5 pairs the sampling controls with the smaller window: temperature and top_p, 198,000 tokens in, 64,000 out. It is the route to reach for when your prompts are temperature-tuned, the documents fit, and the Opus rate is more than the task is worth.

Open the chat playground
Build stable message flows for mid-rate drafting with temperature inside a 198,000-token window
Model
Claude Sonnet 4.5
Good for
mid-rate drafting with temperature inside a 198,000-token window
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 mid-rate drafting with temperature inside a 198,000-token window

Sonnet 4.5 pairs the sampling controls with the smaller window: temperature and top_p, 198,000 tokens in, 64,000 out. It is the route to reach for when your prompts are temperature-tuned, the documents fit, and the Opus rate is more than the task is worth.

  • Sampling kept

    temperature and top_p, not an effort dial

    The Sonnet 5 sibling replaced both with reasoning_effort. Here the knobs you calibrated still apply.

  • A window with edges

    198,000 tokens in

    Small enough to force a retrieval decision, large enough that most single documents never need one.

  • Twice the Opus 4.5 ceiling

    64,000 tokens per reply

    Long structured answers fit in one turn, at a fraction of the Opus rate.

Where Claude Sonnet 4.5 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.5

    Temperature-tuned prompts, bounded inputs

    The combination is specific: sampling control plus a window you can reason about, without paying the Opus rate.

  2. Choose Sonnet 4.6

    The same controls over a million tokens

    Identical family rate and sampling controls, with the window lifted to 1,000,000.

  3. Choose Sonnet 5

    You would rather declare effort

    Lower rate again, a million-token window, and reasoning_effort in place of temperature.

Turn Claude Sonnet 4.5 into concrete work, not generic labels

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

  • Consistent voice at volume

    Support and conversation

    Consistent voice at volume

    A pinned temperature keeps replies recognisably the same across a large number of sessions.

  • Contracts, specs, transcripts

    Single-document work

    Contracts, specs, transcripts

    Anything under 198,000 tokens goes in whole; the retrieval layer stays out of the design.

  • Style transfer with a fixed seed of behaviour

    Structured rewriting

    Style transfer with a fixed seed of behaviour

    Rewriting to a house style benefits from a temperature you chose and stopped changing.

  • Adult characters, clear boundaries

    Unrestricted narrative work

    Adult characters, clear boundaries

    Scene and character work with the sampling controls you trust, at a rate that survives long sessions. We add no content filter.

Organize context into an inspectable Claude Sonnet 4.5 input

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

  1. System rules

    Voice and boundary once, at the top

    Repeating them per turn spends input tokens on something the system message already said.

  2. Evidence

    Mark the document boundary

    Within 198,000 tokens it is still worth delimiting source from instruction explicitly.

  3. Sampling

    One temperature per experiment

    Comparing prompts under two different temperatures measures nothing.

  4. Output

    Fit the answer to 64,000

    Ask for sections; an open-ended request will find the ceiling rather than the end of the argument.

Prove a repeatable Claude Sonnet 4.5 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.5 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.5 API boundaries to confirm before integration

All Claude models10