Fable Belongs at the Decision Points: Routing Models Through a Web Build Workflow

Fable 5.1 is Anthropic's model for demanding reasoning and long-horizon agentic work, and it sits at the top of Anthropic's price list. Used for every step of a build, it costs more and runs slower. The same is true of any provider's frontier model.

Facts checked Oct 27, 2026. Model names, prices, and plan terms change, so check the linked provider pages before you budget.

Fable belongs at the four decision points of a web build: the brief, the site structure call, the design-direction call, and the final review. Cheaper models should handle the repeat work, and people should approve the site structure, the design direction, and the launch.

A common pattern looks different: one model, usually the top-tier one, handles everything from research summaries to component variants, alt text, and test runs. The weekly limit is gone by midweek, and the fix looks like a bigger budget. It isn't. The problem is workflow design.

A quick naming note. Fable 5 is now a legacy model, and Fable 5.1 is current at the same input and output price (cache-read prices differ). I use Fable 5.1 throughout.

Below: why defaulting to Fable backfires, a stage-by-stage plan with a running example (a five-page services site), three setups (one needs no code), and a one-page test. Every lesson applies to any provider's frontier model.

Why Fable as a default backfires

The best model is the most expensive way to do easy work.

It costs far more per step. On Oct 27, 2026, Fable 5.1 input costs $10 per million tokens versus $0.10 for Haiku 5.5, Anthropic's small model. That is 100 times the price for work like generating a tenth button variant or rerunning a link check. Other providers follow the same shape.

It drains plan limits. Anthropic says Fable models use your plan's regular weekly limits faster than other Claude models. Max plans can spend up to 50% of the weekly limit on them, and Pro runs them on usage credits.

It runs slower. Anthropic's own comparison table rates Fable 5.1's latency as "Slower" (Haiku 5.5 is "Fastest"), and its default effort, meaning how hard the model thinks before answering, is "high".

It can quietly switch models. Fable's safety classifiers can move a request to an Opus model, and in Claude Code, "After a fallback, the session continues on the fallback model". A team that thinks Fable reviewed the build may be reading Opus output. And in headless -p runs and Agent SDK runs, Claude Code bills Fable requests that would draw on usage credits without asking first.

My inference, labeled as one: site security QA, such as cleaning injected scripts out of a hacked page, may be more likely to trigger that switch. Anthropic's documented triggers are "Offensive cybersecurity techniques, such as building exploits, malware, or attack tooling", and it says Fable "can assist with routine cybersecurity tasks, but users should expect high fallback rates."

The providers' own guidance starts below the top tier. Anthropic says to "start with Claude Opus 5.5 for most workloads" and to use Fable "when your evals on Claude Opus 5.5 at higher effort still fall short." In a note limiting access to its 2.5 models, Google tells new projects to use "3.5 Flash-Lite or 3.8 Flash".

The workflow: frontier at the decisions, cheaper tiers for the repeat work

Think of models in three tiers: small (fast and cheap), mid (everyday workers), and frontier (slow, expensive experts). Information architecture, or site structure, is how a site's pages are grouped, named, labeled, and linked.

At each decision point, the model drafts and critiques options. A person approves the site structure and the design direction, and owns the launch gate.

Four decision points get the frontier model. Rows marked Human-approved need a person's sign-off before the next stage starts.

Accessibility stays with people. Automated scans help, but W3C is direct about their limits: "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so", and "Human judgement is required." W3C's Easy Checks cover color contrast and keyboard access, and say a decorative image "should have null alt ( alt="" )" and that to judge alt text you "need to see the image and judge it in context." So a person checks every alt text draft against WCAG's text alternative requirement. I'd add a screen reader pass to the same human check.

The content lane. SEO content is one lane, not the whole workflow. Answer-first structure and citability get checked in the final review, the same lens I use for generative engine optimization.

The build lane. I wrote about an earlier build with AI coding assistants in How I Built an SEO-Friendly Website Using AI in Just One Week.

Running example: a five-page services site

A scenario, not a case study.

1. Brief: a small model summarizes research notes and scans competitor pages and SERPs. The frontier model drafts the brief: goals, audience (who the services are for), scope, and success measures (what each page must do).
2. Site structure: a small model inventories and audits existing pages and content first. The frontier model drafts and critiques page types, navigation labels, and URL structure, and a person approves. After approval, a mid model drafts the page list and sitemap.
3. Design direction: the frontier model proposes the core flow (service page to contact form), two or three key screens, and the visual direction, and a person approves. A mid model makes component variants and routine screen states. Empty, error, and edge-case states can surface flow problems, so a form error state that changes the flow goes back to the direction call.
4. Copy: no decision point, since the brief already set direction. A mid model drafts copy and runs copy passes. A small model drafts metadata, internal link suggestions, and alt text. A person checks each alt text draft and decides which images get empty alt text, because decorative or informative depends on context.
5. Build: a mid model builds components and pages, and a small model runs lint and tests.
6. QA: a small model runs link checks, automated accessibility scans, and tests. A person checks keyboard, screen reader, and contrast. The frontier model runs the final review against the brief, the site structure, and the design direction.
7. Launch: a person makes the launch call, outside any model. Afterward, a small model rechecks links and metadata and summarizes analytics exports.

Example models, checked Oct 27, 2026

These are examples, not picks.

*Anthropic has two mid options; Opus 5.5 is its suggested default.

Sources: Claude models overview, OpenAI models (Astra is its "flagship model for complex reasoning and coding"), and Gemini models (Argon is "Our flagship reasoning model"). A small open-weight model you host also fits the small tier.

What to do instead

Tip 1: Route by stage, not by project

Decide the model per task. Claude Code's docs agree: "Control costs by routing tasks to faster, lower-cost models like Haiku".

Compare cost on each pricing page: Anthropic, OpenAI, and Google.

Tip 2: Start on a mid tier and move up only when it falls short

Run a stage on the mid model first, and move it up only if its output keeps failing review. This mirrors Anthropic's advice: start with Opus 5.5, and use Fable when "evals on Claude Opus 5.5 at higher effort still fall short." Anthropic's Academy lists Fable for "Problems you've tested with Opus and it struggled".

Also try the reverse: if a frontier step always passes review (say, design direction on a small feature), test it one tier lower.

Tip 3: Turn the effort down before you change the model

Lower effort is faster and cheaper, so turn it down on repeat work.

Anthropic calls effort "the primary control for intelligence, latency, and cost on Claude Fable 5.1". OpenAI's models page lists the reasoning levels "low medium high xhigh max" for GPT-6 Astra and GPT-6.1 Sol, and OpenAI's smaller models also list "none". In Claude Code, a subagent's effort field takes low, medium, high, xhigh, or max, and "available levels depend on the model."

Tip 4: Log which model actually ran

Record the model for every stage, especially the four decision points, because the one you picked isn't always the one that answered:

• Claude's classifier switch keeps the session on the fallback model.
• Claude Code's -p and Agent SDK runs bill Fable to usage credits without a prompt.
• LiteLLM's fallbacks switch to a backup model when a call fails after retries. Its spend logs record attempted_fallbacks and original_model_group, and the x-litellm-model-id response header names the deployment that served the request.

Tip 5: Pick a setup to try

(a) No code: one saved workspace per stage. Create a saved prompt or project for each stage (brief, site structure, design direction, copy, build, QA review), and choose a model for each where your AI tool allows. Pass output from one stage to the next by hand. It's manual, but the routing is visible.

(b) Claude Code: a model per subagent. Each task gets a helper with its own model and effort.

For technical readers (optional)

The frontmatter format follows the Claude Code subagent docs: model takes sonnet, opus, haiku, fable, a full model ID, or inherit, and effort takes low, medium, high, xhigh, or max, depending on the model. The descriptions are mine.

---
name: link-check
description: Checks built pages for broken internal links and missing metadata, and lists each failure with its file. Use after each build.
tools: Read, Grep, Glob
model: haiku
---

---
name: final-review
description: Reviews a finished page or feature against its brief, site structure, and design direction, and flags gaps and unsupported claims. Use before the launch decision.
tools: Read, Grep, Glob
model: fable
effort: medium
---

Don't set CLAUDE_CODE_SUBAGENT_MODEL_FORCE, which forces one model onto every subagent. Subagent requests count toward the same usage limits as the main conversation.

(c) Any provider: a gateway with one named model per tier. A gateway is a switchboard between your tools and the providers. You name each tier, point each name at any provider's model, and set a backup for failed calls. LiteLLM is one open-source example.

For technical readers (optional)

The structure follows the LiteLLM proxy docs and its gemini/ prefix. The tier names and provider mix are my example; model IDs come from the provider pages linked above.

model_list:
  - model_name: small
    litellm_params:
      model: gemini/gemini-3.5-flash-lite
      api_key: os.environ/GEMINI_API_KEY
  - model_name: mid
    litellm_params:
      model: openai/gpt-6.1-sol
      api_key: os.environ/OPENAI_API_KEY
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-fable-5-1
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: frontier-backup
    litellm_params:
      model: openai/gpt-6-astra
      api_key: os.environ/OPENAI_API_KEY
router_settings:
  fallbacks: [{"frontier": ["frontier-backup"]}]

Start it with litellm --config /path/to/config.yaml. This config was loaded in LiteLLM 1.106.4 on Oct 27, 2026, with dummy API keys, and the proxy listed small, mid, frontier, and frontier-backup. No real calls were made, so the fallback wasn't exercised. The proxy refused to start until a master key was set (the LITELLM_MASTER_KEY environment variable or general_settings.master_key).

Inventories, scans, and test runs call small; copy and front-end work call mid; the four decision points call frontier. Fallbacks run in order after retries fail, and LiteLLM has separate content_policy_fallbacks and context_window_fallbacks settings.

Try it on one page or one feature

Before changing the whole workflow, build one real page or feature twice: once with one model everywhere, once routed. Compare five things:

• retries per stage
• human edit and fix time
• weekly limit or spend used, from the provider's usage screen
• whether it passes the human keyboard, screen reader, and contrast check, not only an automated scan (tools can only assist)
• whether it passes the human launch gate

If the routed build passes with equal or less fixing, keep it. If a stage failed, move just that stage up a tier.

This is an experiment to run, not a result I'm reporting. Your own page is the benchmark that matters.

FAQs about model routing

The short version

Frontier models such as Fable are for decisions, not repeat work. Put them at the four decision points (the brief, the site structure, the design direction, and the final review), have people approve the site structure, the design direction, and the launch, and give everything else to cheaper tiers. Log which model ran, and test on one page first.

Model names and prices change often, so re-check the linked provider pages before you budget.