Reasoning effort is becoming a product decision, not an obscure model parameter. Anthropic's July release of Claude Opus 5 explicitly plots performance against effort settings, allowing customers to trade more intelligence for more tokens, time, and cost. On August 5, Meta described Muse Spark 1.2, a long-horizon model tested on optimization runs exceeding 1,000 tool calls. Models can now keep working far longer than most website conversations should.
A support chatbot needs a policy for where that extra work earns its keep. Start with this routing card, then validate it against your own conversations:
| Customer intent | Default effort | Promote effort when | Keep the bot from |
|---|---|---|---|
| Greeting, navigation, store hours | Low | The request contains two plausible destinations | Searching or planning beyond one turn |
| Grounded policy question | Low to medium | Sources conflict or the policy has exceptions | Filling gaps from general knowledge |
| Troubleshooting | Medium | The first approved procedure fails | Repeating steps the customer already tried |
| Account-specific explanation | Medium | Several verified records must be reconciled | Exposing data before identity is confirmed |
| Refund, access, or policy exception | High plus approval | Evidence is complete and the action is allowed | Turning deeper reasoning into broader authority |
The labels will differ by provider. The durable idea is to spend more inference only when the intent, evidence, and consequence justify it.
Define Effort as an Operating Policy
“Use high reasoning for hard questions” is too vague to implement or audit. Difficulty is not one property. A question can be linguistically complicated but operationally harmless, or phrased simply while carrying financial and privacy consequences.
Define reasoning effort through four controls:
- Model allowance: which model or reasoning level may handle the intent.
- Work allowance: maximum turns, tool calls, retrieved sources, and elapsed time.
- Evidence requirement: what the chatbot must verify before answering or acting.
- Exit condition: when it must answer narrowly, ask one question, or hand off.
These controls belong together. Raising a model's reasoning level without bounding its work can produce a slower answer, more searches, and more opportunities to drift. A work allowance without an evidence rule can make the bot stop quickly with an unsupported claim.
Write the policy at the intent level. “Password reset” may allow low effort, one account-status lookup, and a link to the approved reset flow. “Why was my account suspended?” may allow medium effort across several verified records but no reinstatement action. “Restore my account” may require high effort to assemble evidence and a human approval before any write.
The chatbot confidence guide provides useful signals for deciding whether an answer is supportable. Reasoning effort determines how much additional work the chatbot may do before making that decision.
Worked Example: Route a Returns Conversation
Consider an ecommerce chatbot with three common returns questions:
1. “Where is the returns page?” 2. “Can I return a sale item bought 12 days ago?” 3. “The courier marked my return delivered, but the refund is missing.”
The first request needs retrieval, not deliberation. A low-effort route finds the canonical returns page and links it. Letting the model build a long plan adds latency without improving the outcome.
The second request needs a small policy evaluation. The chatbot retrieves the sale-item rule, purchase date, return window, and any regional exception. Medium effort is justified because several facts must be combined, but the response still remains a policy explanation.
The third request needs reconciliation. The bot must confirm identity, compare the order, carrier event, warehouse receipt, and payment state, then decide whether the evidence supports an explanation or a handoff. Higher effort may improve that synthesis. It does not authorize the bot to issue a refund unless the action policy and approval path allow it.
A routing record for the third request could look like this:
intent: refund_missing_after_return effort: high limits: tool_calls: 6 elapsed_seconds: 25 required_evidence: - verified_customer - order_payment_id - carrier_delivery_event - warehouse_receipt_state stop_when: - records_conflict - refund_state_is_unknown - tool_call_budget_exhausted next_step_on_stop: billing_handoff
Now put numbers behind the choice. Suppose 1,000 monthly conversations split into 600 navigation questions, 300 policy questions, and 100 missing-refund investigations. An all-high policy spends premium inference on every conversation. A routed policy reserves it for the 100 investigations and promotes only the policy questions with conflicting evidence.
If 10% of policy questions are promoted, high effort runs on 130 conversations instead of 1,000. Even before inserting vendor prices, that is an 87% reduction in conversations sent through the expensive path. Measure the actual token, latency, and resolution difference before treating that percentage as savings; a low-effort answer that creates a repeat contact has only moved the cost.
Promote From Evidence, Not Wording
Long messages are not automatically hard, and short messages are not automatically safe. “Cancel it” contains two words but may require identity verification, target disambiguation, cancellation-policy checks, and a consequential action. A long pasted error log may need only one known troubleshooting article.
Use observable promotion triggers:
- Two approved sources disagree on a material fact.
- The answer depends on several customer-specific records.
- A required tool returns a partial, stale, or ambiguous result.
- The first approved troubleshooting path fails.
- The customer disputes a previous answer with new evidence.
- The likely response would create financial, access, legal, or privacy consequences.
Do not use customer frustration as a reason to think indefinitely. Frustration should change tone and may increase handoff priority. It does not make missing evidence appear.
Demotion rules matter too. If a canonical Q&A pair fully answers a question, stop. If the customer asks for a page, give the page. If a tool confirms a terminal state, do not keep searching for an answer the customer might prefer. More computation after the decision is already supported often makes the interaction feel hesitant.
Test the Policy With Complete Conversations
A reasoning-effort test should compare routes, not isolated model responses. Keep the prompt, sources, tools, customer state, and grading rubric fixed. Change only the effort policy or the model tier used to implement it.
Build a set with three case types:
Easy cases test restraint. Include requests with a single canonical answer and obvious navigation. The higher-effort route should not add caveats, tools, or delay without a measurable quality gain.
Borderline cases test promotion. Include conflicting documents, missing identifiers, failed first steps, and ambiguous customer language. The router should recognize when additional work can resolve uncertainty.
Stop cases test discipline. Include unavailable records, expired approvals, policy exceptions the bot cannot grant, and tool results that remain unknown after lookup. More effort must still end in a safe handoff.
Grade the final answer and the path. The chatbot model evaluation framework explains how to hold the rest of the system constant while comparing quality, grounding, latency, and cost. Add routing-specific checks: correct initial tier, justified promotions, budget overruns, unsupported demotions, and handoffs that arrived too late.
Run each case several times. Variable reasoning can change tool selection, answer length, and stopping behavior between runs. One impressive trace is not a release decision.
Count the Cost of the Whole Resolution
Token cost per response is useful but incomplete. Reasoning effort can change the number of turns, tool calls, retries, and repeat contacts. Measure the whole customer outcome:
cost per supported resolution = (model + retrieval + tool + review cost for eligible conversations) / resolutions that remain solved after the reopen window
Suppose low effort costs $0.03 per conversation and resolves 82 of 100 difficult cases without a repeat contact. Its model cost per durable resolution is about $0.037. High effort costs $0.09 and durably resolves 94 cases, or about $0.096 per durable resolution. High effort is still more expensive, but the extra 12 resolved customers may justify it for account access or high-value orders.
Now add human work. If each unresolved case creates an eight-minute ticket at $24 per support hour, the low-effort path sends 18 cases to humans for $57.60. The high-effort path sends six for $19.20. Including model and human handling, the high-effort route can be cheaper for this intent despite costing three times as much at inference time.
Use the same reopen window for every route. Counting a fast answer as “resolved” the moment it is sent rewards confident deflection and hides customers who return later.
Protect the Customer's Time
Higher effort usually competes with response speed. For chat, silence is visible. Set a latency budget by intent and decide what the interface does before that budget expires.
For a policy explanation, stream a short acknowledgment only if it adds information: “I’m checking the sale-item rule and your purchase date.” Do not narrate generic thinking. For work that cannot finish inside the live-chat budget, turn it into a durable job with a reference and checkpoint. The async chatbot workflow guide covers that boundary.
Watch time to first useful content, time to supported answer, and abandonment while processing. The chatbot speed analysis is a reminder that extra intelligence has no customer value when the visitor leaves before seeing it.
Set hard ceilings even for high effort. A model that can continue for hundreds of tool calls is demonstrating capability, not defining an acceptable support experience. When the ceiling is reached, preserve the evidence gathered, explain the unresolved point, and route a handoff packet that lets a person continue without starting over.
Review Promotions as Product Feedback
Promotion logs reveal where the support system is making questions harder than necessary. Review them by trigger and intent every week.
Frequent source conflicts point to a knowledge-ownership problem. Repeated missing identifiers suggest the conversation should collect structured input earlier. Tool ambiguity calls for a clearer result contract. Many high-effort policy answers may mean the policy itself needs simpler rules and better examples.
Track three ratios:
- Promotion precision: promoted conversations where extra work changed the supported outcome.
- Missed-promotion rate: low-effort conversations later found to need deeper evidence or review.
- Unproductive effort: high-effort conversations that ended with the same answer or handoff available at the start.
Do not optimize promotion precision alone. A router can achieve high precision by promoting almost nothing while missing consequential cases. Review the false negatives beside the savings.
Spend Thought Where It Changes the Outcome
Reasoning controls create a useful new dial, but a chatbot should not turn it to maximum by default. Give routine questions a fast, grounded path. Promote when additional evidence or reconciliation can change the answer. Stop when the missing piece is authority, data, or a human decision rather than computation.
In Agentkit, the model picker provides distinct cost and capability tiers, while conversation logs supply real cases for reviewing which intents need a different default.
No credit card required.



