Prefilling Is Dead; Chaining Lives On

What prefilling was

Response prefilling was an API trick: you supplied the beginning of Claude's answer yourself, and the model continued from there. Start the assistant message with { and you forced JSON output with no preamble. Start it with "As Dr. Chen, I" and you locked in a persona. For years it was the go-to move for format control.

It's gone. From Claude 4.6 onward, prefilled assistant responses are no longer supported — the API returns a 400 error. Any guide still teaching prefills is describing models you're not using.

Migrating each prefill use case

Every prefill trick has a cleaner modern replacement:

Structured Outputs is the big one: instead of nudging the model toward valid JSON and hoping, you declare the schema and the API guarantees conformance. What used to be a fragile trick is now a contract.

Chaining: the technique that survived

Prompt chaining means splitting a task into steps and making a separate API call for each step, feeding each call's output into the next. It survived the model generations because it solves problems that no amount of model quality removes:

Inspectability. Each intermediate output is a real artifact you can log, evaluate, and debug. When a five-step pipeline misbehaves, you can see exactly which step went wrong — impossible when everything happens inside one opaque call.

Hard gates. Between calls, your code runs. You can validate an output against a schema, check a word count, run tests — and refuse to proceed, retry, or branch. A gate is a guarantee, not a request.

Per-step optimization. Each step gets its own focused prompt, its own examples, even its own model — a cheap fast model for extraction, a stronger one for synthesis.

The canonical pattern: self-correction

The most common chain in practice is draft → review → refine:

# Call 1: draft
summary = claude(
    "Summarize the key obligations in this contract for a "
    "non-lawyer audience:

" + contract_text
)

# Call 2: review against a rubric
review = claude(
    "Grade this contract summary against the rubric. For each "
    "criterion — accuracy, completeness, plain language — list "
    "specific problems.

<summary>" + summary + "</summary>"
)

# Call 3: refine using the review
final = claude(
    "Revise the summary to fix every problem in the review.

"
    "<summary>" + summary + "</summary>
"
    "<review>" + review + "</review>"
)

Each step is logged, evaluable, and independently improvable. If reviews keep flagging the same accuracy issue, you fix the drafting prompt — you know exactly where the weakness lives. The reviewing call also benefits from fresh perspective: it isn't attached to the draft the way the call that wrote it would be.

When NOT to chain

Here's the equally important flip side: modern models need chaining far less than older ones did. With adaptive thinking, one call can plan, reason through subproblems, and self-check internally. With native subagent orchestration, models can delegate on their own. Most multistep reasoning no longer needs to be manually decomposed.

So the modern rule: chain for inspectability and hard gates, not for reasoning ability.

Chain when:

• You must log or evaluate intermediate outputs (compliance, debugging, evals).
• A step's output needs programmatic validation before the next step runs.
• Steps genuinely benefit from different prompts, examples, or models.

Don't chain when:

• You're decomposing only because you doubt one call can handle it — test the single call first; it's simpler, faster, and cheaper.
• The "steps" are just reasoning stages — thinking already covers that.
• No gate between steps would ever reject anything — then the chain is just latency.

The pattern to internalize: prefilling died because a guarantee (Structured Outputs) replaced a nudge. Chaining lives because gates between calls are also a guarantee. The techniques that survive model generations are the ones that give you control the model can't give you from inside a single call.