12시간 Codex 캐시가 기본 설정이 아님

세션에서 토큰이 줄줄 새길래 고객센터에 물어봤거든. 알고 보니 12시간 캐시가 기본 설정이 아니고, 이걸 설정하면 비용이 더 나온다네.

Codex 세션에서 프롬프트 캐시가 날아가는 문제 좀 조사해 줘.

2시간 33분, 9시간 53분 동안 유휴 상태가 지난 뒤에 클라이언트가 WebSocket 연결을 다시 열었어(connection_closed). 두 요청 모두 캐시된 토큰을 13,184개밖에 인식 못 해서, 총 285,611개의 입력 토큰이 캐시되지 않고 그대로 날아갔어.

모델이랑 설정은 그대로였고, 컨텍스트 압축 같은 것도 없었음.

이 세션이 발표된 12시간 캐시 유지 기능을 제대로 쓰고 있었는지, 왜 캐시 재사용이 안 됐는지, 그리고 내 사용량 제한에는 정확히 어떤 영향이 있었는지 확인해 줘.

The assistant said:

저는 AI 기술 지원 에이전트입니다. 특정 WebSocket 세션에 직접 접근하거나 서버 측에서 response_id 두 개를 조회할 권한은 없지만, API 데이터를 써서 원인이 뭔지, 사용량 제한에 어떤 영향을 줬는지 확인하는 방법은 알려줄 수 있습니다.

• 12시간 유지는 기본값이 아닙니다: 새로운 캐싱 옵션을 지원하는 모델(GPT-5.6+ 이상)의 경우, prompt_cache_options.ttl: "12h"를 명시적으로 설정해야 합니다. 안 그러면 기본값인 "30m"이 적용됩니다.

• 연결이 끊겼다 다시 붙으면 캐시 재사용이 보장되지 않습니다: 캐시가 적중하려면 프롬프트 접두사가 완전히 똑같아야 하고, 캐시 항목을 들고 있는 서버로 라우팅되어야 합니다. WebSocket 연결을 닫았다가 다시 열면 연결 기반의 연속성 상태(프롬프트 캐싱과는 별개 메커니즘)가 날아가기 때문에, 프롬프트나 모델을 안 바꿨어도 connection_closed 이후에는 캐시 재사용률이 떨어질 수 있습니다.

• 확실한 증거로 원인 파악하는 법: prompt_cache_options.comparison_response_id를 이전 응답(기준점)의 ID로 설정하고 결과값에서 prompt_cache_diagnostics를 확인해 보세요(예: model_changed, tools_changed, service_tier_changed, input_changed 등). 실제 캐시 사용량은 usage.input_tokens_details.cached_tokens를 통해 측정됩니다.

• 제한 및 비용 영향: 프롬프트 캐싱을 쓴다고 해서 사용량 제한(TPM)에 들어가는 토큰 수가 줄어드는 건 아니지만, 입력 토큰 비용에는 영향을 줍니다. 각 응답마다 usage.input_tokens, usage.input_tokens_details.cached_tokens, 그리고 해당되는 경우 cache_write_tokens를 비교해 보세요.

두 응답 ID에 대한 model, service_tier, 전체 usage 객체 정보를 주고, prompt_cache_options(모드/ttl/키)를 어떻게 설정했는지 알려주시면, 데이터가 뭘 의미하는지 그리고 재연결 후에 왜 cached_tokens 값이 낮게 나오는지 자세히 설명해 드릴게요.