TokenJam Subagent
Your heavy sessions spawn dozens of subagents. Most of the spend hides inside them.
Break a session cost down per Claude Code subagent, and flag the over-powered ones.
$ tj optimize subagent Subagent right-sizing (last 30d, claude-code, api): 147 subagents across 12 sessions ran inside this window. Subagent spend: $284.10 (66% of window cost) — hidden in parent totals. Top flagged subagents by cost: • researcher-3 claude-opus-4-8 1.2K out, 3 tool calls $18.40 [over_powered] • summarizer-1 claude-opus-4-8 0.8K out, 61K ctx in $14.90 [over_powered, over_provisioned] • linter-2 claude-opus-4-8 0.4K out, 2 tool calls $ 9.10 [over_powered] Flagged spend to review: $52.60 across 6 subagents. ⚠ Candidate-flagging heuristic, not a quality judgment. No recoverable figure is claimed — this is the spend sitting in structurally-flagged subagents. Review before changing how you dispatch them or which model they use. Claude Code only: subagents are read from sub_agent_id, populated by the Claude Code backfill path. Other runtimes are excluded.
The problem
Claude Code spawns subagents through the Task tool, and every subagent's turns get folded into the parent session's total. A single research session routinely fans out into dozens of them. Above the database they all collapse into one number, so you cannot see which subagent actually burned the tokens. On one real session, 66% of spend ran across roughly 147 subagents, invisible in the parent total.
Subagent right-sizing breaks a window's cost down per subagent and flags two structural shapes worth a second look: a premium model dispatched for a tiny task, and a subagent handed far more context than its output suggests it needed. It reports the spend concentrated in those flagged subagents so you know where to look, not a savings number it cannot honestly promise.
How it differs
Subagent right-sizing is not Downsize.
Downsize classifies whole sessions by structural shape and flags the ones a cheaper model could plausibly handle. Subagent right-sizing works one level down: it groups spans by subagent within a session, so a heavy parent that looks fine in aggregate can still surface individual over-powered subagents inside it.
How it works
Group every span by (session_id, sub_agent_id). The sub_agent_id column is populated only by the Claude Code backfill path, derived from the on-disk transcript's agentId / isSidechain fields, so subagents from other runtimes (Codex, the Python SDK, generic OTLP) carry NULL and are excluded. Aggregate token counts and cost per subagent group; no prompt content is read.
Check each group whose spend clears a $0.05 noise floor against two independent structural criteria. over_powered: ran on a premium (Opus-tier) model, produced fewer than 2,000 output tokens, and made 5 or fewer tool calls. over_provisioned: was handed 50,000+ input plus cache-read tokens yet still produced fewer than 2,000 output tokens. A subagent can carry both flags. Report the flagged spend and its structural reason; you decide whether to re-dispatch it differently.
What you do with it
Recommendations land in your existing tools: the terminal, an MCP-capable agent, or an exportable config.
- CLI
tj optimize subagentClaude Code sessions only; other runtimes carry no subagent id
- MCP
surfaces in get_optimize_report