Claude Haiku 5.5: Effort Levels and Practical Uses — Part 1

I use Claude Haiku 5.5 for translations, quick text changes, corrections, and light deployment work. Those jobs need a model that follows a narrow brief and finishes without turning a small edit into a project.

The effort setting matters because those jobs are not equally difficult. Fixing a typo and translating a page with technical terminology deserve different starting points.

This is part 1 of AI Models in Practice, a series about choosing models for actual work. The examples below are reusable prompts and proposed settings. I have not run a controlled comparison of every effort level, and the sample translations are editorial examples, not recorded Haiku outputs. Model details and prices were checked against Anthropic's documentation on October 12, 2026.

Table of contents

What is Claude Haiku 5.5?

Claude Haiku 5.5 is Anthropic's small-model option for high-volume, time-sensitive work. Anthropic released it on October 7, 2026 and positions it for summaries, classification, extraction, routing, and scoped subagent tasks. The Claude API model ID is claude-haiku-5-5. See the Claude Haiku 5.5 launch announcement.

The Haiku 5.5 model overview lists text and image input, text output, a one-million-token context window, and up to 128,000 output tokens in the Messages API. It uses adaptive thinking by default. A large context window describes capacity; it does not establish that sending your whole repository is useful or economical.

I would give Haiku a supplied paragraph, a glossary, and a precise editing task before asking it to interpret an entire business. The narrower brief makes the result easier to inspect.

What is Haiku 5.5 good for?

My practical shortlist starts with the work I already use it for:

Other tasks worth evaluating include extracting fields from a supplied document, sorting messages into known categories, and summarizing a short support conversation. These are proposed uses, not results from my own benchmark.

For broad engineering work, the model choice deserves another look. Anthropic's launch material recommends Sonnet 5.5 and Opus 5.5 for more complex agentic coding. Increasing Haiku's effort does not guarantee the same capability as a larger model.

What do the five effort levels mean?

Haiku 5.5 supports low, medium, high, xhigh, and max. The default is medium. Effort steers how much work the model spends on a response; it is not a fixed token budget or an accuracy guarantee. It affects thinking, answer text, and tool calls. See Anthropic's effort documentation.

My starting rule would be medium, then adjust using the errors you see. For a trivial correction, try low. For a glossary-sensitive translation, compare medium with high. Keep the prompt and inputs the same so you can tell whether the setting helped.

A deployment can involve only one command and still carry substantial consequences. I would choose its verification and approval requirements independently of effort.

Proposed workflow, not benchmark evidence. Acceptance means the result passed the checks for that task; publication and production actions retain their separate approval steps.

How I would set effort for translations

Translation is the clearest example of why one default cannot cover everything. These settings are starting hypotheses for evaluation, not measured winners.

Low for short, literal text

A short status message has little ambiguity:

Translate from Swedish to British English.
Return only the translation.
Keep the order number and date unchanged.

Source:
Din beställning 1842 skickades den 12 oktober 2026.

An acceptable editorial reference is: “Your order 1842 was dispatched on 12 October 2026.” The important checks are the order number, date, and meaning. Several English phrasings can pass.

I would try low here, then move up if it drops a detail. Adding extra reasoning to this prompt should earn its place through a better result.

Medium for normal website copy

For a paragraph, I would start at medium and name the audience, locale, tone, and protected terms:

Translate the supplied Swedish text into British English.
Audience: customers reading a service page.
Tone: direct and friendly. Avoid sales hype.

Preserve:
- brand names and product identifiers
- numbers, currencies, and factual qualifiers
- Markdown links and their destinations
- the paragraph structure

Do not add claims or remove limitations.
Return only the translation.

Source:
Vi uppdaterar normalt sidan inom två arbetsdagar.
Tiden kan bli längre om underlaget behöver kompletteras.

An editorial reference could be: “We normally update the page within two working days. It may take longer if we need additional information.” A version that promises an update within two days has changed the claim.

Anthropic's multilingual support guide recommends stating source and target languages and accounting for regional context. Its published language table covers older models, including Haiku 4.5; it is not evidence of Haiku 5.5's translation accuracy.

High when terminology or ambiguity needs attention

Some terms depend on the business context. The Swedish word “reklamation” should not automatically become “advertising.” A suitable English rendering could involve a complaint or a claim about a faulty product, depending on the sentence.

Translate this product-support text from Swedish to British English.
Use the supplied glossary and preserve every qualifier.

Glossary:
reklamation = complaint about a faulty product
återbetalning = refund

If a phrase remains ambiguous, flag it in a separate note.
Do not resolve uncertainty by inventing a policy.
Return two sections: Translation and Ambiguities.

Source:
Kontakta oss om du vill göra en reklamation.
En återbetalning förutsätter att ärendet har godkänts.

I would compare medium and high for this kind of task. The success criterion is whether the translation preserves the condition and uses the intended terminology. Fluent wording alone is insufficient.

For structured content, I would send translatable strings with stable identifiers. My application would check that every identifier returns once and that protected values survive. Asking a model to preserve a large JSON file does not replace parsing and validation.

Quick text changes and corrections

A correction prompt should define the permitted edit. Otherwise a request to fix grammar can turn into a rewrite.

Correct spelling, grammar, and punctuation in this English paragraph.
Keep my voice, meaning, numbers, and level of certainty.
Do not add examples, claims, headings, or promotional language.
Return only the corrected paragraph.

Text:
We has updated the page, but the payment tests is not finished yet.

The editorial reference is: “We have updated the page, but the payment tests are not finished yet.” A version that says the page is fully tested fails the brief.

Low is a reasonable setting to evaluate for a sentence like this. Medium is my proposed starting point for several paragraphs, protected links, or multiple constraints.

For a text change, ask for the specific result: “Cut this to 80 words, preserve the two limitations, and retain the link.” Word count and link preservation are checks you can run independently of the model.

Light deploy work: define what counts as done

I include simple deployment work among my Haiku uses, but “simple” needs an explicit scope. A known deployment procedure for an approved text change is a different task from diagnosing a broken release or deciding how to migrate a database.

A reusable instruction could be:

Prepare this approved text change for deployment.
Read the project's current deployment procedure and target.
Check the diff and run the required verification.

Report:
- the exact change and intended environment
- commands actually run and their results
- checks that failed or could not run
- rollback instructions from the project procedure

Do not change credentials, infrastructure, or the release scope.
Stop before commit, push, or production deployment until I approve.
After an approved deployment, inspect the public result.
A successful command alone does not prove the change is live.

For preparation and checks, I would start at medium. If the work requires investigating failures across systems, I would reassess the model and effort instead of calling it a light task.

Anthropic's Haiku-specific prompting guide notes that low-effort agents with long prompts can stop early or omit checks. It recommends explicit verification instructions. The guide also notes occasional empty visible replies in multi-turn conversations at xhigh, and tool-call problems when thinking is disabled alongside structured output. An integration should detect incomplete results rather than silently accept them.

How do I change effort in Claude or the API?

In the Claude app, open the model menu beside the send button, select Haiku 5.5, then choose Effort. Available choices may depend on account or administrator settings. Anthropic says thinking cannot be switched off for Haiku 5.5 in the Claude app. See Change the model, effort, and thinking settings.

The API exposes more direct control. A minimal request body looks like this:

{
  "model": "claude-haiku-5-5",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "medium" },
  "messages": [
    {
      "role": "user",
      "content": "Translate the supplied Swedish paragraph into British English. Preserve names, numbers, and links."
    }
  ]
}

This is an illustrative request shape, not a request I executed. Supply the paragraph in the user message. max_tokens is a cap, not a reservation or an instruction to produce a long answer.

Anthropic's Haiku 5.5 migration guide explains that thinking consumes that output budget, so a small limit can truncate the response before visible text appears. Select response blocks by their type, rather than assuming the first block contains the answer.

For new API requests, omit temperature, top_p, and top_k. Replace the older enabled-thinking-plus-budget_tokens configuration with adaptive thinking. The API permits disabled thinking at low, medium, and high; xhigh and max require adaptive thinking. The guide also lists provider differences, so validate your actual platform before migrating.

Keep the API key on the server. The effort field is configuration, not a reason to put credentials in frontend code.

What does Haiku 5.5 cost?

Anthropic's API pricing documentation lists these standard rates in USD per million tokens, checked October 12, 2026:

The higher rate applies to the request, including input accounted for as cache reads or writes. These are API token prices; a Claude subscription is a separate product. Cache writes, server tools, and platform modifiers can add costs.

For an illustrative uncached request with 2,000 input tokens and 1,000 total billed output tokens:

Input:  2,000 / 1,000,000 × $0.10 = $0.00020
Output: 1,000 / 1,000,000 × $0.50 = $0.00050
Total:                            $0.00070

That calculation excludes extra charges and is not a measured translation cost. Count thinking in billed output. Higher effort can change token use, so the price table alone cannot predict the cost of a completed task.

Best practices I would keep across these jobs

Give the model the smallest complete task. Include the glossary or approved source text it needs, and avoid unrelated material.

State the output contract. For a translation, name the two languages and locale. For an edit, specify which facts and formatting must survive. For an agent, define the checks and stopping point.

Treat source text as content to transform. A sentence embedded in a document should not gain authority to change the task, access credentials, or publish content.

Validate the result against the task. Check protected terms, numbers, links, and missing passages. For code or deployment work, inspect actual test and runtime evidence.

Escalate using a concrete failure. A missing qualifier suggests a different prompt or effort level. A task that keeps expanding may need Sonnet or Opus. Repeat failures should trigger review, not an endless increase in effort.

How I would test the settings before relying on them

I would build a small evaluation set from 20 approved, anonymized examples: ten translations, five corrections, and five constrained text edits. Those counts describe a proposed test, not completed research.

Run low, medium, and high with the same inputs and acceptance criteria. Repeat the cases to expose inconsistent behavior. Have a fluent reviewer judge translations without seeing the setting.

Record the exact model, effort, prompt version, elapsed time, billed tokens, and defects. Count lost qualifiers, changed numbers, broken links, omitted text, and unnecessary rewrites. Compare cost per accepted result, including repair work.

For deployment assistance, evaluate separate preparation tasks in a non-production environment with a known expected outcome. Production actions remain subject to the project's approval procedure.

The series starts with the small jobs

Haiku is the first part because translations, corrections, and short edits make the tradeoffs visible. You can inspect whether a sentence kept its meaning and whether a link survived.

The proposed next parts cover Sonnet for daily coding and analysis, Opus for harder work, and a final guide to routing tasks between models. Each part will use the same distinction: documented capabilities, my actual use, and tests still to run.