On October 19, 2026, Cloudflare released a preview of Clairic, an AI model that extracts values such as amounts and dates from documents, on Workers AI. Instead of generating text one word at a time, it returns values of specified types, and it also handles simple calculations and estimates of future values. In a customer-support demo, Cloudflare said that leaving extraction and judgment to dedicated models cut both time and cost compared with processing everything with an LLM. But a value that looks like a valid date is not necessarily the correct date that was read from the document. Using Clairic comes down to deciding which tasks to move off the LLM and where to keep checks in place.
Clairic returns values, Clef chooses among options
Clairic returns values that change with each input, such as an order number or an invoice amount. Clef, which Cloudflare announced on October 1, returns a judgment chosen from options prepared in advance. "Refund or repair?" can be answered by listing options, but "How much will the repair cost?" cannot. Clairic handles the latter.
Cloudflare describes both as "System One"-type models that process an input once and answer. What you give Clairic is state, which contains the text to read, and fields, which defines the items you want. Each field is given a type, such as a number or a date, and can be accompanied by a natural-language instruction if needed. The design does not generate an answer or a reasoning process token by token; it processes the specified fields in parallel.
In the official customer-email example, the model calculates a total payment of $701.10 from a $649.00 product price and $52.10 in tax, and works out 11 days from the September 28 delivery to the October 9 contact. Neither the total nor the elapsed days is a number written directly in the email. Items such as the order number and the damaged part, on the other hand, are returned as strings from the original text along with their positions. Because the application can display the relevant passage, it is easy to take an extraction result back to its original context and verify it.
Estimates use a different output. estimate, used to ask about things like repair costs, returns a predictive distribution between a specified minimum and maximum, showing the median and a central 80% interval. With forecast, you can receive a value and an interval for each future step of a time series. The mechanism avoids treating facts that were read, values calculated from the input, and predictions of outcomes not yet known as the same kind of "number."
After the cut to 19.3 seconds, where does the waiting remain?
Cloudflare compared a demo that handles a customer-support case about a damaged product by processing in the order Clairic, Clef, then a text-generation LLM. Clairic extracts the payment amount and damage details from the email and estimates the repair cost, and Clef decides between a refund and a repair according to company policy. Finally, GLM-5.3 writes the reply. The comparison baseline uses the same email, policy, and prompts but leaves every stage to GLM-5.3.
| Process | Clairic, Clef, and GLM-5.3 split | All stages on GLM-5.3 |
|---|---|---|
| Value extraction | 0.46 s | 16.1 s |
| Decision on response | 0.22 s | 21.9 s |
| Reply generation | 18.6 s | 16.4 s |
| Total time | 19.3 s | 61.7 s |
| Cost per 1 million cases | $6,032 | $11,740 |
Source: Cloudflare's October 19 announcement, customer-support demo comparison table. Total times use the figures published by the company and may not match the sum of the per-stage values shown.
According to the company, the split reduced total time by about 69% and cost by about 49%. Moreover, in this trial both configurations got the fact extraction and the judgment right, so the difference shows up mainly in speed and cost. This is one business example presented by the developer, and it does not measure the performance gap across all documents or all LLMs.
In Cloudflare's comparison demo, reply generation at 18.6 seconds accounts for about 96.4% of the 19.3-second total after the split. This ratio is calculated by dividing 18.6 by 19.3 from the table above. Once extraction and judgment are shortened to under a second combined, the text-generation step takes up most of the waiting time.
In other words, how much Clairic's speed helps depends on how far a workflow can be handled with values and judgments alone. A process that passes numbers to the next system can skip text generation, but if a reply to a customer is needed, LLM time remains. Rather than looking only at the speed of an individual model, you need to design the steps starting from what you ultimately want to output.
Separating type guarantees from correct answers
The official explanation of the extraction model distinguishes between cases where a value cannot be found and cases where an unknown value is being estimated. A field that extracts or calculates a single value returns null when the model judges that the input alone cannot determine the answer. The information may really be missing, or the model may have overlooked it. A null cannot be read as proof that the value does not exist in the original text.
In the customer-email example, the tracking number is null, while the guess field still holds a string for the tax amount that the model would have chosen instead. If that candidate is used as a confirmed value, the application ends up negating the mechanism meant to signal a missing value. The design is meant to use the confidence attached to a result and p_null, the probability that the value cannot be determined, to decide which values to recheck.
Estimates and forecasts, however, return values even when the material is thin. Just because there is null detection during extraction does not mean a repair-cost prediction has sufficient grounds. Likewise, a constraint that a value fall within a specified range does not force real-world outcomes into that range; it merely limits the values the model can return.
Cloudflare itself explains the caveat of the preview as follows:
"This architecture formats every answer, but it does not necessarily make it correct" (Cloudflare, translated from the original)
The same caution applies to prediction intervals. The interval from p10 to p90 represents the central 80% of the predictive distribution. It is not a guarantee that future actual values will fall inside it, and the company acknowledges that intervals can be too narrow on unfamiliar data.
The announcement also includes an example in which next-day forecasts of the number of people screened by the U.S. Transportation Security Administration (TSA) at airports were evaluated over 21 consecutive days. By the company's figures, the mean error was 3.3%, and the actual value fell within the 80% interval on 17 of the 21 days. However, three of the four days that fell outside the interval were during the Columbus Day holiday weekend, when numbers exceeded what could be expected from the previous few weeks. The model cannot read holiday effects that do not appear in the series, and the result cannot be taken as replacing a dedicated time-series model.
Adopt it while keeping calculation and checks
Clairic is priced at $0.10 per million input tokens, with no charge for output tokens. It can be used as @cf/cloudflare/clairic through Workers' env.AI.run() or the REST API. There is no limit on the number of fields, but if the input and field definitions do not fit in a single pass, the work is split across multiple parallel passes and the results are combined. This does not mean a single computation always suffices no matter how many fields are added.
Up to four images can also be passed, but only by embedding PNG, JPEG, or WebP; specifying an image URL is not supported. When adopting it for document processing, you will need to decide how to feed in your existing materials, along with defining the fields you want.
Cloudflare also draws a line on the division of labor for calculation. It says one- or two-step calculations such as totals and date differences work well, but calculations with long dependency chains and aggregation over many table rows are still weak spots. In those cases, it recommends having Clairic extract the necessary values and doing the calculation itself in code. Estimation requires comparison cases or history, and it is not suited to precisely predicting long-term forecasts.
The current offering is a preview, and releasing the model weights is a future plan. In deciding whether to adopt it, check not only whether it picks up the values you need from your own documents, but also whether it avoids overlooking missing items and whether its estimated intervals match actual outcomes. For processes where an error would be costly, such as payments, keep separate evidence or human review in place, and move forward with the split between Clairic and an LLM starting from the steps that can meet those conditions.