ticket: "Where is my replacement charger?"
route A: Haiku
cost: $0.012
latency: 2.4s
result: resolved, no follow-up
route B: forced Opus
cost: $0.36
latency: 12.1s
result: resolved, same policy, same order lookupThat is the entire argument for the Beamdesk router. The customer did not get a better answer from the expensive model. The support team did not get lower risk. They got a slower answer at 30x the unit cost because a single-model system treats every ticket like it deserves the same engine.
Vendor lock-in is dead in every other part of the stack. Your database has replicas. Your email provider has failover. Your payment code knows more than one error path. Yet many AI helpdesks still route refunds, password resets, order status, angry enterprise renewals, multilingual delivery exceptions, and policy interpretation through one preferred model. That model is often very good. It is also 5-10x more expensive than necessary for a large slice of the queue.
Beamdesk starts from a different premise: the correct model is the cheapest model that can actually resolve the ticket under the workspace quality bar. Price alone is a bad router. Confidence alone is a bad router. Latency alone is a bad router. The route is the intersection of all three.
The Roster
Our production roster has thirteen models. The general-purpose set is Claude Opus, Claude Sonnet, Claude Haiku, GPT-5, GPT-5-mini, GPT-4o, Gemini 1.5 Pro, Gemini 1.5 Flash, Gemini 2.0 Pro, Gemini 2.0 Flash, and Llama 3.3. The final three are specialist models: a classification model trained for support intent and priority, a retrieval verifier trained to reject weak knowledge matches, and a compact policy model tuned for refund, warranty, and entitlement language.
The point is not to collect logos. Each model has a job. Haiku wins when the ticket is short, the knowledge match is clean, and the customer needs a direct operational answer. GPT-5-mini wins when the ticket needs structured reasoning but not frontier depth: plan changes, subscription edge cases, or one tool call with clear constraints. Gemini Flash wins in fast multilingual triage and high-volume categorization. Llama 3.3 wins for privacy-sensitive queues where a customer wants a self-hosted or region-pinned option and the task is within the local policy corpus.
Sonnet and GPT-4o sit in the middle. They are the workhorses for ambiguous customer phrasing, longer threads, and tool sequences where the model has to read a few bad assumptions and still produce a crisp answer. Opus and GPT-5 are reserved for the tickets where mistakes are expensive: account closures, high-value refunds, legal language, escalated complaints, and executive customers with history spread across multiple systems. Gemini Pro is useful when long context matters more than raw conversational elegance.
The specialist models rarely send a customer-facing sentence. They decide whether a ticket is safe to automate, whether retrieved material actually supports the answer, and whether a policy clause has been applied correctly. They are cheap, fast, and narrow. Narrow is a feature.
How The Router Decides
The router scores the ticket before generation. It looks at channel, language, customer tier, sentiment, message length, attachment presence, SLA state, requested action, required tools, historical automation performance for that intent, and retrieval quality. It also looks at the persona configuration: billing support can be conservative, order status can be aggressive, and enterprise success can require a human review step even when the model is confident.
router inputs:
confidence_floor: 0.86
cost_ceiling: $0.05
latency_budget: 4.0s
intent: warranty_replacement_status
retrieval: strong
tool_plan: orders.lookup -> shipments.lookup
customer_tier: standard
selected: Claude Haiku
fallback: GPT-5-mini -> Sonnet -> human reviewThe selected model is the first model expected to clear the confidence floor inside the cost and latency budget. Expected does not mean guessed from a vendor benchmark. Beamdesk maintains per-workspace scorecards. If Haiku has resolved 93% of warranty status tickets for your workspace with strong QA scores, it earns the route. If it starts failing after a policy change, the router sees the drop and moves that intent up the chain.
We also price the whole attempt, not just the first call. A cheap model that fails twice and escalates to Opus is not cheap. The router includes the cost of likely verification, tool retries, and fallback. This is why the cheapest raw model does not always win. The cheapest successful route wins.
Fallback Chains Are Product Decisions
A fallback chain is not a panic button. It is a statement about risk. For order status, the chain can be Haiku, GPT-5-mini, then human review only if the tool fails or confidence collapses. For a cancellation that mentions chargebacks, the chain may start at Sonnet and move directly to a human if Watchtower flags the draft. For a refund exception on a high-value account, Opus may draft but never send without approval.
Beamdesk exposes these chains because support leaders need to reason about them. "Use the best model" is not a policy. "Use Sonnet for German warranty disputes above EUR 250, fall back to human review if retrieval support is below 0.78, and never auto-send when sentiment is severe" is a policy. The router is only valuable when humans can shape it.
The same idea applies to outages and vendor drift. If a provider slows down, the latency budget changes the route. If a provider rate-limits your workspace, the queue keeps moving. If a new model improves a class of tickets, Beamdesk can run it in shadow mode before it sends anything. The model roster is an operating system, not a procurement memo.
Pinning Models Per Persona
Automation needs defaults and overrides. Most teams let the router choose for routine personas, then pin specific models where brand voice, compliance, or customer value matters. A retail operations persona might allow Haiku, Flash, GPT-5-mini, and Sonnet. A billing disputes persona might allow only Sonnet, GPT-5, and human review. A developer support persona might pin GPT-5 for code analysis but still use Haiku for "where is the API key page?"
Pinning is not a defeat of routing. It is a boundary. The router still chooses inside the allowed set, still applies confidence and cost budgets, and still records why a model was selected. If a pinned persona gets expensive, the cost dashboard will show whether the policy is worth it.
persona: refunds_enterprise
allowed_models:
- Claude Sonnet
- Claude Opus
- GPT-5
auto_send: false when amount > $500
human_review: always for chargeback, legal, fraud
monthly_model_budget: $1,200The Cost Dashboard
Routing has to be visible or it becomes another black box. Beamdesk breaks down spend by model, persona, queue, intent, customer tier, channel, and outcome. You can see cost per attempted automation, cost per clean resolution, cost per human rescue, and cost per low-QA exception. The useful number is not "we spent $812 on models." The useful number is "German warranty replacements cost $0.09 per clean resolution because they keep falling from Flash to Sonnet after retrieval misses."
Across our pilot fleet, average ticket cost is $0.04. The comparable Decagon quote customers showed us was $0.18 for a blended AI resolution. That does not mean Decagon is always wrong or that $0.04 is magic. It means model choice matters. If 60% of your tickets are order status, password reset, plan limits, address changes, and standard returns, forcing them through a frontier model is a tax, not a quality program.
The dashboard also catches false savings. If a cheap route creates low CSAT or human follow-up, the honest outcome pricing audit will zero the resolution and the router scorecard will degrade that path. A low model bill with a high exception rate is not success. It is deferred labor.
Single-Model Helpdesks Are The Wrong Abstraction
The future of AI support is not one model pretending every ticket has the same shape. It is a controlled market inside the product: models compete on cost, quality, latency, context length, language, tool use, and policy fit. The support team sets the bar. The router buys the cheapest route that clears it. The audit log proves the outcome.
This is why we built Beamdesk around routing instead of brand loyalty. Models will keep changing. Prices will keep falling in uneven ways. A model that is excellent for long reasoning may remain wasteful for shipping questions. A model that is mediocre at open-ended chat may be perfect at classifying disputes. Your helpdesk should be able to use that without a migration project.
The right answer is not "always use the strongest model." The right answer is "use the least expensive model that resolves this ticket at the quality level your customers deserve." Everything else is margin theater.