Cost and model choice
Don't optimize for the cheapest token. Optimize for the cheapest good outcome. That usually means a light model for routine work, a stronger model where judgment or consequences demand it, and a design that avoids sending the same information over and over.
Five levers for lower token cost
- Retrieve, don't paste. Knowledge lives once in raia Command. People and tools ask an agent for an answer instead of loading whole documents into every chat.
- Use the right model for each task. Frontier models for judgment, efficient models for volume. The model is chosen per agent and can be changed.
- Keep agents narrow. Lean instructions, and only the tools the agent needs, mean less context sent with every request.
- Build once, answer many. One agent answering the same question for fifty people beats fifty separate conversations each carrying their own context.
- See it and budget it. Track token cost per agent and tie it to outcomes, so spend is visible and unofficial AI use has a better place to go.
Matching models to work
| Tier | Good for |
|---|---|
| Frontier reasoning | Complex judgment, analysis and consequential decisions |
| Standard | Support answers, drafting and everyday knowledge work |
| Efficient and open-source | Classification, triage, lookups and summaries: the high-volume work |
High-volume, simple work tends to grow fastest as usage scales, so routing it to efficient models matters more over time. Choosing models per agent also means no single provider's outage, retirement or pricing change can stop your agents. You can switch models without rebuilding.
Available models, names and prices change. See Models and pricing for the current list.
The specialist gate
Most conversations are simple, but a few lead to consequential actions, such as creating a CRM case. Rather than running everything on a strong model:
- A light front-line agent handles the conversation and collects the details.
- When an action is needed, it passes a focused request to a specialist agent on a stronger model.
- The specialist checks the details are complete and the identity is right, then either asks for what's missing or takes the action with one scoped tool.
The front line stays fast and inexpensive, and the stronger model is used only where it adds value. Make the specialist a real check, not just a relay. See Pattern 9.
The gopher pattern
When a strong model in Claude or another assistant needs to sift many records, such as CRM history or meeting transcripts, don't send them all to it. Expose a light raia agent as an MCP server instead. It retrieves and filters, then returns a compact answer with its sources, and the strong model reasons over that.
Keep source references in the compact answer, and let the strong model ask follow-up questions when something was left out. See Pattern 11.
Calculations belong in code
Models are poor at precise arithmetic. For totals, counts and financial figures, use the agent's code interpreter or calculate on the server. It's more accurate and often cheaper than asking a stronger model to try harder.
Questions to ask about any design
- Which steps run most often? Are they on an efficient model?
- Which steps are consequential? Do they have a stronger model or a person checking them?
- Is any large content being sent repeatedly that could be retrieved instead?
- Does every agent have only the tools it needs?
- Can you see cost per agent, and compare it to the value delivered?