Summary
Cloudflare has put Clairic, a non-generative "System One" extraction model, on Workers AI as a preview. You send it text, optionally some images, and a list of named, typed fields. It returns typed values with confidence information in one parallel pass, and any field can come back null when the answer isn't found. Cloudflare says Clairic is more accurate, faster and cheaper than LLMs for this kind of task but publishes no benchmarks. It also says open weights will follow.
What happened
The announcement says Clairic is served as @cf/cloudflare/clairic. A request carries unstructured text, up to four images and a field list, and each field has a name, a type and an optional instruction. The supported types are text spans, numbers, dates, lists, estimates and forecasts. Scalar outputs carry confidence information and can be null when no answer is found. According to Cloudflare, the model runs a single forward pass and generates no output tokens, so it can't produce malformed output, and the declared types and bounds limit which values can come back. Cloudflare files Clairic under "System One" models, next to its Clef decision models and TypeSafe's Jev, and contrasts it with generative LLMs. The pitch is that recurring structured-output tasks, whose answers are numbers or known field types, often go to frontier LLMs anyway, and a specialised model is a better fit for them. Workers AI documentation lists an input-token price for the model (d8). Cloudflare admits the model can make mistakes and gives no comparative accuracy or latency figures.
What the archive adds
The archive shows a category taking shape. TypeSafe also uses the "System One models" framing for Jev, a decision model that it is opening up from a waitlist while asking developers where it works and where it falls short (d1). Cloudflare's Clef post describes a similar decision-model design: Qwen post-trained for decision tasks, a prefill-only pass, and valid schema choices scored in parallel, with no autoregressive decoding. Cloudflare hasn't published Clairic's architecture. Because both posts describe a "single forward pass, no output tokens", our inference is that the two are probably related. On the extraction side, fastino's GLiNER2 line already offers a schema-driven information-extraction interface (d2), so typed, schema-first extraction is not new. A hosted, typed model with null outputs on a major inference platform is the newer part. LlamaIndex's ExtractBench Pro is a 100-document benchmark aimed at the long tail of document extraction (d3). It is the kind of hard case that Cloudflare's unbenchmarked claims will eventually have to face.
Trend signal
This is the third step in a sequence. First, teams prompted LLMs for JSON and wrote parsers and retry loops around them. Second, vendors added strict structured-output modes. Those made the shape reliable, but the values could still be wrong and the cost still tracked output tokens. Third, and happening now, come schema-bound models that never generate text: first for decisions (Jev, Clef) and now for extraction (Clairic). At each step the output contract gets narrower and the uncertainty signal becomes more explicit, until confidence scores and nulls are part of the API itself. Our read is that the hard part of document automation is no longer getting valid output. It is deciding what the system should do with a date that comes back at 0.62 confidence, and the tooling for that decision is still thin.
Why now
1) Cost and complexity. Cloudflare says recurring structured-output tasks whose answers are numbers or known types often go to frontier LLMs anyway, and its answer is an input-priced specialised model (primary; d8). 2) Shared framing. TypeSafe also uses "System One" framing for Jev (d1), so a category vocabulary for non-generative, schema-bound models already exists for Cloudflare to build on. 3) An existing stack. Cloudflare already had a non-autoregressive, schema-scoring design in Clef, with Qwen post-trained and valid choices scored in parallel, which likely made an extraction variant a short step. That last point is inference, since Clairic's internals aren't disclosed. 4) Prior work. Schema-driven extractors such as GLiNER2 (d2) and long-tail benchmarks such as ExtractBench Pro (d3) had already shown that typed extraction is a distinct problem from free-form generation.
Connections to other events
Here is how an extraction engineer's routine changes, step by step, after adopting Clairic.
- Prompt engineering becomes field declaration. A long system prompt plus a JSON schema turns into a typed field list with a short instruction per field. Ambiguity now lives in the field definitions, for example "invoice_date: the issue date, not the due date." Field definitions are easier to review and version than a prompt.
- The parse/validate/retry layer mostly disappears. With no generated tokens there is no truncated JSON and no "please return valid JSON" retry, and type checks such as "is this a number" are handled by the interface. Business-rule validation stays. Line items still have to sum to the total, dates still have to fall within the contract period, and IDs still have to match your records.
- Null needs a policy. A generative model has no built-in null signal. A typed extractor that can return null makes missing data explicit, so each field needs a rule: block the record, apply a default, or send it to a person.
- Confidence thresholds become the main control. Each field gets its own cutoff between auto-accept and human review. Each cutoff has to be set on labeled data and checked again whenever the document mix or the model version changes. That is a new, ongoing chore: tracking per-field reliability over time.
- A router appears. Fields that need reasoning across pages or arithmetic over several values may be beyond what a single-pass extractor does well. Our inference is that teams will run Clairic first and send only low-confidence or null fields to an LLM, so the LLM becomes the exception path.
- Cost accounting changes shape. Only an input price is listed (d8), so cost depends on document length plus the field definitions you send, not on how much the model writes. Field names, types and instructions are all input tokens, so a 30-field schema with detailed instructions costs more per call than a 3-field one. The evidence doesn't document how images are counted.
The net effect is that work moves rather than disappears. Time spent debugging malformed output becomes time spent calibrating thresholds and staffing a review queue.
Why it matters
For builders, the case for Clairic is a smaller pipeline, not only a cheaper one. If your structured-output code is mostly retries and type validators, a typed extractor can remove much of it, but the business-rule checks stay. Confidence scores are only useful once you have labeled data to set thresholds against. Without that data you have swapped one unverified output for another that now carries a number. For buyers of document-AI services, a cheap typed primitive probably puts pressure on the simple, high-volume tier: invoices, forms, short emails. It does little against long-tail documents of the kind ExtractBench Pro is built around (d3). For platform teams, the clear pattern to test is extractor first, with an LLM on the exception path, and with routing driven by nulls and low-confidence fields.
What happens next
- Cloudflare publishes Clairic open weights with a stated licence on Hugging Face or a similar hub. (6 months, 60%). Watch for: A Clairic model card and licence file appear and are linked from Cloudflare's blog or Workers AI docs.
- An independent public evaluation reports Clairic's per-field accuracy against at least one frontier LLM structured-output mode. (6 months, 40%). Watch for: Clairic appears as a named entry in ExtractBench Pro results or in a third-party comparison post with numbers.
- At least one other major model or cloud vendor, besides TypeSafe and Cloudflare, ships a non-generative, schema-bound extraction or decision model that returns per-field confidence. (12 months, 45%). Watch for: A launch post from a large provider describing a typed, non-autoregressive model with confidence outputs, under 'System One' or similar language.
Limits and uncertainty
There are no independent benchmarks, so Cloudflare's accuracy, speed and cost claims are unverified. We don't know how Clairic handles multi-page, table-heavy or visually complex documents. The four-image limit and the listed context window (d8) mean long PDFs have to be chunked, and chunking breaks fields whose answers depend on more than one chunk. Cloudflare hasn't said how Clairic's confidence scores are trained or whether they are calibrated. If they aren't, step 4 doesn't work. Preview pricing and terms may change before general availability, and no licence for the promised open weights has been published. The workflow above assumes teams have labeled data for threshold tuning. Many don't, and for them the benefit is smaller than this take suggests.
Skill to build now
Learn to set confidence thresholds field by field. First exercise: take 100 labeled documents and any extractor that returns confidence (the Clairic preview works). For each field, sort predictions into confidence deciles and plot accuracy per decile. Find the lowest cutoff where accuracy meets your target, and record what share of documents that cutoff auto-accepts. That share, field by field, is your realistic automation rate.
Reader takeaway
Don't migrate yet. Take your highest-volume structured-output job and pull 200 real documents. Label the 5–10 fields that matter, then run Clairic alongside your current LLM. For each field, compare accuracy, null rate, and accuracy above several confidence cutoffs. Move a field to Clairic only if some threshold auto-accepts a meaningful share of documents at an error rate you can live with. Keep the LLM as the fallback for everything else.
Open question
Do single-pass typed extractors hold up when a field depends on reasoning across pages or across several values? Or will the long tail send so many fields to the LLM fallback that the two-model pipeline costs more to run than the LLM-only setup it replaced?