GPT-5.6 프롬프팅 가이드: 요금을 1.5 배, 10 배로 늘리는 두 가지 기본값

GPT-5.6 을 잘 프롬프팅하는 건 결국 request 파라미터 두 개로 귀결되는데, 둘 다 기본값이 비싼 쪽으로 잡혀 있다. reasoning_effort 를 생략하면 "none" 으로 고정했을 때보다 1.5 배가 청구됐고, 50 회 콜 매트릭스에서 답변은 완전히 동일했다. 안정적인 prefix 를 표시하지 않으면 매 콜마다 cached read 요율의 10 배로 청구된다. 이 가이드는 GPT-5.6 비용 가이드의 측정 결과에서 나온 request 설계 플레이북이다. 제대로 된 request 는 어떤 모양인지, 작업별로 effort 다이얼을 어떻게 맞추는지, 캐시가 제대로 동작하도록 프롬프트를 어떻게 배치하는지, 그리고 GPT-5.5 에서 프롬프트를 옮겨올 때 무엇이 깨지는지를 다룬다.

TL;DR

• 모든 GPT-5.6 request 에 reasoning_effort 를 고정하라. 생략하면 4-task 매트릭스에서 답변은 동일한데 "none" 대비 1.5 배가 청구됐다.
• 허용되는 effort 는 none 부터 xhigh 까지다. "max" 는 Sol 과 Terra 모두에서 400 을 반환한다.
• 안정적인 prefix 는 명시적 cache breakpoint 로 표시하라. cached read 는 input 요율의 10%, write 는 1.25 배로 청구되므로, 그냥 안정적으로 보이는 것이 아니라 실제로 반복되는 것을 표시하라.
• prompt_cache_options 와 breakpoint 는 GPT-5.5 이하에서 400 을 반환한다. 롤아웃은 버전으로 게이팅하라.

GPT-5.6 request 는 어떤 모양이어야 하나

이 모양에서 시작해서 필요 없는 부분을 지워라. 비싼 기본값을 물려받는 대신 두 레버를 명시적으로 고정한다.

{
  "model": "gpt-5.6-terra",
  "reasoning_effort": "low",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    { "role": "system", "content": "…stable instructions…",
      "prompt_cache_breakpoint": { "mode": "explicit" } },
    { "role": "user", "content": "…the part that changes per request…" }
  ]
}

배치 규칙은 이렇다. 안정적인 것은 전부 breakpoint 앞에, request 마다 바뀌는 것은 전부 뒤에 둔다. 그리고 동적인 값(타임스탬프, 사용자 이름, 콜마다 다른 검색 문서)은 절대 표시된 블록 안에 두지 않는다. 바이트 하나만 바뀌어도 그 블록이 1.25 배 write 프리미엄으로 다시 청구되기 때문이다. prompt_cache_key 는 반복 요청을 같은 캐시로 라우팅한다. tenant 나 session 당 안정적인 키 하나를 쓰고, 키당 분당 약 15 요청이라는 문서상의 soft limit 을 유념하라.

reasoning_effort는 어떻게 설정해야 하나?

무조건 명시적으로 설정하라. 피해야 할 단 하나의 경우는 아무것도 설정하지 않는 것이다. 우리 측정에서 reasoning_effort를 지정하지 않은 요청은 "none"으로 고정한 요청보다 1.5배 더 비싸게 청구됐고, 그럼에도 매트릭스 전 구간에서 답변은 동일했다. 허용되는 값은 none, low, medium, high, xhigh이고, "max"는 유효 범위를 나열한 400 에러로 거부된다. 한 줄짜리 수학 문제 테스트에서 Luna로 각 다이얼이 무엇을 사줬는지는 다음과 같다.

GPT-5.6은 우리 token 사용량 해부 연구에서 이 테스트를 thinking 완전 off 상태로도 정답을 유지한 유일한 계열이었다. 그래서 추출, 분류, 포매팅, 검색 형태의 호출에서는 none을 기본값으로 삼을 만하다. 실제로 추론을 하면 그 token은 보이지 않는데 full output 요율로 청구된다. 기본 설정 수학 예제에서 output 요금의 88%가 읽을 수 없는 chain of thought였다. 다이얼을 올리는 것은 eval이 그 작업에 필요하다고 말할 때지, 기본값이 이미 돈을 썼기 때문이 아니다.

캐시가 돈값을 하도록 prompt를 어떻게 배치하나?

prompt를 안정성 순서로 계층화하고 각 계층을 표시하라. system 지침이 먼저, 그다음 tool 정의, 그다음 참조 문서 순이고, 각각 breakpoint로 끝나며, 변동성이 큰 사용자 턴은 마지막 표시 뒤에 둔다. 요청당 캐시 쓰기는 4번이다. 기본 implicit 모드에서는 최신 메시지에 자동 breakpoint가 걸리며 그중 하나를 소비하므로, explicit 모드를 쓰면 4번을 온전히 확보하고 더 중요하게는 표시한 부분만 캐싱한다.

부분 재사용이 그 대가이며, 이는 측정된 값이다. 안정 블록 A와 교체되는 꼬리 B가 있을 때, 미터는 꼬리만 다시 청구했다. 2,431 token짜리 prompt 중 1,212 token은 캐시 요율로 되읽혔고, 1,210 token은 프리미엄 요율로 새로 쓰였으며, 이는 요율표와 자릿수까지 맞아떨어졌다. 여기서 세 가지 예산 규칙이 나온다.

• 읽기는 input 요율의 10%로 청구되므로, 계층화된 prefix가 warm 상태면 청구서의 input 쪽이 평탄해진다.
• 쓰기는 1.25배로 청구되므로, 표시했지만 다시 읽히지 않는 블록은 캐싱 안 한 것보다 25% 더 든다. 안정적으로 보이는 모든 것이 아니라, 반복되는 것을 표시하라.
• 완전 반복 시 매칭된 길이가 표시 지점 아래로 떨어질 수 있으므로(한 테스트에서 2,422 token 쓰기 중 1,897 token만 캐시됨), 정확 매칭 개수가 아니라 할인 요율로 예산을 잡아라. 캐시 최소치 연구에 계열별 하한이 있다.

ttl: "30m"의 하한은 상한이 아니라 보장되는 최소치이며, Claude의 기본 5분보다 6배다. 이제 24시간 등급은 없으므로, 연장된 보존에 기대던 일별 배치 워크로드는 손익분기점을 다시 계산해야 한다.

GPT-5.5에서 prompt를 이식하면 무엇이 깨지나?

둘은 요란하게 깨지고, 하나는 조용히 깨진다. 요란한 쪽: prompt_cache_options와 prompt_cache_breakpoint는 GPT-5.5 이하에서 명확한 400을 반환하므로(prompt_cache_options is not supported on this model), 공유하는 prompt 빌더에는 버전 게이트가 필요하다. 역시 요란한 쪽: 일부 5.5 설정이 들고 있던 "max" effort는 거부된다.

조용히, 그리고 더 비싸게 깨지는 쪽: GPT-5.6은 기본적으로 추론을 하는데, 5.5 워크로드에서는 추론이 off였을 수 있다. reasoning_effort를 아예 설정하지 않고 이식한 prompt는 같은 요율표에서 1.5배 누락 세금을 그대로 떠안는다. 캐시 마이그레이션은 반대 방향으로 작동한다. 5.5의 자동 prefix 감지는 마크업이 필요 없었지만 트리거하거나 디버깅할 수 없었다. 5.6에서는 같은 prompt가 표시하기 전까지 아무 일도 하지 않고, 표시하면 모든 쓰기를 usage.prompt_tokens_details.cache_write_tokens에 보고한다. 여기서 미스는 침묵이 아니라, 당신이 만든 필드에 0으로 드러난다.

어떤 tier에서 프롬프트를 돌려야 하나

요청 형태는 세 tier 모두 동일하다. 그래서 tier 선택은 프롬프트가 아니라 가격 문제다. Sol은 백만 토큰당 $5/$30, Terra는 그 절반, Luna는 5분의 1이다. prefix가 안정되고 키가 잡히고 워밍업까지 끝나면, cached read 할인이 모든 tier에서 입력 쪽 비용을 평평하게 눌러버린다. 그러면 출력 가격이 차이를 만드는 요소가 된다. 출력 품질 eval이 허용하는 만큼 아래 tier로 내려가면 된다. write 프리미엄의 tier별 손익분기점을 포함한 tier 계산 전체는 비용 가이드에 있다.

FAQ

GPT-5.6이 reasoning_effort: “max”를 지원하나?

아니다. "max"로 보낸 요청은 400을 반환하며, Sol과 Terra 모두 유효한 값으로 none부터 xhigh까지를 나열한다. 상한을 원하는 워크로드는 xhigh를 명시적으로 보내야 한다.

cache breakpoint가 GPT-5.5에서도 동작하나?

아니다. GPT-5.5 이하 모델은 prompt_cache_options와 breakpoint 마커를 400으로 거부한다. 이 모델들에서는 다시 자동 prefix 감지로 돌아가는데, 이건 트리거할 수도, 키를 잡을 수도, 디버깅할 수도 없다. 여기서는 cache 동작을 best-effort로 취급하고, 새 필드를 내보내는 프롬프트 빌더는 버전으로 게이팅해라.

프롬프트에서 breakpoint는 실제로 몇 개나 써야 하나?

정말로 반복되는 레이어 수만큼, 예산 한도까지 쓰면 된다. 요청당 write 4개이고, explicit 모드로 바꾸지 않는 한 그중 하나는 암묵적 auto-breakpoint가 잡아먹는다. 전형적인 레이어드 프롬프트는 두세 개(instructions, tools, reference block)면 충분하다. 다섯 번째 마커를 넣어도 에러 없이 받아들여지지만, 뒤쪽 마크가 그 앞의 모든 것을 커버하기 때문에 write 슬롯을 나눠 쓰는 데 그친다.

이 가이드의 모든 수치는 출시 당일 GPT-5.6 모델을 Synthorai gateway로 측정했으며, 실시간 usage.cost 미터와 대조해 일치시켰다. 방법론과 원시 측정값은 비용 가이드와 cache 최소값 연구에 있다. 각자의 사용 기록으로 직접 검증해라. 요율과 허용 값은 바뀔 수 있다.

← 블로그로 돌아가기