Cloudflare Clef for Product Managers: Decision AI vs. Generative AI
TL;DR
Cloudflare released Clef on October 1, 2026: a model series that returns probability scores over a set of predefined answers you define, not generated text. This matters because most AI product decisions (route, escalate, approve, flag) do not need a sentence from a language model. They need a calibrated confidence score you can act on. Clef, Clef-flash, and Clef-omni give PMs a lighter, cheaper, and faster alternative to using frontier LLMs for classification and routing logic, with open weights and Workers AI hosting. This guide covers what it is, how it differs from the LLMs you already use, when to reach for it, and what changes in your product architecture when you do.
The AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.
What Clef Is and Why It Is Different
Every major model release you have read about in 2026 has been a generative model: a system trained to predict the next token and produce text, code, or structured output in response to a prompt. Clef is not that. It is a decision model: you give it a context and a fixed set of possible answers, and it returns a probability distribution over those answers. It does not write a sentence. It scores your options.
Cloudflare released the series on October 1, 2026, with three models. Clef is the full-size version for highest accuracy on complex decisions. Clef-flash is a 9B parameter model built for low-latency production decisions, priced at $0.09 per million input tokens. Clef-omni, released October 9, extends the series with multimodal input support. All three are released under the Apache 2.0 license with weights available on Hugging Face and hosted inference on Cloudflare Workers AI.
The request format follows the same interface as TypeSafe's Jev model, which means teams already running Jev integrations can switch to Clef by changing an endpoint URL and a model ID. No rewrite required.
Generative model output
A string of tokens forming text, code, or structured JSON. The model decides what to say. You parse the result. Errors show up as hallucinations, wrong formats, or unexpected refusals.
Decision model output
A probability distribution over your predefined answer labels. The model scores your options. You apply a threshold. Errors show up as miscalibration: confidence is too high on wrong answers or too low on clear ones.
The practical implication: if your current AI feature is a generative LLM doing classification, you are paying for sentence-construction capability you do not need and accepting reliability risk from free-form output parsing. Clef is purpose-built for the classification half of that workflow.
Four Use Cases Ready to Evaluate Now
Decision models are a better fit than generative LLMs when the output space is bounded (you already know all possible answers), latency matters more than explanation, and you need to set and enforce a confidence threshold in production. Here are four use cases that fit that profile.
Support ticket routing
High intent signalClassify inbound tickets into routing categories: billing, technical, account, feature request, abuse. The decision model scores each category. Tickets above your confidence threshold go directly to the right queue. Tickets below it go to a human reviewer. You tune the threshold to balance queue accuracy against human review volume.
Metric to track: first-contact resolution rate by routing path vs. human-routed baseline.
Escalation decisions in agent workflows
High intent signalIn a multi-step agentic workflow, the most expensive mistake is an agent proceeding when it should have handed off. A decision model at the handoff gate scores the current state against labels like 'continue autonomously', 'request clarification', and 'escalate to human'. The output is a routing decision, not a generated message.
Metric to track: unnecessary escalation rate and missed escalation rate across traffic segments.
Content moderation scoring
Medium intent signalScore user-generated content against policy violation categories with calibrated confidence. Rather than asking a generative model to explain what is wrong with a post, you ask a decision model to score it across violation labels. High-confidence violations auto-action. Low-confidence cases queue for human review. The probability output gives you a reviewable audit trail.
Metric to track: false positive rate at each confidence tier and human review queue volume.
Lead and deal qualification
Medium intent signalScore inbound leads or deals across qualification tiers (high intent, low intent, disqualified) using behavioral signals, firmographic data, and conversation context. Unlike a scoring rule with explicit weights, a decision model learns the relationship between signals and outcomes from labeled examples. You set the routing threshold, not the scoring formula.
Metric to track: conversion rate by qualification tier and model confidence band.
Calibration: The PM Metric That Replaces Fluency
When you evaluate a generative model, you check fluency, coherence, and factual accuracy. When you evaluate a decision model, the primary concern is calibration: does a 70% confidence score actually correspond to being right about 70% of the time?
A miscalibrated model is dangerous in both directions. If it is overconfident, you auto-route cases you should have reviewed. If it is underconfident, you send too much to human review and the efficiency gain disappears. Good calibration is not automatic: it depends on the similarity between your training distribution and your production traffic.
How to measure calibration
Split your labeled evaluation set into confidence bands (0-50%, 50-70%, 70-90%, 90-100%). Check the actual accuracy within each band. A well-calibrated model has accuracy that closely tracks confidence. Plot this as a reliability diagram before shipping.
What causes miscalibration
Distribution shift is the most common cause. If the model was trained on customer support data from SaaS companies and you route tickets from a logistics company, the language and patterns may differ enough that calibration breaks. Re-evaluate on your own labeled data, not benchmark data.
Setting your threshold
The confidence threshold you pick is a product decision, not a model decision. A high threshold (e.g. 95%+) means fewer auto-actions and more human review. A low threshold (e.g. 60%+) means more automation and more errors. Map it to your acceptable error rate and review capacity.
Monitoring calibration in production
Calibration drifts as your product and users evolve. Track accuracy by confidence band as an ongoing production metric, not a one-time launch check. Use cases where your product changes quickly (seasonal campaigns, new categories) require recalibration on fresh labels.
The product architecture implication: your decision model needs a labeled holdout set you own, not one borrowed from Cloudflare's benchmarks. Budget for labeling 500 to 2,000 examples from your own traffic before launch, and plan for quarterly recalibration cycles as part of your model health process.
Build AI Products That Actually Ship
The AI PM Masterclass covers the full model stack: when to use decision models, generative models, and hybrid architectures, taught live by a Salesforce Sr. Director PM.
Architecture: Where Clef Fits in Your AI Stack
Decision models and generative models are not alternatives to each other. They solve different problems in the same workflow. Most production AI products combine both: a generative model handles open-ended tasks like drafting, summarizing, and answering questions, while a decision model handles the routing, gating, and classification logic around it.
The pattern to look for in your current product: anywhere you are parsing a generative model's output to extract a classification decision, a decision model is likely a better fit. If you are prompting an LLM to reply with "ROUTE_TO_BILLING" or "ROUTE_TO_TECHNICAL" and then parsing that string, you are using a $0.24/M token model for a $0.09/M token job with worse reliability.
Intake gate: Decision model scores input before the generative model sees it
Classify whether an inbound message is a support request, a spam attempt, or a general question before routing to different processing pipelines
Parallel scorer: Decision model runs alongside the generative model on the same input
As the generative model drafts a response, a decision model scores the draft for policy compliance. Scores below a threshold hold the draft for review before delivery
Output validator: Decision model evaluates generative model output before it reaches the user
After a summarization model produces a summary, a decision model classifies whether the summary accurately captures the source material vs. contains introduced errors
Agent handoff gate: Decision model evaluates agent state to decide next action
At each step of an agentic workflow, a decision model scores the current state against possible next actions. Sub-threshold confidence on 'continue autonomously' triggers a human review request
Running Clef-flash on Workers AI keeps the decision layer at the edge, close to where requests arrive. This matters for latency-sensitive applications: a routing decision that takes 800ms adds friction before the main model even starts. Clef-flash is designed for sub-200ms decisions at the edge, which means you can add a routing layer without meaningfully increasing your product's perceived response time.
Five PM Decisions Before You Build with Clef
Decision models introduce a different set of PM decisions than generative models. Before your team starts integrating Clef, lock down answers to these five questions. Ambiguity on any of them will cause the build to stall or ship misconfigured.
1. What are the exact answer labels?
Decision models require you to enumerate all possible outputs upfront. Vague labels like 'needs help' will produce lower accuracy than specific ones like 'billing dispute', 'password reset', 'API error'. Labels should match the downstream action, not a description of the user's feeling. Work with your engineering team to align labels to routing destinations before labeling any training data.
Risk if skipped: If you change the label set after labeling 1,000 examples, those examples may need to be re-labeled.
2. What is your acceptable false positive and false negative rate?
These are not the same number. A false positive on 'route to premium support' costs you premium agent time on a standard issue. A false negative on 'flag for abuse review' means abuse gets through. Map each error type to a business cost before setting your threshold. The threshold is a product policy decision with real dollar consequences.
Risk if skipped: Teams that set a single accuracy target without separating error types ship thresholds that optimize the wrong metric.
3. Who owns the labeled training data?
Clef's open weights are a starting point, not a finished product for your domain. You will need labeled examples from your own traffic to fine-tune or at minimum to evaluate calibration. Decide before the project starts whether your support team, a vendor, or an internal labeling process owns this. Data labeling is the most commonly underestimated work item in decision model projects.
Risk if skipped: No labeled dataset means no calibration evaluation, which means you ship without knowing whether the confidence scores are trustworthy.
4. Hosted on Workers AI or self-hosted?
Clef's Apache 2.0 license lets you self-host the weights on your own infrastructure. Workers AI is faster to start and keeps the decision layer at the edge. Self-hosting gives you more control over data residency and cost at very high volumes. For most teams, Workers AI is the right starting point. Revisit at 100M+ decisions per month.
Risk if skipped: Choosing self-hosting because it 'feels more controlled' adds 6 to 10 weeks of infrastructure work before you ship anything.
5. What is your fallback when confidence is below threshold?
Every decision model deployment needs an explicit fallback. The three options are: route to a human reviewer, route to a generative model for a more expensive but higher-accuracy decision, or reject the request and ask the user for more information. Each has a different cost and user experience. Define the fallback before launch, not during the first incident.
Risk if skipped: No defined fallback means engineers make this decision in a crisis, often producing the most expensive option.
Learn to Make Better Model Architecture Decisions
The AI PM Masterclass covers when to use decision models, generative models, and hybrid architectures, with live instruction from a Salesforce Sr. Director PM who has shipped both at scale.
Related Articles
Before you go: get the AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.