Claude Sonnet 5.5 and Haiku 5.5 in Python: Dual SDKs, Caching, and the 100K Pricing Cliff

Anthropic's Claude 5.5 series brings out both the mid-tier and small-tier models at once: Sonnet 5.5 and Haiku 5.5 share a 1M token context window, 128K max output, and adaptive thinking enabled by default. Both can be called through the Anthropic SDK, or via a gateway using the OpenAI SDK. What you really need to work out in advance is Haiku 5.5's 100K token pricing threshold—once you cross it, every rate for the entire request is multiplied by five.

How to divide the work between the two models

The selection logic isn't complicated. Short-prompt, high-concurrency work like classification, extraction, routing, summarization, and context compression goes to Haiku 5.5; multi-file coding, debugging, and long-running tool loops go to Sonnet 5.5. In Anthropic's own Haiku release table, Sonnet 5.5 scores 70.6% on Terminal-Bench 4.0 while Haiku 5.5 gets 39.2%—the gap speaks for itself.

On list pricing, Sonnet 5.5 is $2 / $10 per million input/output tokens, and Haiku 5.5 is $0.10 / $0.50—exactly 20 times. Anthropic also explicitly says Haiku 5.5 is "a great fit as a subagent for Opus 5.5 and Sonnet 5.5," which is directly relevant to teams building coding agents.

How should you choose for prompts over 100K tokens? The original article gives a counterintuitive answer: although Haiku bills at 5x, the converted cost is still a fraction of Sonnet's unit price, so the deciding factor should be quality, not saving money.

Terminal-Bench 4.0 is a benchmark for terminal-operation tasks, specifically measuring a model's ability to complete multi-step tasks in a real command-line environment—locating files in a filesystem, running build scripts, debugging failing tests, and re-verifying after fixes. Tasks run in containerized sandboxes, and the model must accomplish its goal through shell commands rather than directly editing files, so it tests tool-calling stability, error recovery, and long-horizon planning all at once. The score gap of 70.6% versus 39.2% reflects exactly that Sonnet 5.5 is significantly stronger at maintaining context across long tool loops and recovering from failed commands; Haiku 5.5 is more likely to lose track of its goal midway through terminal tasks that require multiple rounds of trial and error. This also explains why the article recommends Sonnet for coding agent scenarios rather than judging by unit price alone.

Calling Haiku 5.5 with the Anthropic SDK: three easy pitfalls

The original article uses a ticket classifier as an example, setting output_config.effort to low, because this task only needs a label and no reasoning chain. The code sets max_tokens fairly generously because thinking tokens also count toward this limit—set it too small and the response may cut off right after the thinking block, returning not a single text block.

Three details are worth calling out separately: Haiku 5.5 does not accept temperature (only 1 is allowed, or top_p 0.99; passing top_k gets an immediate 400); requests must end with a user turn, and assistant prefill is rejected even with thinking disabled; and when parsing the response you can't just take content[0].text, because the first block may be a thinking block—filter by type == "text" and concatenate.

Adaptive thinking is a mechanism enabled by default in the 5.5 series: the model decides on its own whether to think and how many thinking tokens to spend, based on task complexity, rather than the caller explicitly specifying a fixed budget. This has two direct implications. First, max_tokens is the shared total limit for thinking and body text; set it too tight and you can end up with the thinking block generated but the body truncated before it starts, leaving only thinking content in the response with stop_reason set to max_tokens. Second, the response content is no longer a single text block—the content array may contain both thinking and text blocks, and the order doesn't guarantee text comes first, so any extraction code must filter by type. In addition, thinking tokens are billed at the output price, so you need to count them on the output side when calculating costs—this is also the most common source of discrepancy when your bill doesn't match your own calculations.

Calling Sonnet 5.5 with the OpenAI SDK: what the gateway translates

If your codebase is built on the OpenAI SDK, just point base_url at the gateway's compatible endpoint and change the model string. The original article notes that the gateway does three things on this path: when max_tokens isn't passed, it fills in the model's own output limit rather than a small default (previously 4096, which would truncate long code files mid-function); for both 5.5 models it drops temperature, top_p, and top_k, so clients with default temperatures don't hit Anthropic's 400s; and reasoning_effort is mapped to Anthropic's effort levels.

There's a hard limit on tool calling: Sonnet 5.5 does not support forced tool use—setting tool_choice to tool or any will error. The correct approach is to keep auto, set strict: true on the function, and make it clear in the prompt when the tool should be used.

Forced tool use means specifying via tool_choice that the model must call a certain tool or must call some category of tool; on the OpenAI side this corresponds to tool_choice: "required" or naming a specific function. Sonnet 5.5 does not support this mode—setting tool or any errors out directly. A workable alternative is to keep auto and let the model decide, while enabling strict: true on the function definitions so the server constrains the argument structure against a JSON Schema, thereby eliminating failures like "malformed arguments"; then explicitly state the trigger conditions and non-applicable scenarios in the system prompt, using prompt constraints in place of a forcing mechanism. Note the distinction: strict only guarantees arguments conform to the schema, not that the model will actually call the tool, so for workflows that must produce structured output, you should still validate and retry in your outer code.

Prompt caching: write the first time, read the second

Caching pays off for any content sent repeatedly: long system prompts, policy documents, repository summaries. The minimum cacheable prompt for both models is 512 tokens. The example puts a refund policy document in system and tags it with cache_control: {"type": "ephemeral"}.

The expected behavior is that the first call reports a cache write, and a second call within five minutes reports a cache read. The original article says that at Sonnet 5.5's launch, sending three consecutive calls with the same prefix produced one write and two reads—a pattern you can use directly to verify whether your own cache is actually hitting.

At gateway pricing, a cache read is one-tenth of fresh input: Sonnet 5.5 is $0.12 per million (input 1.20, cache write 1.50), and Haiku 5.5 is $0.009 (input 0.09, cache write 0.1125).

Prompt caching is an Anthropic API capability: when the request prefix is exactly identical, the server can reuse the KV cache computed last time, skipping re-encoding of repeated content and reducing both latency and cost. To use it, mark cache_control: {"type": "ephemeral"} in the messages or system prompt; the cache lasts about five minutes, and hits during that window are billed at the cache read price, after which it must be written again. Caching requires an "exact prefix match," so if the system prompt contains a dynamic timestamp or user ID, your hit rate drops straight to zero. The minimum cacheable length is 512 tokens; prompts below that threshold won't produce a cache entry. Note especially that both cache read and cache write token counts go toward Haiku 5.5's 100K pricing threshold determination, so caching saves money but won't help you get around the pricing cliff.

The 100K pricing cliff: the math and real numbers

Anthropic's rule for Haiku 5.5 is: when a request's prompt exceeds 100,000 tokens—counting new input, cache reads, and cache writes—every rate on that request is multiplied by five, including the output rate. Sonnet 5.5 has no such step within its 1M window.

The cost function in the original article reproduces this rule, and the numbers it produces are telling:

• 99K prompt + 1K output: Haiku $0.00936, Sonnet $0.12480
• 101K prompt + 1K output: Haiku $0.04770, Sonnet $0.12720
• The same 101K split into two 50.5K requests: Haiku $0.01000
• 150K prompt (140K cache read + 10K new input) + 2K output: Haiku $0.01530, Sonnet $0.04080

Just two thousand extra tokens makes the Haiku request cost 5.1 times as much. Splitting into two requests below the threshold cuts cost by about 79%—though you'll of course pay for an extra merge step. Caching won't save you, because cache reads count toward the threshold too.

But this table shouldn't be read as "switch to Sonnet above 100K." The original article makes it clear: past the cliff, Haiku 5.5 is still 37.5% of Sonnet 5.5's price for the same request, and a quarter of it at Anthropic's list price. The reason to move long-prompt tasks to Sonnet should be that Haiku isn't good enough, not to save money.

To catch this cliff in production, compute the prompt size from each response's usage: input_tokens + cache_read_input_tokens + cache_creation_input_tokens, and log it when it exceeds 100,000.

Bill reconciliation and common errors

Every gateway response carries an x-apimodels-request-id header, and non-streaming responses also carry x-apimodels-cost. Using the records endpoint GET /v1/records/{id} you can get the billed amount and the token usage behind it. If it doesn't match your own calculation, compare usage first—thinking tokens counting as output and the three-way split of cache tokens are the most common sources of discrepancy.

Among the errors listed in the original article, a few are worth knowing in advance: on Sonnet 5.5, thinking: {"type": "disabled"} returns a 400—use between_tools instead; on Haiku 5.5, ending with an assistant message returns a 400; a stop_reason of max_tokens with no text means thinking consumed the entire limit; and a streaming interface that goes silent between tool calls is because the inter-tool explanations arrive as thinking blocks while text defaults to empty. There's also one from the gateway itself: prompts estimated to exceed the 1M window are rejected before sending—for example, reporting roughly 3.06 million tokens over the limit.

Trade-offs around the gateway

The original author discloses that they work at apimodels.app, and the example's base_url points to that gateway. Its positioning is one API key for both Anthropic's native Messages endpoint and the OpenAI-compatible endpoint, covering 140+ image, video, audio, and language models; both 5.5 models have multiple upstream channels with automatic failover, and failed requests aren't billed. On pricing, Sonnet 5.5 is $1.20 / $6.00 (60% of list price), and Haiku 5.5 is $0.09 / $0.45 (90%).

The author also spells out when it doesn't apply: if you need Anthropic's Message Batches API (the gateway has no batch endpoint), or you need to sign a contract or data processing agreement with Anthropic itself, this isn't the route to take.

Finally, the limitations the original article flags itself: the code was written to match the request shapes in Anthropic's documentation, but the author did not actually execute it; prices and behavior were verified on October 17, 2026, and should be re-checked before planning quarterly budgets.