Support configurable prompt cache TTL for subagent launches

Problem

Multi-agent workflows (like Planner-Worker-Judge orchestration) launch 17+ subagents over 20-30 minutes. Same-type agents share 95%+ of their system prompt prefix, but the 5-minute prompt cache TTL forces repeated cache_creation_input_tokens charges every time the window expires between launches of the same agent type.

In measured runs, subagent cache_write is $3.52 out of $10.51 total (33% of cost) — the single largest cost line item. Most of this is re-caching identical system prompts because agent launches of the same type are spaced 6-10 minutes apart.

Context

Anthropic's API supports extended cache TTLs (up to 1 hour via cache_control.ttl), but Claude Code does not expose this setting. Users have no way to control the TTL used when Claude Code constructs API calls for subagent system prompts.

Proposed solution

A configurable cache TTL for subagent launches, either:

1. Global setting in settings.json:

``json
{ "subagentCacheTtl": 3600 }
``

1. Per-agent setting in agent definition files (~/.claude/agents/*.md frontmatter):

``yaml
cacheTtl: 3600
``

1. Per-invocation via the Agent() tool parameter:

``
Agent({ cacheTtl: 3600, ... })
``

Option 1 is simplest. Option 2 allows fine-grained control (long TTL for frequently reused agents, default for one-off agents).

Impact

With a 30-minute TTL, same-type subagents in a typical PWJ run would get cache hits instead of cache writes. Estimated savings: ~$1.50-2.00/run (15-20% of total cost), with zero changes to workflow logic.

Cost data from production runs

| Metric | Value |
|--------|-------|
| Total run cost | $10.51 |
| Subagent cache_write | $3.52 (33%) |
| Subagent cache_read | $2.12 (20%) |
| Total subagent launches | 17-19 |
| Agent types | 3 (planner, worker, judge) |
| Run duration | ~25 minutes |
| Avg gap between same-type launches | 6-10 minutes |