On October 19, 2026, Cloudflare introduced Clairic for extracting, computing, estimating and forecasting values from unstructured input. The preview runs on Workers AI as @cf/cloudflare/clairic. The company describes a single forward pass with no billed output tokens. Open weights are a future intention. The initial checkpoint has limitations in multi-step arithmetic and forecasting; company comparisons are not independent SIExpo tests.
From a document to a field
The practical question is how an application can use what was read without depending on an open-ended written answer. Our example is a vehicle-service request: the registration identifier, requested appointment date and problem description belong in separate fields. An application needs to distinguish an absent date from a plausible-looking date. This is a proposed workflow, rather than a Clairic deployment we have tested.
The documentation separates extraction of existing information from estimation of an unknown value. Extraction can return null; estimates and forecasts still return predictions when evidence is sparse. The model card allows up to four embedded images, subject to size limits; remote image URLs are not accepted. These are interface conditions, not accuracy guarantees.
For our hypothetical service application, that suggests storing what the customer actually wrote separately from what the algorithm predicts. An estimated completion date should not silently replace a deadline promised by a member of staff. The same value has a different operational meaning depending on its origin, even when both are represented as a date. Keeping that distinction visible is an application-design recommendation.
What an evaluation should measure
We propose an acceptance set containing realistic documents that the organization is permitted to process: clear and blurred images, corrected amounts, missing fields and mixed formats. An assessment should count wrong values as well as omissions. Cases escalated for human review should be reported separately, so that low automation coverage cannot be mistaken for high accuracy.
For each stored value, retaining its source document and surrounding context would make a correction easier to inspect. A staff member could see why a particular number was selected and change that field, without treating the entire request as an unexplained failure. That is our proposed operational benefit; it is not a measured result for this model.
The important cost is the cost of a correctly completed document, including time spent fixing errors. A lower inference bill can be useful, but it should not conceal additional review work or a missed field that changes the resulting order. A fair comparison would keep the document set and acceptance criteria unchanged between implementations.
Clairic is interesting as a more specialized component in this kind of process. Structured output makes integration easier to reason about. Deciding whether it is suitable still depends on measured document accuracy, review time and the consequences of a mistake in the application that consumes the result.
Editorial verification: 2026-10-20T06:10:23.480994+00:00 (UTC). Cover: conceptual AI illustration, not a documentary photograph.
