Minutes-Long Turns Break Your Harness: Designing Async Agents for Fable 5

Most agent harnesses carry an assumption nobody wrote down: a model call returns quickly. A few seconds of thinking, a burst of tokens, done. That assumption held for a long time. It stopped holding on June 9, 2026, when Anthropic shipped Claude Fable 5 (claude-fable-5) as, in its words, its most capable widely released model — "built for the most demanding reasoning and long-horizon agentic work."

The phrase "long-horizon" is doing a lot of work there. Anthropic's own prompting guidance is explicit: hard-task requests on Fable 5 "can run for many minutes at higher effort," and autonomous runs can "extend for hours." Thinking is always on and adaptive — you cannot turn it off — so a single turn on a genuinely hard problem is not a chatbot reply. It's a work session.

If your harness assumes sub-30-second responses, the timeout you never hit in a year of Opus is about to fire on turn one. This is a redesign, not a config tweak.

Key Takeaways

• Long turns are the default, not the exception. Minutes per hard turn, hours per autonomous run — plan the harness around that, not around chatbot latency.
• Raise client timeouts and use streaming. A blocking request with a 30-second ceiling will kill a legitimate turn. Stream so you see progress and the connection stays alive.
• Move from blocking to async. Fire-and-check-in beats fire-and-wait for anything that runs longer than a coffee break.
• Give the agent a verbatim delivery channel. A client-side send_to_user tool pushes exact text mid-task, because tool inputs are never summarized.
• Skill prompts should authorize the long run. Tell the agent it's operating autonomously and should finish the work before ending its turn — otherwise it stops early with "I'll now do X."

Why the turn got long

Two things changed at once. Fable 5's thinking is always on and adaptive, and you steer its depth with an effort level — low, medium, high (the default), xhigh, and max — set inside output_config. Anthropic's guidance is to start at high and reach for xhigh on capability-sensitive or long-horizon work, meaning tasks expected to run more than 30 minutes.

Read that again: a documented, supported effort tier is explicitly framed for tasks that run over half an hour. That is not an edge case the model wanders into. It's a setting you choose on purpose, and when you choose it you are telling the model to keep working.

The payoff is real. Anthropic reports that Stripe ran a codebase-wide migration on a roughly 50-million-line Ruby codebase in about a day — work estimated at 2+ months by hand. You don't get that kind of leverage from a model that returns in four seconds. You get it from a model that grinds. Your job as the builder is to hold the connection open while it does.

Step 1: Stop blocking. Start streaming.

The single most common failure you'll hit is a client-side read timeout on a non-streaming request. The SDK sends the request, waits for the full response, and gives up at 30 or 60 seconds while the model is still mid-turn. It never crashed on Opus because Opus usually finished first. It will crash on Fable 5.

Two fixes, applied together:

1. Raise the client timeout generously. For xhigh work, a ceiling measured in single-digit minutes is not paranoid — it's correct. Match the timeout to the effort level you requested.
2. Stream the response. Streaming keeps the connection warm and gives you a live token feed, so you can render progress instead of a spinner that looks frozen. A spinner that hasn't moved in two minutes reads as "hung" to every user alive, even when the agent is working perfectly.

While you're in there, remember that Fable 5 returns thinking blocks whose display is either "summarized" or "omitted". The raw chain of thought is never returned. If you continue the same conversation on the same model, pass those thinking blocks back unchanged — other models drop them, but same-model continuation expects them intact.

Step 2: Show progress, or users will kill the run

A minutes-long turn with no visible output trains users to hit cancel. That's the worst outcome: you paid for the thinking, the user never saw the answer, and they've learned the tool is unreliable.

A progress UI doesn't need to be fancy. It needs to prove the agent is alive:

• Stream partial text as it arrives, even summarized thinking, so the screen is never static.
• Surface tool calls as they happen ("reading auth.ts", "running the test suite") — this is the most reassuring signal you can show, because it's concrete.
• Show elapsed time and the effort level, so a two-minute wait on xhigh reads as expected rather than broken.

This is the same discipline that makes long-running loop recipes tolerable to watch. If you build or run automation loops, the progress patterns in the loops channel transfer directly — a loop that iterates for ten minutes needs the same "here's what I'm doing right now" heartbeat as a single long Fable 5 turn.

Step 3: Move to async and scheduled check-ins

For anything that runs longer than a user is willing to stare at a screen, blocking is the wrong shape entirely. Anthropic's guidance says as much: adjust client timeouts, use streaming and progress UIs, and move to async or scheduled check-ins rather than blocking.

The async pattern is straightforward:

1. Accept the job and return immediately with a job ID. Don't hold the HTTP request open for an hour.
2. Run the agent in the background — a worker, a queue, a durable task.
3. Check in on a schedule — poll status, or push updates to the user as milestones complete.
4. Notify on completion rather than making anyone wait synchronously.

Note one hard platform constraint if you deploy on serverless: many hosts cap function execution at 10 seconds on entry-level tiers, and a longer maxDuration in config is silently ignored. A minutes-long Fable 5 turn cannot live inside a request/response function on those plans. Move the long run to a background worker or a scheduled job, and let the web tier only kick it off and report status. This is the same architectural split that orchestration patterns for parallel subagents rely on — the coordinator hands off, it doesn't sit and block.

Step 4: Give the agent a verbatim delivery channel

Here's a subtle failure mode of long autonomous runs. The agent discovers something the user needs verbatim — a generated password, an exact command to run, a legal disclaimer, a precise diff — but it's only halfway through the turn. By the time the turn ends and gets summarized into a final message, the exact string may be paraphrased or lost.

Anthropic's recommended pattern is a client-side send_to_user tool. The trick is that tool inputs are never summarized — whatever the model passes as the tool argument arrives at your handler byte-for-byte. So you register a tool whose only job is to deliver exact text to the user mid-task, and the agent calls it whenever it has something that must survive intact.

A minimal definition you can register looks like this. It's a plain tool schema — nothing exotic:

{
  "name": "send_to_user",
  "description": "Deliver a message to the user immediately and verbatim, mid-task. Use for content that must arrive exactly as written: commands to run, credentials, exact code, or precise instructions. The text is delivered unchanged and is not summarized.",
  "input_schema": {
    "type": "object",
    "properties": {
      "text": {
        "type": "string",
        "description": "The exact text to deliver to the user, unchanged."
      },
      "level": {
        "type": "string",
        "enum": ["info", "action_required", "warning"],
        "description": "How the client should surface this message."
      }
    },
    "required": ["text"]
  }
}

Your client-side handler for this tool does nothing clever: it renders text in the UI exactly as received and returns a short acknowledgment so the turn continues. The value is entirely in the guarantee — the user sees the real string, not a helpful rewrite of it. For agent builders assembling capabilities, this is worth packaging as a reusable primitive; every long-running agent you ship wants it. The wider case for treating capabilities as installable units is the whole premise of the agents channel.

Step 5: Authorize the long run in the prompt

The last piece is behavioral. Fable 5 sometimes stops early with a text-only "I'll now do X" instead of actually doing X, and it can fret about running low on context budget. Both have documented one-line prompt fixes, and both matter more when the turn is long because a premature stop wastes minutes of setup.

Bake these into your skill or system prompt for autonomous work:

• "You are operating autonomously. Don't ask for confirmation — do the work before ending your turn." This kills the "I'll now do X" stop-short.
• "You have ample context remaining." This settles the budget anxiety so the model doesn't wrap up prematurely to save room it doesn't need to save.
• State boundaries explicitly so the agent doesn't wander into unrequested adjacent actions during a long run, where there's more room to improvise.

These small nudges are part of a broader shift in how you write for this model — prompts tuned for older models tend to be too prescriptive and can actually degrade output. If you're auditing your skill library, the companion piece on refactoring prescriptive skills covers that in depth, and the series overview ties the behavioral shifts together.

The takeaway

The mental shift is small to state and large to implement: a Fable 5 turn is a work session, not a message. Once you accept that, the redesign follows on its own. Raise timeouts. Stream. Show progress. Move long work off the request path into async jobs and scheduled check-ins. Give the agent a verbatim channel so exact strings survive. And write prompts that authorize the model to keep working until the job is actually done.

Teams that make this shift get the Stripe-scale payoff — hours of autonomous work compressed into one dispatch. Teams that don't will spend a week debugging timeouts and blaming the model for a harness that was quietly built for a slower, chattier era. The model is ready for long turns. Make sure your harness is too.