Your users have a vocabulary.
Teach the route.
Choose how requests reach the right model with domain rules, examples, and confidence floors. Built-in MCIR memory keeps relevant context available as those model choices change. Routing picks the path; memory carries the history.
“Look at this clause.”
Short wording does not necessarily mean a simple task.
01change one rule
Inspect the difference before you save.
Choose one of three fixed requests, change the keyword rule, or turn it off. A non-matching rule leaves the authored baseline unchanged. No classifier or model is called here.
pattern: \b(clause|warranty)\b
target_mode: think“Look at this warranty clause.”
Every baseline on this page is authored, not measured.
The \b(clause|warranty)\b rule matches before the classifier in this simplified example.
Illustrative capability: theo-1-reason. A route choice is not a quality score.
Read the worked routing comparisons
- Warranty clause + contract rule: authored baseline fast → configured think, using theo-1-reason in this example.
- TypeScript function + code rule: authored baseline fast → configured code, using theo-1-code in this example.
- Greeting + either rule: no keyword matches, so fast remains fast.
- Rule off: all examples retain the authored baseline. This does not model inherited account preferences.
Authored example. Synthetic records, no live inference, and no network requests. This small comparison does not reproduce the full routing cascade, few-shot classification, or safety locks.
02three different controls
Rules match. Examples guide. Floors constrain.
- Routing rules explicit match
- Map keywords or an advanced regular expression to a target mode. Rules are evaluated before the general intent classifier, but within the broader routing cascade and its existing constraints.
- Few-shot examples classifier context
- Pair a representative prompt with an expected mode. The docs describe injecting up to eight examples into the classifier. These are guidance for classification, not exact-match rules and not a guarantee that every similar prompt follows that mode.
- Confidence-floor overrides promotion threshold
- Adjust the confidence needed to promote a request to a mode. Lowering a floor makes promotion easier; raising it is more conservative. A classifier confidence value is not an independently verified accuracy score.
03not every rule wins
A preference is not permission to escape the path.
Read the surrounding cascade.
The routing guide places task-family locks, attachment handling, and exclusive skill overrides ahead of customer rules. After rule matching, the classifier can use the examples and confidence floors, with family-preservation and conversation hints still part of the wider decision.
A rule can influence which mode handles a request. It does not authorize a tool, grant access to another owner’s context, remove a bound policy, or prove the chosen model will produce a correct result.
In an enabled orchestrator graph, keep the chosen path connected to a usable model. A broken graph should surface a configuration error, not silently switch to an unrelated model.
04test the boundary of the rule
Use fixtures that can prove your assumption wrong.
- 01
Start from real vocabulary, not real secrets
Create synthetic prompts that use the terms your application expects. Include paraphrases, a near miss, and a prompt that should stay on the baseline path. - 02
Compare baseline and configured
Use the dashboard’s test surface to inspect the routing difference before saving. Its result describes routing behavior; it is not a live model-quality comparison. - 03
Inspect the reason
Check whether a rule matched, examples were supplied, or the broader cascade kept the request elsewhere. A changed mode without a known reason is not enough evidence. - 04
Review inheritance after saving
Confirm the key’s effective rules or shared preference. Repeat your fixtures when a rule, skill, default, or allowed capability changes.
before you broaden the rule
A few useful distinctions.
Is the comparison on this page a production preview?
No. It uses a small authored baseline and two fixed keyword rules to explain the concept. The actual routing cascade includes more inputs and constraints; use the documented test surface to inspect your own configuration.
Can I share one rule set across keys?
The public guide describes shared rule sets as an advanced option for reuse and defaults. Keep track of whether a key has local rules or inherits a shared configuration; clearing local rules can change which defaults apply.
Should I send every request to the most involved mode?
Not automatically. Choose the behavior the task needs, inspect mistakes, and evaluate the final output separately. A routing preference is a hypothesis about task handling, not evidence that one mode is always better.
Write one rule. Keep the counterexample.
Open a key’s routing configuration in the existing dashboard, test a small fixture set, and inspect what changes before saving.