Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
From Generating Text to Returning Fields
Cloudflare released Clairic as a preview model on Workers AI on October 19, 2026. It targets tasks that extract amounts, dates, IDs, and similar information from unstructured text or images. Developers have often handed this work to a general-purpose large language model, asking it to read an invoice or email and generate JSON that software then parses and checks. Clairic takes a different approach: the caller declares the fields and types it needs, and the model returns the corresponding values rather than a passage of free-form text.
The important change is not the goal of structured output itself, but the interface between the model and the application. A conventional generation flow combines natural-language generation, format following, and fact extraction in one answer. When the format breaks, the application must also deal with parsing failures. Clairic tries to narrow the deliverable to numbers, dates, text spans, or null values so software can consume it more directly. But a correctly typed value only has the expected shape. It does not prove that the amount or date is factually right.
Cloudflare describes these models as part of a three-layer division of labor. Extraction models turn raw input into typed values, decision models choose among specified options, and general-purpose LLMs turn decisions into words. Clairic handles questions whose answers cannot be listed in advance, such as the total on an invoice. That distinguishes it from decision models such as Cloudflare's Clef and TypeSafe's Jev, which primarily score a set of predefined choices. This separatio
The Schema Is Not a Free Control Layer
A request consists of the input and a set of named fields. Each field can include a type, a plain-language instruction, and optional constraints. Supported types include text, numbers, dates, times, durations, lists, estimates, and forecasts. Text results can identify their positions in the source, while scalar results carry confidence and p_null, the model's estimate that a value is absent. Estimates and forecasts can return a median and an 80% interval from p10 to p90, and forecasts can cover up to 64 steps.
This interface does more than specify an output format. It also describes the task. Clairic can calculate a total from an amount and tax in an email or work out elapsed days from dates, so it does not only copy text into fields. In one example from Cloudflare, the email did not state the final total, yet the model calculated $701.10 and worked out that 11 days had passed since delivery. For a small amount of local computation, this may avoid an additional model call. Cloudflare also says that multi-step arithmetic and aggregation across multiple rows are not reliable.
“One forward pass” should not be read to mean that every request runs only once no matter how many fields it contains. If the fields do not fit with the input in a single computation, the system splits the task into parallel passes, each of which still sees the full input. An official example involving a 61-token invoice was split into three passes and billed for 655 input tokens, of which 472 came from the field definitions. This reveals a cost that is easy to miss: a short document does not necessari
The Claims Pipeline Shows Both the Gain and the Bottleneck
Cloudflare's main performance comparison comes from a damaged-product claims workflow. In the combined setup, Clairic extracts facts, Clef chooses between a refund and a repair, and GLM-5.3 writes the reply. The comparison setup uses GLM-5.3 for all three stages. Cloudflare reports that the combined workflow took 19.3 seconds, compared with 61.7 seconds for the all-GLM workflow. Estimated cost per million claims fell from $11,740 to $6,032, a reduction of about 49%.
The stage-level figures show where the gain came from. Extraction fell from 16.1 seconds with GLM-5.3 to 0.46 seconds with Clairic. The decision stage fell from 21.9 seconds to 0.22 seconds with Clef. Yet writing the customer reply still took 18.6 seconds in the 19.3-second combined workflow, accounting for nearly all of its runtime. Specialized models sped up fact collection and decision-making, but they did not remove the final step that needs natural-language expression. Teams optimizing end-to-end experience still need to examine that remaining generation stage rather than focusing only on the extraction model's latency.
The case also has limits around quality and reproducibility. Cloudflare says both workflows extracted the facts and made the right decision. Clairic returned the same repair estimate across runs, while GLM-5.3 returned $250, $250, and $220 in three runs. The company also says Gemma 4 and Qwen failed in the all-LLM setup, but the materials do not provide a complete test protocol or a standardized accuracy benchmark. The figures of 19.3 seconds, 61.7 seconds, and the cost difference should t
Confidence and Nulls Are Signals, Not Guarantees
Clairic includes missing values in its output interface, which matters for business workflows. When a field is absent, a general-purpose model may produce a plausible-sounding completion. Clairic can return null and include p_null and confidence. In one example from Cloudflare, an email lacked a tracking number and the model returned null instead of inventing one. In another, it read seven present values from a skewed receipt image and marked the missing discount as null. Its lowest confidence score was 0.776 for the order number.
These signals can help a system decide which fields to process automatically and which to send for review, but they are not proof of correctness. Confidence reflects a model signal about its answer, while p_null expresses its judgment about whether a value is missing. Both can be miscalibrated on unfamiliar data. Cloudflare's documentation specifically warns that prediction intervals may be too narrow on unfamiliar inputs and that correctly formatted output can still be wrong. For refund amounts, identity details, or compliance records, business rules and source checks should remain the final safeguards.
The forecasting example further shows that returning an interval is not the same as being calibrated. Cloudflare says Clairic forecast TSA checkpoint counts for 21 consecutive days, with an average error of 3.3%; actual counts fell inside the model's 80% interval on 17 days. Three of the four misses occurred over Columbus Day weekend. That context suggests holidays may create unusual variation, but a short sample cannot establish that the model
Validate It on Narrow Tasks Before Expanding Its Role
Deployment constraints make Clairic look more like a cloud component to integrate than a model a team can host itself. It is available as a preview on Cloudflare-hosted GPUs through Workers AI, under the model identifier `@cf/cloudflare/clairic`. It has a 65,536-token context window and supports up to four images per request. Cloudflare plans to release the weights but has not given a date, so there is currently no local deployment option. For teams that must keep data in their own environment or control model versions, this is an architectural constraint, not a minor implementation detail.
The current price is $0.10 per million input tokens. Because the model does not generate output tokens, Cloudflare says there is no output-token charge. That pricing can look attractive for extraction tasks with short outputs and well-defined fields, but field definitions count toward input and split computations may read the full input more than once. Cost estimates should therefore use real document lengths, field counts, and observed splitting behavior rather than the list price or the fact that output tokens are not billed. If a schema is longer than the source text, a low input rate does not necessarily produce a low end-to-end cost.
Technical leaders can begin with narrow fields that existing rules can check, such as invoice dates, order IDs, or explicit amounts, then use internal samples to examine missing values, confidence signals, and error patterns. The preview alone is not enough to establish suitability for long chains of calculations, cross-row aggregation, or long-range