How to Build Long-Running Claude Code Workflows with Fable 5.1, Prompt Caching, Progress Updates, and Human Checkpoints

Start with the right mental model: the agent loop is yours

A long-running Claude Code workflow is an application-owned agent loop with durable state, explicit permissions, resumable steps, bounded tools, and human checkpoints. It is not a model independently running infrastructure in the background. Claude Fable 5.1 can reason across a very large context, produce long outputs, call tools through your harness, and expose controls that make extended work more practical, but your application still owns persistence, retries, authorization, audit logging, rate limiting, rollback, and approval gates.

Operational definition: Treat a long-running workflow as a controlled sequence of model turns and tool executions where every step can be replayed, inspected, resumed, denied, or escalated by the surrounding system. The model proposes plans and tool calls; the workflow engine decides what is allowed, what is recorded, and when a human must approve the next action.

This distinction matters because Fable 5.1 is positioned by Anthropic for demanding reasoning and long-horizon agentic work, but Anthropic’s documentation does not make the model an autonomous scheduler, deployment system, security principal, or production operator. If a Claude Code workflow migrates a repository, updates a dependency tree, audits failing tests, or drafts a database migration, the agent harness must still define which files can be edited, which commands can run, which secrets are inaccessible, which network calls are blocked, and which changes require a human checkpoint before execution.

The practical target for this playbook is a workflow that can run for minutes or hours across many tool calls without losing the thread, corrupting prior reasoning, wasting cached context, or silently performing high-impact operations. Typical examples include a multi-package refactor, a monorepo test-failure investigation, a security triage pass that must stop before exploit development, a documentation regeneration workflow, or a staged production-readiness review where Claude Code prepares evidence but humans approve merges and releases.

If you already operate Claude Code as a task runner, this opening section reframes it as a stateful agent system rather than a chat transcript with tools attached. The design pattern overlaps with broader Claude Code automation, but this article focuses on Fable 5.1-specific mechanics: append-only history, prompt caching economics, effort selection, beta progress updates, and human checkpoints. For a wider architecture view, see . For deeper context on Claude Code Agent Workflows, The Claude Code Power User Handbook is a practical companion. The selected article presents a Claude Code power-user handbook covering setup, CLAUDE.md, prompting, subagents, hooks, MCP, debugging, and team-scale workflows for production use.

Why Fable 5.1 changes the long-running workflow design

Anthropic’s Fable 5.1 documentation describes a model intended for more demanding reasoning and long-horizon agentic work than typical short prompts. The official model information lists the model ID as claude-fable-5-1, a one-million-token context window, a 128K maximum output, always-on adaptive thinking, and high default API effort. Anthropic’s guidance also recommends starting most workloads with Opus 5 and using Fable 5.1 when the workload requires more capability for demanding reasoning or long-horizon agentic execution.

That positioning should affect routing. Do not send every autocomplete, summarization, or simple search task to Fable 5.1 just because it has a larger context window. Route tasks to Fable 5.1 when the cost of losing continuity is high: cross-file reasoning, multi-stage planning, repeated tool feedback, complex debugging, or tasks where a large stable prefix can be cached and reused over many turns. For routine classification, small edits, or independent short prompts, the extra long-horizon capability may not justify the operational complexity.

Fable 5.1’s long context also changes failure modes. A million-token window can preserve far more project state, but a larger transcript is not automatically a better transcript. If the workflow keeps every command output, every stack trace, every dependency tree, and every generated diff without summarization, it can bury critical constraints and increase cost. The correct pattern is a stable cached prefix for durable instructions and reference material, an append-only turn history for recent reasoning and tool results, and periodic compaction summaries that preserve decisions, constraints, open risks, and approved next steps.

The append-only rule is both a correctness rule and a cache rule

Anthropic’s Fable 5.1 migration guidance makes append-only conversation histories a central recommendation. The reason is not cosmetic. The documentation warns that changing content before an existing thinking block can invalidate it, and it notes that older Claude models cannot read Fable 5.1 thinking blocks. In a production workflow, that means you should not “clean up” previous messages, rewrite old tool outputs, splice in missing context before prior reasoning, or replay a Fable 5.1 transcript through an older model as if all internal reasoning artifacts were portable.

The operational rule is simple: append new information; do not mutate the past. If the agent discovers that an earlier assumption was wrong, append a correction. If a human changes the objective, append the new instruction with a timestamp and approver identity. If a tool returned noisy output, append a summary that explains which parts are relevant. If context needs to be compacted, create a new summary turn or server-side compaction artifact rather than editing earlier messages in place.

{
  "workflow_id": "repo-migration-2026-09-06-001",
  "model": "claude-fable-5-1",
  "history_mode": "append_only",
  "cache_prefix_version": "repo-policy-v7",
  "current_phase": "test-failure-triage",
  "allowed_tools": [
    "read_file",
    "search_repo",
    "run_tests_in_sandbox",
    "propose_patch"
  ],
  "blocked_actions": [
    "push_to_remote",
    "deploy_to_production",
    "rotate_credentials",
    "publish_package"
  ],
  "checkpoint_policy": {
    "requires_human_approval_before": [
      "writing_outside_allowed_paths",
      "modifying_auth_or_payment_code",
      "creating_release_artifacts",
      "running_destructive_commands"
    ]
  }
}

This example is a recommended state shape, not an Anthropic API schema. The important detail is that the workflow state records the model version, the append-only policy, the cache-prefix version, the current phase, allowed tools, blocked actions, and approval boundaries. Those fields let the application resume after interruption, explain why a tool call was denied, and reconstruct the exact context used for a decision.

Prompt caching is a workflow architecture decision, not just a billing feature

Fable 5.1’s cache economics make stable-prefix design especially important. Anthropic’s official pricing lists base input at $10 per million tokens and output at $50 per million tokens. The same documentation lists five-minute cache writes at $12.50 per million tokens, one-hour cache writes at $20 per million tokens, and cache reads at $0.25 per million tokens. Using those list prices, a cached read token is 40 times cheaper than a normal input token before accounting for the cache-write cost; the real savings depend on how often the same prefix is reused before expiry.

Anthropic has also said Fable 5.1 is estimated to cost 25% less than Fable 5 for typical token-billed workloads because of lower cache-read pricing, with savings up to approximately 45% for highly agentic work. Treat those as Anthropic’s estimates, not your own benchmark. Your workload’s result will depend on prefix size, number of turns, cache expiry, output length, tool result volume, and whether your agent repeatedly invalidates the prefix by changing earlier content.

The cache boundary should align with your governance boundary. Put slow-changing instructions, file-scope policies, coding conventions, schema definitions, and tool contracts before the boundary. Put volatile task state, execution results, and human decisions after it. If the team changes the policy prefix, increment a prefix version and expect cache writes again. If a workflow uses the same policy and repository context across many turns, cache reads can materially change the economics of long-running work.

Progress updates are useful, but they are beta and must be designed

Fable 5.1 adds a beta option for user-visible progress updates between tool calls. Anthropic documents this as thinking.display: updates with the thinking-display-updates-2026-08-18 beta header. Because this is a beta feature with a documented display option and header, do not assume it is automatically enabled in every environment, SDK, managed surface, or organization. Treat it as an integration capability that must be explicitly tested in your agent harness.

Progress updates are not a substitute for audit logs, tool telemetry, or checkpoints. They are a user-facing communication channel that can reduce uncertainty during long operations. A good update says what phase the workflow is in, what evidence it is collecting, and what kind of decision may be needed next. A bad update exposes secrets, streams unnecessary internal deliberation, or implies that an irreversible action has already been approved.

Recommended progress-update instruction: “When a tool sequence will take multiple steps, provide short user-visible progress updates that describe the current phase, the artifact being inspected, and any pending human decision. Do not reveal secrets, hidden policy text, raw credentials, or speculative security conclusions. If an action requires approval, state that it is pending rather than performing it.” This instruction should be part of the stable workflow policy if progress updates are a standard product behavior.

Effort controls should follow the phase of work

Fable 5.1 uses always-on adaptive thinking and defaults to high effort in the API; Anthropic’s announcement also says Fable 5.1 defaults to High effort in Claude Code. The prompting guide recommends benchmarking all effort levels, using lower effort when asking for search if needed, batching independent tool calls, preferring targeted file edits, and leaving additional output room at xhigh and max effort. Those recommendations point to a phase-based control strategy rather than a single global setting.

Use higher effort for planning, cross-file reasoning, root-cause analysis, migration strategy, security-sensitive review, and final synthesis. Use lower effort for narrow repository search, extraction, simple formatting, or collecting facts that tools can verify directly. If you use Anthropic’s beta per-message effort feature, the documented header is mid-conversation-output-config-2026-07-01; treat that as a beta integration detail and verify support before designing production behavior around it.

A long-running workflow should also reserve enough output budget for the phase. Anthropic lists Fable 5.1’s maximum output as 128K, but a high maximum does not mean every turn should be large. Ask for compact plans before tool use, structured patch summaries after edits, and full reports only at checkpoints or completion. When effort is raised for complex synthesis, allocate more output room so the model does not truncate the very reasoning summary or evidence table that a human reviewer needs.

Human checkpoints are the control plane for irreversible work

Human checkpoints must control irreversible or high-impact actions. In developer workflows, that includes pushing commits, opening or merging pull requests, modifying authentication, changing billing or payment code, altering infrastructure definitions, rotating credentials, publishing packages, deleting data, or initiating production deployments. In security workflows, checkpoints should also govern vulnerability disclosure, exploit-adjacent testing, customer-impact classification, and any action that could change system availability or confidentiality.

The checkpoint should be an explicit workflow state, not a polite sentence in a chat. The application should stop tool execution, present the proposed action, show supporting evidence, list expected effects, identify rollback options, and require an authenticated approval or rejection. If approval is denied, the denial should be appended to the conversation and stored in the audit log so the resumed agent does not retry the same high-impact step under a different wording.

This is where long-running Claude Code workflows intersect with human-in-the-loop agent governance. The model can prepare options, compare risks, and draft a patch, but the human approval system determines whether the next action is authorized. For deeper checkpoint patterns, escalation rules, and review design, see . For deeper context on Human in the Loop AI Agents, The 2026 AI Coding Agents Production Playbook is a practical companion. This production playbook for AI coding agents covers deployment architecture, operating boundaries, review practices, and the controls needed to move from autonomous capability to dependable engineering use.

The rest of this playbook builds on this opening architecture: stable cached prefixes, append-only transcripts, bounded tools, explicit effort choices, beta progress updates where available, compaction summaries that preserve critical constraints, and checkpoints that stop high-impact actions until a person approves them. If any one of those pieces is missing, the workflow may still be useful as an assistant, but it should not be treated as a reliable long-running production agent loop.

Design the state layer before you design the prompts

A long-running Fable 5.1 workflow should be treated as a resumable distributed system, not as a single oversized prompt. Anthropic’s Fable 5.1 documentation emphasizes append-only histories, preserved thinking blocks, prompt caching, progress updates, and compaction as design concerns for agentic work; the practical consequence is that your harness must own durable state, replay rules, retry policy, permissions, and audit logs. Claude can reason inside the turn, but your application decides what is saved, what is replayed, what is cached, what requires a human checkpoint, and what happens after a process crash.

The safest architecture is a task record with an immutable prompt prefix, an append-only message log, a checkpoint store, a tool-result ledger, and a compaction layer. This separates model context from operational truth. The model context is the conversation you send to Fable 5.1; the operational truth is your database record of files touched, tool calls attempted, approvals granted, tests run, and artifacts produced. If those two diverge, the database should win, and the next model turn should receive a concise correction or compaction summary rather than a silent edit to earlier history.

The task record is the durable contract for the run

Create a task record before the first model call. The record should include a stable task identifier, repository or workspace scope, requested outcome, allowed tools, forbidden actions, approval policy, cache policy, effort policy, compaction policy, and current lifecycle state. This record is not just metadata for observability; it is the contract that allows a run to resume after an API timeout, worker restart, or human approval delay without reconstructing intent from a partial transcript.

Build a stable system and tool prefix

The stable prefix is the part of the request that should almost never change during a run: system instructions, tool definitions, safety constraints, repository rules, output conventions, and checkpoint policy. Fable 5.1’s lower cache-read pricing makes stable prefixes more attractive for agentic workflows, but prompt caching only helps when the prefix remains byte-for-byte or semantically stable according to the provider’s caching mechanism. Treat every “quick tweak” to the prefix as a cache and correctness event, not as harmless text editing.

Put run-specific facts after the stable prefix rather than inside it. For example, the global rule “never deploy without human approval” belongs in the prefix; the particular approval ticket for task TASK-2481 belongs in the append-only message history or checkpoint store. This distinction lets many tasks reuse the same cached policy and tool surface while each task carries its own mutable operational state.

The tool prefix should define available tools and schemas without forcing a tool call. Anthropic’s Fable 5.1 migration guidance states that forced tool choice using any or a named tool returns a 400 error, so harnesses should rely on automatic tool selection plus strict schemas or structured outputs where needed. The practical rule is simple: constrain tool inputs tightly, validate tool outputs externally, and let the model decide whether a tool is needed rather than configuring an unsupported forced-tool mode.

# Pseudocode: harness-internal request assembly, not provider SDK syntax.

STABLE_SYSTEM_PREFIX = {
    "role": "system",
    "content": """
You are operating inside a controlled software-maintenance workflow.
Respect repository scope, approval gates, and tool schemas.
Do not perform irreversible actions without a recorded human checkpoint.
Prefer targeted edits, batched independent reads, and concise progress updates.
"""
}

STABLE_TOOL_PREFIX = [
    ToolSpec("read_file", input_schema={...}),
    ToolSpec("search_repo", input_schema={...}),
    ToolSpec("propose_patch", input_schema={...}),
    ToolSpec("run_tests", input_schema={...}),
    ToolSpec("request_human_checkpoint", input_schema={...}),
    ToolSpec("apply_approved_patch", input_schema={...}),
]

def assemble_request(task_id: str) -> dict:
    task = db.tasks.get(task_id)
    messages = conversation_store.load_append_only(task_id)

    return {
        "model": "claude-fable-5-1",
        "system": mark_cacheable_prefix(STABLE_SYSTEM_PREFIX, ttl=task.cache_ttl),
        "tools": mark_cacheable_prefix(STABLE_TOOL_PREFIX, ttl=task.cache_ttl),
        "messages": messages,
        "tool_choice": "auto",
        "effort": task.current_effort,
        "max_output_tokens": task.output_budget,
        "progress_updates": task.enable_progress_updates,
    }

The mark_cacheable_prefix function above is intentionally shown as harness pseudocode rather than provider-specific request syntax. The design point is the boundary: keep stable instructions and tool definitions together, place volatile task state later, and record the exact prefix version used by each task. If you later change the policy wording, create a new prefix version and start new tasks with it instead of mutating active conversations.

Use append-only messages as the replay source

Append-only history is the central preservation rule for Fable 5.1 workflows. Anthropic’s migration notes warn that changing content before an existing thinking block can invalidate it. Therefore, once a model response has been stored, do not edit prior user messages, assistant messages, tool calls, tool results, or thinking blocks to “clean up” the transcript. Add a new correction message, checkpoint message, or compaction message instead.

This rule is stricter than typical chat UX expectations. A user interface may allow a human to revise a request, but the workflow engine should represent that revision as a new event: “The requester replaced requirement A with requirement B at 14:32 UTC.” That preserves the causal record and avoids presenting a retroactively altered history before existing thinking blocks. In regulated or security-sensitive workflows, the same append-only record also supports incident review because tool outputs and approvals remain tied to the exact model turns that used them.

Append-only does not mean “send everything forever.” Fable 5.1 has a one-million-token context window according to Anthropic’s model documentation, but long context is still an engineering budget, not a reason to skip summarization. Use compaction when the transcript contains obsolete exploration, repeated tool outputs, or bulky logs, but append the compaction as a new state artifact and assemble future context from the stable prefix, preserved recent turns, ledger-backed facts, and the compaction summary. For broader context-budget techniques, see . For deeper context on Long Context Window Management, 20 Production-Ready Prompts for Claude’s 1M Token Context Window is a practical companion. The selected article provides 20 production-ready prompt templates for using Claude’s 1 million token context window across codebase analysis, log processing, document synthesis, and multi-source research.

Preserve thinking blocks by preserving their ancestry

Thinking blocks should be handled as model-state artifacts with compatibility constraints. The migration guidance states two important limits: older Claude models cannot read Fable 5.1 thinking blocks, and changing content before an existing thinking block can invalidate it. In practice, that means a continuation request should replay the prior Fable 5.1 conversation in order, including the assistant content blocks returned by the model, and should not rewrite earlier context to save tokens or fix wording.

What invalidates thinking is any alteration that changes the ancestry of the thinking block. Examples include editing the original user request, removing a tool result that preceded the model’s reasoning, rewriting a system instruction above the block, changing a prior assistant message, or compacting earlier history in place while leaving a later thinking block as if nothing changed. These edits make the preserved reasoning no longer correspond to the visible conversation state.

What preserves thinking is append-only continuation with compatible content. Add new information after the existing transcript, keep prior blocks intact, keep tool results attached to the tool calls that produced them, and use a new compaction boundary only when you are intentionally starting from a summarized state. If you compact, treat the summary as a new context artifact and avoid pretending that older thinking blocks still have the same unmodified ancestry unless the original preceding content is still present.

Operational rule: if the harness changes anything before a stored Fable 5.1 thinking block, it should assume that block is no longer valid for continuation. Start a clean continuation from an appended compaction summary or replay the unmodified original history instead.

Separate the tool-result ledger from the chat transcript

The conversation history should include tool results because the model needs to see what happened, but the transcript should not be your only source of truth. Maintain a tool-result ledger keyed by task ID, tool name, normalized input, idempotency key, execution status, output digest, artifact references, and timestamps. This ledger lets the worker distinguish “the model asked to run tests again” from “the previous run_tests call timed out after tests actually completed.”

Idempotency is mandatory for any tool that mutates state. For read-only tools, an idempotency key can deduplicate redundant search or file-read calls and reduce cost. For write tools, the key should prevent duplicate pull requests, repeated issue comments, repeated branch creation, duplicate deployment requests, or multiple checkpoint prompts for the same action. A good idempotency key includes the task ID, tool name, target resource, normalized arguments, and the model-turn identifier.

def execute_tool_call(task_id: str, turn_id: str, call: ToolCall) -> ToolResult:
    normalized_args = normalize_json(call.arguments)
    idem_key = hash_json({
        "task_id": task_id,
        "turn_id": turn_id,
        "tool": call.name,
        "args": normalized_args,
    })

    existing = ledger.find_by_idempotency_key(idem_key)
    if existing and existing.status in {"succeeded", "pending_approval"}:
        return existing.as_tool_result_for_model()

    if call.name in HIGH_IMPACT_TOOLS:
        approval = checkpoints.require_approval(
            task_id=task_id,
            action=call.name,
            arguments=normalized_args,
            idempotency_key=idem_key,
        )
        if not approval.granted:
            return ToolResult.denied("Human approval is required before this action.")

    ledger.insert_attempt(idem_key, task_id, turn_id, call.name, normalized_args)

    try:
        result = tool_runtime.invoke(call.name, normalized_args)
        ledger.mark_succeeded(idem_key, output_digest=digest(result), artifacts=result.artifacts)
        return result
    except RetryableToolError as exc:
        ledger.mark_retryable_failure(idem_key, error=str(exc))
        raise
    except NonRetryableToolError as exc:
        ledger.mark_failed(idem_key, error=str(exc))
        return ToolResult.failed(str(exc))

The model should receive concise, truthful tool results; the ledger should retain the full operational record. For example, a test runner result sent to the model might include failing test names, exit code, and the relevant log excerpt, while the ledger stores the full log artifact. This avoids filling the context with bulky output while still allowing a human or replay worker to inspect the original evidence.

Retries should resume the run, not duplicate the world

Retries belong at three levels: API request retries, tool execution retries, and workflow retries. API retries should be safe only when the harness can determine whether a response was received and committed to the append-only log. Tool retries should consult the ledger before execution. Workflow retries should reload the task record and message log from durable storage, not from worker memory.

Never retry a mutating tool call by simply asking the model to “try again” without checking the ledger. If the network failed after the tool performed the action but before the harness recorded the result, a blind retry can duplicate the side effect. Prefer tools that can query the target system by idempotency key or deterministic resource name. If the target system cannot support idempotency, require a human checkpoint before retrying the action.

def run_agent_step(task_id: str) -> None:
    task = db.tasks.lock_for_update(task_id)

    if task.state in {"waiting_for_human", "completed", "failed"}:
        return

    request = assemble_request(task_id)

    response = claude_client.messages_create_with_retry(
        request,
        retry_policy=RetryPolicy(
            retry_on=["rate_limit", "transient_network", "server_error"],
            max_attempts=3,
        ),
    )

    conversation_store.append_assistant_response(
        task_id=task_id,
        response=response,
        preserve_content_blocks=True,
    )

    for call in response.tool_calls:
        try:
            result = execute_tool_call(task_id, response.turn_id, call)
        except RetryableToolError:
            scheduler.retry_later(task_id)
            return

        conversation_store.append_tool_result(
            task_id=task_id,
            tool_call_id=call.id,
            result=result.to_model_visible_summary(),
        )

    db.tasks.update_phase_from_response(task_id, response)

This pattern ensures that a model response is stored before its tool calls are processed. If the worker crashes after appending the assistant response but before executing all tools, the next worker can inspect the response, consult the ledger, and continue. If the worker crashes after a tool succeeds but before the tool result is appended to the conversation, the ledger can reconstruct a model-visible result and append it exactly once.

Human checkpoints are state transitions, not chat messages only

A human checkpoint should be represented both in the conversation and in the checkpoint store. The model-visible message explains whether approval was granted, denied, or modified; the checkpoint record stores approver identity, time, action, arguments, risk class, linked ticket, and any conditions. This distinction matters because the model may need a concise approval fact, while auditors and operators need a durable authorization record.

Use checkpoints for irreversible or high-impact actions: applying patches to protected branches, creating external tickets, sending customer-visible communications, modifying access controls, running destructive database operations, deploying code, or scanning systems outside the approved scope. Anthropic’s prompting guidance supports long-running agent loops, but it does not transfer responsibility for permissions or impact control to the model. Your harness should block these actions until the checkpoint store contains a valid approval for the exact action and arguments.

Compaction should preserve constraints, decisions, and open work

Compaction is a controlled state transition that reduces context size while preserving the facts needed for safe continuation. A useful compaction summary should include the original objective, non-negotiable constraints, repository scope, files inspected, files changed, tests run, decisions made, rejected approaches, unresolved risks, pending approvals, and next recommended action. It should also reference ledger artifacts rather than copying large logs into the prompt.

Do not compact by deleting earlier messages and leaving later messages untouched as if the ancestry were unchanged. Instead, create a compaction event, mark the previous range as summarized in your context assembly metadata, and continue with a clean sequence that includes the stable prefix, the compaction summary, recent unsummarized turns, and current task state. This keeps the model’s visible context coherent and avoids the dangerous middle ground where old thinking blocks remain after their preceding context has been rewritten.

def maybe_compact(task_id: str) -> None:
    usage = context_meter.estimate_tokens(task_id)
    policy = db.tasks.get(task_id).compaction_policy

    if usage.total_tokens < policy.compact_after_tokens:
        return

    source_range = conversation_store.select_compaction_range(
        task_id=task_id,
        keep_last_n_turns=policy.keep_recent_turns,
    )

    summary = compactor.create_summary(
        source_messages=source_range.messages,
        required_fields=[
            "objective",
            "constraints",
            "scope",
            "files_inspected",
            "files_changed",
            "tool_results_by_ledger_id",
            "decisions",
            "risks",
            "pending_checkpoints",
            "next_actions",
        ],
    )

    conversation_store.append_system_note(
        task_id=task_id,
        content={
            "type": "compaction_summary",
            "summarizes_message_ids": source_range.ids,
            "summary": summary,
        },
    )

    context_assembly.mark_summarized(task_id, source_range.ids)

The compactor itself should be tested like any other production component. Give it adversarial transcripts with conflicting requirements, denied approvals, failed tests, and security constraints, then verify that the summary preserves the facts that should constrain the next turn. A compaction system that drops “do not modify authentication code” or “deployment approval was denied” is not an optimization; it is a safety bug.

Progress updates belong in the message model, but they are not persistence

Fable 5.1 adds beta user-visible progress updates between tool calls when the documented display option and beta header are used. The relevant configuration named in Anthropic’s documentation is thinking.display: updates with the thinking-display-updates-2026-08-18 beta header. Use this for operator trust and long-running visibility, but do not treat progress text as a substitute for the task record, ledger, or checkpoint store.

A good progress update says what phase the agent is in, what evidence it has gathered, what it will do next, and whether a human decision is approaching. A bad progress update invents certainty, exposes sensitive internal details unnecessarily, or claims that an action has completed before the ledger confirms it. Store progress updates in the append-only log if they are returned as part of the conversation, but derive operational dashboards from durable task and ledger state.

A practical state machine for long-running Fable 5.1 work

The run should move through explicit states so operators can reason about stuck tasks and safe restarts. A typical workflow starts in created, moves to planning, then gathering_context, editing, testing, waiting_for_human, applying_approved_change, and finally completed or failed. Each transition should be caused by a stored event: model response, tool result, checkpoint decision, retry exhaustion, or operator cancellation.

The design goal is not to make the agent slower; it is to make long-running work resumable, reviewable, and safe under failure. Stable prefixes improve cache behavior, append-only histories preserve Fable 5.1 thinking compatibility, ledgers make retries safe, checkpoints control impact, and compaction keeps the context useful without falsifying the past. Once this state layer exists, prompt design becomes much easier because every instruction can point to a durable mechanism instead of relying on the model to remember operational rules indefinitely.

Operate the run with phase policies, effort budgets, and explicit approval boundaries

A long-running Claude Code workflow should not run at one effort level, one permission level, and one communication style from start to finish. Anthropic documents Fable 5.1 as generally available with a one-million-token context window, always-on adaptive thinking, and a High default API effort setting, while also adding beta controls for per-message effort, turn-scoped system messages, and progress updates. The practical design rule is to treat each phase of the agent loop as a policy boundary: discovery can be cheaper and broader, planning can be more deliberate, implementation can be targeted, verification can be tool-heavy, and release can be blocked behind human approval.

The distinction between generally available model behavior and beta workflow controls matters operationally. The model ID `claude-fable-5-1` and the baseline Fable 5.1 capabilities are not the same thing as beta progress updates or beta per-message effort. If your production environment does not allow beta headers, the harness should still run with stable prefixes, append-only history, tool-result ledgers, and human checkpoints; it should simply disable the beta-specific features and fall back to explicit assistant status messages or separate phase-level requests. Do not build persistence, access control, deployment authority, or audit logging on the assumption that the model owns those systems; your application or agent runner owns them.

Use a phase table instead of a single global effort setting

Anthropic’s Fable 5.1 prompting guidance advises teams to benchmark effort levels and to leave additional output room at higher effort levels such as xhigh and max. In practice, that means the workflow should declare expected effort by phase before the agent starts, then let the orchestrator apply the appropriate request configuration for the next turn. This gives platform teams a concrete review artifact: every costly or risky phase has a named reason for its effort level, and every low-risk phase has a default that avoids unnecessary reasoning spend.

Recommendation: store this table as machine-readable run policy, not only as prose inside the prompt. The prompt can explain the policy to the model, but the harness should enforce the gates. This separation prevents a clever or mistaken plan from bypassing a production-deployment gate merely because the conversation drifted. Teams that need a deeper governance pattern can connect this phase policy to a dedicated approval design such as . For deeper context on AI Agent Approval Gates, The Complete Guide to Codex Approval Policies — Controlling AI Autonomy in Enterprise Environments is a practical companion. The selected article explains Codex approval policies as auditable controls for managing AI autonomy with human-in-the-loop approvals, automated guardrails, privacy controls, and cost governance.

{
  "run_policy": {
    "model": "claude-fable-5-1",
    "default_phase": "intake",
    "phase_effort": {
      "intake": "low",
      "planning": "high",
      "implementation": "medium",
      "verification_routine": "low",
      "verification_diagnosis": "high",
      "release_review": "high"
    },
    "approval_required_for": [
      "destructive_command",
      "production_deployment",
      "credential_use",
      "external_communication",
      "irreversible_action"
    ],
    "beta_features": {
      "per_message_effort": "mid-conversation-output-config-2026-07-01",
      "turn_scoped_system_messages": "mid-conversation-system-clear-at-2026-08-21",
      "progress_updates": "thinking-display-updates-2026-08-18"
    }
  }
}

This example is an orchestrator policy, not a substitute for the current Anthropic SDK or Messages API schema. The important production idea is that the run has a durable phase, each phase has an expected effort level, and each beta-dependent feature is explicitly declared so the harness can disable it in environments where beta headers are not permitted.

Apply beta controls only where they improve the loop

Fable 5.1’s beta controls are most valuable when they keep long-running work from becoming opaque or expensive. Per-message effort, enabled with the beta header value `mid-conversation-output-config-2026-07-01`, lets an application vary effort within a conversation instead of starting every phase at the same level. Turn-scoped system messages, enabled with `mid-conversation-system-clear-at-2026-08-21`, use `clear_at: next_user_message` so a temporary instruction can apply to the current turn without permanently contaminating the stable prefix. User-visible progress updates, enabled with `thinking-display-updates-2026-08-18`, use `thinking.display: updates` so the model can provide status between tool calls. These are beta behaviors; treat them as opt-in dependencies and test them before relying on them in regulated or customer-facing workflows.

{
  "headers": {
    "anthropic-beta": [
      "mid-conversation-output-config-2026-07-01",
      "mid-conversation-system-clear-at-2026-08-21",
      "thinking-display-updates-2026-08-18"
    ]
  },
  "model": "claude-fable-5-1",
  "thinking": {
    "display": "updates"
  },
  "turn_scoped_system_message": {
    "content": "For this turn only: diagnose the failing test without editing files. Summarize likely causes and the next safe tool calls.",
    "clear_at": "next_user_message"
  },
  "phase_policy": {
    "phase": "verification_diagnosis",
    "effort": "high"
  }
}

The snippet above is intentionally framed as a request-design pattern. The exact integration should follow Anthropic’s current API documentation and your SDK version, but the operational ingredients are fixed by the documented feature names: the progress display option is `thinking.display: updates`, the turn-scoped expiry value is `clear_at: next_user_message`, and the beta header values must be present for those beta behaviors. If the beta header is omitted, the application should not pretend that the corresponding behavior is active.

Use turn-scoped system messages for temporary rules, not permanent policy

Turn-scoped system messages solve a common long-run problem: the agent needs a narrow instruction for the next move, but you do not want to edit earlier messages or pollute the stable system prefix. A good temporary instruction says what to do now, what not to do now, and when to stop. For example, during verification, a turn-scoped instruction can say, “Inspect the failing test output and propose the smallest next tool batch; do not edit files in this turn.” During release review, it can say, “Prepare a deployment checklist only; do not call deployment tools.”

{
  "role": "system",
  "content": "For this turn only: prepare a release-risk summary. Do not deploy, do not post externally, and do not request credentials. List the exact approval gates needed before any irreversible action.",
  "clear_at": "next_user_message"
}

This pattern keeps the stable prefix cacheable and auditable. It also reduces the temptation to mutate prior instructions, which Anthropic warns can affect thinking-block validity when content before an existing thinking block changes. When teams combine turn-scoped messages with append-only history and stable cache boundaries, they get a cleaner replay model and fewer cache-prefix surprises. For the cost and prefix-design side of that decision, connect the workflow to a dedicated cache strategy such as . For deeper context on Prompt Caching Optimization, The Big Prompt Engineering Story: What July 23’s News Means for Developers is a practical companion. The selected article analyzes developer-focused prompt engineering news including Anthropic’s deep prompt-caching discount on Claude Sonnet 4.6, OpenAI JSON schema enforcement, and Google Gemini 1M-token availability.

Make progress updates useful enough for humans to act on

Progress updates should not be decorative. When `thinking.display: updates` is enabled with the `thinking-display-updates-2026-08-18` beta header, ask the model to produce user-facing status lines that describe completed work, current work, next tool calls, and blockers. The user should be able to tell whether the agent is reading, editing, testing, waiting for approval, or blocked by missing information. Avoid status text that reveals sensitive chain-of-thought details; the useful information for operators is workflow state, evidence gathered, and the next safe action.

Sample progress instruction:

Provide concise user-facing progress updates between tool calls. Each update must include:
1. Completed: the concrete files, tests, tickets, or logs already inspected.
2. Now: the current subtask.
3. Next: the next independent tool batch or the reason no tool call is safe.
4. Gate: whether a human approval gate is approaching.

Do not expose private reasoning. Do not claim success until tests or requested evidence confirm it.

Good status lines are specific and falsifiable. “Completed: inspected payment/refund_service.py and the failing refund idempotency test. Now: checking whether the retry key is persisted before the gateway call. Next: run the refund unit tests and the idempotency integration test together. Gate: no production action requested.” This is more useful than “Still working,” because it gives a reviewer enough context to interrupt, redirect, or approve the next phase.

Batch independent tools, but never batch approvals away

Anthropic’s prompting guide recommends batching independent tool calls. The reason is simple: long-running agents often waste time by serializing read-only operations that have no dependency on one another. Repository search, test inventory inspection, package metadata reads, and multiple independent test commands can often be planned as a batch. The model should explain why calls are independent before batching them, and the harness should still enforce tool permissions for each call.

Tool batching rule for the agent:

If tool calls are independent, propose or execute them in the same batch:
- Read package metadata and test configuration in parallel.
- Search for call sites while reading the failing test file.
- Run independent unit test shards together when the harness supports it.

Do not batch:
- A command that depends on the output of another command.
- A write operation with a read operation that is meant to validate the write.
- Any action requiring human approval.
- Any credential use, external communication, deployment, destructive command, or irreversible action.

The approval exception is critical. A model may correctly infer that “delete old objects,” “run database migration,” and “post release note” are part of one release workflow, but those actions are not safe to batch as a single autonomous step. Each high-impact operation must pass through the approval state machine with a proposed command, expected effect, target environment, rollback plan where possible, and recorded approver identity.

Define approval gates as structured records

A human checkpoint is reliable only when it has a structured payload. A chat message that says “looks good” is ambiguous; an approval record that says “approve deployment to staging, not production, for commit abc123, using deploy job X, with rollback job Y” is operationally meaningful. The harness should block the tool call until the approval record matches the requested action and scope.

{
  "approval_request": {
    "gate": "production_deployment",
    "proposed_action": "Run the production deployment job for service checkout-api",
    "scope": {
      "environment": "production",
      "artifact": "commit abc123",
      "region": "approved target region from deployment policy"
    },
    "evidence": [
      "unit tests passed",
      "integration tests passed",
      "release-risk summary prepared"
    ],
    "rollback_plan": "Use the existing rollback job for the previous artifact if health checks fail",
    "status": "blocked_until_human_approval"
  }
}

The agent may prepare this record, but the harness must decide whether it is complete, route it to the right approver, and enforce the block. That division of responsibility is the difference between an AI assistant that proposes a deployment and an unsupervised system that can change production.

Useful Links

• Anthropic prompting guide for Claude Fable 5.1
• Anthropic documentation on what is new in Claude Fable 5.1
• Anthropic migration guide for Claude Fable 5.1

Operational controls for long-running runs

A production Claude Code or custom-agent workflow should treat Fable 5.1 as the reasoning engine inside a supervised system, not as the owner of the job. Your application or agent harness remains responsible for persistence, retries, permissions, audit logs, approval routing, rate limiting, and recovery. That distinction matters because Anthropic’s Fable 5.1 guidance emphasizes append-only histories, prompt caching, effort selection, progress updates, and preserved thinking, while the operational contract around who may merge code, deploy infrastructure, or touch customer data must be enforced outside the model.

Recommendation: define every long-running run as a controlled operation with a run identifier, a task record, a transcript pointer, a tool-result ledger, a checkpoint ledger, a cost ledger, and a security event stream. If any one of those records cannot be written durably, the run should pause before issuing additional tool calls. A model response is not sufficient evidence that the operation was safe; the operator must be able to replay what was requested, what was approved, what tools executed, what changed, and what remains unresolved.

Preflight checklist before starting a run

• Model and migration check: confirm the integration is using claude-fable-5-1, not a legacy model alias, and remove forced tool choice patterns because Anthropic says tool_choice: any or a named forced tool returns a 400 error for Fable 5.1.
• Append-only history check: verify that the harness appends new messages instead of editing prior content before existing thinking blocks, because Anthropic warns that changing content before an existing thinking block can invalidate it.
• Cache-boundary check: freeze the stable prefix containing role, policy, repository rules, tool contracts, and invariant instructions before the run begins. Put volatile issue comments, test output, and operator notes after the cache boundary so they do not cool the expensive prefix.
• Budget check: set a maximum input-token, cache-write, cache-read, output-token, and wall-clock budget. Fable 5.1 list prices in Anthropic’s documentation are $10 per million input tokens, $50 per million output tokens, $12.50 per million tokens for five-minute cache writes, $20 per million tokens for one-hour cache writes, and $0.25 per million cache-read tokens.
• Approval check: classify the task before execution. Read-only analysis can proceed automatically; source edits require a review checkpoint; production deploys, data migrations, credential changes, destructive commands, and customer-visible actions require explicit human approval.
• Beta-feature check: enable beta progress updates only when the integration is prepared to display and log them. Anthropic documents progress updates with thinking.display: updates and the thinking-display-updates-2026-08-18 beta header; do not depend on this beta feature as the only persistence mechanism.
• Security check: confirm the run has least-privilege tool credentials, a redaction policy for secrets and personal data, and a logging rule that records tool names, arguments, approval IDs, and outputs without storing unnecessary sensitive payloads.
• Resume check: prove that an interrupted run can reload the task record, reconstruct the append-only transcript, validate open checkpoints, and resume from the next safe state without re-running completed side effects.

Failure handling and safe fallback rules

Failures should be classified before the workflow decides whether to retry, fall back, or stop. A transient transport failure may be retried with the same immutable request envelope and idempotency controls in your harness. A model refusal, policy conflict, tool schema error, stale repository state, or failed approval is not a transient failure; it requires a branch in the state machine and, usually, human review.

Fallback rule: when the primary Fable 5.1 path cannot continue safely, fall back by reducing scope rather than weakening controls. Examples include switching from “implement and open a pull request” to “produce a patch plan,” from “apply migration” to “generate a reviewed migration script,” or from “deploy” to “prepare a deployment checklist.” Anthropic recommends Opus 5 for many workloads and Fable 5.1 for demanding reasoning or long-horizon agentic work; choose the model based on measured task requirements rather than using fallback as a way to evade a refusal.

Observability, security logging, and stale-state detection

Observability should separate model behavior, tool behavior, operator behavior, and cost behavior. Model logs should capture request IDs, model ID, effort setting, beta headers used, cache read/write indicators available to your billing telemetry, output length, refusal markers, and progress-update events. Tool logs should capture tool name, normalized arguments, execution start and stop time, exit status, affected files or resources, and a content hash of important outputs. Operator logs should capture approval decisions, approver identity, timestamp, reason, and scope.

{
  "run_id": "run_2026_09_06_0421",
  "model": "claude-fable-5-1",
  "phase": "edit",
  "effort_policy": "high",
  "approval_id": "approval_1837",
  "cache_policy": "stable_prefix_v12_one_hour",
  "tool_call": {
    "name": "apply_patch",
    "arguments_hash": "sha256:...",
    "side_effect": "repository_write"
  },
  "stale_state_checks": {
    "repo_head_before": "abc123",
    "repo_head_after": "abc123",
    "ticket_version": 17,
    "approval_scope_version": 3
  },
  "security": {
    "secrets_redacted": true,
    "least_privilege_profile": "repo_write_no_deploy"
  }
}

Stale-state detection should run before planning, before side effects, before approval consumption, and before final evidence packaging. For code workflows, compare the current branch head, base branch head, dependency lockfiles, generated files, and test configuration with the values used during planning. For administrative workflows, compare the target resource version, policy version, approval scope, and environment tag. If any value has changed, pause and request a revised plan because a correct plan can become unsafe when the world changes.

Security logs should be useful for investigation without becoming a data lake of secrets. Record that a credential-bearing command was requested, who approved it, and which permission profile was used, but redact tokens, private keys, and customer payloads unless your retention policy explicitly allows storage. If a tool result contains unexpected sensitive data, the run should mark the result as restricted, stop automatic summarization into future prompts, and require a human decision before continuing.

For teams standardizing AI operations across vendors and internal agents, map this run model to a broader reliability program such as . The practical alignment point is simple: every model turn that can change the external world needs an owner, an approval boundary, an audit trail, and a tested recovery path. For deeper context on Production AI Agent Reliability, The Ultimate Guide to AI Agent Infrastructure in 2026: Architecture, Tools, and Best Practices is a practical companion. The selected article is a guide to production-grade AI agent infrastructure covering orchestration patterns, caching strategies, model routing, and observability frameworks.

Cost budgets and SLOs for operator control

Cost governance should be implemented as a live control, not as an invoice review. Use a per-run budget that estimates cache writes, cache reads, uncached input, and output separately. The reason to separate them is that Fable 5.1 cache reads are priced differently from fresh input and cache writes in Anthropic’s documentation, so a workflow with a large stable prefix and many turns has a different cost profile from a one-shot long prompt. Batch API requests receive a 50% input-and-output discount according to Anthropic’s Fable 5.1 documentation, but batching is appropriate only for independent work that does not require sequential human approvals.

Incident process for unsafe or ambiguous runs

1. Freeze the run: stop issuing model calls and disable side-effect tools for the run ID. Preserve the append-only transcript, tool ledger, progress updates, approval records, and current state fingerprints.
2. Classify severity: treat missing approval before a destructive action, suspected secret exposure, unauthorized data access, repeated side effect, or safety-policy bypass attempt as a security or reliability incident rather than a normal model error.
3. Contain external effects: revert code changes, revoke credentials, close deployments, disable scheduled jobs, or quarantine generated artifacts as appropriate for the affected system.
4. Reconstruct the decision path: review the stable prefix version, compaction summaries, turn-scoped instructions, effort changes, beta headers, tool arguments, and human approvals to identify whether the fault came from prompting, stale state, tool permissions, operator action, or recovery logic.
5. Resume only from a new checkpoint: if work should continue, create a fresh operator-approved state transition with updated constraints. Do not simply unpause the old loop after a severe ambiguity.

Post-run evidence package

Every completed run should produce a compact evidence package that a reviewer can inspect without replaying the entire conversation. Include the original task, final scope, model ID, effort policy by phase, beta features used, cache policy, approvals consumed, state fingerprints, tool-call summary, changed files or resources, tests run, tests not run, residual risks, refusal or fallback events, and the final human decision. This package becomes the artifact that supports pull-request review, audit response, change-management review, and future tuning.

Operator rule: a long-running AI workflow is not complete when the model says it is done. It is complete when the harness has recorded evidence, tests have been attached or explicitly waived, approvals match the side effects, and the remaining risk is visible to the accountable human.

Staged rollout plan

Start with read-only dry runs against representative repositories or operational tickets. Measure plan quality, refusal behavior, tool-call shape, cache effectiveness, output length, and compaction fidelity without granting write permissions. The exit criterion is not “the model answered well”; it is that the harness can replay the run, detect stale state, produce an evidence package, and stop at approval gates.

Move next to sandbox write runs where the agent can create branches, draft patches, or update non-production fixtures. Require human review for every proposed change and deliberately inject failures: expired approval, changed branch head, interrupted response, tool schema error, and budget exhaustion. A rollout should not proceed until resume behavior is demonstrated with test evidence rather than assumed from design.

The third stage is limited production with low-blast-radius tasks, such as documentation updates, dependency-analysis reports, or small code changes behind normal review. Track SLOs weekly, compare cost ledgers against approved budgets, inspect refusals for legitimate safety boundaries, and tune prompts only through versioned stable prefixes. Avoid editing old transcript content to “clean up” runs because Anthropic’s migration guidance warns that altering content before thinking blocks can invalidate them.

Full production should remain gated by task class. Even after successful rollout, irreversible actions should keep human checkpoints, progress updates should remain advisory rather than authoritative persistence, and beta controls should be isolated behind feature flags so they can be disabled without changing the core state machine.

Useful Links

• Anthropic: Prompting Claude Fable 5.1
• Anthropic: What’s new in Claude Fable 5.1
• Anthropic: Claude Fable 5.1 migration guide