Claude Haiku 5.5 on Bedrock: A Subagent Field Guide

Claude Haiku 5.5 on Bedrock landed on October 7, 2026, and it is the first Haiku with effort controls, a 1M-token context window and a job description that reads like a subagent’s: fast, cheap, parallel, forgettable. If you run agent fleets, this is the model that will see most of your tokens. Here is what to check before you point production traffic at it.

What Claude Haiku 5.5 on Bedrock shipped

The facts below come straight from the Bedrock model card and the launch post on the AWS Machine Learning blog.

• Context window of 1M tokens, max output of 128K tokens, knowledge cutoff June 2026.
• Text and image in, text out.
• Adaptive thinking is on by default and can be turned off. Effort levels are low, medium, high, xhigh and max, with medium as the default. With thinking disabled, effort is capped at high.
• Lifecycle is active, with end of life no sooner than October 7, 2027.
• Anthropic’s pitch is roughly 75 percent cheaper than Claude Haiku 4.5 for most tasks, and the intended pairing is Claude Opus 5.5 planning while Haiku fans out to parallel workers.

Notice what the launch post does not do: it never shows you the request field for effort. Do not guess it. Open the Messages API reference linked at the end of this article and copy the field from there.

Pick the right model ID and endpoint

There is no in-region invocation on bedrock-runtime for commercial Regions. You go through an inference profile, and the prefix decides where your data may travel.

• global.anthropic.claude-haiku-5-5 routes across most commercial Regions, GovCloud excluded.
• us., eu., au. and jp. prefixes keep traffic inside a geography.
• anthropic.claude-haiku-5-5 is the base ID. It matters for prompt optimization, which only accepts the base ID, and for the bedrock-mantle endpoint.

The AWS docs recommend bedrock-runtime for new applications. The bedrock-mantle endpoint serves only the Messages API and drops Guardrails, Knowledge Bases, Flows and Agents. In GovCloud (us-gov-west-1) mantle is the only in-region option, so that is the one case where you have a reason to care.

Residency is the real decision here. If your compliance team wrote “EU only” in a spreadsheet somewhere, the global. prefix is a policy violation waiting for an audit. Use eu., and ask the API where a given geography can route with GetInferenceProfile from your source Region.

The first call, and the parsing bug waiting for you

Converse is the least annoying way in. It gives you one request shape across models, which matters when your planner is a different model than your workers.

aws bedrock-runtime converse \
  --region us-east-1 \
  --model-id global.anthropic.claude-haiku-5-5 \
  --messages '[{"role":"user","content":[{"text":"Classify: refund request or bug report? Answer with one word. Text: my invoice is wrong"}]}]' \
  --inference-config '{"maxTokens":256}'

Now the trap. With adaptive thinking on, the response can lead with a reasoning block before the text block. The launch post says so explicitly. Code that reads content[0]["text"] will throw a KeyError on the exact requests where the model thought hardest, which is the fun kind of intermittent.

import boto3

client = boto3.client("bedrock-runtime", region_name="us-east-1")
MODEL = "global.anthropic.claude-haiku-5-5"

def ask(prompt: str, max_tokens: int = 512) -> tuple[str, dict]:
    resp = client.converse(
        modelId=MODEL,
        messages=[{"role": "user", "content": [{"text": prompt}]}],
        inferenceConfig={"maxTokens": max_tokens},
    )
    blocks = resp["output"]["message"]["content"]
    text = "".join(b["text"] for b in blocks if "text" in b)
    return text, resp["usage"]

Select blocks by type, never by index. Also keep the usage dict. Reasoning tokens count toward output, so your bill follows outputTokens, not the length of the string you printed.

Effort is a budget, not a vibe

Treat effort the way you treat maxTokens: a per-call knob you set deliberately. A routing call that picks one of five labels does not need the model to deliberate. A call that reviews a diff for a subtle race condition might. Pick a level per task class and keep it in config, not scattered across call sites.

My starting point for an agent fleet:

• Routing and classification: low.
• Extraction from a few documents: medium, the default.
• Code review of a small change, or a computer-use step that must not misclick: high, then measure before going higher.

Run the same 200 labeled examples at each level and log accuracy against output tokens. You are buying a curve. Find the knee and stop there.

Prompt caching and compaction

Subagents tend to share a fat system prompt: tool definitions, policy text, a few examples. That is exactly what caching is for. The model card lists implicit and explicit caching, a 512-token minimum per checkpoint, up to four checkpoints per request, and a 5-minute or 1-hour TTL. Checkpoints are accepted in system, messages and tools.

resp = client.converse(
    modelId=MODEL,
    system=[
        {"text": open("policy_and_examples.txt").read()},
        {"cachePoint": {"type": "default"}},
    ],
    messages=[{"role": "user", "content": [{"text": ticket_text}]}],
    inferenceConfig={"maxTokens": 256},
)
print(resp["usage"])

Check the cache read and write counters in usage after the second call. If they are zero, your prefix is not stable. A timestamp in the system prompt is the usual culprit.

For long-running agents, compaction is available on bedrock-runtime behind the beta value compact-2026-09-04, which keeps a 1M window from becoming a 1M-token invoice.

Feature gaps to check before you commit

Read the support matrix before you design around a feature, because Haiku 5.5 on bedrock-runtime does not support:

• Structured outputs. Ask for JSON in the prompt and validate it yourself.
• Count tokens. Estimate locally, or use mantle where it is supported.
• Intelligent prompt routing.

It does support Guardrails, Knowledge Bases, Agents, Flows, prompt management, client-side tool calling, and computer use. Server-side tool use is limited to tool search, in regex and BM25 flavors. The matrix also has Priority, Flex and Batch tiers marked unsupported while the surrounding text describes some of them, so confirm against your account instead of trusting either.

Cost shape and observability

The model is billed through AWS Marketplace and shows up under the model provider on your invoice, not under Amazon Bedrock. Tell your FinOps people before the first bill surprises them. There is also long-context tiering: prompts over 100,000 tokens use higher rates for input, output and cache read and write, on a separate “Long Context” line item. A 1M window does not mean 1M is priced like 10K.

For monitoring, wire in the Bedrock monitoring docs: CloudWatch for latency and invocation counts, CloudTrail for who called what, and invocation logs if you need payloads. Application inference profiles are supported, so tag one per team or per agent and your cost allocation stops being a guessing game.

A rollout checklist

• Use a geo prefix that matches your residency rules, not global. by default.
• Parse by block type. Test with thinking on and off.
• Set effort per task class and measure accuracy against output tokens.
• Cache the shared prefix and verify the counters move.
• Validate JSON yourself, because structured outputs are not available here.
• Alarm on prompts crossing 100K tokens.
• Keep the planner and worker model IDs in config so you can swap either one.

Other references worth bookmarking: the Converse API guide, the Anthropic Claude Messages API parameters, and AWS’s Haiku 5.5 getting-started notebook.

Haiku 5.5 is not exciting, and that is the compliment. The wins come from boring discipline: right profile, right parsing, right effort, cached prefix. Do those four and the model does the rest of the work for you.

ENKOMPASS IS HERE TO HELP

At Enkompass (enkompass.net), this is our home turf. We design and run Bedrock agent platforms, from inference profile and residency decisions to caching, guardrails and cost allocation for model fleets. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.