Jev Decides, Fable 5.2 Writes: The Two-Model Architecture

Claude Fable 5.2 is the most capable model Anthropic sells to everyone, and at $8 per million input tokens and $40 per million output, it is priced like it. Most production AI features do not need that much model for most of their traffic. They need a fast, cheap judgment first, what is this, how urgent, who should handle it, and a capable writer only for the part that is actually hard.

That is the architecture we build most often, and the rule behind it is short: Jev decides, Fable writes. A decision model reads every input and answers typed questions about it. Code routes on those answers. The frontier model only sees what deserves it.

Run the inbox

Here is a support inbox of ten messages. Jev has answered one Choice for each, the intent, with a confidence. Code acts on answers above the threshold: spam is dropped, how-to questions get a help article, and refunds, bugs and sales messages go to Fable 5.2 for a drafted reply. Anything below the threshold goes to a person.

Press Run the inbox, then move the threshold and the effort level.

Three things show up straight away:

• Jev's share of the bill rounds to nothing. The decision layer costs a few millionths of a dollar per message. Almost all of the pipeline's cost is the Fable calls you chose to make.
• The savings come from the calls you skip. Every dropped spam message and every help-article reply is a Fable call that never happened, along with its thinking tokens.
• The threshold trades cost for human time. Raise it and more messages go to a person; lower it and more go to code. The right setting is a business decision, which is why it belongs in your code, not in a prompt.

Why not let Fable do both?

You can ask Fable 5.2 to classify the message and write the reply in one call. It will do both well. It is the wrong trade for three reasons.

Cost. Fable 5.2 always thinks, and thinking bills as output at $40 per million tokens. A classification that Jev answers for its input tokens alone costs Fable hundreds or thousands of output tokens. Across a month of traffic, that is the difference between a rounding error and a line item. The cost comparison has a calculator.

Control. Jev returns a probability for every option and a confidence for the answer. Code can set a threshold per action, stricter for refunds than for routing, and change it without touching a prompt. An LLM's self-reported confidence is not calibrated the same way; we explain the difference in Confidence vs probability.

Latency. Jev answers in a few hundred milliseconds. A Fable 5.2 call at high effort can take far longer, because it thinks before almost every reply. Deciding first means fast paths stay fast: the spam filter and the help-article reply never wait on a frontier model.

The pieces

A working version of this pipeline has four parts.

1. One Jev request per message

Ask every question code might need in a single request. Questions are evaluated in parallel against the same state, so extra ones barely move latency, and the state dominates the bill. We call this speculative fan-out.

{
  "model": "typesafe/jev-1.14",
  "state": { "email": "Charged twice for the annual plan. Payroll runs Friday. Refund the duplicate today please." },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does the sender of `email` want?",
      "criteria": {
        "refund": "Money back, a credit, or a disputed charge.",
        "bug": "Something in the product is broken.",
        "how_to": "How to do something the product already supports.",
        "sales": "Pricing, plans, seats, or a purchase.",
        "spam": "Unsolicited, automated or irrelevant."
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "How soon does `email` need a reply?",
      "criteria": ["This week", "Today", "Within the hour"]
    },
    "angry": { "type": "noul", "instructions": "Is the sender of `email` angry or threatening to leave?" }
  }
}

2. Routing in code

The routing is ordinary code, which is the point: you can test it, log it and change it.

const { intent, urgency, angry } = decision.answers;
const sure = intent.confidence >= THRESHOLD[intent.choice];

if (!sure || angry.noul > 0.7) return queueForPerson(msg, decision);
if (intent.choice === 'spam') return drop(msg);
if (intent.choice === 'how_to') return sendHelpArticle(msg);
return draftWithFable(msg, decision, urgency.score >= 1.5 ? 'high' : 'medium');

Notice the effort choice on the last line. Jev's urgency score picks Fable's effort level, so routine replies run at medium and the hard ones get high.

3. Fable gets the decision as context

When Fable 5.2 drafts the reply, pass Jev's answers in the prompt: the intent, the urgency, whether the sender is angry. The writer starts from a structured brief instead of re-deriving it, and you never pay Fable to classify. Keep the system prompt fixed for the session and put per-message context in the user turn. Fable 5.2 checks that history is append-only on every account, which we cover in Fable 5.2 for builders.

4. Log both halves

Store Jev's full answer, including the probabilities and the exact model build, next to Fable's output and the final outcome. When something goes wrong you can see whether the decision or the writing failed, and you have the labelled data to re-tune thresholds.

Where the pattern bends

This design assumes most of your traffic does not need a writer. When it all does, such as a coding agent where every turn needs real reasoning, a decision model still earns a place, just a smaller one. Our Claude Code model router asks Jev how big each request is and sends the small ones to a smaller Claude. And for judgments that genuinely need multi-step reasoning, a decision model is the wrong tool; send those straight to the LLM.

Want this pipeline in your product? It is the core of our AI engineering practice. Send us a brief.

FAQ

Why put a decision model in front of an LLM?

To make the cheap, fast judgment first and spend the expensive model only where it adds value. A decision model like Jev answers typed questions for input tokens only, returns calibrated probabilities that code can threshold, and answers in a few hundred milliseconds.

How much does Jev add to a Claude Fable 5.2 pipeline?

Very little. At $0.042 per million input tokens, a Jev request on a short message costs a few millionths of a dollar, which is typically well under one percent of a pipeline whose writing is done by Fable 5.2 at $8 and $40 per million tokens.

Can Jev's answers choose Claude's effort level?

Yes. Route on a Jev Score such as urgency or complexity and set output_config.effort from it, so routine work runs at a lower effort and hard work runs at high.