Agent and scout tiers

Instead of naming a model, you can name a tier. There are two.

toolsxpo-agent   The main agent. Writes code, runs tools, makes decisions.
toolsxpo-scout   Cheap exploration — reading files, searching symbols,
                 scanning logs. Never writes code.

Why a tier and not a model

A tier is a routing decision, not a model. What toolsxpo-agent runs is decided by your workspace and can change without you updating anything.

Pinning a catalogue row into a released extension would freeze both that choice and its pricing. Models get better and cheaper; a name that can be repointed keeps up, a hardcoded id does not.

A fresh sign-in points at toolsxpo-agent.

What scouts do

When scout subagents are on (Settings → Agent), the agent delegates exploration to the cheap tier: reading files, searching for symbols, scanning logs.

This usually lowers what a task costs. Exploration is most of an agent's token spend and almost none of its difficulty — finding the file is not the hard part, and it does not need your best model.

Scouts return a short structured briefing rather than raw file contents, so the main agent's context stays small. They never write code.

Overriding a tier

Set what a tier runs from your dashboard, per workspace. The override applies to every ToolsXpo app at once.

Guards apply: a model that cannot hold an agent turn — no tool calling, no streaming, too small a context — is skipped rather than trusted, and the tier falls back to its default. A scout that silently stalls is worse than one that costs slightly more.

Stability within a conversation

A tier resolves to the same model for every turn of one conversation. That is deliberate rather than incidental: providers cache a prompt prefix, and an agent that bounced between two hosts of the same model would miss the cache on every turn while resending a context that grows each time — the expensive half of agent traffic, paid twice.

See also

• Choosing a model
• Subagents
• Prompt caching