OpenAI 12시간 프롬프트 캐싱: 2.5× 쓰기 비용의 손익분기점
긴 간격을 두고 재사용하는 고정 프리픽스에는 12시간 캐시를 적용하고, 바뀌는 세션 내용은 30분 캐시나 일반 입력으로 처리하세요. TTL을 혼합한 Responses API 요청을 구성하고 usage로 입력 요금을 계산하며 Codex, Work, Anthropic의 캐싱과 구분하는 방법을 설명합니다.
목차
OpenAI 12시간 프롬프트 캐싱은 에이전트가 긴 간격을 두고 재사용하는 고정된 앞부분, 즉 프리픽스에 적용하고, 바뀌는 세션 내용은 30m으로 유지하거나 캐시 쓰기 대상에서 제외하세요. 다른 선택지에서 요청마다 새로운 30m 쓰기가 필요하다면, 12h에 한 번 쓰는 방식은 프리픽스가 계속 일치한다는 조건에서 세 번째 요청, 즉 두 번째 재사용부터 더 저렴합니다. 30m에서도 계속 캐시가 적중한다면 유효기간을 늘려도 읽기 요금은 내려가지 않고 비용만 추가됩니다.
30m과 12h의 요금은 얼마인가요?
12h는 기본 캐시 쓰기 요금의 두 배를 내고 캐시 입력 요금을 적용받는 기간을 늘리는 옵션입니다. OpenAI는 2026년 10월 20일 API 변경 내역에서 Responses용으로 이 옵션을 발표했습니다. 프롬프트 캐싱 가이드에 명시된 GPT-5.6 이후 모델의 규칙은 다음과 같으며, 확인 기준일은 2026-10-24입니다.
| 입력 과금 유형 | 일반 입력 요금 대비 배수 | GPT-6.1 Sol, 1M tokens당 USD |
|---|---|---|
| 일반 입력 | 1× | $2.00 |
기본값인 30m 쓰기 | 1.25× | $2.50 |
12h 쓰기 | 2.5× | $5.00 |
| 캐시 읽기, 두 유효기간 모두 동일 | 대부분의 모델은 0.1×, GPT-6.1 Sol은 0.05× | $0.10 |
표의 쓰기 요금은 합계 요금입니다. 12h 쓰기로 청구되는 토큰은 일반 입력의 2.5×를 지불하며, 일반 입력 요금에 2.5×를 추가로 더하는 방식이 아닙니다.
달러 금액은 gpt-6.1-sol의 현재 OpenAI Standard 요금을 기준으로 합니다. 입력이 272K 토큰 이하인 프롬프트이며, 지역별 처리에 따른 할증은 없는 조건입니다. 출력 요금은 1M tokens당 $10.00입니다. 더 긴 프롬프트, 다른 서비스 등급, 지역별 처리에는 다른 요금이 적용될 수 있으므로 아래 계산을 사용하기 전에 해당 모델 요금 조건을 확인하세요.
재사용할 프리픽스 자체에 가시 입력 토큰이 최소 1,024개 있어야 합니다. 요청 전체가 크더라도 변하지 않는 앞부분이 짧다면, 그 앞부분이 자동으로 캐싱 요건을 충족하는 것은 아닙니다.
더 비싼 쓰기 요금은 언제 이득인가요?
유효기간을 늘려서 피할 수 있는 쓰기 횟수를 계산하세요. B는 변하지 않는 프리픽스의 일반 입력 비용, n은 전체 요청 수, r은 읽기 요금 배수, k는 최초 쓰기를 포함한 30m 쓰기 횟수입니다.
매번 쓰거나 캐시에 적중할 때 프리픽스 전체가 포함되고, 12h는 한 번 쓴 뒤 계속 읽기에 성공한다고 가정하면 다음과 같습니다.
12h cost = B × [2.5 + (n - 1) × r]30m cost = B × [1.25 × k + (n - k) × r]No-cache cost = B × n
r = 0.1과 r = 0.05 모두 장기 캐시는 n = 3부터 캐시를 쓰지 않는 일반 입력보다 저렴합니다. 기본 캐시와 비교하면, 12h에서 여전히 쓰기 한 번만 필요한 동안 k >= 3이 되어야 더 저렴해집니다. 단순히 적중 횟수가 많아지는 것이 아니라, 최초 쓰기 이후 발생할 단기 캐시 쓰기를 두 번 피해야 한다는 뜻입니다.
두 정책 모두 한 번 쓴 뒤 모든 요청에서 캐시가 적중한다면 12h는 계속 1.25 × B만큼 더 비쌉니다. 따라서 짧은 간격으로 이어지는 대화에서는, 중간에 다시 쓰기가 필요한 긴 공백이 발생하지 않는 한 장기 쓰기 요금을 지불할 이유가 적습니다.
30분보다 긴 공백은 비용을 줄일 기회가 될 수 있지만, 캐시 미스가 발생한다는 증거는 아닙니다. OpenAI는 최소 유효기간이 지나도 항목을 유지할 수 있으며, 30m 캐시 읽기는 유효기간을 최소 30분 더 갱신합니다. 기존 워크로드의 비용을 예측할 때는 실제로 관측한 쓰기 횟수를 사용하세요.
구체적인 추정치로, GPT-6.1 Sol의 Standard 요금에서 10,000토큰 프리픽스를 사용한다고 가정하겠습니다. 이때 B = $0.02, r = 0.05입니다. 프리픽스를 바꾸지 않고 0시간째부터 11시간째까지 매시간 한 번씩 총 12번 요청합니다.
| 가정한 캐시 동작 | 12번 요청에 대한 프리픽스 입력 비용 |
|---|---|
| 캐시 없음: 일반 입력 12회 | $0.240 |
30m: 12번 요청 모두 쓰기 필요 | $0.300 |
12h: 쓰기 한 번, 읽기 11회 | $0.061 |
30m: 쓰기 한 번, 읽기 11회 | $0.036 |
30m의 두 행은 요청 간격만으로 절감액을 결정할 수 없는 이유를 보여 줍니다. 모든 요청에 쓰기가 발생한다는 행은 가정이며, 매시간 요청하면 반드시 나타나는 결과가 아닙니다. 이 추정치에는 바뀌는 뒷부분, 출력 토큰, 도구 사용 요금이 포함되지 않으며 실제 청구서를 측정한 값도 아닙니다.
요청 전체에 12h를 설정하면 왜 더 비싸질 수 있나요?
요청 수준의 prompt_cache_options.ttl: "12h"는 암시적 브레이크포인트에도 적용됩니다. 브레이크포인트는 캐싱할 프리픽스의 끝을 지정하는 경계입니다. 기본값인 mode: "implicit"에서는 이전 프리픽스를 저렴하게 읽더라도, 대화에 새로 추가된 캐싱 가능 내용에 매 턴 2.5× 쓰기 요금이 발생할 수 있습니다.
도구 결과와 사용자 메시지가 계속 쌓이는 에이전트에서는 늘어나는 뒷부분의 비용이 고정된 앞부분에서 얻는 절감액을 넘어설 수 있습니다. 캐시 적중률이 높다는 사실만으로 해당 정책이 경제적인지는 알 수 없습니다.
내용의 재사용 방식에 맞춰 다음 중 하나를 선택하세요.
- 고정된 공유 자료와 재사용할 세션 컨텍스트: 요청 기본값을
30m으로 설정하고 공유 자료의 끝에12h재정의를 둡니다. - 고정 자료와 일회성 질문:
mode: "explicit"를 사용하고 바뀌는 질문은 마지막 명시적 브레이크포인트 뒤에 둡니다. - 최신 컨텍스트를 곧 재사용할 대화: 요청 기본값
30m과mode: "implicit"를 유지하면서 공유 프리픽스에는12h브레이크포인트를 설정합니다.
브레이크포인트는 그 앞에 있는 프리픽스 전체를 포함합니다. 캐시가 없는 첫 요청에서 2,000토큰 지점에 12h, 5,000토큰 지점에 30m 브레이크포인트가 있다면 2,000토큰은 장기 쓰기, 나머지 3,000토큰은 단기 쓰기로 청구됩니다. 대신 뒤쪽의 5,000토큰 경계에 12h 브레이크포인트를 두면 5,000토큰 모두에 장기 쓰기 요금이 적용됩니다. 각 토큰은 자신을 포함하는 쓰기 설정 중 가장 긴 유효기간의 요금으로 한 번만 청구됩니다.
유효기간을 바꿀 때는 두 가지 규칙도 확인해야 합니다. 아직 유효한 30m 캐시를 12h로 늘리면 이전 쓰기 비용을 차감하지 않고 새로운 장기 쓰기 요금을 부과합니다. 30m 요청이 아직 유효한 12h 캐시의 프리픽스를 읽으면 해당 토큰에는 읽기 요금만 적용되며, 12시간이 처음부터 다시 시작되거나 쓰기 요금이 추가되지 않습니다. 이러한 범위 중첩과 유효기간 규칙을 고려해 큰 프리픽스를 처음 캐시에 쓰기 전에 정책을 정하세요.
하나의 Responses 요청에 12h와 30m을 함께 설정하기
요청 기본값을 30m으로 설정하고, 명시적 브레이크포인트로 공유 참조 자료, 세션 컨텍스트, 현재 질문을 구분하세요. 다음 예시는 OpenAI의 Responses API에 직접 요청을 보내고, 생성된 텍스트와 요금 확인에 필요한 사용량을 함께 출력합니다.
Bash, curl, jq와 gpt-6.1-sol에 접근할 수 있는 OpenAI API 키가 필요합니다. 현재 디렉터리에 다음 파일을 준비하세요.
shared-context.md: 하루 동안 재사용할 유용한 엔지니어링 지침과 참조 자료입니다. 가시 입력 토큰이 최소 1,024개 있어야 합니다.session-context.md: 이번 세션에서 재사용할 현재 배포 또는 풀 리퀘스트의 컨텍스트입니다.
예제의 두 호출 사이에는 두 파일을 바꾸지 마세요. read가 입력을 기다리면 API 키를 붙여 넣고 Enter를 누릅니다. 입력한 키는 터미널에 표시되지 않습니다. 인증 방식은 OpenAI API 빠른 시작 가이드를 따릅니다.
set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY
cache_request() {
jq -n \
--rawfile shared ./shared-context.md \
--rawfile session ./session-context.md \
--arg question "$1" \
'{
model: "gpt-6.1-sol",
service_tier: "default",
reasoning: {effort: "low"},
prompt_cache_options: {mode: "explicit", ttl: "30m"},
input: [
{
role: "developer",
content: [{
type: "input_text",
text: $shared,
prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
}]
},
{
role: "user",
content: [
{
type: "input_text",
text: $session,
prompt_cache_breakpoint: {mode: "explicit"}
},
{type: "input_text", text: $question}
]
}
]
}' |
curl --silent --show-error --fail-with-body \
https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @- |
jq '{id, status, service_tier,
text: ([.output[]? | .content[]? |
select(.type == "output_text") | .text] | join("\n")),
usage, error}'
}
cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."첫 번째 콘텐츠 블록은 "ttl": "12h"로 요청 기본값을 재정의합니다. 세션 블록은 자체 TTL을 생략하므로 "30m"을 상속합니다. 이 요청은 명시적 브레이크포인트만 사용하기 때문에 마지막 질문에는 캐시 쓰기 요금이 발생하지 않습니다. 다만 일반 입력 요금은 그대로 발생합니다.
캐싱 요건을 충족하며 아직 캐시에 없는 프리픽스라면, 첫 번째 완료 응답의 usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens에 장기 쓰기가 표시되어야 합니다. 프리픽스가 계속 일치하고 캐시가 유효하면 두 번째 응답에는 cached_tokens > 0이 표시되고 새로운 장기 쓰기는 없어야 합니다. 반환된 text에는 실제로 사용할 답변이 들어 있습니다. 즉시 반복 호출하면 프리픽스 일치 여부와 과금을 확인할 수 있으며, 긴 공백에서의 절감 효과는 실제 운영 간격으로 요청을 보내 평가하세요.
400 invalid_request_error가 발생하면 TTL 문자열이 정확한지, 선택한 모델과 Responses 엔드포인트가 맞는지 확인하세요. 두 호출 모두 캐시 토큰이 0이라면 먼저 프리픽스 길이를 확인하고, 이어서 파일, 모델, 설정, 브레이크포인트 위치를 비교합니다. 도구를 추가하면서 도구 정의를 바꾸는 경우를 포함해 공유 브레이크포인트 앞의 내용이 달라지면 재사용이 안 될 수 있습니다.
캐시를 사용하지 않는 기준 비용을 확인하려면 mode: "explicit"를 유지하고 모든 prompt_cache_breakpoint를 제거하세요. 공식 요청 스키마는 명시적 모드에서 마커가 없으면 프롬프트 캐싱을 사용하지 않는다고 설명합니다.
usage로 입력 요금 계산하기
일반 입력, 캐시 읽기, 두 종류의 쓰기를 서로 겹치지 않는 항목으로 계산하세요. 전체 쓰기 토큰 수인 cache_write_tokens에는 이미 ttl_30m_tokens와 ttl_12h_tokens가 포함되어 있으므로 세 값을 모두 과금하면 쓰기를 중복 계산하게 됩니다. 12h로 업그레이드하면서 청구된 토큰은 쓰기에 포함되며 cached_tokens에서는 제외됩니다.
OpenAI의 사용량 과금 예제는 다음과 같은 구조입니다.
{
"usage": {
"input_tokens": 12000,
"input_tokens_details": {
"cached_tokens": 4000,
"cache_write_tokens": 7000,
"cache_write_tokens_details": {
"ttl_30m_tokens": 3000,
"ttl_12h_tokens": 4000
}
}
}
}I는 input_tokens, R은 cached_tokens, W30과 W12는 각각 두 TTL의 쓰기 토큰 수라고 하겠습니다. 일반 입력은 U = I - R - W30 - W12로 계산하며, 이 예시에서는 1,000토큰입니다.
일반 입력 요금 P의 단위가 1M tokens당 USD이고 캐시 읽기 요금 배수가 r이면 다음 공식을 사용합니다.
Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000
문서의 가상 요금 P = $1, r = 0.1을 적용하면 다음과 같습니다.
(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515
같은 사용량에 GPT-6.1 Sol의 Standard 요금을 적용하려면 P = $2, r = 0.05를 대입합니다. 입력 요금은 $0.02990입니다. 출력과 그 밖에 적용되는 요금은 별도로 더하세요. 이 계산은 입력 과금만 분리한 것으로, 코딩 작업 하나를 완료하는 전체 비용을 추정한 것은 아닙니다.
응답 ID, 시간, 모델, 실제로 적용된 service_tier, 각 토큰 수를 로그에 남기세요. 클라이언트가 TTL별 내역을 생략한다면 서로 다른 유효기간의 비용을 계산하기 전에 원본 JSON을 확인해야 합니다. 카운터가 없다는 사실은 쓰기가 없었다는 증거가 아닙니다. 한 번의 적중률만 보고 정책을 선택하지 말고, 대표적인 하루 동안 발생한 달러 비용을 합산해 비교하세요.
12h는 캐시 읽기 요금이 적용되는 최소 유효기간을 뜻합니다. 데이터 삭제 시한을 지정하거나 최대 데이터 보존 정책을 바꾸지 않으며, 모든 요청의 지연 시간이 줄어든다고 보장하지도 않습니다.
Codex, Work, Anthropic의 캐싱과는 무엇이 다른가요?
API 과금과 로그인한 제품에서 제공하는 사용 한도는 구분해야 합니다. Tibo Sottiaux는 2026년 10월 21일 게시물에서 로그인한 Codex 및 Work 사용자의 캐시를 “forever”, 즉 영구적으로 유지한다고 설명하고, 예전 대화로 돌아와도 캐시가 적중한다고 말했습니다. 이 발언은 해당 제품 세션에 관한 것으로, API의 TTL을 정의하거나 구독을 무제한으로 만드는 것은 아닙니다.
Codex 공식 요금 문서는 크레딧 기반 Codex 과금에는 별도의 캐시 쓰기 요금이 없고, API 키를 사용하는 경우에는 API 요금이 적용된다고 설명합니다. API 키로 Codex를 실행한다면 로그인한 제품에 대한 설명을 적용하지 말고 API 과금 규칙에 맞춰 예산을 잡으세요.
2026-10-24 기준 Claude 문서의 선택지는 쓰기 요금이 1.25×인 기본 5분 캐시와 쓰기 요금이 2×인 선택형 1시간 캐시입니다. 읽기 할인은 모델마다 다릅니다. Claude Opus 5.5와 Sonnet 5.5는 0.05×를 적용하며, 다른 요금은 Anthropic 요금표에 나와 있습니다. 읽기에 성공하면 추가 쓰기 할증 없이 유효기간이 갱신되며, TTL을 혼합한 요청에서는 유효기간이 긴 블록을 짧은 블록보다 앞에 배치해야 합니다.
이미 지원 모델을 사용하는 애플리케이션에서 수 시간의 공백이 반복된다면 OpenAI의 고정 프리픽스 12h 정책부터 시험해 보세요. 계속 활성 상태인 세션이라면 짧은 캐시부터 시작하는 편이 낫습니다. 공급자를 비교할 때는 실제 기본 요금, 출력 사용량, 관측한 캐시 동작을 함께 봐야 합니다. 유효기간과 쓰기 배수만으로 작업 완료 비용이 더 저렴한 공급자를 결정할 수는 없습니다.
