Cloudflare Clef-omni Reads Audio and Video, but Media Intake Still Needs a Human Reviewer

What Cloudflare announced

In an October 9 post, Cloudflare engineers Michelle Chen, Alex Reneau and Kevin Jain announced Clef-omni, which extends the company's Clef decision-model line to accept audio and video alongside text and images. The developer documentation describes the job precisely: the model takes a state and a schema of typed questions, reads that state as text, JSON, images, audio or video, and returns a probability for every allowed option of every question. It does not write a reply. Cloudflare also published the weights on Hugging Face, so the same interface can be examined outside the hosted service.

The same announcement carries two separate changes that are easy to merge together. Hosted Clef-flash input pricing moved from $0.09 to $0.038 per million tokens, and its hosted context window was cut from 64k to 24k. Cloudflare states that only 0.24 percent of its requests exceeded 24k input tokens, and that the published weights were trained for a 256k window if a customer self-hosts. Separately, Cloudflare reports faster hosted Clef responses after serving changes, with median speedups of 1.7x to 2.0x in its own tests. Those are vendor measurements on Cloudflare workloads, not independently reproduced benchmarks, and Clef, Clef-flash and Clef-omni are three different products with different prices and limits.

The documented input limits shape any build. A request accepts up to four embedded audio clips of 300 seconds each and two videos of 60 seconds each, with audio and video together capped at 16 MiB decoded. Images are capped at four files, and remote media URLs are not accepted, so files must be uploaded with the request. Media tokens count against the context window alongside the questions; if they overflow, the request fails, and otherwise the text portion is truncated to fit.

What this means for your business

The practical detail is the shape of the output. A service company that receives a written job description, a few photos and a short recording usually has staff assemble those pieces by hand, decide which queue the request belongs in, and notice what is missing before anyone quotes or schedules. A model that returns a category choice with a probability is easier to attach to that queue than a chat assistant that produces a paragraph, because a queue can act on a label and a number. Treat the returned probability as a model score. We have not verified its calibration on your requests, so any routing threshold built on it requires testing against representative examples before it can be trusted to route on its own.

A concrete system Detailed In Design could build is a customer intake portal that stores the description, photos and an optional short clip in one record, proposes a queue and a missing-information checklist, and shows the evidence to a staff member before any quote or scheduling action. The media limits above are the design constraints: a short clip and up to four photos may fit if they meet the format, decoded size and context limits, while a long site walkthrough does not, so the portal would need to compress, trim or split recordings, or route them to a person instead. Detailed In Design would build that portal, connect it to your existing customer records, and keep human approval on every consequential action. We are not claiming a partnership with Cloudflare, and we have not run this model against your data.

Realistic limitations matter as much as the capability. A hosted deployment needs authorized Cloudflare account access and its own retention and consent rules for customer media, and self-hosting the open weights requires substantial GPU memory. Schema-constrained answers can still be wrong, so the portal should treat routing as a suggestion and never let the model approve billing, payments or safety judgements about equipment. Pricing and context windows changed once in a single announcement, so any contract should recheck current published limits rather than assume they hold.

A restrained next step

If media-based intake is a real bottleneck, the first step is not installing a model. It is writing down the categories your staff already use, the evidence that arrives with each request, and which actions require a person. That specification is what makes any routing system auditable, and it is also what tells you whether the documented media ceilings fit your recordings. Detailed In Design can help you map that intake workflow and run a scoped pilot against your own requests, with human review kept on every decision that affects a customer.