- Book: LLM Observability Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
The invoice in the example on Cloudflare's Clairic docs page has no purchase order number. The model gets that right: the po_number answer comes back with "value": null and "p_null": 1. The same answer object also carries "guess": "INV-2291", which is the invoice number. If your code reads guess, the invoice number lands in your PO column.
That one line is the most useful thing to know before you wire up the model Cloudflare released on October 19.
What Cloudflare shipped on October 19
Clairic is a preview model on Workers AI, ID @cf/cloudflare/clairic, announced in a Cloudflare blog post on October 19, 2026. Cloudflare calls it a "System One" extraction model: you send text and a map of typed fields, and it returns a value per field in a single forward pass. It writes no text and produces no output tokens (Cloudflare blog).
It does four jobs, per Cloudflare's extraction-models page: extract a value that is in the input, compute one from facts in the input, estimate one the input doesn't fix, and forecast a series. The model page example computes a due date from an issue date plus "net 30". Clairic sits next to Clef, Cloudflare's decision model, which returns probabilities over a fixed list of options (Cloudflare blog). Clef shipped on October 1, per Unite.AI and eWeek.
The numbers from the model page:
- $0.10 per million input tokens, and no output price listed
- a 65,536-token context window
- each pass holds 8,192 tokens of fields plus input; more fields are split across parallel passes
- up to 4 embedded images (PNG, JPEG or WebP), no remote URLs
Two caveats sit on the model page and in Cloudflare's announcement. The model is provided "AS IS" and "AS AVAILABLE", and Cloudflare may stop offering it without a refund (model page). The weights are not public yet; Cloudflare says it intends to release them "soon" (Cloudflare blog). Today it runs only on Cloudflare's endpoint.
Read value, not guess
Every scalar answer has more keys than you need. Here is the po_number answer from Cloudflare's example response, reformatted to fit (model page):
{
"type": "text",
"p_null": 1,
"span": [8, 16],
"guess": "INV-2291",
"confidence": 0.9995,
"value": null
}
value is the answer. p_null is the model's probability that the input doesn't contain one. guess looks like what the model would have said if forced to pick, and span here is the same [8, 16] as the invoice number. Cloudflare doesn't document what confidence measures when value is null, so a 0.9995 next to a null value is no reason to trust guess. Cloudflare's extraction-models page says a null single-value result means the model considers the input insufficient.
So gate every scalar field before it touches your data. A small helper in TypeScript:
type Scalar = {
value: unknown;
p_null: number;
confidence: number;
};
// Placeholder thresholds. Set yours from a labelled sample.
function accept(a: Scalar, minConf = 0.95, maxNull = 0.05) {
if (a.value === null) return { ok: false, why: "absent" };
if (a.p_null > maxNull) return { ok: false, why: "unsure" };
if (a.confidence < minConf) return { ok: false, why: "low" };
return { ok: true, value: a.value };
}
This covers text, number and date answers, which carry p_null and confidence. Lists return values with spans and a confidence score, and estimates return median, p10 and p90 instead of p_null (model page), so they need their own checks.
Let your code do the arithmetic
Cloudflare's blog is direct about the weak spot: "Reading is strong, but multi-step arithmetic isn't yet." Its advice: "At least for now, have Clairic predict the value and let code do the math."
The docs example asks for total as a computed field and gets 1080 back (model page). For anything you bill on, ask for the parts instead. This is a sketch I haven't run against the endpoint; sendToReview stands in for your own handler:
const res = await env.AI.run("@cf/cloudflare/clairic", {
model: "clairic",
state: "Invoice 1042. 4 pallets at $250.00 each, "
+ "shipping $80.00, net 30.",
fields: {
quantity: { type: "number" },
unit_price: { type: "number", decimals: 2, unit: "USD" },
shipping: { type: "number", decimals: 2, unit: "USD" },
},
});
const a = res.answers;
const parts = [a.quantity, a.unit_price, a.shipping]
.map((x) => accept(x));
if (parts.some((r) => !r.ok)) return sendToReview(res);
const [q, p, s] = parts.map((r) => r.value as number);
const total = q * p + s; // 4 * 250 + 80 = 1080
A misread number may show up as a low score on that field, and the arithmetic stays in code you can test.
Your schema is most of the bill
The example response reports its own usage: 61 state_tokens for the invoice, 472 schema_tokens for the field definitions, 655 input_tokens in total, 0 output_tokens, and 3 passes (model page). On a short input, your field names and instructions cost about eight times what the document does.
At $0.10 per million input tokens, that 655-token call costs $0.0000655, or $65.50 per million calls. Workers AI gives every account 10,000 Neurons a day, and the pricing page lists Clairic at 9,091 Neurons per million input tokens, so the free allocation covers about 1.1 million input tokens a day. Keep instructions short, and batch fields for the same document into one call rather than one field per call.
Log the scores, then check them
Cloudflare's headline number comes from its own test. In a damaged-product claims pipeline, Clairic for extraction, Clef for the decision and GLM-5.3 for the reply took 19.3 seconds and cost $6,032 per million claims. GLM-5.3 doing all three steps took 61.7 seconds and cost $11,740. That gap is where Cloudflare's "49% less" comes from (Cloudflare blog). PPC Land points out that the comparison is Cloudflare's own, covers one claim type and doesn't state how many runs it averaged.
The blog also says "Calibration is measured, not guaranteed" (Cloudflare blog). A 0.95 confidence on your invoices may not mean 95% correct. The only way to know is to record what the model said and compare it with what a person later confirmed:
console.log(JSON.stringify({
field: "unit_price",
value: a.unit_price.value,
p_null: a.unit_price.p_null,
confidence: a.unit_price.confidence,
input_tokens: res.usage.input_tokens,
}));
Join those lines with the corrected values from your review queue. Once you have a few hundred per field, you can see what accuracy each confidence band really buys and move the thresholds in accept() to match. Cloudflare's own guidance points the same way: consider human review before irreversible actions (extraction-models page).
Should you move extraction off your LLM?
If you already pay an LLM to turn emails, receipts or forms into JSON, Clairic is worth a test. It returns typed fields with character offsets and a probability that each field is missing, which is more than a bare JSON string tells you. Cloudflare calls the endpoint "an early checkpoint and we expect it to get better" (Cloudflare blog).
Keep the LLM path behind the same interface for now. The model is a preview, it is hosted only by Cloudflare, and its terms let Cloudflare withdraw it. Run both on a labelled sample of your own documents and compare per field. I haven't run Clairic myself, so treat the numbers here as Cloudflare's.
Would you trust a model that tells you how likely a field is to be missing more than one that always returns well-formed JSON? Tell me in the comments.
If this was useful
If you try Clairic, keep the logging line from the last section. A record of each field's value, confidence and token count is what lets you tune the thresholds later, or swap the model out. The LLM Observability Pocket Guide covers how to pick the tracing and eval tools that keep those records for you. I also build Hermes IDE, a free IDE for running Claude Code, Codex and other coding agents side by side.
Top comments (0)