Cloudflare Clairic: extract support data before acting

Cloudflare’s Clairic preview gives ecommerce developers another way to turn a customer message into structured fields before deciding what to do with it. It is a building block for a custom workflow, not an installed Shopify support app.

In its October 19 announcement, Cloudflare describes extraction, calculation, estimation and forecasting from unstructured inputs. Text extraction can return the original character spans; missing information can return null. That distinction matters when a customer supplies an order number but omits a tracking number.

Keep extraction separate from action

Our recommendation is to trial a narrow task: identify the order reference, reported problem and delivery date in a support message, then show those fields beside the original text for an agent to check. Compare the order reference with the store’s actual record before accepting it. A customer’s description of a payment is a claim to reconcile, not proof of payment.

Keep refund eligibility and payment execution in separate, explicitly controlled steps. A well-formed number can still be the wrong number. Do not turn an extracted amount or estimated repair cost directly into an automatic refund.

What the preview exposes

The model documentation lists @cf/cloudflare/clairic, vision support and pricing of $0.10 per million input tokens. Requests specify the input and typed fields; responses include confidence information. Check the live documentation before estimating workload costs.

Cloudflare says complex arithmetic remains a weakness, confidence calibration is not guaranteed on unfamiliar data, and forecasting is basic. Open weights are planned; the announcement does not say they have already been released. Its speed and cost comparisons are vendor examples, not results we have reproduced.

A useful acceptance test

Build a small labelled set of representative messages, including missing dates, two order numbers, ambiguous currencies and contradictory statements. Record errors per field, not just whether the response parses. Define when to stop and request human review. Test the complete workflow cost and elapsed time, including retries and review, before replacing an existing process.