persona: 1h prompt-cache TTL on BYOK narration blocks

[shauntrennery]

Motivation

Narration traffic is bursty: events cluster while an agent is working, with gaps in between. Whenever a gap exceeds the default 5-minute cache TTL, the next event rewrites the ~11k-token cached system block at 1.25× input price.

Nine days of my own BYOK cost data (Anthropic console export, Haiku 4.5) shows how much that adds up:

Line	Cost	Share of narration spend
input_cache_write_5m	$4.73	44%
input_no_cache	$3.30	30%
input_cache_read	$1.51	14%
output	$1.30	12%

At Haiku rates that write line is ~340 rewrites of the block over 9 days (~38/day) — the cache spends most of the day expiring and rebuilding.

Change

Both BYOK cache_control blocks in persona.py (harness path + _byok_haiku_rewrite) now use {"type": "ephemeral", "ttl": "1h"}. The managed path is untouched — heard-api sets its cache_control server-side, so mirroring this there is a separate (heard-api) decision.

Math

• 5m writes cost 1.25× base input; 1h writes cost 2×. Break-even is ~1.6 rewrites/hour.
• The TTL refreshes on every hit, so a continuous session is one 2× write, then 0.1× reads — "1h" effectively means "all day" during active use. Residual cold writes are only the first event after a >1h gap.
• Worst case (user so sparse every gap exceeds 1h): +0.8¢ per cold write vs today. That's why it's a flat default rather than a config key.

Expected effect on the data above: the write line roughly halves (~20% off total narration spend). 1h TTL is GA — no beta header, works with the existing request shape.

Validation

• ruff clean, 946 tests pass.
• Running live on my daemon since the change — startup warmup logged cache_write=10630 as the single 1h entry; happy to follow up with a before/after haiku_cache log comparison after a few days of real use.

🤖 Generated with Claude Code