[BUG] Interactive sessions write the 5-minute prompt cache from session start, while `claude -p` on the same account writes 1-hour (2.1.296, Team seat, survives `/login`)
What's wrong
Since 2026-10-12 at about 18:18 UTC, every newly started interactive session writes its main-conversation prompt cache under the 5-minute TTL. Headless claude -p runs on the same account, machine, version and model still write under 1 hour. The account is a subscription within its included usage, so per the prompt-caching docs both should get 1 hour. Interactive turns, -p runs and SDK turns are documented as the same "main conversation" bucket.
Evidence (from local transcripts, message.usage.cache_creation on non-sidechain assistant rows)
| Case | Entrypoint | Result |
|---|---|---|
| Interactive sessions started before 2026-10-12 18:18 UTC | cli | 1h; they kept writing 1h until they went idle (last at 19:56 UTC) |
| Every interactive session started after 18:18 UTC (5 sessions) | cli | 5m from the first turn, 1h always 0 |
| claude -p runs after 18:18 UTC (4 runs, latest 2026-10-13 04:54 UTC) | sdk-cli | 1h |
| Interactive session in a plain terminal, outside tmux and any launcher (2026-10-13 05:05 UTC) | cli | 5m |
| Interactive session after /login re-authentication (2026-10-13 05:08 UTC) | cli | 5m |
- No session ever changed bucket partway through, across 14 sessions, so the TTL looks fixed at session start.
usagemetadata is identical on 1h and 5m rows:service_tier: "standard",speed: "standard",fallback_credit: null.- In the transcripts from the four days up to the onset (2026-10-09 to 2026-10-12 18:18 UTC), every main-thread cache write was 1h.
Environment
- Claude Code 2.1.296 (native install) on Linux (WSL2); model
claude-opus-5-5. The same version was in use on both sides of the onset - Auth: claude.ai subscription via
/login(OAuth). Team seatteam_tier_1; user rate-limit tierdefault_claude_max_5x ~/.claude.json:oauthAccount.hasExtraUsageEnabled: true,cachedExtraUsageDisabledReason: "out_of_credits"(still present after/login)- Not near the 5-hour or weekly limits
- None set:
ANTHROPIC_API_KEY,CLAUDE_CODE_USE_*,CLAUDE_CODE_OAUTH_TOKEN,CLAUDE_CODE_PROMPT_CACHE_TTL,FORCE_PROMPT_CACHING_5M,ENABLE_PROMPT_CACHING_1H,DISABLE_TELEMETRY,CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC. NopromptCacheTtlin user or managed settings - Cached
tengu_prompt_cache_1h_config.allowliststill includesrepl_main_thread*andsdk
Steps to reproduce (on an affected account)
- Run
claudeinteractively, send one turn and exit. - Run
claude -p "Reply with OK"in the same directory. - Compare the buckets:
``sh`
jq -c 'select(.type=="assistant" and .isSidechain!=true and .message.usage.cache_creation)
| [.timestamp, .entrypoint, .message.usage.cache_creation.ephemeral_1h_input_tokens,
.message.usage.cache_creation.ephemeral_5m_input_tokens]' ~/.claude/projects/<dir>/<session>.jsonl
Interactive shows and -p shows [...,"sdk-cli",N,0]`.
Expected
Interactive sessions on a subscription within included usage write the main conversation under the 1-hour TTL, as -p does.
Possibly related
- #46829: Anthropic support described an overage-latch bug, fixed in 2.1.90, in which a session started while the seat was in overage kept 5m on the main loop. The latch-at-start shape matches this report, but this seat is not in overage.
- #79337, #80749, #93840: the interactive client misjudged usage-credit entitlement while
-pworked on the same account. One investigator traced it to per-session flag evaluation, and one report involvedout_of_credits.
Question
Does the interactive startup path consult usage-credit state (here, an org-level out_of_credits) when choosing the main-conversation TTL, and treat it as "drawing on usage credits"? Or has the overage latch regressed?
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Reproduced by a second user in the same Team org, 2026-10-13.
claude-opus-5-5, entrypointcli(interactive).ephemeral_5m_input_tokens> 0 andephemeral_1h_input_tokens: 0, from the first turn.One extra data point: the harness system prompt in that same session tells the model the session "uses a 1-hour Anthropic prompt-cache TTL". So the client appears to believe it is requesting 1h, while the usage shows 5m writes. That points to the request being sent or handled differently, not to the account being in usage overage.
Checked with:
Follow-up from the reporter's side:
"promptCacheTtl": "1h"switches a running interactive session toephemeral_1hwrites within seconds. The interactive client's default TTL choice is what lands on 5m, even though the system prompt says "1-hour TTL".cachedExtraUsageDisabledReasonwent fromout_of_creditstoorg_level_disabled), a fresh interactive session with user settings excluded (--setting-sources project,local) still wrote 5m.Same symptom here, with a data point on behavior rather than just the label. Claude Code 2.1.296, Linux, Team seat, interactive
clisessions. Our 1h writes ended around 2026-10-12 15:15 CT, and 5m writes have continued since (a few sessions between about 14:00 and 15:10 CT that day were still 1h, so onset wasn't clean for us). Headlesssdk-cliruns on the morning of 10-13 were still 1h. No TTL setting or env var is set, and/usageshowed 39% of the session and 7% of the week used.To test whether the 5m label matches behavior, I ran a controlled probe: a background session in an empty directory with three one-shot cron wakes, each a tiny no-tool turn. All writes were labeled
ephemeral_5m:| Idle before wake | cache_read | cache_write |
|---|---|---|
| 13.4 min | 56,368 | 30 |
| 30.0 min | 56,398 | 28 |
| 70.0 min | 27,378 (shared prefix only) | 29,076 |
So 5m-labeled writes survived 30 minutes and expired by 70, which looks like a 1h-like lifetime under a 5m label. The 27,378 read at 70 minutes is the same shared system-prompt prefix the probe's first call read, so the conversation itself was rebuilt. Interactive sessions on 10-12 and 10-13 show the same: idle gaps of 5–20 minutes and one of about 30 with full cache reads despite 5m labels.