Advanced Patterns: Teams, Scheduled Tasks, and Idle Token Creep
- Estimate token cost for agent teams and apply the four strategies for keeping team costs manageable
- Identify the five reasons usage climbs in a long idle session and the setting that controls each one
- Design a scheduled task loop that minimizes per-run token cost
Why Some Sessions Cost Far More Than the Work Warrants
A session that has been open for hours, or a scheduled task that fires frequently, can consume far more tokens than the actual work performed suggests. Understanding the mechanics of idle token consumption prevents surprise costs and helps you design automation that stays within budget.
Agent Teams: ~7x the Token Cost
Agent teams spawn multiple Claude Code instances, each with its own full context window. In plan mode, agent teams use approximately 7x more tokens than standard sessions — each teammate runs its own context window and maintains its own state. That multiplier applies regardless of how much each teammate is actually doing.
Four strategies for keeping team costs manageable:
Teammates rarely need Opus-level reasoning. Sonnet balances capability and cost for coordination tasks. Set the model explicitly in teammate configuration.
Each teammate is a full context window. Token usage is roughly proportional to team size. Start with the minimum team that can complete the task.
Teammates load CLAUDE.md, MCP servers, and skills automatically. Everything in the spawn prompt adds to their context from the start — keep it tight.
Each active teammate continues consuming tokens until it exits. Explicit shutdown when work is complete prevents lingering consumption.
Five Reasons Usage Climbs in an Idle Session
A session that has been open all day accumulates cost even during quiet periods. Here are the five mechanisms and how to control them:
1. Long Context Re-Reads
Claude Code sends the full conversation with every request. In a session with hours of file reads and tool results, even a one-line question draws usage for the whole context. With prompt caching, the repeated content is served at the cached token rate — but a cache miss (after the TTL expires) re-processes everything at full price. Manage with /compact or /clear.
2. Cache Misses After Breaks
The first message after a break longer than the cache TTL misses the cache and reprocesses the full context. On subscription plans within the seat allowance, the TTL is one hour. Once drawing on usage credits, it drops to five minutes. An afternoon break in a large session can trigger a significant re-cache cost. Control: use the resume-from-summary dialog on large resumed sessions, or compact before long breaks.
3. Scheduled Tasks
A /loop or scheduled task fires on its interval even while the session is otherwise idle. Each firing sends the full context. If a scheduled task fires every 5 minutes in a session with 50,000 tokens of context, that is 600,000 tokens per hour in background consumption. Design scheduled tasks with minimal context: start a fresh session for each run, keep the prompt focused, and use Haiku where capability allows.
4. Cross-Session Messages
Claude Code delivers messages from your other sessions as new turns when this session sits idle — each delivery sends the full context. Set crossSessionInbound: hold in settings to queue inbound messages instead of delivering them automatically.
5. Goal Check-Ins
While background work runs under an active goal, Claude Code checks on that work even when the session is idle — up to three check-ins between your prompts, each sending the full context. Set CLAUDE_CODE_GOAL_CHECKIN_MINUTES=0 to disable idle check-ins.
Designing Cost-Efficient Scheduled Tasks
The highest-cost mistake in scheduled automation is running a long-running session as the host for a recurring task. Each firing accumulates more context in the same session, making each subsequent firing more expensive than the last.
Better pattern: design scheduled tasks to start fresh each run. Use /clear at the end of each run, or configure the task to spawn a new session for each firing. Combine with a focused prompt that names exactly what to do, a Haiku model where appropriate, and no MCP servers that are not needed for the specific task. The result is a predictable, bounded per-run cost rather than a cost that climbs over time.
The Full Picture
Cost control in Claude Code is not one setting or one habit — it is a stack of practices that compound. The developers who run Claude Code most efficiently are not the ones who are most conservative; they are the ones who are most intentional. They know what fills the window, when to clear vs compact, which model earns its cost, and how to design automation that stays bounded. That is the complete picture this track has built toward.
- Agent teams use approximately 7x more tokens than standard sessions in plan mode — keep teams small, use Sonnet for teammates, write focused spawn prompts, and shut down teammates when their work is done.
- Five mechanisms drive idle token creep: long context re-reads, cache misses after breaks, scheduled tasks firing on interval, cross-session messages, and goal check-ins — each has a specific setting or practice to control it.
- Scheduled tasks that accumulate context over multiple firings become progressively more expensive; design them to start fresh each run with /clear or spawn a new session per firing.
- Set crossSessionInbound: hold to queue inbound messages instead of delivering them automatically in idle sessions, and CLAUDE_CODE_GOAL_CHECKIN_MINUTES=0 to disable idle goal check-ins.
- Cost control in Claude Code is a stack of practices that compound: context awareness, session hygiene, model matching, prompt precision, structural choices (MCP, skills, CLAUDE.md), hooks, and automation design — mastering all of them is the complete picture.