What Is Cloudflare Clairic? System One Extraction Explained

Cloudflare Clairic (@cf/cloudflare/clairic) is a preview model on Workers AI that reads its input in one pass and returns typed values such as numbers, dates, text spans, lists and estimates, without generating tokens. When the requested fields do not fit beside the input in one pass, the server splits them into parallel passes that each see the whole input. It bills input only, took 0.46 seconds in Cloudflare’s own claims demo, and returns null with a confidence score when a field is missing.

Facts here were checked on 22 October 2026, three days after the preview launched. Cloudflare’s figures come from its launch post and model page, which are not linked here, and are labelled as vendor tests.

What is Cloudflare Clairic and what is a System One model?

Clairic is an extraction model that Cloudflare released as a preview on 19 October 2026. It belongs to the System One class: models that do one narrow job, here reading typed values out of text and images, and write no prose.

The label comes from TypeSafe AI, which uses it for a model that makes decisions and does nothing else. Cloudflare’s Clef and TypeSafe’s Jev are the decision models, and Clairic is the extraction side. Open weights are promised without a date.

A request carries the input text, up to four images, and a map of named fields. Each field has a type: text, number, date, time, datetime, duration, list, estimate or forecast. The model page lists a 65,536-token context window and a price of $0.10 per million input tokens.

How does Clairic differ from asking an LLM to return JSON?

An LLM asked for JSON generates its answer token by token and bills for every token it writes. Clairic reads the input in a forward pass (parallel passes when the fields do not all fit in one), generates no output tokens and bills only for input. In Cloudflare’s claims demo the extraction step took 0.46 seconds, and dates and numbers arrive already typed.

The last row comes from Cloudflare’s own claims demo, which does not state a run count, so treat it as a reason to test.

What do the claims-pipeline numbers show?

In Cloudflare’s own test, a cracked-screen damage claim took 19.3 seconds end to end through Clairic, Clef and GLM-5.3, against 61.7 seconds with GLM-5.3 at every step. Cost was $6,032 against $11,740 per million claims. It covers one claim type run by the vendor, so treat it as a direction to test.

PPC Land’s coverage repeats the headline numbers and notes that the post gives no run count for the all-LLM side and no failure rates for Gemma 4 and Qwen, which Cloudflare says failed the task in that setup.

Two details in the results table matter.

• The reply step is still the cost. The reply took 18.6 of the cascade’s 19.3 seconds (96%). Output tokens were $5,848 of its $6,032 per million claims (97%). Clairic and Clef made extraction and the decision nearly free, leaving the model that writes text.
• The step times do not add up to the reported total. The all-LLM steps sum to 54.4 seconds, not 61.7, and the post does not explain the 7.3-second gap. On step times alone the cascade is 2.8 times faster, against the headline 3.2.

Accuracy did not separate the two setups. Cloudflare says both pipelines got the facts and the decision right in every run. Speed, cost and the repair estimate differed: it was identical across Clairic runs and varied across GLM-5.3 runs.

What does Clairic return when a field is missing?

Clairic returns null for a field it cannot find in the input. Every scalar answer also carries p_null, the probability that the value is absent, and a confidence score. In Cloudflare’s example, a missing tracking number came back null while the model’s low-confidence guess stayed visible, so downstream code can branch on absence instead of parsing a made-up value.

GIGAZINE reports the same tracking-number case, and the DEV Community summary adds that text answers carry character offsets, so the source passage can be highlighted. Estimate fields return a median and an 80% interval.

Cloudflare tested the interval by forecasting public TSA checkpoint counts daily for 21 days. Average error was 3.3%, and 17 of 21 actual counts fell inside the 80% interval (81%, on a small sample), with three of the four misses on the Columbus Day weekend.

Cloudflare, quoted by PPC Land, puts the boundary of all this plainly: “the architecture makes every answer well formed, not necessarily correct.” A null with a confidence score tells your code when to be careful, but a high-confidence value can still be wrong.

Where does Cloudflare Clairic fall short today?

Cloudflare lists its own limits: long chains of dependent arithmetic and sums across many table rows are hard, forecasting is basic, and calibration is measured, not guaranteed. Clairic is also a preview under as-is terms with no open-weights date, and every performance number so far comes from Cloudflare’s own single claim type.

• Arithmetic. PPC Land quotes Cloudflare saying reading is strong but multi-step arithmetic is not there yet. One- and two-step calculations such as totals, differences, conversions and date arithmetic “seem reliable”, while longer chains and aggregation across many table rows are hard for any one-pass model without a scratchpad. For those cases, extract the numbers with Clairic and do the sums in code.
• Forecasting. The model forecasts from patterns in the series and ignores holidays. Cloudflare says it does not replace a dedicated time-series model.
• Calibration on unfamiliar data. In Cloudflare’s receipt example, confidence on an order number and a purchase time was lower than on the other fields, and intervals can be narrow on unfamiliar data.
• Self-hosting. Without open weights, a data-residency rule against hosted APIs rules Clairic out for now.

What does a cascade of small models mean for agent teams?

Small models read and decide, and one large model only writes: the model choice moves from one per agent to one per job. For a developer shipping an internal agent, or the IT lead who signs off its cost, output tokens become the line item to watch, at 97% of the cascade’s cost in Cloudflare’s test.

Extraction sits right after a tool call in an agent loop: a tool returns a record, and something reads fields out of it before the next step. If that is a large model writing JSON, every field pays for output tokens and every missing field invites a made-up value. Null plus confidence gives code a way to handle absence.

That is the shape we use inside Defender, StackOne’s open-source guard for tool results. Its third tier used to ask a generative LLM whether a tool result was trying to give the agent instructions. We are testing a decision model in that slot that answers three typed questions and returns a probability for each option. The post linked earlier reports 16 ms of GPU time per request, against a few hundred milliseconds for the old generative tier. It is in initial testing, replaces nothing yet, and still struggles with long tool results. Our notes on OpenAI’s Decisions API cover how to evaluate that class of model before switching.

How should you test Clairic against your current extraction step?

Build a labelled set of a few hundred real inputs from your own records, run Clairic and your current LLM extraction on the same set, and compare field-level accuracy, null handling and cost per completed record. Start with fields that are sometimes absent, because that is where the two approaches differ most.

1. Label 200 to 300 real inputs, including some where a field is absent, such as a claim with no tracking number.
2. Run both extractors on the same inputs three times each, and record how often the same field changes between runs.
3. Score null handling on its own: how often does each return a value when the right answer is null?
4. Pick a confidence threshold and count confident wrong answers above it, not just overall accuracy.
5. Work out cost per completed record, including retries and any record escalated to a larger model. Where agent tokens go counts the failed attempts too.

If Clairic passes on your data, you have a faster, cheaper extraction step with an explicit “not found”. If you run agents over enterprise apps and want to see how tool results are screened before they reach the model, you can book a StackOne demo.