GPT-5.6 비용 가이드: Prompt Caching 90% 절감, Reasoning Effort

GPT-5.6 은 두 가지 비용 레버를 동시에 움직인다. 캐시된 입력은 입력 요율의 10% 로 떨어지고（5.x 는 50% 할인이었다）, reasoning 이 기본으로 켜져 있어 reasoning_effort 를 보내지 않으면 none 으로 고정할 때보다 비용이 더 든다. 50건 호출 매트릭스에서 답변은 동일한데 1.5배가 청구됐다. 입력 쪽에서는 이제 cache breakpoint 를 최대 네 개까지 명시적으로 고정할 수 있고, 출력 쪽에서는 effort 손잡이가 얼마나 많은 thinking 에 대해 비용을 낼지 결정한다. 두 레버를 출시 당일 모델 세 종에 대해 gateway 를 통해 측정했다. Sol（1M token 당 입력 $5 / 출력 $30）, Terra（$2.50 / $15）, Luna（$1 / $6）이고, 모든 요율은 라이브 usage.cost 미터로 검증했다.

TL;DR

• 캐시된 입력은 입력 요율의 10% 로 청구된다. 티어별로 1M 당 $0.10 / $0.25 / $0.50 로 실측됐다. 5.x 는 50% 할인이었다.
• Breakpoint 는 부분 재사용을 제공한다. 마커 뒤의 블록을 바꿨더니 2,431 token 중 1,210 개만 다시 청구됐다.
• 1,024 token 미만의 prefix 는 캐시되지 않고, 반복 요청도 조용히 miss 할 수 있다. hit rate 는 100% 미만으로 잡아라.
• 캐시 write 는 기록된 token 에 대해 1.25배로 청구된다. 한 번도 읽히지 않은 write 는 캐시를 아예 안 하는 것보다 비싸다.
• reasoning_effort 를 생략하면 4개 task 매트릭스에서 none 대비 1.5배가 청구됐고, 답변은 동일했다. 명시적으로 고정하라.

2026-07-10 에 Synthorai gateway（OpenAI 호환 chat completions）를 통해 측정했으며, OpenAI 가 이 제품군을 발표한 다음 날이다. 세 모델 모두 라이브 상태이고, 새 캐싱 파라미터는 그대로 통과된다.

세 개의 티어, 하나의 세대

이름 체계가 새로워졌다. 숫자는 세대를 뜻하고, Sol, Terra, Luna 는 pro/mini/nano 접미사를 대체하는 성능 티어다. 세 모델 모두 1M token context window 와 128K 최대 출력을 공유한다. 아래 요율은 모두 알려진 token 수에 대한 미터링된 usage.cost 와 정확히 일치하며, 캐시 열도 마찬가지다.

Sol 은 플래그십이자 gpt-5.5 의 가격 동등 후속작이다. 요율표가 $5/$30 로 동일하다. Terra 와 Luna 는 같은 세대의 축소 티어로, 각각 Sol 가격의 절반과 5분의 1이며, 예전 mini 와 nano 접미사가 차지하던 자리를 대신한다. Token 카운팅 관점에서는 세 모델이 한 모델이다. 우리가 보낸 모든 샘플에서 셋 다 동일한 카운트를 반환했다.

5.6 캐싱 동작 방식（공식 문서 기준）

과거 GPT 캐싱은 동작이 하나뿐이었다. API 가 1,024 토큰 이상의 반복 prefix 를 알아서 감지하고, 캐시된 부분을 절반 가격으로 청구했다. 프로바이더 비교에서 GPT 열을 “완전 자동”으로 분류한 것도 이 때문이다. 5.6 캐싱 가이드는 이를 두 가지 모드 설계로 바꿨다：

{
  "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 의 끝을 표시한다. 해당 블록과 그 앞의 모든 것을 포함한다. 기본값인 implicit 모드는 여전히 가장 최근 메시지에 breakpoint 를 자동으로 배치하고, explicit 모드는 직접 표시한 부분만 캐시한다.
• 요청당 캐시 쓰기는 4 회다. implicit 자동 breakpoint 가 그중 하나를 소비하므로, 기본 모드에서는 explicit 마커에 3 개, explicit 모드에서는 4 개의 슬롯이 주어진다. 이전 대화 턴의 breakpoint 는 이후 요청에서 읽기 전용이다.
• 1,024 토큰 하한은 그대로 유지된다. 이보다 짧은 prefix 를 표시해도 캐시되지 않는다.
• ttl: "30m" 은 상한이 아니라 보장된 최소 수명이다（“최소 30 분… 더 오래 유지될 수 있음”）. 5.6 에서 deprecated 된 prompt_cache_retention 을 대체하며, 이와 함께 기존 24h 확장 보존 옵션도 사라졌다.
• 안정적인 매칭은 prompt_cache_key 로 얻는다. 가이드는 테넌트나 세션마다 고정된 키를 사용해 반복 요청을 같은 캐시로 라우팅하도록 권장하며, 키당 분당 약 15 요청의 soft limit 이 있다. 캐시는 조직 단위로 스코핑된다.
• 캐시 쓰기는 5.6+ 에서 input 요율의 1.25 배로 청구되며, 새로운 usage.prompt_tokens_details.cache_write_tokens 필드에 보고된다. 5.x 이전에는 쓰기가 무료였다.

GPT-5.5 이하는 새 파라미터를 400 으로 깔끔하게 거부하므로（prompt_cache_options is not supported on this model）, 롤아웃 시 버전 게이팅을 걸어야 한다.

설계가 익숙하게 들린다면 당연하다. content 블록의 마커, 4 개의 breakpoint, 쓰기 프리미엄, 슬라이딩 방식의 읽기 전용 히스토리는 Claude 의 cache_control 이 처음부터 가져온 형태다. 차이는 TTL 이다. OpenAI 의 30 분 보장 하한은 Claude 기본값인 5 분의 6 배다.

미터가 말하는 것

문서는 주장일 뿐이고, 여기 게이트웨이 미터가 프로브 하나하나마다 실제로 반환한 값이 있다. 원본 로그 전체는 실행 기록에 있으며, 아래 모든 비용은 티어 요율에 맞춰 자릿수까지 정확히 일치한다.

이 중 세 행은 풀어서 볼 가치가 있다.

부분 재사용은 실제로 동작하며, 이것이 breakpoint 를 도입해야 하는 이유다. 안정적인 블록 A와 교체된 tail B가 있을 때, 미터는 tail 만 다시 청구했다. 2,431 토큰 prompt 중 1,212 토큰을 cached 요율로 다시 읽고, 새 B의 1,210 토큰을 write 프리미엄으로 write 했으며, 합계는 요금표와 자릿수까지 맞아떨어진다. 이것이 Claude 사용자들이 prompt 를 구성하는 계층형 prefix 동작(system prompt, 다음 tools, 다음 documents 를 각각 마킹)이고, GPT 의 자동 모드로는 결코 보장할 수 없었던 부분이다. 주석 하나: 완전 반복에서 매칭 길이가 마킹 아래로 떨어지는 경우가 있다(한 프로브에서 2,422 토큰 write 중 1,897 매칭). 정확한 매칭 개수가 아니라 할인 요율 기준으로 예산을 잡아라.

바닥값과 조용한 미스가 운영상의 함정이다. 621토큰으로 표시된 블록은 오류도 없고 0 이외의 사용량 힌트도 없이 두 번이나 아무것도 캐시하지 못했다. 만약 당신의 “안정적인 접두어(stable prefix)“가 짧은 시스템 프롬프트라면, 당신은 전액을 지불하고 있으면서도 아무것도 그것을 알려주지 않는다. 그리고 미스는 쓰기 없이, 전액으로, 마찬가지로 조용히 도착할 수 있다. 요청이 어떤 경로를 타든, 적중률은 약속이 아니라 분포다. 프로덕션에서 cached_tokens를 읽고 그것에 대해 알림을 설정하라. 우리의 5분 캐시 감사가 하는 방식대로.

write 프리미엄은 실제로 존재하며, 손익분기점을 바꾼다. write 토큰은 세 티어 모두 입력 요율의 정확히 1.25배로 청구된다(Luna write 는 백만당 $1.25, Terra 는 $3.125, Sol 은 $6.25). 최종 실행의 모든 프로브에서 자릿수까지 일치했다. 이 프리미엄은 prefix 가 다시 읽힐 때에만 회수된다. 히트가 한 번도 없는 write 는 아예 캐시하지 않는 것보다 25% 더 비싸다. LangChain 글에서 Claude 의 write 프리미엄으로 측정했던 바로 그 함정이다. 안정적으로 보이는 모든 것이 아니라, 반복될 것이 확실한 prefix 만 마킹하라.

30분 하한선은 우리가 탐색한 범위 내에서 유지되었습니다. 쓰기 후 15분에 수행한 키 재읽기는 완전히 캐시된 상태로 돌아왔으며(1,313개 토큰 중 1,313개, 10% 요율로 정산), 이는 기존의 5분에서 10분이라는 인메모리 한계를 훨씬 넘어선 것입니다. 동일한 간격으로 진행한 두 번째 키 탐색도 같은 결과를 반복했습니다. 우리는 전체 30분을 탐색하지는 않았습니다.

비교를 위해 같은 워크로드를 GPT-5.5 에서 돌려보면

공정한 비교는 가격 기준을 맞추는 것이다. Sol 은 gpt-5.5 와 똑같은 요금표($5/$30)를 쓰므로 동급의 후속 모델이고, 그 아래로 Terra 와 Luna 가 낮은 등급으로 붙는다. 표시 가격은 같지만 캐싱 조건은 크게 다르다.

동일한 정가 기준으로, 캐싱 조건이 곧 업그레이드입니다. 3,000-token 프리픽스는 5.5에서 자동 캐시가 히트하기로 결정될 때 호출당 $0.0075의 비용이 들고, 웜 상태의 Sol에서는 $0.0015로 캐시된 부분에서 5배 저렴합니다. 더 깊은 변화는 제어와 가시성입니다: 5.5의 히트는 트리거할 수도 디버그할 수도 없는 불투명한 프리픽스 탐지에 의존하는 반면, 5.6은 무엇이 캐시되어야 하는지 정확히 표시하고, prompt_cache_key로 반복을 라우팅하며, 모든 쓰기가 usage에 기록되는 것을 지켜볼 수 있게 해줍니다. 이제 미스는 침묵이 아니라 여러분이 만든 필드에 0으로 표시됩니다. 단계적 인하 경로가 그 위에 쌓입니다: 만약 5.5가 워크로드에 과도하게 서비스하고 있었다면, Terra는 전체 요금표를 절반으로 줄이고 Luna는 5로 나누며, 동일한 웜 프리픽스는 $0.00075와 $0.0003으로 떨어집니다. 5.5가 유지하는 한 가지는 선택적 24시간 보존입니다; 만약 여러분의 트래픽이 거대한 프리픽스에 대한 일일 배치라면, 그 트레이드오프는 반대 방향으로 작동합니다. 그리고 두 번째 레버는 마이그레이션에서 반대 방향으로 작동한다는 점에 유의하세요: 5.6은 기본적으로 추론하므로, reasoning_effort를 고정하지 않고 옮겨온 5.5 워크로드는 동일한 요금표로 새로운 출력 비용을 발생시킵니다.

두 번째 레버: reasoning effort

캐싱이 입력 쪽 비용을 좌우한다면, reasoning_effort 는 출력 쪽을 좌우한다. reasoning 토큰은 출력 요율로 과금되고, 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 개 호출로 매트릭스를 돌렸다. 네 가지 작업 형태(리뷰 분류, 로그 한 줄에서 필드 추출, 여러 단계를 거치는 산술 문장제, 작은 코드 생성 작업)를 none 부터 xhigh 까지 여섯 가지 설정에 파라미터 생략까지 걸쳐, Terra 와 Luna 에서 돌리고 Sol 로 스팟 체크했다. 50 개 답변이 모든 설정에서 전부 정확했다. 달라진 건 청구서였다. 이들은 출력이 짧은 호출(눈에 보이는 토큰 수십 개 수준)이라, 출력 요율의 reasoning 토큰 몇십 개가 총액을 좌우한다. ratio 열은 호출 전체 비용을 비교한 것이다:

세 가지를 확인했다. 첫째, 5.6 은 스스로 적응한다. 자명한 두 형태에서는 어떤 설정에서도 reasoning 토큰을 하나도 쓰지 않았으니, 이 노브는 그 경우 공짜다. 둘째, 생각이 필요해 보이는 형태(math, code)에서는 이득이 없어도 기본값이 reasoning 을 한다. 파라미터를 생략하면 Luna 의 math 와 code, Terra 의 math 에서 같은 정답을 얻는 데 none 요금의 2.5x~3.5x 가 들었고(Terra 의 code 실행은 기본값에서 우연히 아무것도 쓰지 않았다), Terra 와 Luna 그리드를 합산하면 1.5x 였다. 셋째, 중간 설정(표에는 없다)은 다이얼이 아니라 노이즈다. Terra 의 math 실행은 low 에서 reasoning 토큰 19 개, medium 에서 0, high 에서 21, xhigh 에서 다시 0 을 썼고, Luna 의 code 실행은 high 에서 41 개인데 xhigh 에서는 101 개를 썼다. 이 이름들은 예산이 아니라 의도다. GLM 5.2 에서 측정한 것과 같은 동작이다.

모든 호출에 reasoning_effort 를 명시적으로 보내고, 분류·추출·라우팅·짧은 변환에는 none 을 기본값으로 두라. 특정 호출 지점을 올리는 건 작업이 어려워 보여서가 아니라, eval 에서 높은 설정이 결과를 바꾼다고 나올 때만이다. 우리가 다룬 네 형태는 출력이 짧은 API 워크로드다. 진짜로 어려운 다단계 작업이라면 reasoning 지출이 값을 할 수도 있지만, 그건 측정으로 판단하라.

두 레버는 곱해진다. prefix 가 데워지면 Luna 호출의 입력 쪽은 정가의 10 분의 1 로 떨어지고, 짧은 작업에서는 reasoning 기본값이 남은 항목 중 가장 큰 비용이 된다. Luna 의 math 호출은 none 에서 총 $0.00007 였고 파라미터를 생략하면 $0.00025 였다. reasoning 기본값 하나가 $0.00018 을 더한 것으로, managed 호출 전체보다 두 배 넘는 금액이다. effort 를 고정하지 않고 캐싱만 하면 절감분이 반대편으로 다시 새어 나간다.

워크로드별 권장 설정

이제 판단 기준이 명확해졌으니, 게이트웨이 고객에게 안내하는 내용을 정리한다.

형태와 무관하게: 테넌트 또는 세션마다 안정적인 prompt_cache_key를 전송하고(문서에서는 이 키를 신뢰할 수 있는 매칭의 기준으로 삼습니다), 표시된 모든 레이어를 1,024-token 하한선 이상으로 유지하며, 조용한 실패가 존재하므로 cached_tokens를 모니터링하세요. 캐시는 모델별이라는 점을 기억하세요: 티어 간 A/B 테스트는 양쪽에서 각각 0부터 다시 예열됩니다. 그리고 같은 커밋에서 다른 레버도 설정하세요: 위의 매트릭스에 따라 reasoning_effort를 고정하고, 평가에서 달리 말하지 않는 한 none으로 두세요.

티어 선택에서는, 90% 할인이 티어 자체보다 계산을 훨씬 크게 바꾼다. 3,000 token prefix 를 반복 재생하는 워크로드는 warm 상태의 Luna 트래픽에서 그 prefix 에 대해 1,000 콜당 약 $0.30, warm Sol 에서는 $1.50 을 낸다. 캐시된 부분에서 티어 간 차이는 출력 token 에서의 차이보다 작다. 그러니 티어는 출력 품질과 가격을 보고 고르고, 입력 쪽은 캐싱이 평평하게 만들도록 두면 된다. gpt-5.5 에서 넘어온다면 Sol 이 동일한 요금표에 캐시 읽기가 5배 저렴하고 그 시점을 제어할 수 있는 무난한 업그레이드다. eval 상 작은 티어로 버틸 수 있는 곳에서는 Terra 나 Luna 로 내려라. 요금표는 거기서 다시 절반 혹은 5분의 1로 줄어든다.

tokenizer 는 바뀌지 않았다

우리가 준비한 24개 샘플 (9개 언어의 서술형 지문, 그중 6개 언어의 기술 문서 및 뉴스 버전, Python 함수 하나, JSON tool-call 하나)은 완료된 모든 비교에서 GPT-5.5, Sol, Terra, Luna 에 걸쳐 동일하게 카운트됐다. 5.5 를 기준으로 보정한 token 예산과 캐시 하한 추정치는 그대로 이어진다. 언어별 동작은 언어별 tokenizer 포스트에 정리했으며, 5.6 에도 그대로 적용된다.

결론

• 캐시 할인이 50%에서 90%로 깊어지고 30분 TTL 이 보장된 것이 이번 릴리스의 진짜 가격 인하다. 티어 가격이 헤드라인이지만, 실제 청구서를 더 크게 움직이는 건 캐싱 조건이다.
• 계층화된 프롬프트에는 explicit breakpoint 를 도입하라. 부분 재사용은 이론이 아니라 측정된 값이고, 사고 모델은 Claude 에서 그대로 옮겨온다.
• 1,024 token 하한을 지키고, prompt_cache_key 를 전송하고, cached_tokens 를 모니터링하라. 조용한 미스와 아예 캐시되지 않는 경우가 둘 다 존재한다.
• reasoning_effort 를 명시적으로 보내고 기본값은 none 으로 하라. 관리되지 않는 기본값은 우리 매트릭스 전반에서 1.5배, 단일 작업에서는 최대 3.5배까지 과금하면서 답변은 동일했다.
• xhigh 가 실질적인 상한이다 (max 는 chat completions 기준 400s). 5.5 대비 tokenizer 재기준화는 없다.

자주 묻는 질문

GPT-5.6 도 Claude 처럼 명시적 prompt caching 을 지원하나요? 지원합니다. prompt_cache_options: {"mode": "explicit"} 와 함께 content block 에 prompt_cache_breakpoint 마커를 달면 되고, 요청당 최대 4 회까지 write 할 수 있습니다 (implicit 모드에서는 자동 breakpoint 가 한 자리를 차지하므로 3 회). OpenAI 호환 게이트웨이로 측정해 보니, 마커를 붙인 3,012-token prefix 가 첫 호출에서 write 되고 두 번째 호출에서 전체가 cached 요율로 read back 되었습니다.

GPT-5.6 에서 cached input 비용은 얼마인가요? input 요율의 10% 이며, 세 티어 모두에서 확인했습니다. Luna 는 100 만 token 당 $0.10，Terra 는 $0.25，Sol 은 $0.50 입니다. GPT-5.x 는 cached token 을 input 의 50% 로 청구했으니, 5.6 의 cached token 요율은 5 배 낮습니다.

GPT-5.6 의 caching 이 GPT-5.5 보다 나은가요? 할인 폭과 제어 측면에서는 그렇습니다. cached 요율이 50% 가 아니라 10% 이고, 트리거하거나 디버그할 수 없는 자동 감지 방식 대신 explicit breakpoint 를 4 개 쓸 수 있으며, best effort 5~10 분이 아니라 키 기반 30 분 하한을 보장합니다. 5.5 에 남은 한 가지 장점은 선택적 24 시간 보존 티어인데, 5.6 은 이걸 없앴습니다.

GPT-5.6 캐시는 얼마나 오래 유지되나요? 문서에서는 최소 30분을 보장하며(ttl: "30m"가 유일하게 허용되는 값), 그보다 길 수도 있습니다. 이 옵션은 더 이상 사용되지 않는 prompt_cache_retention을 대체하며, 기존의 24시간 확장 계층도 포함합니다. 저희 테스트에서는 쓰기 후 15분이 지난 키 기반 재읽기가 완전히 적중했으며, 전체 30분까지는 테스트하지 않았습니다.

prompt_cache_key가 필요한가요? 보내세요: 문서에서는 테넌트 또는 세션별로 안정적인 키를 만드는 것이 5.6에서 신뢰할 수 있는 매칭의 기반이며, 키당 분당 약 15개 요청이라는 소프트 리밋이 있다고 설명합니다. 포함해도 비용이 들지 않으며, cached_tokens 모니터링과 함께 사용하는 것이 할인이 실제로 적용되는지 확인하는 방법입니다.

reasoning_effort 는 GPT-5.6 비용을 얼마나 바꾸나요? 우리가 돌린 50 콜 매트릭스 (작업 형태 4 종, 설정 6 개, Terra 와 Luna)에서는 모든 설정이 정답을 냈고, 파라미터를 생략하면 전체적으로 none 보다 1.5 배, arithmetic 작업에서는 최대 3.5 배까지 청구되었습니다. 간단한 형태 (classification, extraction)에서는 어떤 설정도 reasoning token 을 전혀 쓰지 않았습니다. none 으로 고정하고 eval 결과가 필요할 때만 올리세요.

GPT-5.6 Sol 에서 최대 reasoning effort 를 쓸 수 있나요? chat completions 로는 안 됩니다. reasoning_effort: "max" 요청은 Sol 과 Terra 모두에서 none 부터 xhigh 까지 나열한 400 을 반환합니다.

API 워크로드에는 어떤 GPT-5.6 티어를 써야 하나요? Sol 은 gpt-5.5 의 가격 동일 후속작입니다 ($5/$30 요율표가 같고, cached read 는 5 배 저렴). Terra 와 Luna 는 그 절반, 5 분의 1 가격의 축소 티어입니다. prefix 가 안정되고 키가 붙으면 90% cache 할인이 input 쪽을 평탄하게 만들어 주니, output 품질 eval 이 허용하는 만큼 최대한 낮은 티어로 내려가고 output 가격은 티어에 맡기세요.

← 블로그로 돌아가기