Cloudflare Clairic: A Practical Guide to Zero-Output-Token Extraction Models

Title

Cloudflare Clairic: A Practical Guide to Zero-Output-Token Extraction Models

Meta Description

Cloudflare Clairic extraction models generate no output tokens and return structured fields plus probabilities. This article explains why you should read value instead of guess, how to gate fields in TypeScript, letting code do arithmetic, and practical methods for calibrating confidence.

Article Content

Cloudflare has launched an extraction model called Clairic on Workers AI. It generates no output tokens and only returns structured field answers. This design makes extraction tasks faster and cheaper, but it also introduces a new question: which field should you read? Based on official documentation and third-party analysis, this article provides a practical integration guide.

What Is Clairic: Extraction in a Single Forward Pass

According to Cloudflare's official blog, Clairic was released on October 19 with the model ID @cf/cloudflare/clairic, positioned as a "System One" extraction model. You pass in text and a set of typed field definitions, and the model returns a value for each field in a single forward pass. It does not write text or generate output tokens. This complements Clef—Cloudflare's decision model released on October 1, which returns probability distributions over fixed options (as reported by Unite.AI and eWeek).

Clairic can handle four types of tasks: extracting values already present in the input, computing values based on facts in the input, estimating values not fixed by the input, and predicting sequences. The official example demonstrates computing a due date from an invoice date plus "net 30." For pricing, it costs $0.10 per million input tokens with no output pricing; the context window is 65,536 tokens; each pass can accommodate 8,192 tokens of fields plus input, with additional fields split into parallel batches; and it supports up to 4 embedded images (PNG, JPEG, or WebP), with remote URLs not supported.

Two risk disclaimers are worth noting: the model is provided "AS IS" and "AS AVAILABLE," and Cloudflare may discontinue the service at any time without refund; the weights have not been published yet, and the official statement says they will be released "soon," so for now it can only run on Cloudflare endpoints.

Forward pass and output tokens: In the Transformer architecture, a forward pass refers to the complete process in which an input sequence is computed layer by layer from the embedding layer and attention layers to the output layer. Traditional generative LLMs need to sample one token after each forward pass, append that token back to the input, and run another forward pass until an end-of-sequence token is generated, so output length directly determines the number of inference steps and cost. Clairic's "zero output tokens" means it reuses the representation from the final forward pass and directly performs classification or regression for each field, without entering an autoregressive decoding loop. This explains why it bills only for input and is faster, and also why it is not good at multi-step arithmetic—there are no intermediate reasoning steps to unfold.

Core Pitfall: Read value, Not guess

In the official documentation example, there is an invoice with no purchase order number. The model returns a po_number answer with "value": null and "p_null": 1, but the same answer object also contains "guess": "INV-2291"—that is the invoice number. If your code reads guess, the invoice number will land in the purchase order column. This is the single most important rule to know before integration.

Each scalar answer contains multiple keys. Taking the official example's po_number as an example: type is text, p_null is 1, span is [8, 16], guess is INV-2291, confidence is 0.9995, and value is null. value is the answer, and p_null represents the probability that the input does not contain that value. guess looks like a guess the model is forced to make when choosing, and here the span is at the same position as the invoice number. Cloudflare has not explained what confidence measures when value is null, so with 0.9995 sitting next to null, there is no reason to trust guess. The official extraction model page states that a null single-value result means the model believes the input lacks sufficient information.

Therefore, every scalar field must be gated before being written to the database. Below is a TypeScript helper function with placeholder thresholds (actual thresholds should be tuned from labeled samples):

type Scalar = {
  value: unknown;
  p_null: number;
  confidence: number;
};

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 function covers text, number, and date answers, which carry p_null and confidence. Lists return values with spans and confidence scores, and estimates return median, p10, and p90 instead of p_null, so they need separate checks.

Semantics of p_null, span, and confidence: p_null is the model's probability that the field value does not exist in the input, and it is a raw score before calibration; span is the character offset range of the answer in the input text, which can be used to trace back to the original text and verify whether the extraction position is reasonable; confidence is the overall confidence of the answer object, but Cloudflare has not clearly defined it under different value states. When value is null, confidence may still be close to 1. This does not mean the guess is reliable; it more likely reflects that the model is very certain about the judgment that the field is missing. Therefore, gating logic should first check whether value is null and whether p_null is too high, then consider confidence, and all three must be calibrated on your own data before being used as threshold criteria.

Let Code Do the Arithmetic, Not the Model

The Cloudflare blog is blunt about the shortcoming: "strong at reading, but not yet good at multi-step arithmetic." Its recommendation is: "For now at least, let Clairic predict values and let code do the math." The official documentation example asks for a total field to be computed and gets 1080. For any billing-related result, you should request the component parts rather than the total directly.

Below is illustrative code that has not actually been run against the endpoint, where sendToReview represents your own workflow:

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

This way, even if a number is misread, it may show up as a low score for that field, while the arithmetic remains in testable code.

Field Definitions Are the Biggest Part of the Bill

The official example response reports its own usage: 61 state_tokens for the invoice text, 472 schema_tokens for the field definitions, totaling 655 input_tokens, with output_tokens at 0 and passes at 3. On short inputs, the cost of field names and instructions is about eight times that of the document itself.

At $0.10 per million input tokens, this 655-token call costs $0.0000655, or $65.50 per million calls. Workers AI offers 10,000 free Neurons per account per day, and the pricing page lists Clairic at 9,091 Neurons per million input tokens, so the free allowance covers roughly 1.1 million input tokens per day. Keep instructions short and batch multiple fields from the same document into one call rather than calling once per field.

Neurons and Workers AI billing: Neurons are Cloudflare Workers AI's unified metering unit. Different models are converted into different numbers of Neurons per million input/output tokens, and each account has a daily free allowance of 10,000 Neurons. Clairic is billed at 9,091 Neurons per million input tokens, meaning the free allowance corresponds to roughly 1.1 million input tokens per day. Since Clairic has no output-token billing item, cost is entirely determined by state_tokens and schema_tokens; in short-document scenarios, schema accounts for an extremely high proportion, so shortening field names and merging multiple fields from the same document into one call are the most direct ways to control cost.

Log the Scores, Then Calibrate Them

Cloudflare's headline numbers come from internal testing. In a damaged-product claims workflow, Clairic performed extraction, Clef made decisions, and GLM-5.3 generated replies, taking 19.3 seconds at $6,032 per million claims; GLM-5.3 alone completed all three steps in 61.7 seconds at $11,740. This gap is the source of Cloudflare's "49% reduction" claim. But as PPC Land points out, the comparison is Cloudflare's own test, covers only one claim type, and does not state how many runs were averaged.

The blog also writes: "Calibration is measured, not guaranteed." On your own invoices, a confidence of 0.95 may not mean 95% correct. The only way to know is to log model outputs and compare them with the results confirmed by human follow-up:

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,
}));

Correlate these logs with the corrections in your review queue. After accumulating a few hundred entries per field, you can see how much accuracy each confidence interval actually delivers and adjust the thresholds in accept() accordingly. Cloudflare's guidance points in the same direction: consider human review before irreversible operations.

Confidence calibration: Calibration refers to the consistency between the confidence scores output by a model and the actual accuracy rate. A well-calibrated model should be correct about 95% of the time among samples with confidence 0.95; however, uncalibrated scores are often overconfident, especially on out-of-distribution inputs. Common metrics include Expected Calibration Error (ECE) and reliability diagrams: bucket samples by confidence and compare the average confidence in each bucket with the measured accuracy. For Clairic, you should correlate the confidence in logs with human review results, plot reliability diagrams separately for each field, and then set the thresholds in accept() accordingly; calibration curves can differ greatly across fields, so a single global threshold cannot be shared.

Should You Move Extraction Tasks Out of the LLM?

If you are already paying an LLM to convert emails, receipts, or forms into JSON, Clairic is worth trying. It returns typed fields with character offsets and field-missing probabilities, offering more information than a bare JSON string. Cloudflare calls the endpoint "an early checkpoint, and we expect it to get better."

For now, however, it is advisable to keep the LLM path behind the same interface. The model is in preview, hosted only by Cloudflare, and the terms allow Cloudflare to withdraw it. Run both on your own labeled samples and compare field by field. The author of this article has not personally run Clairic, so the numbers in this article should be treated as Cloudflare's data.

A question worth considering: is a model that tells you how likely a field is to be missing more trustworthy than one that always returns well-formed JSON? The answer depends on whether you are willing to pay the integration cost for measurable uncertainty.

Summary: Checklist Before Integration

If you are going to try Clairic, keep the log line from the previous section. Recording each field's value, confidence, and token count is the basis for later adjusting thresholds or switching models. Specifically: always read value rather than guess; gate every scalar field; let code handle arithmetic; compress field definitions to the minimum; and log and calibrate confidence scores.

Clairic represents a "zero-output-token" extraction paradigm. Its advantages are cost and speed, and the price is new complexity in field semantics. Treating it as a testable component in your pipeline rather than a black-box answer generator is currently the safest way to integrate it.

One-line Summary

Practical guide to the Clairic zero-output-token extraction model: read value not guess, gate and calibrate.

Paragraph Summary

Cloudflare has launched the Clairic extraction model on Workers AI. It returns structured fields in a single forward pass, generates no output tokens, bills only for input tokens, and offers clear advantages in cost and speed. Based on official documentation and third-party analysis, this article provides an integration guide: in the answer object, value is the real answer, while guess is a guess the model is forced to make when choosing, and reading the wrong one can write an invoice number into the purchase order column; every scalar field must be gated with p_null and confidence before being stored; multi-step arithmetic should be handled by code rather than the model; field definitions (schema_tokens) can account for most of the bill on short inputs, so they need to be compressed and batched into calls; and confidence must be logged and calibrated on your own labeled data. Cloudflare's "49% reduction" comes from its own single-type test, and the model is still in preview, so it is advisable to keep the LLM path running in parallel for comparison.