{"id":100865,"date":"2026-10-20T05:56:26","date_gmt":"2026-10-20T09:56:26","guid":{"rendered":"https:\/\/overcentral.com\/en\/?p=100865"},"modified":"2026-10-20T05:56:26","modified_gmt":"2026-10-20T09:56:26","slug":"clairic-system-one-extraction-ai-model-100865","status":"publish","type":"post","link":"https:\/\/overcentral.com\/en\/clairic-system-one-extraction-ai-model-100865\/","title":{"rendered":"Clairic Brings System One Extraction to Cloudflare Workers AI"},"content":{"rendered":"<p>Cloudflare has opened a preview of Clairic, a System One extraction model now available on <a href=\"https:\/\/developers.cloudflare.com\/workers-ai\/\" target=\"_blank\" rel=\"noopener noreferrer\" data-iacss-external=\"1\">Workers AI<\/a>, and it represents a deliberate departure from how developers have been using large language models for structured data tasks. Instead of generating text that happens to contain a value, Clairic reads the input \u2014 text, images, or both \u2014 and returns typed values directly: numbers, dates, durations, lists, estimates, and forecasts. The model answers every requested field in a single forward pass, with no reasoning loop and no output tokens. That architectural choice yields the headline result: an extraction step that took roughly 0.46 seconds in Cloudflare\u2019s own claims-pipeline test, compared with 16.1 seconds when the same step was handled by the GLM-5.3 LLM.<\/p>\n<h2>What Is Clairic, and Why Does \u201cSystem One\u201d Matter?<\/h2>\n<p>Clairic builds on the System One concept first introduced by TypeSafe\u2019s Jev model. The naming borrows from Daniel Kahneman\u2019s influential framework of human cognition: System One is the fast, intuitive, pattern-matching mode of thought, while System Two is slow, deliberate reasoning. LLMs are fundamentally System Two devices \u2014 they generate tokens step by step, effectively \u201cthinking\u201d in sequence. Clairic is designed to behave like System One: it processes the input and produces answers in one shot, without generating intermediate tokens or explaining its work.<\/p>\n<p>This distinction is not academic. Generation is the dominant cost in LLM inference, both in latency and in compute. A typical extraction task performed by models like GLM or GPT involves requesting a JSON object, waiting for the model to emit it token by token, and then hoping the output is both well-formed and semantically correct. Clairic skips that entire process. For a predefined schema of typed fields, it runs the input through the network once and emits a structured response holding all the answers.<\/p>\n<p>Cloudflare positions Clairic within a three-part stack it calls the future of applied AI:<\/p>\n<ul>\n<li><strong>Extraction models<\/strong> (such as Clairic) transform raw, unstructured input into typed, structured values.<\/li>\n<li><strong>Decision models<\/strong> (such as Cloudflare\u2019s own Clef) evaluate the extracted values and select an option from a predefined set.<\/li>\n<li><strong>Generative LLMs<\/strong> take the decisions and produce natural-language output, such as a <a href=\"https:\/\/overcentral.com\/en\/ai-support-agent-skills-96628\/\" title=\"The One Mistake Ruining Your AI Customer Support Agent\" data-iacss-internal=\"1\">customer support<\/a> reply or a summary.<\/li>\n<\/ul>\n<p>The logic here is that each stage of an application pipeline should use the smallest, fastest, most deterministic model that can do the job. A generative LLM is overkill for reading an invoice total; a decision model cannot find a date that isn\u2019t on any list; and an extraction model cannot, on its own, choose between \u201crefund\u201d and \u201crepair.\u201d Together, the three cover a full automation workflow with each model doing what it does best.<\/p>\n<h2>How Clairic Handles a Request: Fields, Types, and Parallel Passes<\/h2>\n<p>To understand Clairic\u2019s behavior, it helps to look at the anatomy of a request. A Clairic request consists of a <strong>state<\/strong> \u2014 the raw text plus up to four images \u2014 and a <strong>map of fields<\/strong>. Each field is explicitly typed and named, and can carry plain-language instructions added by the developer.<\/p>\n<p>The supported types are worth listing in full, because the set is narrower and more purposeful than a general-purpose LLM\u2019s output space:<\/p>\n<ul>\n<li><strong>text<\/strong> \u2014 an exact span of the input, with character offsets<\/li>\n<li><strong>number<\/strong> \u2014 a numeric value, honoring the decimals and unit specified by the developer<\/li>\n<li><strong>date<\/strong>, <strong>time<\/strong>, and <strong>datetime<\/strong> \u2014 real calendar dates and times of day<\/li>\n<li><strong>duration<\/strong> \u2014 a span of time in the requested unit<\/li>\n<li><strong>list<\/strong> \u2014 every matching item from the input, in input order<\/li>\n<li><strong>estimate<\/strong> \u2014 a value sampled from a distribution bounded by developer-specified min, max, and step grid, on either a linear or log scale<\/li>\n<li><strong>forecast<\/strong> \u2014 a sequence of estimates for a time series, up to 64 steps ahead<\/li>\n<\/ul>\n<p>Every scalar answer that Clairic returns includes two metadata values: <strong>p_null<\/strong>, which is the model\u2019s estimated probability that the answer is genuinely absent from the input, and a <strong>confidence<\/strong> score. Text answers additionally return their exact span with character offsets \u2014 a particularly important feature for developers who need to verify or highlight the source of an extracted value. Estimates and forecasts return a median plus an 80% interval spanning p10 and p90, giving downstream systems both a point estimate and a measurement of the model\u2019s own uncertainty.<\/p>\n<p>Cloudflare claims there is no hard limit on the number of fields a request can contain. If the schema grows too large to fit alongside the input in the model\u2019s 8,192-token context window, Clairic splits the fields into parallel passes. Crucially, each pass sees the entire input. In the documentation\u2019s example, a 61-token invoice required 3 passes because the schema was broader than the document itself; the request billed 655 input tokens, of which 472 were schema tokens. This is a subtle but practical cost consideration: wide schemas with many fields and verbose instructions can end up costing more than the document those fields are trying to parse.<\/p>\n<h2>The Architecture: One Pass, No Tokens, No Reasoning Loop<\/h2>\n<p>The core architectural claim \u2014 and the key to Clairic\u2019s performance \u2014 is that the model produces all answers concurrently within a single forward pass. There is no autoregressive generation, no sampling of output tokens, and therefore no quadratic scaling of latency with output length. The model is structurally incapable of \u201cchanging its mind\u201d or engaging in intermediate deliberation; it must commit to a complete answer set each time the network is run.<\/p>\n<p>This is more consequential than it may initially appear. In LLM-based extraction, the model\u2019s reasoning tokens \u2014 phrases like \u201cTo extract the total, I first\u2026\u201d or \u201cLooking at line 4\u2026\u201d \u2014 are not the answer; they are overhead that costs time and money on every request. The more complex the prompt, the more the model generates before producing the payload. For a high-volume service extracting a handful of values from every incoming message or document, that overhead is the entire cost of the operation. Removing it changes <a href=\"https:\/\/overcentral.com\/en\/emdas-serverless-pricing-98017\/\" title=\"The Economics of EmDash: How Serverless Pricing Works for a CMS\" data-iacss-internal=\"1\">the economics of<\/a> the task.<\/p>\n<p>The design also addresses the distinct weakness of LLMs when a value is <em>not<\/em> present in the input. Generative models are strongly biased toward producing plausible-sounding numbers, even when the source material does not support them \u2014 a phenomenon often described as hallucination. Because Clairic\u2019s output includes p_null, the model can explicitly acknowledge that a requested value is absent from its input. In Cloudflare\u2019s support-email example, a missing tracking number returned <code>null<\/code>codecodecodecode with p_null of 1.0 rather than an invented string. This is not a minor detail: a system that can distinguish \u201cthe field is empty\u201d from \u201cthe field is unknown\u201d is far safer to automate than one that fills every gap with a confident lie.<\/p>\n<h2>Cloudflare\u2019s Testing: Extraction on Real Documents and Images<\/h2>\n<p>Cloudflare\u2019s announcement does not present a standard public benchmark. There is no MMLU-style score, no leaderboard comparison, no third-party accuracy assessment. What the company has provided \u2014 for now \u2014 is a set of illustrative tests on realistic workloads. These are informative, but they are self-reported and should be read as such.<\/p>\n<p>In the support-email scenario, the model was asked to extract six distinct facts: an order ID, a delivery date, the amount paid, the days since delivery, a list of damage descriptions, and a tracking number. The email itself read: \u201cOrder A-88412 arrived on Sept 28, 2026 with a cracked screen and a dented corner. I paid $649.00 plus $52.10 tax. It\u2019s now Oct 9, 2026 and I\u2019d like this fixed or refunded.\u201d The model correctly returned the order ID as \u201cA-88412\u201d with exact character offsets, the delivery date as 2026-09-28, the damage list as the two items <em>cracked screen<\/em> and <em>dented corner<\/em> \u2014 and, most impressively, computed the amount paid as $701.10 by adding the price and tax, and computed 11 days since the delivery date. Neither $701.10 nor 11 appears anywhere in the email; they are derived values. The missing tracking number returned null with p_null of 1.0.<\/p>\n<p>The image test is equally notable. Given a skewed photograph of a receipt, Clairic extracted all seven present values correctly and returned null for an absent discount. The lowest confidence across all answers was 0.776, assigned to the order number \u2014 an intuitive result, since reading a long alphanumeric sequence from a skewed photo is harder than reading a price or a date.<\/p>\n<h2>Forecasting and Estimates: A Measurable Performance Claim<\/h2>\n<p>In addition to extraction, Cloudflare tested Clairic\u2019s forecasting capability on daily TSA checkpoint passenger counts, a publicly available dataset. The model was asked to produce next-day forecasts for 21 consecutive days. Its average error was 3.3%. Of the 21 actual counts, 17 fell inside the model\u2019s stated 80% interval. Of the four misses, three occurred on the Columbus Day weekend \u2014 a recognizable limitation: the model appears to be calibrated on recent patterns but cannot anticipate unmapped calendar events.<\/p>\n<p>On one forecast day (the illustrative example for October 14, 2026), Clairic produced a median of 2,419,283 passengers with an 80% interval from p10 of 2,270,774 to p90 of 2,556,769. The actual TSA count for that day was 2,419,474 \u2014 a near-perfect hit that underscores the value of the interval-based output format. The forecasting mechanism itself is modest: next-step forecasts follow recent patterns, but multi-step forecasts decay toward the average, and entirely novel events (a holiday, a disruption, a spike in travel) will appear as outliers.<\/p>\n<h2>The Claims Pipeline: Clairic vs. a Generalist LLM at the Same Job<\/h2>\n<p>The most thorough test in the announcement is a full claims-processing pipeline designed to simulate a real automation workload. The workflow has three stages: extract facts from a damaged-product claim (Clairic), decide whether to refund or repair based on those facts (Clef), and write the customer-facing reply (GLM-5.3). Cloudflare compared this assembly against a single GLM-5.3 model handling all three stages alone.<\/p>\n<p>The results are stark in terms of latency:<\/p>\n<ul>\n<li>The full pipeline \u2014 extraction, decision, and written reply \u2014 took 19.3 seconds using the three-stage stack versus 61.7 seconds for GLM-5.3 doing every step. The three-model architecture was about 3.2\u00d7 faster end to end.<\/li>\n<li>The extraction step alone took 0.46 seconds using Clairic versus 16.1 seconds using GLM-5.3 \u2014 a 35\u00d7 difference.<\/li>\n<li>The decision step took 0.22 seconds using Clef versus 21.9 seconds using GLM-5.3.<\/li>\n<li>The reply-writing step took 18.6 seconds in the three-stage pipeline versus 16.4 seconds when GLM-5.3 wrote directly. That difference reflects the extra context the generative model received from the two preceding stages (and the cost of injecting a larger prompt before generation begins).<\/li>\n<\/ul>\n<p>Cost followed a similar pattern. The three-stage pipeline totaled $6,032 per million claims processed, including input and output tokens across all three models. The single-LLM approach ran $11,740 per million claims \u2014 a 49% reduction in compute cost per unit of work. Both versions ultimately produced the same verdict on the same facts.<\/p>\n<p>The largest cost driver for the LLM-only approach was output tokens: $5,848 versus $11,194. Reasoning is expensive, and a model that thinks out loud before answering pays for every step of its thinking. Clairic\u2019s output token count for the extraction stage is exactly zero; the other two models in the pipeline are still generative, but they have far less to generate because the input has already been reduced to structured facts.<\/p>\n<h2>Where Clairic Stumbles: Honest Limitations<\/h2>\n<p>Cloudflare\u2019s announcement is notably candid about the model\u2019s boundaries, and that restraint is important. The current preview has real weaknesses \u2014 known, documented, and specific.<\/p>\n<p><strong>Multi-step arithmetic is unreliable.<\/strong> One- and two-step calculations \u2014 adding a price and a tax, subtracting two dates, converting a number across units \u2014 are dependable. Long, dependent chains of arithmetic, aggregation across many table rows, or multi-stage reasoning are not. Cloudflare\u2019s guidance is sensible: use Clairic to extract the raw numbers, then perform any complicated arithmetic in code. A model is at its best when it is reading values, not doing the work of a calculator.<\/p>\n<p><strong>Estimates require evidence.<\/strong> Clairic produces the most useful intervals when it has comparables, historical data, or descriptive text to work from. Absent such evidence, the 80% interval will be wide \u2014 in some cases too wide to support a decision. The model\u2019s calibration is trained, not promised; intervals can run narrow on data outside its training distribution.<\/p>\n<p><strong>Forecasting is a pattern follower.<\/strong> The TSA test shows the model tracking recent passenger-count trends well, but it failed four of 21 days precisely because it could not foresee an upcoming holiday. Forecasts several steps out flatten toward the series average and lose nuance. This behavior is reasonable \u2014 it is, after all, a single-pass model \u2014 but anyone planning to automate travel, inventory, or staffing decisions should not expect Clairic to predict the unexpected.<\/p>\n<p><strong>Well-formed is not the same as correct.<\/strong> Every answer Clairic returns is either a valid value of its declared type or null. Format validity gives structural safety, not semantic truth. The confidence score, p_null, and the intervals are the model\u2019s self-assessment of its own certainty; they are the developer\u2019s tool for deciding what to automate and what to route to a human. Using them is not optional polish \u2014 it is the operating protocol for safely delegating extraction to a machine.<\/p>\n<h2>What Clairic Signals for the Industry<\/h2>\n<p>Clairic is not an isolated product announcement; it is part of a broader pattern in applied AI model design. The industry is moving from single generalist models toward specialized model families where architecture is shaped by the shape of the task itself. Extraction has one best shape, decision has another, generation has a third \u2014 and forcing all three into a single autoregressive network is a compromise of all three.<\/p>\n<p>The economics reinforce the shift. In the decade since scaling laws became the industry\u2019s de facto roadmap, the cost model for compute has not changed: tokens are money. Every token \u2014 input, reasoning, output \u2014 is paid for in latency and in GPU-seconds. Clairic\u2019s 0.46-second extraction versus GLM\u2019s 16.1 seconds is not a marginal improvement; it is the difference between a batch job and a real-time interaction. For application builders, a 49% reduction in cost per million claims is the difference between a feature that is profitable and one that is merely interesting.<\/p>\n<p>The model\u2019s preview size is 65,536 tokens of context for up to four images per request, hosted exclusively on Cloudflare workers via the <code>@cf\/cloudflare\/clairic<\/code>codecodecodecode endpoint. Company representatives state that open weights are planned, which would enable local deployment and custom fine-tuning once released. The absence of a published accuracy benchmark will invite scrutiny, and rightfully so \u2014 anyone considering production deployment should hold the model to their own test cases rather than taking the TSA examples as a general claim of reliability.<\/p>\n<p>System One extraction models will not replace general-purpose LLMs. They are narrowing an important slice of the work those models have been doing by default: the tedious, predictable, high-volume job of turning unstructured input into typed data. In doing so, they change the architectural conversation. The question for developers is no longer \u201cwhich large language model is best for extraction?\u201d but rather \u201cdo I need a language model for extraction at all?\u201d Clairic answers that question with a particular kind of authority: a single forward pass, a typed answer on every field, and a confidence score <a href=\"https:\/\/overcentral.com\/en\/emdash-dashboard-menu-cms-98090\/\" title=\"EmDash\u2019s Dashboard UI: The Menu That Tells You Everything\" data-iacss-internal=\"1\">that tells you<\/a> exactly when to trust the machine \u2014 and when to hand the work to someone who can think more slowly.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Cloudflare has opened a preview of Clairic, a System One extraction model now available on Workers AI, and it represents a deliberate departure from how developers have been using large language models for structured data tasks. Instead of generating text that happens to contain a value, Clairic reads the input \u2014 text, images, or both [&hellip;]<\/p>\n","protected":false},"author":7,"featured_media":100868,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/100865.png","fifu_image_alt":"Clairic Brings System One Extraction to Cloudflare Workers AI","footnotes":""},"categories":[31],"tags":[],"class_list":["post-100865","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/en\/100865.png","fifu_image_alt":"Clairic Brings System One Extraction to Cloudflare Workers AI","_links":{"self":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/100865","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/comments?post=100865"}],"version-history":[{"count":1,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/100865\/revisions"}],"predecessor-version":[{"id":100866,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/posts\/100865\/revisions\/100866"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media\/100868"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/media?parent=100865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/categories?post=100865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/en\/wp-json\/wp\/v2\/tags?post=100865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}