Introducing Clairic, a new System One class of extraction models

Today, we're announcing a preview of a new class of System One-style models: extraction models. Our first one, Clairic, is available hosted on Workers AI as @cf/cloudflare/clairic.We intend to release the model open-weights soon. Clairic is an extraction model that is able to extract, compute, estimate, and forecast values from unstructured inputs — all at a significantly higher accuracy, faster latency, and cheaper cost than traditional LLMs.

When System One models were announced by TypeSafe a month ago, it took the industry by storm. As referenced by TypeSafe in their blog and defined by Daniel Kahneman’s book Thinking, Fast and Slow, a System One model should be fast and precise, which contrasts a System Two model that is capable of deliberate reasoning (like LLMs). With this, TypeSafe introduced Jev — a model that is purpose-fit for a specific use case, and priced accessibly given its niche domain. It excelled where LLMs failed, helping users make decisions based on probabilities and well-typed outputs. The introduction of Jev prompted people to start thinking about a new class of models that were not LLMs and how to integrate them into their workflows.

We were inspired by the concept of System One models and started thinking about other tasks where LLMs are inefficient. There are many structured-output calls going to frontier LLMs today with the same shapes again and again: What's the invoice total? When was this delivered? How many days late is it? What will this repair cost? What will traffic look like over the next 24 hours? None of these have answers you can list out in advance, which is needed for a decision model to give probabilities against. That led us to the class of models we're introducing today: System One extraction models.

Until now, every System One model has been a decision model: Jev and Clef take an input state and a list of questions and give probabilities against the inputs and your listed questions. Clairic is the first model in a new class: System One extraction models. It is still fast, typed, and cheap, but it answers with values directly extracted from the input, computed from it, or predicted beyond it.

Most model tasks ask for one of three kinds of output: a number, a choice from a fixed set, or open-ended text. Clairic handles the first, returning numbers with an 80% range, and also pulls typed values like names, dates and lists out of the input. Clef handles the second: it picks among options and returns a probability for each. LLMs handle the third. We call Clairic and Clef System One models because they answer in a single pass, without reasoning or generating tokens. They charge only for input and typically respond in under a second, while an LLM that reasons through the same step takes several seconds.

And because it generates no tokens, it can't produce a mistyped answer or “hallucinate” in the same way as an LLM (though it can, of course, make mistakes). Outputs are a value of the type you asked for, or null when the model fails to find an answer in the input. It also comes with confidence scores against the outputs to help you evaluate if it is appropriate to trust the model or to take a second look.

Here’s how extraction models fit into the landscape of System One and System Two models:

Typed values: spans, numbers, dates, times, lists, distributions, with calibrated probabilities

Typed decisions: options with calibrated probabilities

Continuous, but typed and bounded by your schema

What's the amount? When does it happen? How much will it be?

Which category is it? Is it legitimate? Which action should we take?

Why did it happen? How should we approach it? Can you fix it?

Yes: every answer is a value of its declared type (or null), inside your bounds

Yes: answers are always one of your options

Together, these models can work together in unison to help you get closer to parsing through real-world data, making decisions on inputs, and then taking actions. Extraction models turn raw input into typed values, decision models turn values into decisions, and LLMs turn decisions into words.

Clairic is designed differently than an LLM. Similar to a decision model, it only processes input tokens with a single forward pass, and thus has no charge for output tokens. It is much faster, cheaper, and more accurate than an LLM for certain use cases.

A request is a state (the text to read, plus up to four optional images) and a map of typed fields. You name each field, give it a type and optional plain-language instructions, and get back one typed answer per field, all from one parallel pass. There is no reasoning and no output tokens – everything computes in a single forward pass, which means it is both fast and cheap.

A specific span of the input, with its offsets

A number read or computed, honoring integer and decimals

Calendar dates and valid times, in ISO form

Matching text, number or date, in input order

A distribution inside your [min, max], on your step grid, linear or log scale.

Every scalar answer comes with p_null (the probability that the value isn’t in the inputs) and confidence. Every estimate answer comes with a median and an 80% interval (p10 to p90), plus all 99 percentiles on request. There's no limit on the number of fields: if they don't fit beside the input in one pass, the server splits them into parallel passes that each see the whole input, then merges the answers.

Here are some examples to illustrate the model’s features. Of course, using these features in a workflow would require appropriate inputs.

Extraction is probably the most common job handed to LLMs today: "return the invoice number, vendor and due date as JSON." It works most of the time, but the failure modes are hard to catch. The output may not be valid JSON, a digit can be misread as it's generated, and once a text excerpt comes back, there's no way to trace it to where it appeared in the source. Most people build extraction pipelines to combat this, with multiple layers of parsing, schema validation, retries and spot checks. On top of that, you pay for reasoning and output tokens on every field of every document.

Clairic operates differently; it doesn’t generate text answers. Instead, you get:

Let’s walk through an example to illustrate the ways Clairic can extract values from unstructured data and make estimates. Take a customer support email:

Hi, order A-88412 arrived on Sept 28, 2026 with a cracked screen and a dented corner. I paid $649.00 plus $52.10 tax. It's now Oct 9, 2026 and I'd like this fixed or refunded. Thanks, Dana

From a Worker, you would make a request to Clairic to process this data:

const { answers } = await env.AI.run("@cf/cloudflare/clairic", { state: email, fields: { order_id: { type: "text", instructions: "Order number" }, delivered_on: { type: "date", instructions: "Delivery date" }, amount_paid: { type: "number", decimals: 2, unit: "USD", instructions: "Total paid including tax" }, days_since_delivery: { type: "duration", unit: "days", integer: true, instructions: "Days from delivery to the date the customer wrote" }, damage: { type: "list", items: "text", instructions: "Each kind of damage described" }, tracking_number: { type: "text" }, }, });

Clairic returns the extracted values, spans in the input, probability that it is null (p_null) and confidence score:

{ "order_id": { "type": "text", "p_null": 3.4e-6, "span": [10, 17], "guess": "A-88412", "confidence": 0.999957, "value": "A-88412" }, "delivered_on": { "type": "date", "p_null": 6.5e-8, "guess": "2026-09-28", "confidence": 0.999999, "value": "2026-09-28" }, "amount_paid": { "type": "number", "p_null": 1.6e-5, "guess": 701.1, "confidence": 0.999944, "value": 701.1 }, "days_since_delivery": { "type": "duration", "p_null": 6.1e-9, "unit": "days", "guess": 11, "confidence": 0.999999, "value": 11 }, "damage": { "type": "list", "value": ["cracked screen", "dented corner"], "spans": [[50, 64], [71, 84]] }, "tracking_number": { "type": "text", "p_null": 1, "span": [106, 112], "guess": "$52.10", "confidence": 0.416016, "value": null } }

A few things to notice:

Here’s a real-life photo of a receipt — the text is not perfect and the angle of the image doesn’t help its legibility. We passed this image to Clairic to see what it could extract:

{ "model": "clairic", "answers": { "order_number": { "type": "number", "p_null": 0.0040206750854849815, "guess": 77245, "confidence": 0.776249383996532, "value": 77245 }, "purchased_at": { "type": "datetime", "p_null": 4.136094133855295e-08, "guess": "2026-07-01T13:34:00", "confidence": 0.831464227002992, "value": "2026-07-01T13:34:00" }, "quantity": { "type": "number", "p_null": 5.2313655629632194e-08, "guess": 2, "confidence": 0.9997007500403496, "value": 2 }, "unit_price": { "type": "number", "p_null": 0.001599092734977603, "guess": 7.99, "confidence": 0.9991279019989127, "value": 7.99 }, "subtotal": { "type": "number", "p_null": 9.69956488461321e-08, "guess": 15.98, "confidence": 0.9999881983893096, "value": 15.98 }, "sales_tax": { "type": "number", "p_null": 2.5511653802823275e-06, "guess": 0, "confidence": 0.9999800924450729, "value": 0 }, "tip": { "type": "number", "p_null": 5.953857908025384e-05, "guess": 2.39, "confidence": 0.9335768781214697, "value": 2.39 }, "discount": { "type": "number", "p_null": 0.9994148015975952, "guess": 0, "confidence": 0.91852733929319, "value": null } } }

As you can see, it was able to extract all the values from the images, alongside a confidence score. It also correctly stated that there was no discount shown in the receipt, giving the value as null.

Some values aren't in the input at all, but the input carries evidence for them. For example, values might not be in plain text but can be discerned from values around it. If you ask an LLM for an estimation, you usually get a single number with no sense of how sure the model is. It will make safe guesses or hallucinate, or reason its way around the answer. If you land on an estimate, any downstream processing can't tell a confident $180 from an unconfident $180, so it can't help you decide what is appropriate to automate in the circumstances. It is also a lot slower and more expensive to do reasoning through LLMs.

A decision model can approximate an estimate by choosing among buckets ("under $100", "$100–500", …), but buckets are coarse, every bucket adds input tokens, and each new category adds more sources of confusion for the model during its decision making process.

Clairic returns a distribution over the range you declare: a point value, a median, an 80% interval, and every percentile on request. The estimate is designed to fall inside your bounds, so there's nothing to clamp or round afterward. The width of the interval reflects data confidence: a narrow range signals high certainty, while a wide range indicates low certainty, information you can use to route another check.

Here’s another example, where Clairic looks at historical home prices and comparable sales, to determine an estimate :

const { answers } = await env.AI.run("@cf/cloudflare/clairic", { state: `Comparable sales: sqft,beds,year_built,neighborhood,sale_price 1450,3,1998,Elm Park,412000 2100,4,2006,Elm Park,585000 980,2,1975,Riverside,265000 1600,3,2003,Elm Park,449000 1300,3,1990,Riverside,318000

Subject property: sqft,beds,year_built,neighborhood 1620,3,2001,Elm Park`, fields: { sale_price: { type: "estimate", unit: "USD", min: 50000, max: 5000000, scale: "log", step: 1000 } });

Clairic will return an estimated value:

{ "sale_price": { "type": "estimate", "value": 418000, "median": 415000, "p10": 370000, "p90": 470000, "p_below": 0.0, "p_above": 0.0 } }

Values always fall inside your bounds, and the width of the interval shows how much the input informs the prediction: price is narrow ($370,000-$470,000), days on market is wide (24-148