[BUG] Agent team subagents do not honor 1-hour prompt cache TTL — main sessions show 100% 1h, every agent session shows 0% 1h

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

In multi-agent workflows (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), spawned subagent processes never produce 1-hour TTL cache writes, while the parent (lead) session always does. The split is bimodal and absolute: across hundreds of sessions on two independent machines, every agent session shows 0% 1-hour TTL and every main session shows 100% 1-hour TTL. There are no mixed sessions.
This means roughly 90%+ of cache-creation tokens in a multi-agent plan execution are stuck on 5-minute TTL regardless of any client-side configuration, because the heavy work happens in agent sessions. For users running multi-agent workflows, this is a structural source of inflated quota burn that's independent of any rate-limit changes.
Observed data — Machine A (WSL2, last 10 days):
Sample of agent sessions (all show 0% 1h):

agent-aef4bcf953ac29771 — 775,841 5m tokens, 0 1h tokens, 0.0%
agent-a74553372babab42a — 780,991 5m tokens, 0 1h tokens, 0.0%
agent-a53f7c81453243662 — 773,155 5m tokens, 0 1h tokens, 0.0%
agent-a5f2c4fc079d7072a — 841,764 5m tokens, 0 1h tokens, 0.0%
agent-a869a7d83c2def328 — 485,827 5m tokens, 0 1h tokens, 0.0%
(30+ additional agent sessions, all 0.0%)

Sample of main sessions (all show 100% 1h):

7778be9a-d878-4ef3-a627-5a0af90ed71f — 0 5m tokens, 661,394 1h tokens, 100.0%
98f868a4-01aa-4a72-996c-97c4e329fb4e — 0 5m tokens, 632,797 1h tokens, 100.0%
f6d1c892-9d8c-495c-b820-16e82543abbe — 0 5m tokens, 1,297,372 1h tokens, 100.0%
d70664c0-a399-4c54-a8ee-9c0ca25e28f1 — 0 5m tokens, 624,187 1h tokens, 100.0%
9fce7fcb-dcbc-4593-876c-226c7244bf6b — 0 5m tokens, 369,160 1h tokens, 100.0%

Machine A totals (142 sessions, 10 days): 279,440,203 5m tokens, 30,996,663 1h tokens — 10.0% overall, but 100% bimodal split by session type.
Machine B (separate Ubuntu VPS, separate context, last 7 days): 278,100,614 5m tokens, 5,720,735 1h tokens — 2.0% overall. Same pattern: every agent-* session 0.0%, every UUID-named session 100.0%.
What we ruled out:

Not env-var-related on main sessions: main sessions show 100% 1h without ENABLE_PROMPT_CACHING_1H being set. Whatever default is in effect for main sessions is already 1-hour.
Not server-side A/B variance (issue #46829): the bimodal-by-session-type pattern is incompatible with random server-side variance — it's perfectly correlated with whether the session is a main or an agent.
Not model-related: main and agent sessions use the same models (Opus 4.6 [1M], Opus 4.7 [1M]) on the same machine and account.
Not machine-related: reproduces on two independent machines.
Not telemetry-related: DISABLE_TELEMETRY is unset.

Hypothesized cause: the agent-spawn code path either strips environment variables when spawning the agent process, hardcodes cache_control.ttl: "5m" in the agent's API request payload, or reads TTL configuration from a code path that runs in the parent process only.

What Should Happen?

Agent team subagents should honor the same 1-hour prompt cache TTL as the parent session that spawned them. In order of preference:

Propagate TTL configuration (env var or default) from the parent Claude Code session into agent processes. The lead's ENABLE_PROMPT_CACHING_1H setting should apply to all agents it spawns, since they are conceptually part of the same workflow.
Make 1-hour TTL the default for agent sessions specifically, since agent workflows have natural multi-minute gaps and benefit most from longer TTL.
At minimum, expose a documented mechanism to configure agent TTL — e.g. a setting in ~/.claude/teams/<n>/config.json or a CLAUDE_CODE_AGENT_CACHE_TTL env var that the agent spawn path explicitly reads.

Error Messages/Logs

No error messages — this is a silent behavior issue, not a crash. The evidence is in the JSONL session logs at ~/.claude/projects/<project>/, where each assistant message includes a usage.cache_creation.ephemeral_5m_input_tokens / ephemeral_1h_input_tokens breakdown that makes the TTL tier per-call observable.
For agent-* session files, the ephemeral_1h_input_tokens field is consistently 0 across every assistant message. For main-session UUID files, the ephemeral_5m_input_tokens field is consistently 0.

Steps to Reproduce

Enable agent teams: export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Start a Claude Code session and run a workflow that spawns multiple agents (a multi-agent orchestration skill that spawns lead + impl + QA teammates).
Let the team run for any non-trivial duration (≥30 minutes).
Inspect session JSONL files in ~/.claude/projects/<project>/.
Sum usage.cache_creation.ephemeral_5m_input_tokens and usage.cache_creation.ephemeral_1h_input_tokens per session file.
Observe: files named agent-*.jsonl show only 5m tokens; files named <uuid>.jsonl (main sessions) show only 1h tokens.

Reproducible diagnostic script:
https://gist.github.com/Nikrmana/747199cf19830b6c91471c5212a71067

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown — agent sessions appear to have always shown 0% 1h TTL across the full data window (Apr 2026).

Claude Code Version

2.1.119

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Plan: Claude Max
Agent teams flag: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Multi-agent skill: custom orchestration skill spawning lead + impl + QA + arch teammates
ENABLE_PROMPT_CACHING_1H: not set in shell at time of measurement (irrelevant to the bug — main sessions show 100% 1h without it; agent sessions show 0% with or without it).
FORCE_PROMPT_CACHING_5M: unset
DISABLE_PROMPT_CACHING*: all unset
DISABLE_TELEMETRY: unset
Aggregate data over 90 days:

Machine A: 1,079 sessions, 1.97B 5m tokens, 0.13B 1h tokens (6.0% 1h overall, but 100% bimodal split by session type)

Related issues:

#16157 — General "Instantly hitting usage limits" thread (assigned: @ThariqS, @wolffiex, @whyuan-cc). This issue identifies a specific architectural cause for what some users in that thread are experiencing.
#46829 — Cache TTL silently regressed from 1h to 5m around early March 2026. Documents server-side default behavior for main sessions; this issue is orthogonal and additive — agent sessions remain stuck on 5m regardless of main-session default.
#48082 — Prompt caching TTL env var docs gap.
#38335 — Symptom report (marked invalid for lack of evidence) that this data substantiates.
#2603 — Original 1-hour cache feature request (June 2025), superseded by env vars in 2.1.108.
#16442 — Configurable prompt cache TTL via env var (closed by 2.1.108 changelog).

None of these issues address the agent-vs-main split documented here.