Vibe coding model comparison: why Haiku wins most loops in 2026

For the first 80% of vibe coding (one sentence in, mobile app out, refine by talking) Claude Haiku 4.5 is the right default. It is fast enough that the first HTML token lands in the preview iframe inside a second on a warm sandbox, and it is cheap enough at $1 input and $5 output per million tokens that the loop tolerates a lot of throwaway turns. Sonnet 4.6 takes over when the app crosses two screens and state has to live somewhere, because the multi-file coordination Sonnet does outweighs the speed Haiku gives up. Opus 4.7 only earns its keep when the agent has to plan a refactor or debug a behavior across multiple files; on a single-screen build it slows the loop without adding output the user can tell apart.

src/components/header.tsx defines a four-entry MODEL_LABELS map. 'default' shows up as 'Fast', 'haiku' as 'Scary', 'sonnet[1m]' as 'Fast+', and 'opus[1m]' as 'Smart'. The 'haiku' label is dramatic on purpose: it is the only model an anonymous or free-tier user can run, and the landing copy advertises sub-30-second builds against it. The '[1m]' suffix on Sonnet and Opus selects the 1M-token long-context variant. Anthropic includes the 1M context window at standard per-token rates on Sonnet 4.6, Opus 4.6, and Opus 4.7, so the 'Smart' label does not carry a context premium; it carries a per-token premium and a latency premium.

Because the benchmarks grade a different loop. Terminal-Bench, GDPval, and SWE-Bench grade single-shot agentic execution against a fixed task. Vibe coding is not single-shot; it is a back-and-forth where the human types a sentence, watches output stream, types another sentence, watches output stream, and decides the app is done when it looks right. The thing that decides whether the loop converges is iteration count per unit of attention. Haiku at 5x cheaper on both input and output, with first-token latency well under a second, lets the human take more shots before they get bored. The output of any single shot is usually worse than what Opus would have written, but the human gets four shots for the price of one, and the fourth shot is usually closer to right than the one Opus produced. The benchmarks do not measure that.

Switch when the change you are asking for has to coordinate across files, or when state has to survive across screens. Concretely: 'add a settings screen and remember the toggle on the home screen' is a Sonnet prompt; 'change the home screen header to teal' is a Haiku prompt. Sonnet 4.6 at $3 input and $15 output per million tokens is 3x the per-token cost, but the work is qualitatively different because Sonnet plans the cross-file edits in its head before writing them. Asking Haiku to do the same thing produces output that compiles but loses the toggle on a route change.

Two cases. First, the planning turn before a real refactor: 'we have three screens, the data is in localStorage, I want to move it to a server component with a Postgres backend, write me a plan and a list of files to change'. Opus is good at producing the plan because it spends more compute reasoning before it writes. Once the plan is in the conversation, you usually drop back to Haiku or Sonnet to do the actual edits, because the plan is the bottleneck, not the typing. Second, hard debugging: 'this animation drops a frame on iOS Safari but not Chrome, what is happening'. Opus is meaningfully better at the kind of cross-context inference where the answer is not in any single file. On a fresh single-screen build, neither of those cases applies, so Opus is paying for compute the user cannot tell apart from Haiku.

Yes, by a non-trivial amount. Anthropic's pricing page notes that Opus 4.7 uses a new tokenizer that may use up to 35% more tokens for the same fixed text compared to previous models. The headline per-token rate dropped (Opus 4.7 is $5 input and $25 output per million versus Opus 4.1 and Opus 4 at $15 and $75) so the net effect is still a real price drop, but the multiplier is not the full 3x you would estimate from the rate card alone. For a vibe coding session where you are passing a system prompt plus conversation history on every turn, the practical effect is that an Opus 4.7 session is roughly 2x cheaper than the same session on Opus 4.1, not 3x.

The model gate at src/app/api/chat/model/route.ts unlocks the same way as for an mk0r-billed paid session, but the inference for every turn is billed against your Claude Pro plan instead of mk0r's shared API key. The 'Fast', 'Scary', 'Fast+', and 'Smart' labels all still apply; what changes is who pays the per-token cost. With the OAuth path, Sonnet and Opus turns count against the rolling 7-day weekly cap on your Pro or Max plan, not against an mk0r usage line. Heavy users who already pay Anthropic for Claude Code typically pick this path because it makes builder turns flat-rate.

The labels are an opinion about the loop, not the leaderboard. Haiku is 'Scary' because it streams an HTML page before you finish reading the prompt you wrote, which is genuinely unsettling the first time a non-developer sees it; the speed crosses a threshold where the artifact feels less like 'I asked an AI for code' and more like 'I asked a thing for an app'. Opus is 'Smart' because it produces the kind of output you would have to read through to evaluate; the win is reasoning quality, not perceptual speed. The picker is telling you a true thing about what each tier feels like to use, not what each tier scores on a benchmark.

Yes, and it is the workflow most heavy mk0r users settle into. Use Haiku for the first three to five prompts, until you have a working prototype that compiles and renders. Switch to Sonnet for the screen-2-and-beyond work where state has to live somewhere. Switch to Opus for one prompt: a planning turn that reads the conversation history and writes a plan for the next chunk of work. Then drop back to Haiku to execute that plan. The pattern works because the expensive part of vibe coding is figuring out what to ask for; once you know what to ask for, Haiku can usually write it.