Greptile Summary

This PR fixes a bug where explicit cacheRetention: "long" on custom anthropic-messages providers was silently downgraded to 5-minute ephemeral cache because the TTL gate required an allowlisted hostname. The fix adds a short-circuit: if cacheRetention is explicitly "long", the 1h TTL is applied regardless of hostname, while implicit/env-driven long retention still requires an allowlisted endpoint. The implementation is minimal and correct, with three new test cases covering explicit long, env-driven long, and explicit short retention on custom hosts.

Confidence Score: 5/5

Safe to merge — minimal, targeted fix with correct logic and comprehensive regression tests.

The logic change is provably correct across all four input cases (explicit long, env-driven long, explicit short, none). Tests cover the new behavioral paths. No P0/P1 findings.

No files require special attention.

_{Reviews (1): Last reviewed commit: "Merge branch 'main' into codex/anthropic..." | Re-trigger Greptile}

@hxy91819 PTAL

The security bot's concern seems overstated for this use case. When a user explicitly sets cacheRetention: "long", they've already made a deliberate configuration choice — they know they're routing traffic through a custom/proxy host and have accepted that relationship. The previous silent downgrade to 5-minute TTL is the surprising behavior here, not the fix.

The allowLongTtlOnCustomHosts flag suggestion just adds friction without meaningful security benefit: anyone who configures cacheRetention: "long" on a custom host is presumably already aware of and trusting that host. Requiring a second opt-in flag doesn't change the trust model, it just makes the feature harder to use.

Option 3 from the original issue is the right call — honor explicit user intent. The allowlist can remain as the default guard when cacheRetention is unset or "auto".

Review: Honor explicit long Anthropic cache TTL on custom hosts

APPROVED — this is completing an already-open capability path, not introducing new behavior.

Custom anthropic-messages providers with explicit cacheRetention: "long" already emit cache_control: { type: "ephemeral" } (5-min TTL) via #59049. This PR just adds the ttl: "1h" variant that was incorrectly blocked by the hostname allowlist. The explicit-vs-implicit distinction is clean: cacheRetention === "long" bypasses the allowlist (explicit opt-in), while PI_CACHE_RETENTION=long still requires allowlist membership (conservative default preserved).

Why the gap exists — historical investigation

The allowlist and custom-provider support evolved independently:

1. fix(agents): honor cacheRetention for custom anthropic providers #59049 — resolveCacheRetention() extended to admit custom-anthropic-api providers with explicit config. Door opened.
2. 067496b129 — Policy logic refactored into anthropic-payload-policy.ts with baseUrl.includes("api.anthropic.com"). Wall built — only Anthropic official endpoints get 1h TTL.
3. fix(cache): enable prompt cache retention for Anthropic Vertex AI #60888 — Wall upgraded to proper isLongTtlEligibleEndpoint() allowlist + Vertex AI hostnames. Window added, but the custom-anthropic-api family from step 1 was not accounted for.
4. This PR — Adds explicit-config escape hatch. Door and wall aligned.

The gap was not an intentional security boundary — it was an alignment miss between two layers implemented at different times.

No blocking issues. Optional nice-to-have: warn-level log when ttl: "1h" is applied to a non-allowlisted endpoint, to help operators validate the configuration is intentional.

Note: Do not merge until after the next release.

Merged via squash.

• Prepared head SHA: 0ffde15713b68c6953da826fca06a67000086b9b
• Merge commit: 4bacdc882454fa6ae557d6522f778b630cb4c4a2

Thanks @MonkeyLeeT!