CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL: model choice vs Sume spend gates
Claude Code 2.1.296 can run every workflow agent on one model. Sume's idempotency_key, dry_run and max_spend_credits gates do not change with the model.

CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL, added in Claude Code 2.1.296 on October 9, 2026, runs every workflow agent on one model while other subagents keep theirs (changelog read 2026-10-13). If those workflow agents call Sume, switching to a cheaper model changes your token bill, not Sume's rules: paid tools still need an idempotency_key, and dry_run and max_spend_credits work the same on any model.
What does the variable do?
The changelog entry is one line: it runs every workflow agent on one model while other subagents keep theirs. The same release also priced Sonnet 5.5 cache reads at $0.10 per million tokens in /cost, the status line and --max-budget-usd (was $0.20), and Claude Code 2.1.293 added Claude Haiku 5.5 as the default Haiku at $0.10 and $0.50 per million tokens, with $0.50 and $2.50 above 100K-token prompts (all read 2026-10-13). I did not find the variable on the environment variables page I fetched, so confirm the accepted values in your install.
| Question | Claude Code side | Sume side |
|---|---|---|
| Which model runs the workflow agents? | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL | Not involved; Sume tools do not depend on the caller's model |
| Which model runs other subagents? | Their own model setting | Not involved |
| What stops a duplicate paid job? | Nothing built in | idempotency_key is required on write and paid tools |
| What previews cost? | Not applicable | dry_run=true returns an estimate in usage.credits |
| What caps a call? | --max-budget-usd counts Claude Code's own cost | max_spend_credits is an enforced cap when provided |
Should workflow agents use a small model for Sume work?
A workflow agent that only submits jobs, polls jobs_status and writes ids down is a good fit for a small, cheap model, because the expensive work happens in Sume's render, not in the agent's tokens. The risk is not capability but fan-out: many workflow agents can submit at once, and they all share your workspace's generation capacity.
Keep the paid step narrow. Give only one agent a Sume server with write access, or use a read-only OAuth scope for the others; with mcp:read only, write and paid calls return insufficient_scope.
What to set before turning workflows on
- Have a parent generate the
idempotency_keyper intended job, so a retried agent reuses it. - Run
dry_run=truefirst and readusage.credits. - Pass
max_spend_creditson every paid call. - Use
generation_admission_previewbefore an expensive burst, as the MCP tools page recommends. - Treat
--max-budget-usdas a limit on Claude Code's cost only; it is not a Sume limit.
What this does not cover
Sume does not know which model called it, so it cannot enforce a model policy. If you need that, enforce it in Claude Code settings. I also have not measured any workflow run here; the figures above are only the prices and defaults the changelog lists.
Sources
Related posts
More in Developers
- Claude MCP connector denylist: switch off Sume's paid tools
Enable all Sume tools in an mcp_toolset, then disable the paid ones by name. Anthropic recommends denylisting write tools for read-only assistants.
- Claude MCP connector supports tool calls only: how Sume results arrive
The Messages API connector supports only MCP tool calls, not resources or prompts. Fetch Sume job results with the jobs_result tool, not a resource read.
- Claude MCP connector is not ZDR-eligible: check before sending briefs
Anthropic lists the MCP connector beta as not eligible for zero data retention. If your org requires ZDR, do not route Sume briefs through it.
- mcp_toolset cache_control: cache the Sume tool list on Haiku 5.5
An mcp_toolset accepts cache_control. Haiku 5.5 caches prompts of 512+ tokens; reads cost $0.01 per MTok up to 100,000 tokens. Set it on the toolset.
Written by Sume