Why I picked Haiku for Field Kit's either-or questions

Field Kit used to be three tools. One of them, Decision Simulator, took an either-or product question and laid out how the options compared and what would flip the call. It needed to feel fast and still read as reasoned. I put it on Claude Haiku 4.5 instead of Sonnet 4.6 or Opus 4.7, and I'd make the same call again.

The shape of the task picks the model

Decision Simulator did three things in a row. It worked out the three to five things that mattered for the question, compared each option against them, and named the conditions that would flip the answer. All three are a matter of filling in a fixed structure. The reasoning lived in the prompt, not in the model.

When the job is “follow this schema and fill it in sensibly,” you don't need the heaviest model. You need the fastest one that reliably fits the schema and writes like a person who understood the question.

What I measured

Speed mattered most. People leave if nothing happens within about a second, and Haiku 4.5 started streaming in roughly 400 to 600ms, against 1.1 to 1.5 seconds for Sonnet on the same input.

Reliability was close enough. Across 50 test prompts Haiku fit the schema 49 times, and Sonnet and Opus 50 each. One retry in fifty is fine for this.

Cost settled it. Haiku is a fraction of the price of either, and this is a portfolio site, not an enterprise contract.

Where Sonnet won

The other two tools, Experience Mapper and Compass Check, ran on Sonnet. Experience Mapper reasoned over my own project history and wrote a multi-paragraph answer. Compass Check gave one sentence of judgment that had to land. Both got better with the bigger model.

Pick a model per task, not per product. Most teams default to the biggest model they can afford and pay for it in speed and cost. The right call is per task, and often per step inside a task.

Update, August 2026

Experience Mapper and Compass Check moved to Sonnet 5. Decision Simulator stayed on Haiku 4.5, for the same reasons it was there in the first place.

The more useful change came from checking a claim I'd been making. This page said Field Kit showed what each run cost. It didn't. It was estimating. Input tokens were a fixed number plus your character count divided by four, and the “cached” label only meant you had run that tool before in the same browser session. The server had the real numbers the whole time and threw them away.

Fixing that turned up a second problem. Prompt caching, where the model provider reuses the unchanged start of a prompt at a discount, was never happening. The prompt I'd marked for caching was about 800 tokens, and the minimum is 1,024 on Sonnet and 4,096 on Haiku 4.5. Below that, the request quietly skips caching. No error, no warning. Worse, the part I'd marked changed with every question, so it would have missed even if it were long enough.

The fix was to stop caching the part that changes. The full set of background material now sits at the front of the prompt and the question-specific part sits after it, so two unrelated questions share the same start and the second one gets the discount. It's a real trade, not a free win. With the one-hour cache a first run costs twice an uncached one and every repeat costs a tenth, so you're ahead from the third question. I had that number wrong here too, and only caught it by doing the arithmetic instead of repeating it.

The lesson is narrower than the one above it. Measure the thing you're claiming. I'd written a confident note about model choice on a page whose own numbers were guesses.