Cloudflare's Clairic returns typed values in one pass. Its own benchmarks are the first test, not the verdict

What a Clairic request asks for

In Cloudflare's 19 October technical introduction, a request contains a state, such as an email or document, and a map of named fields. Types include text, number, date, time, datetime, duration, list, estimate and forecast. A text result can point back to its source span by character offset. A scalar can carry confidence and p_null, the model's estimate that the value is absent. Estimates and forecasts can include a median and an 80% interval bounded by caller-specified minimum, maximum and grid. A typed answer can still be wrong; correct format is not the same as a correct fact.

This is a different division of work from asking a chatbot to read a document, infer a policy decision and write a customer reply in one generation. Cloudflare's example separates extract values with Clairic → decide with Clef → write the reply with an LLM. That decomposition may make each step easier to test and audit. It also creates integration duties: applications must check source spans, confidence thresholds, policy logic and the final response, and must not pass an estimated value to a consequential decision as though it were observed fact.

output types are separated by evidence status. The comparison deliberately does not put an estimate beside an extracted fact as though both are observed.

Extracted span

• What it means: Text located in the supplied input.
• Example validation: Check the offsets and whether the span is the intended field.

Computed value

• What it means: A number or date derived from the input.
• Example validation: Recompute deterministically where possible.

Estimate

• What it means: A value inferred from evidence in the input.
• Example validation: Check bounds, calibration and whether relevant comparables exist.

Forecast

• What it means: A future value inferred from a series.
• Example validation: Compare against a suitable baseline over the same horizon.

What the published API example reveals

The Workers AI model documentation includes a worked invoice string: INV-2291, issued 2 September 2026 on net-30 terms, four pallets at $250 each and $80 shipping. The request asks Clairic for an invoice number, due date, total, contacts, purchase-order number and expected days until payment. Its example response returns 2 October as the due date and $1,080 as the total. Those are values a programmer can independently check: 2 September plus 30 days, and 4 × 250 + 80 = 1,080. The invoice number is tied to character offsets [8, 16], so a consumer can test whether the cited span actually matches the source text.

The absent purchase-order field is more revealing. The example response sets value to null and p_null to 1, while also exposing a high-confidence guess of the invoice number. If an integration reads guess instead of the null value, it could manufacture a PO number from the wrong field despite the model's explicit absence signal. The distinction between the returned value, a candidate guess, and confidence is operationally important. A schema can carry evidence; downstream code can still misuse it.

The estimate field is different again. The example asks for days until payment on a 0-to-120 grid. Cloudflare's response gives median 30 and an 80% interval from 21 to 38 days. No payment date appears in the invoice. That range is a prediction, not an extracted promise by the customer. For a credit decision, an operator would need calibration on comparable invoices, a baseline forecast and a policy for acting on uncertainty rather than accepting the median as fact.

The current model page lists a 65,536-token context window, input pricing of $0.10 per million input tokens, and a preview label. It allows up to four embedded PNG, JPEG or WebP images, with per-image and total size limits; remote image URLs are not accepted. The page says fields that do not fit next to the state in one 8,192-token pass are split across parallel passes and merged. A large schema therefore does not guarantee literally one physical pass, even though each field prediction uses the one-pass model approach. Those published limits and prices can change during preview and should be rechecked before deployment.

The numbers Cloudflare chose to show

Cloudflare reports a customer-support workflow using Clairic, Clef and GLM-5.3 against a version using GLM-5.3 for all three stages. Its measured end-to-end latency is 19.3 seconds versus 61.7 seconds, and its estimated cost is $6,032 versus $11,740 per million claims. That is about 3.2 times faster and 49% cheaper in Cloudflare's example, not a general claim for every workload. The same blog says both versions got the facts and decision right in its repeated demonstration, which is too small and selected a setting to infer a broad accuracy lead.

The workflow breakdown sharpens that comparison. Cloudflare lists Clairic extraction at 0.46 seconds and Clef decision at 0.22 seconds in the cascade, versus 16.1 and 21.9 seconds for GLM-5.3 in those two stages. Both paths still use GLM-5.3 for the final reply, at 18.6 and 16.4 seconds respectively. The 42.4-second end-to-end saving mainly comes from replacing the first two model calls in this chosen flow, not from Clairic writing the customer response faster. The stated per-million-claim costs are estimated token costs within that example. They exclude engineering, data handling, human correction and any other operating expense.

For forecasting, Cloudflare says it supplied TSA daily checkpoint counts and asked for the next day across 21 days. It reports 3.3% average error and 17 of 21 outcomes inside its stated 80% prediction interval. Seventeen out of 21 is about 81%, close to 80%, but the series is short and seasonal effects matter. Cloudflare says three of the four misses were around Columbus Day weekend, an event the series did not explicitly encode. This is a useful demonstration of limits as well as capability. It does not establish superiority to a purpose-built time-series model, because the blog does not present a like-for-like independent baseline for that claim.

A fair test before a production decision

A useful evaluation would compare systems on exactly the same invoice or support records, field schema, null frequency, document quality and hardware/network conditions. Split cases by input type: clean text, OCR from an image, missing fields, conflicting dates, long tables and malformed entries. Score exact extraction separately from derived arithmetic, estimation and forecasting. For text spans, verify that offsets point to the claimed evidence. For a null answer, measure both false fills and missed values. For forecasts, compare interval coverage and error against a simple seasonal or persistence baseline at the same horizon, rather than only quoting average error.

The decision pipeline also needs an explicit hand-off contract. Treat extracted strings as untrusted input, validate dates and currency units, recompute totals deterministically, and send only the verified fields into policy code such as Clef or a conventional rules engine. If a returned p_null is high or an estimate interval is wide, the application should abstain or route the case to a person. Measure how often that happens and include it in the total cost and latency calculation. Otherwise a fast model can simply move work into a slower exception queue.

Where the preview itself says to be cautious

Cloudflare says one- and two-step calculations seem reliable, while longer chains and aggregation across many table rows remain difficult for a one-pass model. It advises letting code do the maths. Estimates need relevant evidence in the input; intervals may be too narrow on unfamiliar data. Cloudflare says the current checkpoint is early, forecasting is basic, and open weights are planned rather than released. These limitations belong near the headline claim of faster, cheaper answers, not buried after it.

An evaluator should collect a representative sample of invoices, support messages or incident records and define the exact field schema, null cases, cost and latency target before comparison. Measure per-field error, abstention, calibration of the 80% intervals, failure on poor-quality images, and the cost of human review. Compare against a deterministic parser where one exists and a general LLM on the same input and output requirements. For financial totals or safety-critical decisions, independently recompute arithmetic and require a human gate where the error cost is material.

The story to revisit is whether the open weights arrive, whether external tests reproduce these results and whether the preview improves its stated multi-step arithmetic limits.

Sources checked 20 October 2026: Cloudflare's Clairic announcement; Cloudflare's model documentation.