Route model effort to the task

Keep the current model when it fits, and change course only when task evidence and your controls justify it.

Last updated August 2026Copy a starter prompt ↓

Let the normal Brief loop make the first call

Model routing runs inside the normal Brief workflow. When the current model is a good fit—or the coding agent has not exposed enough runtime information—Brief stays quiet and keeps one primary agent on the task.

Ask your coding agent

Use Brief to route model effort for <task>. Use only the current model, reasoning level, available models, and switching capabilities this coding agent actually exposes. Keep the current single-agent route when it fits. If a change is useful, show the recommended route, the route this host can execute, why it is material, and whether I need to approve it. Don't claim a switch happened until the host confirms it.

Set the boundaries that matter

Ask your coding agent

Recommend model routing for this mission with quality per token as the objective. Do not switch providers. Do not exceed <model class or reasoning level>. Ask before using a frontier model. Keep fanout off unless I approve named, independent workstreams. If no allowed route clears the quality floor, stop and tell me what constraint is blocking it.

Choose whether routing is off, advisory, approval-based, or automatic.
Set maximum model class and reasoning effort instead of naming a stronger model after work begins.
Keep provider changes and frontier-model approval explicit.
A cheaper route still has to clear the task's evidence-derived quality floor.

Keep model routing separate from fanout

One agent can move to a cheaper or stronger model without fanout. Fanout is a separate choice for named investigations or verification tracks, not a fallback when the host cannot switch models.

Ask your coding agent

Keep one primary agent responsible for edits and synthesis. Suggest fanout only when there are two or three named, independent workstreams. Keep investigation workers read-only, do not auto-launch parallel implementation, and wait until the verification phase before auto-launching verification tracks.

Recheck when the evidence changes

Ask your coding agent

Recheck the model route after this checkpoint. Use the failed validation, blocking review findings, changed scope, or localized root cause as new evidence. Escalate or de-escalate only when the change is material and stays inside my controls. Otherwise continue on the current route without adding ceremony.

Escalate when repeated failures or a new trust boundary raise the evidence bar.
De-escalate when the root cause is localized and focused checks can prove the fix.
Reconsider fanout when the work reaches a real investigation or verification checkpoint.

Was this guide useful?Help us make Brief easier to learn.

Ready for another workflow?Choose your next mission →