Clairic AI 🚀: AI Extraction Models Turn Data into Action
Discover Clairic AI: AI extraction models by Cloudflare Workers AI for structured data extraction, estimates, and forecasts. Learn use cases & limits.
Clairic and the Shift From AI Text to Typed Answers
Most AI workflows don't need another paragraph. They need a reliable invoice total, a delivery date, a list of reported defects, or a forecast - with some indication of uncertainty.
So teams reach for a general-purpose large language model (LLM). It can work for extraction, but it also comes with some familiar headaches: generated tokens that you pay for, validation layers around free-form output, and answers that look confident even when you can't tell how sure the model really is. The issue isn't that LLMs are incapable of pulling values out - it's that generation is a clunky, expensive way to get a small, structured result.
Cloudflare's Clairic is aimed squarely at that gap. It's positioned as a System One extraction model: instead of generating a response token by token, it's designed to extract, compute, estimate, or forecast typed values in a single pass. In this article, we'll look at how Clairic works, where it can fit in a business workflow, and why its confidence signals (and limits) matter as much as its speed.
What Clairic is designed to do
Clairic is a Cloudflare model for turning unstructured inputs into values with declared types. You can send text, and in supported requests, up to four images. You define the fields you want - dates, numbers, lists, estimates - and the model returns an answer for each field.
That's a different job from asking an LLM to explain a document. A general LLM is built to generate language and follow prompts. Clairic is meant for tighter tasks where you already know what you're asking for: read the source, identify (or compute) a value, and return it in a shape software can use.
Cloudflare frames Clairic as part of its broader System One model family. That framing borrows the common product contrast between quick, low-deliberation responses and slower, more careful reasoning. It's a helpful analogy, not a claim that the model "thinks" like a human. Practically, Clairic is designed to make one pass over the input - without producing a chain-of-reasoning or streaming generated tokens.
Extraction is more than copying text
An extraction task might pull an order number or vendor name from an invoice. Clairic also supports values that involve a bit of calculation. For example, if you provide a purchase price and a tax amount, the request can ask for the total. If you provide a delivery date and a message date, it can calculate elapsed time.
It also supports estimates and forecasts. Those aren't just "extract what's written" - the answer may not appear directly in the input. Instead, the input includes evidence the model can use for a prediction. Clairic can return a median and an 80% interval for estimates, or a sequence of forecast values with intervals.
Supported output types include:
- Text spans, with offsets showing where the value appears in the source.
- Numbers, with options for decimal precision and units.
- Dates, times, datetimes, and durations.
- Lists of matching text, numbers, or dates.
- Estimates bounded by a range and step size you specify.
- Forecasts for a declared number of future steps.
The typed interface matters because downstream systems shouldn't have to guess whether a model meant a date, a currency amount, or "a sentence that sounds like one."
How it differs from decision models and LLMs
Cloudflare places Clairic next to decision models such as Clef and Jev. A decision model picks from options you provide and can return probabilities for each option. Clairic, by contrast, returns values from a defined type or range. And an LLM is still the right tool when you actually need open-ended writing, explanation, or multi-step reasoning.
| Model approach | Typical job | Output |
|---|---|---|
| Extraction model, such as Clairic | Read or calculate values from input | Typed values, spans, or distributions |
| Decision model, such as Clef | Choose among defined alternatives | A selected option and associated probabilities |
| General-purpose LLM | Explain, write, or reason through a broader task | Generated text |
These approaches aren't rivals. The real question is simpler: which step of your workflow needs which kind of model?
How its extraction model works
A request gives the model a state - the text (and optionally images) to process - plus a map of named fields. Each field has a type, and it can include plain-language instructions. Clairic then returns an answer for each field in a single pass, or splits into parallel passes when needed.
Take a customer support email. A developer might ask for:
- an order ID as text,
- a delivery date as a date,
- the total paid as a number, and
- damage descriptions as a list.
The model can return the values along with signals like confidence and the probability that a value is absent.
Typed answers reduce parsing work, not the need for checks
Even when an LLM returns something that looks like JSON, your application still has to verify that it's valid JSON, that each field has the expected type, and that the values make sense. With a typed extraction interface, the response is structured around the field types you requested. Text answers can include character offsets, which makes it easier to point back to the exact supporting span.
If the model can't find a requested value, it can return null instead of inventing something plausible. It can also include a p_null signal - the estimated probability that the value is not present. In practice, that helps you decide whether to accept the result automatically or route it to a human review step.
None of this eliminates error, though. A "valid" date can still be wrong. A number can be well-formed and still based on a misread digit. Type safety mostly keeps the output shape under control; it doesn't magically guarantee correctness.
Estimates and forecasts include uncertainty
For estimates, the caller defines the range and, when relevant, the step grid or scale. Clairic returns a value distribution with a median and an 80% interval. A narrow interval usually means the evidence points more strongly in one direction; a wide interval is a sign to be cautious or ask for another check.
Forecasts use a similar setup for future values in a series. The input can be a plain-text history (including table-like data), and the request specifies the horizon and bounds. In Cloudflare's launch example, the model forecasted the next day using historical daily TSA checkpoint counts. Across 21 forecasts, the company reported a 3.3% average error, with 17 actual values inside the model's 80% intervals. The misses clustered around a holiday travel period - basically a reminder that historical patterns don't automatically account for events your input doesn't include.
One important caveat: the interval is only useful if it's calibrated for the data you're feeding it. Treat it as a decision signal for how you handle the result, not as a blanket promise that the "true" value will always land inside the range.
Where businesses can use it
Clairic tends to fit best when you have repeated, well-defined fields and inputs that arrive in inconsistent formats. The benefits get clearer at scale - when the same extraction task runs across thousands of records. In that situation, a small reduction in latency, token usage, or manual review can add up quickly.
Invoices, receipts, and claims
Finance and operations teams often need supplier names, invoice numbers, dates, subtotals, tax, and totals. Support teams may need an order ID, delivery date, a customer-reported problem, or an amount paid from an email or receipt image.
Span offsets can help users verify what text supported the extracted value. Typed numbers and dates can also cut down some of the conversion and parsing glue that usually wraps LLM-based extraction. And if a tracking number is missing, returning null is better than quietly passing along a guess as if it were fact.
That still requires business rules. You'll want to validate that invoice totals reconcile, dates fall within expected ranges, and currency values match the transaction record. Confidence thresholds are useful for routing ambiguous or high-impact cases to a person. The goal isn't to remove review everywhere - it's to put review effort where it matters most.
Triage and policy workflows
Extraction can also sit before a decision model. For example, a claim email can become typed facts: delivery date, amount paid, reported damage, and an estimated repair cost. Then a separate decision model can compare those facts against a refund or repair policy. Finally, an LLM can draft the customer message using the approved facts and the selected outcome.
This split is usually easier to control than asking one generative model to ingest a raw message, interpret policy, pick an outcome, and write the response in a single pass. Each stage does a narrower job, and you can log what values and decisions moved through the system.
It can also reduce exposure to prompt injection. If the model that writes the response never receives the raw customer email, instructions embedded in that email are less likely to influence the writing step. Separation of duties isn't a full security strategy - policies, permissions, and input handling still matter - but it can shrink the attack surface.
Forecasting and operational estimates
A team might use estimates to prioritize property listings, predict repair costs, or triage inbound leads. Forecasts can also help with lighter planning from historical counts, especially when you don't want to build and maintain a dedicated time-series pipeline.
There's a trade-off, though. A specialized forecasting system may be more accurate for a stable, well-instrumented metric - especially over a long horizon. Clairic's advantage is that it can work with less setup and imperfect input. That makes it a good candidate for exploratory or lower-risk workflows, not a guaranteed replacement for a forecasting model you already trust.
For implementation guidance, start with the Workers AI documentation and the Workers AI model catalog. Before production, test with representative documents, monitor errors by field, and decide exactly when the system should abstain or ask for human review.
What the preview can and cannot promise
Cloudflare introduced Clairic as a preview hosted on Workers AI, with open weights planned later. Preview status matters: the endpoint and model behavior can change, and launch results shouldn't be treated as a universal benchmark across every business dataset.
Cloudflare also described several limits in its early evaluation:
- Reading and simple calculations seemed stronger than long chains of arithmetic.
- Aggregating many rows, or depending on several chained calculations, can be harder in a one-pass model.
- Estimates work best when the input includes relevant evidence (comparable sales, historical values, and similar context).
- Confidence intervals are intended to be calibrated, but can be too narrow on unfamiliar data.
- Forecasting is basic, and isn't presented as a replacement for models trained for a specific metric.
These constraints point to a practical architecture rule: let the model read and identify; let deterministic code handle calculations that must be exact; and use domain-specific models when forecasting error would be expensive. In other words: a model extracts line items, regular code sums them and checks accounting rules. That's often safer than asking one system to do a long chain of dependent arithmetic.
Measure the workflow, not the demo
Cloudflare reports that a sample Clairic-to-Clef-to-LLM workflow took 19.3 seconds end to end, versus 61.7 seconds for a version using an LLM at every step. The company also reported a 49% lower cost for the cascaded workflow in that test. Those numbers are useful evidence for that example - but they're not a promise you'll see everywhere. Latency and cost will depend on model versions, input sizes, deployment choices, and the real shape of your workflow.
Before adopting this approach, compare it to your own baseline. Track at least:
- Field-level accuracy: Which fields fail, and what does it cost you when they fail?
- Abstention quality: Does null show up when information is genuinely missing?
- Calibration: Do confidence values and intervals match what you observe?
- End-to-end latency and cost: Include retries, validation, human review, and downstream calls.
- Operational impact: Does the workflow actually reduce handling time or improve service?
A fast extraction call won't automatically make a slow approval process feel fast. Measure the full system, including the work needed to catch and resolve mistakes.
Conclusion
Clairic is a useful signpost for how AI systems can be assembled: not every task needs a generative model. When the job is to turn a document into a date, an amount, a list, or a bounded estimate, a typed extraction model often fits better than asking an LLM to produce structured text and then trying to validate it after the fact.
In most cases, the strongest design is a pipeline, not one "do-everything" model. Extract facts, calculate exact values in code, make policy decisions with an appropriate decision layer, and reserve generative AI for the parts that truly need language. And keep humans in the loop whenever uncertainty or business impact calls for it.
If you're evaluating Clairic, start with one repetitive workflow and a representative test set. Compare accuracy, abstentions, confidence calibration, latency, and total cost against your current process. The real question isn't whether the model looks good in a demo. It's whether the whole system ends up more reliable and cheaper to operate.