GPT-5.6 비용 가이드: 프롬프트 캐싱 90% 할인과 Reasoning Effort

GPT-5.6에서는 두 가지 비용 조절 수단이 동시에 바뀌었다. 캐시된 입력 요금은 입력 요금의 10%로 낮아졌다. 5.x의 할인율은 50%였다. reasoning은 기본으로 활성화되며, 50회 호출 매트릭스에서 reasoning_effort를 보내지 않았을 때 none으로 고정한 경우보다 비용이 1.5배 높았다. 답변은 동일했다. 입력 측면에서는 최대 4개의 cache breakpoint를 명시적으로 지정할 수 있다. 출력 측면에서는 effort 설정으로 reasoning에 지불할 비용을 조절한다. 출시 당일 모델인 Sol(입출력 1M token당 $5/$30), Terra($2.50/$15), Luna($1/$6)를 gateway를 통해 측정했으며, 모든 요금은 실시간 usage.cost 미터로 확인했다. 프롬프트 작성법 자체는 GPT-5.6 프롬프트 가이드를 참고하라.

TL;DR

• 캐시된 입력에는 입력 요금의 10%가 부과된다. tier별 측정값은 1M당 $0.10/$0.25/$0.50이었다. 5.x의 할인율은 50%였다.
• breakpoint를 사용하면 일부 prefix를 재사용할 수 있다. marker 뒤의 block을 변경했을 때 2,431 token 중 1,210 token에만 다시 요금이 부과됐다.
• 1,024 token 미만의 prefix는 캐시되지 않으며, 반복 요청도 아무 알림 없이 miss가 날 수 있다. hit rate는 100% 미만으로 잡고 예산을 계산해야 한다.
• cache write에는 기록된 token 기준 1.25배 요금이 부과된다. 한 번도 읽히지 않은 write는 캐시를 사용하지 않을 때보다 비싸다.
• 4개 task 매트릭스에서 reasoning_effort를 생략하면 none보다 비용이 1.5배 높았고 답변은 동일했다. 명시적으로 지정해야 한다.

OpenAI가 이 제품군을 발표한 다음 날인 2026-07-10에 Synthorai gateway(OpenAI 호환 chat completions)를 통해 측정했다. 세 모델 모두 현재 사용할 수 있으며, 새로운 caching parameter도 변경 없이 전달된다.

하나의 세대, 세 가지 tier

명명 체계가 바뀌었다. 숫자는 세대를 뜻하고, Sol, Terra, Luna는 기존 pro/mini/nano suffix를 대체하는 capability tier다. 세 모델 모두 1M-token context window와 최대 128K 출력을 지원한다. 아래 모든 요금은 알려진 token 수를 기준으로 측정한 usage.cost와 정확히 일치했다. 캐시된 입력 열도 마찬가지다.

Sol은 flagship 모델이며 gpt-5.5와 같은 가격대의 후속 모델이다. 요금표도 $5/$30로 동일하다. Terra와 Luna는 같은 세대의 경량 tier로, 각각 Sol 가격의 절반과 5분의 1이다. 기존 mini와 nano suffix가 차지하던 위치를 대신한다. token 계산 방식은 세 모델이 같다. 전송한 모든 sample에서 token 수가 동일하게 반환됐다.

문서에 나온 5.6 캐싱 동작 방식

기존 GPT caching은 한 가지 방식으로 동작했다. API가 1,024 token 이상의 반복 prefix를 자동으로 감지하고, 캐시된 부분에 절반 가격을 적용했다. provider 비교에서 GPT를 “완전 자동”으로 분류한 이유다. 5.6 caching 가이드는 이를 두 가지 mode로 바꿨다.

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

가이드에서 실제 운영에 필요한 규칙만 정리하면 다음과 같다.

• breakpoint는 캐시할 prefix의 끝을 표시한다. 해당 block과 그 앞의 모든 내용을 포함한다. 기본값인 implicit mode는 여전히 마지막 message에 breakpoint를 자동으로 배치한다. explicit mode에서는 직접 표시한 부분만 캐시한다.
• 요청당 cache write는 4개까지 가능하다. implicit auto-breakpoint도 한 자리를 사용한다. 따라서 기본 mode에서는 explicit marker를 3개, explicit mode에서는 4개까지 사용할 수 있다. 이전 대화 turn의 breakpoint는 이후 요청에서 read-only다.
• 최소 1,024-token 조건은 그대로다. 표시한 prefix가 이보다 짧으면 캐시되지 않는다.
• ttl: "30m"은 최대 시간이 아니라 보장되는 최소 수명이다. “최소 30분 동안 유지되며 그보다 오래 보관될 수 있다.” 5.6에서 deprecated된 prompt_cache_retention을 대체한다. 기존 24h extended retention option도 함께 없어졌다.
• 안정적인 matching에는 prompt_cache_key가 필요하다. 가이드에서는 반복 요청을 같은 cache로 routing할 수 있도록 tenant 또는 session별로 안정적인 key를 사용할 것을 권장한다. key당 분당 약 15개 요청이라는 soft limit가 있다. cache scope는 organization 단위다.
• 5.6 이상에서는 cache write에 입력 요금의 1.25배가 부과된다. 새로운 usage.prompt_tokens_details.cache_write_tokens field에 기록된다. 5.x 이하에서는 write가 무료였다.

GPT-5.5 이하 모델은 새 parameter를 명확한 400 오류(prompt_cache_options is not supported on this model)로 거부한다. rollout할 때 model version별 분기가 필요하다.

익숙한 설계다. content block에 marker를 지정하고, breakpoint를 4개까지 사용하며, write premium과 sliding read-only history를 제공한다. Claude의 cache_control이 처음부터 사용해 온 구조다. 차이는 TTL이다. OpenAI는 최소 30분을 보장하며, 이는 Claude의 기본 5분보다 6배 길다.

미터로 확인한 결과

문서의 설명을 실제 gateway 미터로 probe별 검증했다. 전체 raw record는 run log에 있다. 아래 모든 비용은 tier별 요금과 마지막 자리까지 일치한다.

이 가운데 세 가지는 자세히 볼 필요가 있다.

일부 prefix 재사용은 실제로 동작하며, breakpoint를 도입해야 하는 핵심 이유다. 안정적인 block A와 교체되는 tail B를 사용했을 때 미터는 tail에만 다시 요금을 부과했다. 2,431-token prompt 중 1,212 token은 캐시 요금으로 읽혔고, 새 B의 1,210 token은 write premium으로 기록됐다. 총비용도 요금표와 마지막 자리까지 일치했다. Claude 사용자가 prompt를 구성하는 layered-prefix 방식과 같다. system prompt, tools, documents 순으로 두고 각 구간을 표시할 수 있다. GPT의 automatic mode에서는 이를 보장할 수 없었다. 한 가지 주의점이 있다. 전체 반복 호출에서도 일치 길이가 marker보다 짧게 잡히는 경우가 있었다. 한 probe에서는 2,422-token write 중 1,897 token만 일치했다. 정확한 match token 수가 아니라 할인 요율을 기준으로 예산을 잡아야 한다.

최소 token 조건과 silent miss가 운영상의 함정이다. 621-token block을 표시해 두 번 호출했지만 아무것도 캐시되지 않았다. 오류도 없었고, usage의 0 외에는 별도 신호가 없었다. “안정적인 prefix”가 짧은 system prompt라면 계속 정상 요금을 내면서도 알아차리지 못할 수 있다. miss가 나도 write 없이 정상 요금으로 처리되며 아무 알림이 없을 수 있다. 요청 경로와 관계없이 hit rate는 보장값이 아니라 분포로 다뤄야 한다. 운영 환경에서 cached_tokens를 읽고 alert를 설정해야 한다. 5분 cache 감사에서도 같은 방식을 사용한다.

write premium은 실제로 부과되며 손익분기점도 달라진다. 세 tier 모두 기록된 token에 정확히 입력 요금의 1.25배가 부과됐다. 1M token당 Luna는 $1.25, Terra는 $3.125, Sol은 $6.25였다. 최종 run의 모든 probe에서 마지막 자리까지 일치했다. 이 premium은 prefix를 다시 읽어야 회수할 수 있다. 한 번도 hit되지 않은 write는 캐시를 전혀 사용하지 않을 때보다 25% 비싸다. LangChain 글에서 측정한 Claude write premium과 같은 함정이다. 안정적으로 보이는 모든 부분이 아니라 반복 사용이 확실한 prefix만 표시해야 한다.

측정한 범위에서는 최소 30분 수명이 유지됐다. write 15분 후 key를 지정해 다시 읽었을 때 1,313 token 중 1,313 token 전체가 캐시됐으며, 10% 요금과 일치했다. 기존 in-memory 기준인 5~10분을 크게 넘긴 결과다. 같은 간격으로 두 번째 keyed probe를 실행해도 동일했다. 30분 전체 구간까지는 측정하지 않았다.

비교를 위한 GPT-5.5의 동일 workload

공정한 비교 대상은 같은 가격대다. Sol의 요금표는 gpt-5.5와 정확히 같은 $5/$30다. 따라서 직접 대응되는 후속 모델이며, Terra와 Luna는 그보다 낮은 경량 tier다. 표시 가격은 같지만 caching 조건은 크게 다르다.

표시 가격이 같으므로 caching 조건 자체가 핵심 업그레이드다. 3,000-token prefix는 5.5의 automatic cache가 hit할 경우 호출당 $0.0075다. warm 상태의 Sol에서는 $0.0015로, 캐시된 부분의 비용이 5배 낮다. 더 큰 변화는 제어와 가시성이다. 5.5의 hit 여부는 직접 trigger하거나 debug할 수 없는 불투명한 prefix 감지에 달려 있다. 5.6에서는 캐시할 구간을 정확히 표시하고, prompt_cache_key로 반복 요청을 routing하며, 모든 write를 usage에서 확인할 수 있다. 이제 miss는 사용자가 만든 field의 0으로 표시된다. 아무 신호도 없던 이전과 다르다. 하위 tier를 사용하는 선택지도 추가된다. 5.5가 workload에 비해 과한 모델이었다면 Terra는 전체 요금표를 절반으로 낮추고 Luna는 5분의 1로 낮춘다. 같은 warm prefix 비용도 각각 $0.00075와 $0.0003으로 줄어든다. 5.5가 유지하는 장점은 선택적 24시간 retention이다. 큰 prefix를 사용하는 일일 batch traffic이라면 이 조건이 더 유리할 수 있다. migration 시 두 번째 비용 조절 수단은 반대 방향으로 작용한다. 5.6은 기본적으로 reasoning을 사용하므로, reasoning_effort를 고정하지 않고 5.5 workload를 옮기면 같은 요금표에서도 새로운 출력 비용이 추가된다.

두 번째 비용 조절 수단: reasoning effort

Caching은 입력 비용을 결정한다. reasoning_effort는 출력 비용을 결정한다. reasoning token에는 출력 요금이 부과되며, prefix와 달리 캐시할 수 없기 때문이다. GPT-5.6의 모든 tier는 none부터 xhigh까지 지원한다. 출시 글에서는 Sol용 max effort도 소개했지만 chat completions에서는 사용할 수 없다. Sol과 Terra 모두 400: 'reasoning_effort' does not support 'max' with this model을 반환했다. gateway와 SDK가 사용하는 API 경로에서는 xhigh가 실질적인 상한이다.

50회 호출 매트릭스를 실행했다. task는 review 분류, log line에서 field 추출, 여러 단계의 산술 word problem, 작은 code generation의 4가지였다. Terra와 Luna에서 none부터 xhigh까지 6개 설정과 parameter 생략을 비교했고, Sol도 일부 확인했다. 50개 답변 모두 모든 설정에서 정답이었다. 차이는 비용이었다. 출력이 짧은 호출이라 visible token은 수십 개에 불과했다. 따라서 출력 요금이 적용되는 reasoning token 수십 개만으로도 총비용이 크게 달라졌다. 비율 열은 전체 호출 비용을 비교한다.

세 가지 결과가 나왔다. 첫째, 5.6은 자체적으로 적응한다. 단순한 두 task에서는 어떤 설정에서도 reasoning token을 하나도 사용하지 않았다. 이런 경우에는 설정에 따른 추가 비용이 없다. 둘째, reasoning이 필요해 보이는 task인 수학과 코드에서는 결과가 달라지지 않아도 기본값이 reasoning을 사용했다. Luna의 수학과 코드, Terra의 수학에서 parameter를 생략하면 같은 정답을 내면서도 none보다 2.5배에서 3.5배 비쌌다. Terra의 코드 run에서는 기본값으로 reasoning을 사용하지 않았다. Terra와 Luna grid 전체 합계에서는 비용이 1.5배였다. 셋째, 표에 없는 중간 설정은 정밀한 조절 장치가 아니라 변동성이 큰 신호였다. Terra의 수학 run은 low에서 reasoning token 19개, medium에서 0개, high에서 21개, xhigh에서 다시 0개를 사용했다. Luna의 코드 run은 high에서 41개, xhigh에서 101개를 사용했다. 이름은 budget이 아니라 intent를 나타낸다. GLM 5.2에서도 같은 동작을 측정했다.

모든 호출에서 reasoning_effort를 명시적으로 보내고, 기본값은 none으로 설정해야 한다. 분류, 추출, routing, 짧은 변환 작업에는 특히 그렇다. task가 어려워 보인다는 이유로 올리지 말고, 높은 설정이 결과를 개선한다는 것을 eval로 확인한 call site만 상향해야 한다. 이번에 사용한 4개 task는 출력이 짧은 API workload다. 실제로 어려운 다단계 작업이라면 reasoning 비용이 타당할 수 있지만, 측정 결과로 결정해야 한다.

두 가지 비용 조절 수단은 함께 작용한다. prefix가 warm 상태가 되면 Luna 호출의 입력 비용은 표시 가격의 10분의 1로 낮아진다. 짧은 task에서는 기본 reasoning이 남은 비용 중 가장 큰 항목이 된다. Luna의 수학 호출은 none일 때 총 $0.00007였고, parameter를 생략하면 $0.00025였다. 기본 reasoning만으로 $0.00018가 추가됐으며, 이는 관리된 호출 전체 비용의 2배를 넘는다. cache를 적용하고 effort를 고정하지 않으면 절감한 비용이 출력 측면에서 다시 빠져나간다.

workload별 권장 구성

이제 선택 기준이 명확해졌다. gateway 고객에게는 다음과 같이 권장한다.

workload 형태와 관계없이 tenant 또는 session별로 안정적인 prompt_cache_key를 보내야 한다. 문서도 이 key를 안정적인 matching의 기반으로 설명한다. 표시한 각 layer는 1,024-token 조건을 충족해야 한다. silent miss가 있으므로 cached_tokens도 모니터링해야 한다. cache는 model별로 분리된다. tier를 나눠 A/B test하면 양쪽 모두 처음부터 다시 warm-up해야 한다. 같은 변경 사항에 다른 비용 조절 수단도 포함해야 한다. 위 매트릭스에 따라 reasoning_effort를 고정하고, eval 결과가 다르지 않다면 none을 사용한다.

tier 선택에서는 tier 자체보다 90% 할인이 계산 결과에 더 큰 영향을 준다. 3,000-token prefix를 반복하는 workload는 warm Luna traffic에서 1,000회 호출당 해당 prefix 비용으로 약 $0.30를 지불한다. warm Sol에서는 $1.50다. 캐시된 입력의 tier별 가격 차이보다 출력 token의 가격 차이가 더 크다. 출력 품질과 가격을 기준으로 tier를 선택하고, caching으로 입력 비용을 낮추면 된다. gpt-5.5에서 이전한다면 Sol은 같은 요금표를 유지하면서 cache read 비용이 5배 낮고 hit 시점을 제어할 수 있는 교체 모델이다. 작은 tier로도 eval을 통과한다면 Terra나 Luna로 낮출 수 있다. 그러면 요금표도 각각 절반 또는 5분의 1로 줄어든다.

tokenizer는 바뀌지 않았다

24개 sample을 사용했다. 9개 언어의 narrative passage, 그중 6개 언어의 technical 및 news version, Python function, JSON tool-call을 비교했다. 완료된 모든 비교에서 GPT-5.5, Sol, Terra, Luna의 token 수가 동일했다. 5.5에 맞춘 token budget과 cache 최소 조건 추정값을 그대로 사용할 수 있다. 언어별 차이는 언어별 tokenizer 분석 글에 정리돼 있으며, 5.6에도 그대로 적용된다.

결론

• 이번 출시에서 실질적인 가격 인하는 cache 할인율이 50%에서 90%로 커지고 최소 30분 TTL이 보장된 것이다. tier 가격이 headline이지만 실제 비용에는 caching 조건이 더 큰 영향을 준다.
• layered prompt에는 explicit breakpoint를 도입해야 한다. 일부 prefix 재사용은 이론이 아니라 측정으로 확인됐다. Claude의 mental model을 그대로 적용할 수 있다.
• 최소 1,024-token 조건을 지키고 prompt_cache_key를 보내며 cached_tokens를 모니터링해야 한다. 아무 알림 없이 miss가 나거나 아예 캐시되지 않는 경우가 모두 존재한다.
• reasoning_effort를 명시적으로 보내고 기본값을 none으로 설정해야 한다. 관리하지 않은 기본값은 매트릭스 전체에서 1.5배, 개별 task에서는 최대 3.5배 비쌌지만 답변은 동일했다.
• 사용할 수 있는 상한은 xhigh다. chat completions에서 max는 400을 반환한다. 5.5에서 이전할 때 tokenizer 기준을 다시 잡을 필요는 없다.

FAQ

GPT-5.6은 Claude처럼 explicit prompt caching을 지원하나요? 지원한다. prompt_cache_options: {"mode": "explicit"}와 content block의 prompt_cache_breakpoint marker를 사용한다. 요청당 최대 4번 write할 수 있다. automatic breakpoint가 한 자리를 사용하는 implicit mode에서는 3번이다. OpenAI 호환 gateway로 측정했을 때, 표시한 3,012-token prefix는 첫 번째 호출에서 write됐고 두 번째 호출에서는 전체가 캐시 요금으로 읽혔다.

GPT-5.6에서 캐시된 입력 비용은 얼마인가요? 입력 요금의 10%다. 세 tier에서 측정한 1M당 가격은 Luna $0.10, Terra $0.25, Sol $0.50였다. GPT-5.x에서는 캐시된 token에 입력 요금의 50%가 부과됐으므로, 5.6의 캐시된 token 요금은 5배 낮다.

GPT-5.6의 caching은 GPT-5.5보다 나은가요? 할인 폭과 제어 기능은 더 낫다. 캐시 요금은 50%에서 10%로 낮아졌다. 직접 trigger하거나 debug할 수 없는 automatic 감지만 제공하던 방식에서 explicit breakpoint 4개를 지원하는 방식으로 바뀌었다. best effort 5~10분이던 수명도 key 사용 시 최소 30분 보장으로 늘었다. 5.5에 남은 장점은 선택적 24시간 retention tier이며, 5.6에서는 제거됐다.

GPT-5.6 cache는 얼마나 오래 유지되나요? 문서는 최소 30분을 보장하며 그보다 오래 유지될 수도 있다. ttl: "30m"만 허용된다. 이 option은 deprecated된 prompt_cache_retention과 기존 24시간 extended tier를 대체한다. 이번 probe에서는 write 15분 후 keyed re-read가 전부 hit했다. 30분 전체 구간까지는 측정하지 않았다.

prompt_cache_key가 필요한가요? 보내는 것이 좋다. 문서에서는 tenant 또는 session별로 안정적인 key를 사용하는 것을 5.6의 신뢰할 수 있는 matching 기반으로 설명한다. key당 분당 약 15개 요청이라는 soft limit가 있다. 포함해도 추가 비용은 없다. cached_tokens 모니터링과 함께 사용해야 할인이 실제로 적용되는지 검증할 수 있다.

reasoning_effort는 GPT-5.6 비용을 얼마나 바꾸나요? 50회 호출 매트릭스에서 4가지 task 형태와 6개 설정을 Terra와 Luna로 비교했다. 모든 설정에서 정답이 나왔지만, parameter를 생략한 경우 전체적으로 none보다 1.5배 비쌌다. 산술 task에서는 최대 3.5배였다. 단순한 분류와 추출에서는 어떤 설정도 reasoning token을 사용하지 않았다. 기본값을 none으로 고정하고 eval 결과에 따라 필요한 경우에만 올려야 한다.

GPT-5.6 Sol에서 최대 reasoning effort를 사용할 수 있나요? chat completions에서는 사용할 수 없다. Sol과 Terra 모두 reasoning_effort: "max" 요청에 400을 반환하며, 지원 값으로 none부터 xhigh까지 표시한다.

API workload에는 어떤 GPT-5.6 tier를 사용해야 하나요? Sol은 gpt-5.5와 같은 가격대의 후속 모델이다. 요금표는 동일한 $5/$30이며, cache read는 5배 저렴하다. Terra와 Luna는 각각 그 가격의 절반과 5분의 1인 경량 tier다. prefix가 안정적이고 key를 사용하면 90% cache 할인이 입력 비용을 낮춘다. 출력 품질 eval이 허용하는 범위까지 tier를 낮추고, tier에 따라 출력 가격을 결정하면 된다.

이 시리즈의 다른 비용 측정 가이드: 7개 ASR 모델의 음성 인식 비용, 이미지 생성 비용, GPT Realtime 음성 요금.

← 블로그로 돌아가기