Remember when Sonnet 5.5 showed up six days after Opus 5.5? September 22 for Opus, September 28 for Sonnet. Two models, one week, and a line in both announcements saying Haiku 5.5 would join the family “in the coming weeks.” I read that and immediately started sketching a router config for a model that did not exist yet.
That was two and a half weeks ago. As of October 8, 2026, Haiku 5.5 is still unreleased. No date, no price, no context window, no model ID. The current lineup is Opus 5.5, Sonnet 5.5, and Haiku 4.5. The small model sat out the party.
Why bot builders care about the small one most
If you build agents for a living, the cheap fast model is the one you think about constantly. Opus handles the hard reasoning calls. Sonnet does the bulk work. But the small model is what runs your classifiers, your intent routers, your tool-argument validators, your “is this message spam” checks, your summarizers that fire on every single turn of a conversation.
Those calls add up. In the agent architectures I ship, the small model handles the majority of total requests by a wide margin, even though it accounts for a minority of the interesting work. Haiku 4.5 currently sits at $1 per million input tokens and $5 per million output. Sonnet 5.5 is $2/$10, Opus 5.5 is $4/$20. That spread is the entire reason tiered routing exists.
So when the cheapest tier in your stack is a generation behind the other two, you feel it in a specific way. Your routing logic now spans two model families. Prompts tuned for 5.5 behavior do not always transfer cleanly down to a 4.5 model. Capability assumptions you can make for Sonnet, you have to re-test for Haiku.
What “in the coming weeks” actually means for your roadmap
Anthropic said it twice. Once on the Opus 5.5 launch page, once again around Sonnet 5.5 on September 28. Same phrasing both times. That is a confirmation of intent, not a schedule. Nothing has been published about pricing, the context window, or the model identifier string you would need to call it.
I take that as a planning signal rather than a planning input. Here is how I am treating it in active projects:
- Do not block on it. If a feature needs a fast tier today, ship it on Haiku 4.5. A model that exists beats a model that was mentioned.
- Keep model IDs in config, never inline. Obvious advice, routinely ignored. When the Haiku 5.5 ID lands, swapping it should be one environment variable, not a grep across forty files.
- Write evals before the model ships. This is the highest-value thing you can do during a waiting period. Build a test set of the exact small-model tasks in your pipeline: intent classification, JSON extraction, short summaries, safety pre-checks. Score Haiku 4.5 on it now. When 5.5 arrives you get a comparison in an afternoon instead of a vibes-based guess.
- Do not assume pricing. Opus 5.5 at $4/$20 came in below where a lot of people expected a flagship to land. That does not tell you what Haiku 5.5 will cost. Leave the number out of your cost models until it is published.
The architecture lesson hiding in the delay
This gap is a free audit of how tightly coupled your system is to a specific model. If a new small model dropping tomorrow would mean a week of refactoring, that is not a vendor problem. That is a design problem you can fix while you wait.
The pattern I keep coming back to is a thin routing layer that takes a task type and returns a model handle, with capability requirements declared per task instead of per model. A task says “I need structured output and a short context.” The router decides who serves it. When a new tier appears, you register it, run your evals, and move tasks over one at a time based on measured results rather than release-day enthusiasm.
That approach also protects you from the opposite scenario, where the new small model turns out to be a sidegrade for your particular workload. It happens. Benchmarks measure general capability; your pipeline measures your pipeline.
What I would do this week
Build the eval use. Pin your model IDs to config. Keep shipping on 4.5. Check Anthropic’s model docs occasionally rather than refreshing a release-notes page every morning, because the model ID appearing in the API reference is usually the real signal, not the blog post.
The waiting part is not the interesting part. The interesting part is whether your bot architecture can absorb a new model tier without a rewrite. Right now, with a confirmed-but-absent model on the horizon, you have a rare window to find out cheaply. I would use it.
🕒 Published: