Claude Haiku 3.5 is no longer a live option on Anthropic's own API. Anthropic retired claude-3-5-haiku-20241022 on February 19, 2026 and names claude-haiku-4-5-20251001 as its replacement. For a team that still has the old ID in code, configuration, tests, or runbooks, this is a required migration, not a contest that needs a winner.
This guide covers Messages API workloads on Anthropic-operated platforms. Amazon Bedrock and Google Cloud manage their own retirement schedules and use different model ID formats, so teams on those services must confirm provider status separately. The steps below report no HUMAI API call, output comparison, latency measurement, bill, deployment, or production result.
The safe question is narrower: what has to change before Haiku 4.5 can carry the same business task under an explicit quality, cost, throughput, and data boundary? A model-name edit is only one line in that answer.
The direct API comparison has ended
Anthropic's model lifecycle page defines retired as unavailable, with requests to the retired model expected to fail. It lists Haiku 3.5 as retired and Haiku 4.5 as active on July 17, 2026. It also gives Haiku 4.5 a tentative retirement date no sooner than October 15, 2026. That phrase is not a promised shutdown date, but it is a reason to keep lifecycle monitoring in the runbook.
The dates apply to the Claude API, Claude Platform on AWS, and Microsoft Foundry. Anthropic says partner-operated Amazon Bedrock and Google Cloud schedules may differ. Do not use a provider's continued listing of Haiku 3.5 as evidence that the Anthropic API still accepts it, and do not use the Anthropic date to predict a partner cutoff.
A team that has no retained Haiku 3.5 baseline cannot recreate a direct-API side-by-side test after retirement. It can still migrate responsibly by evaluating Haiku 4.5 against approved examples, saved outputs, labeled incidents, schema fixtures, and the current non-AI process. That distinction prevents a manufactured benchmark from entering the release record.
Start with a dependency map, not a model swap
Search beyond application source. Model IDs commonly live in environment variables, feature flags, job definitions, infrastructure templates, notebooks, evaluation scripts, dashboards, alerts, support playbooks, cost models, and vendor integrations. Anthropic's lifecycle guidance also points teams to a Console usage export broken down by API key and model, which can reveal traffic that a repository search misses.
Assign one owner to every dependency. Engineering owns request compatibility and deployment. The domain owner defines acceptable output. Finance approves the revised usage model. Security or privacy reviews the data path. Operations owns alerts and fallback. A migration is ready only when each owner can point to retained evidence.
| Dependency | Old assumption to find | Haiku 4.5 action | Evidence to retain |
|---|---|---|---|
| Model route | Haiku 3.5 ID, alias, provider ID, or hidden default | Set the provider-specific Haiku 4.5 pinned snapshot | Configuration diff and resolved runtime ID |
| Sampling | temperature and top_p sent together |
Keep only one parameter | Request fixture and successful contract test |
| Tools | Legacy text editor, code execution, or undo_edit |
Use current tool versions and remove the command | Tool-call fixtures and side-effect controls |
| Stop handling | No branch for refusal or context exhaustion |
Handle both documented stop reasons | Stop-reason fixtures and logged workflow outcomes |
| Prompts | Wording tuned around Haiku 3.5 behavior | Version prompts and test the new response style | Prompt hash, rubric, and reviewed examples |
| Capacity and cost | Old token prices, cache rules, or rate assumptions | Reprice and load-test within current limits | Token ledger, cost forecast, and 429 handling |
| Data route | Retention or training assumption copied from another product | Verify the API, feature, provider, and contract path | Approved data classes and retention setting |
Request and response changes can stop the release
Anthropic's Haiku 4.5 migration checklist starts with the full Claude API model ID claude-haiku-4-5-20251001. The versioning documentation says this dated ID is a pinned snapshot. The shorter pre-4.6 alias is a convenience pointer, so a release record that needs repeatability should capture the resolved dated ID.
Provider syntax is not portable. Anthropic currently documents anthropic.claude-haiku-4-5-20251001-v1:0 for Amazon Bedrock and claude-haiku-4-5@20251001 for Google Cloud. Record the actual provider and region before changing configuration. A syntactically valid ID for one platform can be wrong on another.
The first breaking request rule is sampling. A Claude 3.x request that sets both temperature and top_p must be reduced to one of them; Anthropic says Haiku 4.5 returns a 400 error when both are present. Test the serialized request, not only the SDK object, because wrappers may add defaults.
The second rule concerns tools. Anthropic names text_editor_20250728 and code_execution_20250825 in the Haiku 4.5 checklist, says legacy tool versions are unsupported, and tells teams to remove undo_edit. Inventory tool definitions, permissions, parsers, and every side effect. A passing text-only call does not prove that a tool workflow survived.
Response handling needs two explicit branches. One covers the refusal stop reason. The current guide also says Claude 4.5 and later models can return model_context_window_exceeded when generation reaches the context-window limit instead of the requested max_tokens limit. Neither outcome should drift into a success path that assumes complete task output.
Prompts are another migration dependency. Anthropic describes Claude 4 models as more concise and direct, which can change a format, tone, explanation length, or downstream parser even when the request succeeds. Treat the current prompting guidance as a review input, then prove the exact prompt version against the team's rubric.
Capability documentation is an evaluation hypothesis
The current model overview lists Haiku 4.5 with text and image input, text output, multilingual and vision support, a 200k-token context window, a 64k-token maximum output, and optional extended thinking. The migration guide also points to context awareness, output capacity, coding, and reasoning as areas to examine.
Those are product specifications and Anthropic characterizations. They do not show that a support classifier, document extractor, code assistant, or internal search tool improves under a team's prompts and data. A larger output ceiling is not a reason to request longer responses. Extended thinking can add token use and affects prompt-caching efficiency. Vision support does not establish accuracy for a particular document or image.
Translate each claimed capability into a falsifiable acceptance condition. For a schema task, measure valid fields, omissions, unsupported values, and parse failures. For retrieval-assisted answers, require citations to supplied evidence and score unsupported claims separately. For a tool workflow, verify tool choice, arguments, permission boundaries, refusals, and side effects. For a user-facing draft, define tone and prohibited content before reviewers see the output.
Anthropic's model-selection guidance recommends testing actual prompts and data, response accuracy, quality, edge cases, and cost tradeoffs. The team owns those results. This article supplies no score and no winner claim.
Reprice the workload before testing at volume
The legacy article said the two models had the same price. Anthropic's live pricing table does not support that statement. On July 17, 2026, it lists Haiku 4.5 base rates at $1 per million input tokens and $5 per million output tokens. Its retired Haiku 3.5 row lists $0.80 and $4. These are direct API base rates in USD, not a complete workload bill.
Build the forecast from retained usage: uncached input, cache writes by duration, cache reads, output, batch eligibility, provider endpoint, region, retries, and optional thinking tokens. Keep development and production separate. Use p50 and high-volume periods from the team's own logs instead of multiplying a single friendly request by a monthly guess.
Output behavior matters because output tokens cost more than base input tokens. Set max_tokens from the required deliverable, not from the 64k model ceiling. If the migration changes prompt caching, tool definitions, or response length, a simple old-token-count substitution will miss part of the cost.
Haiku 4.5 also has limits separate from Haiku 3.5. Anthropic's rate-limit reference distinguishes monthly spend caps from request and token rates, explains that limits depend on the organization and tier, and documents 429 responses and retry information. Capture the current Console limits, workspace caps, headers, retry policy, and traffic ramp. No public tier table can prove how a particular organization behaved under load.
Use a retained-baseline migration test
Freeze the evaluation before inspecting Haiku 4.5 output. Start with approved production examples, known failures, edge cases, refusals, malformed input, and cases that must escalate. Remove secrets or obtain permission for every data class. If Haiku 3.5 outputs were retained lawfully, label them as historical artifacts with their prompt, model ID, settings, and date. If they were not retained, compare Haiku 4.5 with a human-reviewed expected result or the current non-model process.
- Version the packet. Hash the inputs, system prompt, user prompt template, tools, schemas, model ID, SDK, and evaluator instructions.
- Separate hard gates from preferences. A valid schema, correct tool permission, required refusal, or prohibited disclosure is a hard gate. Tone and concision can be scored separately.
- Blind the review where practical. Hide model labels from domain reviewers and keep the route key with a different owner. This reduces expectations from becoming results.
- Record cost and capacity from responses. Capture input, cache, output, retry, stop reason, error, and timing fields produced by the reader's own run.
- Inspect disagreements. Do not approve on one average. Review high-consequence errors, missing evidence, invalid arguments, refusals, and failures concentrated in a task class.
- Set the ship rule in advance. State which gates require zero failures, which metrics have thresholds, who may accept a tradeoff, and what sends the build back.
Run the packet in a development environment without a production side effect. Tool calls should target a sandbox or stop before execution. Keep the raw request and response evidence allowed by the team's data policy. A slide containing only aggregate percentages cannot diagnose a parser, prompt, or safety regression later.
The privacy gate depends on the product surface
Changing the model ID does not answer where data goes. Anthropic's commercial retention page says direct API inputs and outputs are automatically deleted from its backend within 30 days by default. It lists exceptions for features with longer customer-controlled retention such as Files API, different agreements, Usage Policy enforcement, and legal requirements. Other commercial products that save conversations retain chats or coding sessions for the product experience.
Anthropic's commercial training statement says chats and coding sessions are not used to train its models unless the customer participates in the Development Partner Program, reports material through feedback, or otherwise opts in. That statement is not the same as zero retention.
A zero-data-retention arrangement must also be verified, not assumed. Anthropic's ZDR scope page says approval and product eligibility matter, safety-classifier results can still be retained, and organizations can confirm the setting in Privacy Controls.
The migration record should name the commercial product, Anthropic or partner route, workspace, enabled features, approved input classes, retention setting, training opt-in state, logs, feedback controls, and deletion process. A policy for the direct API does not automatically describe Bedrock, Google Cloud, a saved Console conversation, or a file feature.
Cut over with a forward-only fallback
On Anthropic's direct API, rollback cannot mean restoring the retired Haiku 3.5 ID. Define a forward-only fallback before release: return the task to a human queue, pause the feature, use the previous application build while retaining the compatible Haiku 4.5 contract, or route an approved task to another active model whose cost, data, and evaluation gates have already passed.
Begin with a bounded internal or low-consequence cohort. Watch 400 contract errors, 429 throttling, refusal handling, schema failures, tool denials, token use, cost, and the task's quality gates. Expand only after the named owners sign the same evidence, and preserve a kill switch that does not depend on the retired endpoint.
The final cutover record should contain:
- every production route and its provider-specific pinned model ID;
- the sampling, tool, prompt, parser, refusal, and retry changes;
- the hashed evaluation packet, reviewer roles, results, exceptions, and approval;
- the direct and peak cost forecast, current limits, workspace caps, and alerts;
- the product surface, data classes, retention, training, and deletion approval;
- the deployment cohort, observation window, pause owner, and forward-only fallback;
- the next lifecycle review date for Haiku 4.5.
If any line has no owner or retained evidence, the migration is not ready. Keep the affected workload paused or human-operated until the missing contract, evaluation, budget, capacity, or data control exists.
