The paper details the transition from Claude Haiku 4.5 to Claude Haiku 5.5, a model optimized for high-volume, latency-sensitive tasks including classification, routing, extraction, and subagent operations. The update introduces a 1M token context window and a 128k output token capacity, while utilizing a new tokenizer that results in approximately 30% higher token counts for identical text compared to the 4.5 version.

Core Methodology and Technical Specifications

Adaptive Thinking and Effort Parameters
The model integrates adaptive thinking by default, enabling the system to autonomously determine the duration and intensity of its internal reasoning process. Users can influence this process using an effort parameter rather than manual budget constraints.

• The budget_tokens parameter used in previous versions is now deprecated in favor of this adaptive system.
• Disabling the thinking process is permissible via thinking: {"type": "disabled"}, though the effort parameter is recommended for balancing latency, cost, and response quality.

Architecture and Tooling

• Browser Use: A new native tool for browser interaction is available via the Claude API and Google Cloud.
• Computer Use: To support computer-based automation, developers must migrate from computer_20250124 to the updated computer_toolset_20260801 specification.
• Content Block Handling: Because responses may now begin with thinking blocks, integration code must be updated to programmatically select content blocks by their type rather than assuming a fixed position.

Operational Constraints and Breaking Changes
The transition mandates several technical adjustments to API integration:

1. Sampling Constraints: Non-default sampling parameters (temperature, top_p, top_k) are no longer supported and will trigger an error.
2. Message Sequencing: Assistant message prefilling is restricted; all messages must end with a user-initiated turn.
3. Refusal Handling: Developers must implement logic to capture the refusal stop reason, as the model now utilizes safety classifiers that provide explicit feedback when a request is declined.
4. Data Integrity: Thinking blocks are cryptographically or logically scoped to the originating account. If replaying conversations across accounts, requests must be routed through the original account, and the conversation must remain append-only to prevent invalidating existing thinking blocks.
5. Token Budgeting: Due to the 30% increase in tokenization density, all prior cost estimates and max_tokens limits must be recalculated. Since thinking blocks are counted against the max_tokens limit, developers must set sufficiently high output bounds to ensure complete response generation.