Iris cost and token usage: what drives spend and how to control it

Iris cost and token usage: what drives spend and how to control it

On a cloud provider, Iris is billed per token: what goes in (the request) and what comes out (the answer). Requests dominate, and one feature dominates requests. Knowing which gives you most of the control you need. On a self-hosted model there’s no per-token bill; the same numbers tell you how hard the model server works.

What drives cost

Configuration text runs at roughly 3 to 4 characters per token, so a 60,000-character config is around 15,000 to 20,000 input tokens before the question.

MCP agents don’t appear here. They use their own provider and account.

Measuring it

Every Iris request writes prompt and completion token counts to the AI audit trail (ai_audit_logs). There’s no screen for it in this release. An administrator can summarise it from the database:

SELECT DATE(created_at) AS day, capability, model,
       SUM(prompt_tokens) AS prompt_tokens, SUM(completion_tokens) AS completion_tokens
FROM ai_audit_logs
GROUP BY DATE(created_at), capability, model
ORDER BY day DESC;

Multiply by your provider’s per-token prices for an estimate, and compare it with the provider’s own usage report.

Controls

• Spend limits and alerts in the provider’s console. This is the only hard cap.
• Capability switches in AI Configuration. Turn off what nobody uses.
• Max Output Tokens caps answer length (it can lower a feature’s cap, never raise it). It trims a little; inputs matter more.
• Habits: start a new chat for a new topic (long conversations are re-billed on every turn), and select the lines you care about on very large configs.
• Model choice: a smaller, cheaper model for drift and compliance narration is often enough, but rConfig uses one model for all features, so weigh it against config analysis quality.

Related reference

• Set up an AI provider: model controls
• AI Center governance: audit trail
• Public API design