Reducing costs

That means the choices you make about which model runs, how agents are structured, and when they wake up have a direct and measurable effect on what you spend.

​

Pick the right model for the job

Model tokens are the biggest lever. The difference between a flash model and a flagship can be 100x in price per token, and most agent tasks do not need a flagship. A quick rule: match the model to the hardest thing the agent does regularly, not the hardest thing it could ever do. An agent that summarizes support tickets, routes leads, or monitors a feed is doing structured work on known inputs. It does not need a reasoning model with a $50/M output rate.

​

What the tiers cost

Rates are USD per 1M tokens (input / output), passed through at cost. The full catalog with context sizes and notes is at Models.

​

Turn thinking down

Reasoning-capable models expose a thinking level. Higher thinking burns more tokens. For most everyday tasks, low or off is fine. Save high thinking for genuinely hard problems, not for every run.

​

Lock in a default, escalate deliberately

Set a workspace default model that is cheap and capable enough for routine work. Switch individual agents up when their job genuinely warrants it. That way a new agent someone spins up does not silently land on a flagship. In Settings, Models, you can also hide models from pickers entirely. If half your team does not need access to the top-tier options, remove the temptation.

​

More agents, lower cost

This sounds backwards, but it is true in practice. A single general-purpose agent handling ten different kinds of work carries all ten contexts at once. A long, mixed context means more tokens on every turn, regardless of which task is actually happening. Split that agent into focused specialists and each one runs a shorter, tighter context. The Intercom agent knows support. The GitHub agent knows code. They do not need to hold each other’s world in memory on every turn. Focused agents also let you match models precisely. Your support triage agent can run on Haiku or a flash model. Your code review agent gets Sonnet. Your weekly executive summary agent is the only one that needs a flagship, and it runs once a week. You are not paying Opus rates for the agent that routes tickets. The Usage dashboard makes this visible. Per-agent spend tells you which agent is running heavy. That is usually the one doing too many jobs.

​

Wake on event, not on a schedule

A cron-polling agent wakes up, loads its context, calls the API, reasons over the result, and does nothing if nothing arrived. You paid for the full run anyway. A webhook-triggered agent sleeps at zero cost until the service sends an event. It wakes once per real event, does the work, and stops. For most support, sales, and notification workflows, that is a significant reduction in idle spend with no change in what gets done. Use a scheduled cron when the trigger is genuinely time-based: a weekly digest, a daily standup, a monthly report. Use a webhook when the trigger is an event: a new ticket, a merged PR, a payment landing. Any service that can POST to a URL works. Ask your agent to set up a webhook receiver and it will handle the endpoint, signature verification, and deduplication automatically using its built-in webhook-receiver skill.

​

Watch the Usage dashboard

The Usage page breaks spend down per agent and over time. The common pattern: one agent with an overfit model or a too-frequent cron is driving a surprising share of total spend. Find it, look at what it is doing, and fix the model or the schedule.

​

Set a spend limit

On the Billing page, you can set a monthly spend limit with a soft or hard cap. A soft limit notifies workspace admins when you cross it. A hard limit pauses new work. Both reset at the period boundary. This is not a substitute for good agent design, but it is a sensible backstop while you tune things.