Cloudflare Clairic: A System One Extraction Model That Returns Typed Values, Not Text

Compare: How does Cloudflare's Clairic extraction model compare with Jev, OpenAI Decisions, Clef and Microsoft-Decision-1? See the side-by-side comparison.

Cloudflare has previewed Clairic, a model that does not write answers at all: it fills in a typed form. You send it text (and up to four images) plus a map of named fields, and it returns numbers, dates, durations, lists, text spans, estimates with intervals, or short forecasts, each with a confidence score. It is hosted on Workers AI as @cf/cloudflare/clairic, and Cloudflare says open weights are coming "soon", with no date.

The headline claim is that a pipeline built around Clairic cost 49% less and ran about 3.2 times faster than the same pipeline on a large language model. That figure comes from one Cloudflare-run test. This post separates what Cloudflare measured, what it merely asserts, and how you can check it yourself. It is the third act of a story we have followed since TypeSafe's Jev launch and Cloudflare's Clef decision model: the idea that many LLM calls are really single-pass classification or regression problems in disguise.

TL;DR: Clairic claimed vs verified

What does Clairic actually do?

Cloudflare splits model output into three kinds: a number, a choice from a fixed set, or open-ended text. Clairic handles the first, and also pulls typed values like names and dates. Clef handles the second by returning a probability for each option you list. LLMs handle the third.

A request has a state (the text to read, plus up to four optional images) and a fields map. Each field has a name, a type and optional plain-language instructions. The supported types are text, number, date, time, datetime, duration, list, estimate and forecast. Every answer arrives in the type you asked for, or as null when the model cannot find it.

Every scalar answer carries two extra numbers: p_null, the probability the value is not in the input, and confidence. Estimates return a median and an 80% interval (p10 to p90), with all 99 percentiles available on request. Text answers return character offsets, so you can highlight the exact span in the source.

Because everything is computed in one parallel forward pass, there are no output tokens to bill and, Cloudflare says, responses typically come back in under a second. Asking for thirty fields costs about the same as asking for three; if the fields do not fit beside the input, the server splits them into parallel passes and merges the answers.

Structured output schema with fields filled in from a source document

The worked examples: what Cloudflare showed

Cloudflare's first example is a short customer email: order A-88412 arrived on Sept 28, 2026 with a cracked screen and a dented corner, the customer paid $649.00 plus $52.10 tax, and it is now Oct 9. Six fields were requested, and the post reports:

• The order ID came back as A-88412 with offsets 10 to 17 and confidence 0.999957.
• The amount paid came back as 701.10, a figure that appears nowhere in the email. Clairic added price and tax.
• Days since delivery came back as 11, computed from two dates.
• The damage list returned "cracked screen" and "dented corner" as exact spans.
• The tracking number, which is not in the email, came back as null with p_null of 1. Its internal guess was the tax amount, "$52.10", at confidence 0.416, and it was not returned as an answer.

That last behavior is the real design point. An LLM asked for JSON with a tracking number may invent a plausible string. A typed model that returns null and exposes its rejected guess makes the failure visible and routable.

The second example is a photographed receipt with an awkward angle. Clairic extracted order number 77245 (confidence 0.776), a purchase datetime (confidence 0.831), quantity 2, unit price $7.99, subtotal $15.98 and a $2.39 tip, and returned null for the discount with p_null of 0.9994. The lowest confidences landed on the fields most likely to be smudged, which is the behavior a confidence score is for. Cloudflare published only this one image, so treat it as a demo rather than an OCR benchmark.

Estimates and forecasts: useful, but "basic"

For values the input implies but does not state, Clairic returns a distribution inside bounds you declare. Cloudflare's example gives five comparable home sales and a subject property of 1,620 sqft; the model returns a value of $418,000, a median of $415,000 and an 80% interval of $370,000 to $470,000. The width of the interval is the signal: narrow means the input was informative, wide means route it to a human.

The forecasting test used public TSA checkpoint counts. Each morning for 21 days, Cloudflare gave Clairic the real counts so far and asked for the next day. For October 14 it predicted a median of 2,419,283 against an actual 2,419,474. Across the 21 days, Cloudflare reports an average error of 3.3%, with 17 of 21 actuals inside the 80% interval, which is roughly what a calibrated 80% interval should deliver. Three of the four misses fell on the Columbus Day weekend, which the series alone could not anticipate.

Cloudflare is candid here: Clairic "is not claiming to replace a dedicated time-series model," and the post calls forecasting "basic," meant for non-critical pattern matching rather than long horizons. Note that 21 days of one public series is a demonstration, not a forecasting benchmark.

A gauge with a narrow green confidence band illustrating Clairic's 80 percent interval

The pipeline test: 49% cheaper, 3.2x faster

The most quoted result comes from a three-stage customer-claim pipeline. Clairic extracts values and estimates a repair cost, Clef chooses between a full refund and a repair under a stated policy, and GLM-5.3 writes a short reply. The baseline uses GLM-5.3 for all three steps. Cloudflare's reported table:

Cloudflare describes this as 69% faster, about 3.2 times quicker, and 49% cheaper. The cascade column adds up (0.46 + 0.22 + 18.6 is about 19.3 s), but the all-LLM column does not. The all-LLM step times (16.1 + 21.9 + 16.4) sum to 54.4 seconds rather than the stated 61.7, a gap of about 7.3 seconds that the post does not explain; PPC Land flagged a mismatch too, though its own sum was off. PPC Land also notes that the post does not break out Clairic's or Clef's per-token prices, so the blended cost cannot be reproduced from the page alone.

What is verified: the cascade numbers are internally consistent and the extraction and decision steps really are sub-second in Cloudflare's run. What is not verified: that the result generalizes beyond one email, one policy and one baseline model. Cloudflare also says Gemma 4 and Qwen failed the all-LLM version because they could not deduce values like repair cost, but gives no version numbers or run counts. And note where the remaining cost sits: almost all the cascade's 19.3 seconds is the LLM writing the reply. The savings come from removing LLM calls from the steps that did not need prose.

One more reported finding: Clairic's repair estimate was identical across runs, while GLM-5.3's varied between runs ($250, $250 and $220, with different ranges each time). Determinism is a genuine advantage for audit trails, though the post does not say how many total runs were performed.

A short fast lane beside a long road, standing for a one-pass model skipping slow token generation

What Cloudflare says does not work yet

The post ends with a list of limits worth reading before you build on it:

• Arithmetic. One- and two-step calculations (totals, differences, date math) "seem reliable," but longer chains and aggregation across many rows are hard for any one-pass model. Cloudflare recommends having Clairic predict values and letting code do the math.
• Evidence. Estimates work best from comparables, history or descriptive text; asking for a value with no evidence gives vague answers.
• Calibration. It is "measured, not guaranteed," and intervals can run narrow on unfamiliar data.
• Forecasting. Basic, as above.
• Correctness. The architecture makes every answer well formed, "not necessarily correct."

That last line matters most. The marketing claim of "significantly higher accuracy" is not backed by a general extraction benchmark in the post; the evidence is worked examples. A typed output eliminates broken JSON and mistyped values. It does not eliminate a confidently wrong number.

Why System One models keep multiplying

Clairic is the latest entry in a fast-moving category. TypeSafe's Jev started the framing, borrowed from Kahneman's fast and slow thinking: fast, cheap, single-pass models for narrow jobs, with slower reasoning LLMs reserved for open-ended work. Since then we have tracked Microsoft's Decision-1, Liquid AI's open D1 models, Perplexity's decider and OpenAI's Decisions API. For the mechanism, see our explainer on how Jev works and the guide to what decision models are.

Until now, every one of these was a decision model: pick from options you list. Clairic is the first major entry on the regression and extraction side, where the answer space is continuous or open (an invoice total, a date, next week's traffic). That is a real expansion of the idea, because extraction is arguably the most common job handed to LLMs today.

There is also a security argument. In Cloudflare's cascade, Clef decides from a short summary of typed values rather than from the raw email, and the final LLM never sees the email. A hidden instruction in customer text must survive conversion into a typed number, date or span before it can influence anything downstream. That reduces, but does not remove, prompt-injection exposure. For that class of risk, see our guide to indirect prompt injection in AI agents and the AgentBeam platform from the explainx.ai team, which stops AI agents before they take dangerous actions.

How to test Clairic yourself

Cloudflare's own snippet is the fastest start. From a Worker with the AI binding:

const { answers } = await env.AI.run("@cf/cloudflare/clairic", {
  state: email,
  fields: {
    order_id: { type: "text", instructions: "Order number" },
    amount_paid: { type: "number", decimals: 2, unit: "USD",
      instructions: "Total paid including tax" },
    tracking_number: { type: "text" },
  },
});

A sensible evaluation plan before you move any production extraction off an LLM:

1. Collect 200 real documents from your own pipeline, with ground-truth values your team has verified.
2. Run both Clairic and your current LLM on identical fields and score exact-match accuracy per field type.
3. Check calibration. Bucket answers by confidence and p_null, and confirm that low-confidence answers are the wrong ones.
4. Measure latency and cost at your real volume, using the Workers AI pricing page since the announcement lists no price.
5. Keep the arithmetic in code. Have the model read values and let your own function compute totals.
6. Plan the fallback. Route null or low-confidence answers to an LLM or a human.

If open weights do land, you will also be able to compare a self-hosted run against the hosted endpoint, which would settle the cost question for high-volume users.

What this means for what you build or pay

If your product makes repeated structured-output calls with the same shape, such as invoice totals, delivery dates, days late, repair costs or traffic estimates, Clairic is worth a bake-off, because those calls currently pay for reasoning and output tokens on every field of every document. The upside is lower latency, lower and more predictable cost, deterministic outputs and a built-in way to say "I could not find it." The downside is a preview endpoint, no published price, no independent benchmark, and a lock-in risk until the weights ship.

If your extraction needs multi-step math, reasoning over long documents, or free-form summaries, an LLM is still the right tool. The more honest framing is Cloudflare's own: extraction models turn raw input into typed values, decision models turn values into decisions, and LLMs turn decisions into words.

Related reading

• TypeSafe's Jev launch and the System One idea
• Cloudflare Clef: the open multimodal decision model
• How Jev works: RLCD explained
• What are decision models?
• Top 10 decision models ranked
• Microsoft Decision-1 and Foundry pricing
• Cloudflare Sandbox SDK 1.0 for agents
• Official: Cloudflare's Clairic announcement and the Workers AI docs

Details such as pricing, open-weights timing and benchmark numbers are accurate as of October 19, 2026 and may change as the preview evolves.