Cloudflare releases Clairic: a data extraction model with no output tokens

Cloudflare has released Clairic in preview, the first model in a new class it calls System One extraction. It is available on Workers AI as @cf/cloudflare/clairic, and open weights are promised in the near future. Clairic pulls values out of unstructured input, then computes, estimates and forecasts them. It does this in a single parallel pass, with no reasoning and no output tokens. A response usually takes less than a second, whereas an LLM that reasons through the same step spends several seconds. You pay only for input.

A third model type in the System One family

The System One concept (a fast, accurate model in Kahneman's terms, as opposed to a slow System Two such as an LLM) was introduced a month earlier by TypeSafe with its Jev model. Jev and Clef are decision models: they are given a state and a list of questions, and they return probabilities over pre-listed options. Cloudflare spotted a gap.

A huge share of calls to frontier LLMs with structured output boils down to the same questions: what is the total on the invoice, when was it delivered, how many days late was it, how much will the repair cost, what will traffic be over the next 24 hours. You cannot list the answers to such questions in advance, so a decision model does not fit here.

The division of labor looks like this. Clairic turns raw input into typed values, Clef and Jev turn values into decisions, and an LLM turns decisions into words. Clairic's output space is continuous but bounded by your schema, and every answer is either a value of the declared type or null.

What a request looks like and what comes back

A request consists of a state (text plus up to four images) and a map of typed fields. Each field has a name, a type and an optional plain-language instruction. If the fields do not fit alongside the input in a single pass, the server splits them into parallel passes on its own, each of which sees the entire input, and then merges the answers. That is why thirty fields cost about as much as three.

Supported types:

• text: a fragment of the input with character offsets (span) • number: a number that is read or computed, respecting integer and decimals • date, time, datetime: calendar dates and valid times in ISO format • duration: a length of time in the chosen unit • list: a list of texts, numbers or dates in the order they appear in the input • estimate: a distribution within your [min, max] on a given grid, linear or logarithmic • forecast: one estimate for each future step of a series, each with its own 80% interval

Every scalar answer comes with p_null (the probability that the value is not in the input) and confidence. Estimates have a median and a p10–p90 interval, and all 99 percentiles are returned on request.

Take the example of a customer's email: order A-88412 delivered on September 28, $649.00 paid plus $52.10 in tax, email written on October 9. Clairic adds up the price and tax itself and returns 701.10, and it computes the number of days since delivery as 11. The damage (cracked screen, dented corner) comes back as exact spans that can be highlighted in the source. The email contains no tracking number, so the field returns null with p_null = 1, while the guess ($52.10) shows what the model would have picked if it were not allowed to leave the answer empty. Its confidence in that guess is only 0.416.

The same mechanism works on a photo of a receipt taken at an awkward angle. The model extracted order number 77245, purchase time 2026-07-01T13:34:00, two items at 7.99 each, a subtotal of 15.98, a tip of 2.39 and zero tax. It correctly returned the discount as null, with p_null of about 0.9994. Confidence in the order number and time is lower (0.78 and 0.83) than in the amount (0.99999), and this gap is what the company suggests using to route documents to manual review.

Where this changes pipeline economics

A typical LLM-based extraction pipeline accumulates layers: parsing, schema validation, retries, spot checks. You pay for reasoning and output tokens on every field of every document. The errors are also insidious. The JSON may turn out to be invalid, a digit may get distorted during generation, and the extracted fragment is not tied back to the source. Clairic has no generation, so there are no mutated digits. It can still be wrong, but the error will be a value of the correct type with low confidence or a wide interval, not a broken string.

With estimates the advantage is even bigger. An LLM gives a single number, and from it you cannot tell a confident $180 from an uncertain one. The buckets in a decision model are coarse, and each one adds input tokens and confusion. A narrow interval from Clairic means confidence, while a wide one means the value should go to a second check.

In practice, this means parsing invoices, receipts and support requests, estimating repair costs or prices from comparable sales, and forecasting load for the next 24 hours. For all of these tasks, the automation threshold can be set as a number, for example accepting values with confidence above 0.95 and sending the rest to a human or to an LLM. For now Clairic is in preview, but open weights will let you test it on your own documents and possibly host it yourself.