Synthorai의 Claude Opus 4.8: 4.7/4.6과 캐싱 및 TTL 비교

이제 Synthorai gateway에서 claude-opus-4-8을 사용할 수 있습니다. 이미 Opus 계열에 prompt caching을 적용하고 있다면 반가우면서도 다소 심심한 소식입니다. 캐싱이나 TTL 계약은 4.7 또는 4.6에서 달라진 것이 없습니다. cache_control marker, 5분 및 1시간 TTL, read 할인율, write 할증이 모두 같습니다. 기존 캐싱 코드를 그대로 옮겨 쓸 수 있습니다.

token budget에 영향을 주는 변경 사항은 정확히 하나입니다. 이 변경은 4.8이 아니라 4.7에서 이미 적용됐습니다. 직접 측정할 필요가 없도록 이 글에서 결과를 정리합니다.

TL;DR

• Claude Opus 4.8의 캐싱 계약은 4.7/4.6과 같습니다. 측정된 read 할인율은 89%, write 할증은 5분 TTL에서 약 1.25배, 1시간 TTL에서 약 2배입니다.
• 같은 system text를 입력해도 Opus 4.7/4.8은 4.5/4.6보다 약 43% 많은 input token을 보고합니다(11,394 대 7,976 token).
• Opus 계열의 token당 가격은 모두 같습니다. 4.8/4.5 비용 비율 1.43은 token 비율 1.429와 일치합니다.
• Opus 4.54.8의 warm read TTFT는 2.22.8초 구간에 있습니다. 차이는 jitter 수준입니다.

아래 수치는 모두 2026-05-29에 https://synthorai.io/의 Anthropic-native /v1/messages를 대상으로 측정했습니다. 약 8K자의 영어 system prompt를 사용하고 max_tokens는 작게 설정했으며, 순차적으로 한 번 실행했습니다. 수치를 인용하기 전에 실제로 사용하는 prompt로 재현해 보십시오.

사용 방법

import os
from anthropic import Anthropic

anth = Anthropic(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/",   # SDK appends /v1/messages
)

msg = anth.messages.create(
    model="claude-opus-4-8",            # the only line that changes
    max_tokens=512,
    system=[
        {"type": "text", "text": SYSTEM_PROMPT,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": question}],
)
print(msg.usage)   # cache_creation_input_tokens, cache_read_input_tokens, cost

claude-opus-4-7을 claude-opus-4-8로 바꾸기만 하면 됩니다. 캐싱 경로의 다른 부분은 손댈 필요가 없습니다. cache_control의 동작 방식은 캐싱 튜토리얼에서 다룹니다. cache가 존재하는 이유와 아키텍처는 시리즈 1편에서 설명합니다.

캐싱 동작: 4.7/4.6과 동일

최근 Opus 계열 전체에서 동일한 cache write, cache read, cache 미사용 순서를 실행했습니다. 할인 구조는 모든 버전에서 동일했습니다.

네 버전 모두에서 다음 두 가지가 일정합니다.

• Read 할인율 ≈ 89%. warm cache read 비용은 cache를 사용하지 않을 때의 input 가격 중 약 11%입니다. Anthropic이 문서에 명시한 cached read 요율 10%와 일치하며, 변경되지 않았습니다.
• Write 할증 ≈ 25%. cache를 채우는 첫 번째 cold call의 비용은 cache 미사용 가격의 약 1.25배입니다. 한 번만 hit해도 손익분기점을 넘습니다.

4.7과 4.8의 절대 비용은 4.5/4.6보다 높습니다. 하지만 이는 cache 경제성의 변화가 아니라 token 수의 차이 때문입니다. 비율은 동일합니다.

TTL 동작: 4.7/4.6과 동일

Opus 4.8은 나머지 Opus 계열과 동일한 두 TTL을 지원합니다. 기본값은 sliding 방식의 5분이며, 명시적으로 설정하면 1시간을 사용할 수 있습니다. 이전 cache entry가 결과에 섞이지 않도록 call마다 고유한 prefix를 사용해 TTL 경로를 분리한 뒤, TTL별 write 할증을 측정했습니다.

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

usage object가 보고하는 TTL bucket도 이전과 정확히 같습니다. cache_creation.ephemeral_5m_input_tokens 또는 ephemeral_1h_input_tokens입니다. 1시간 write 비용은 cache를 사용하지 않을 때의 약 2배이며, 5분 write는 약 1.25배입니다. read 비용은 TTL과 관계없이 약 11%로 유지됩니다. 4.7과 동일합니다. 4.7에서 실시간 채팅에 5m, human-in-the-loop 대기 시간이 있는 agent에 1h를 사용했다면 4.8에서도 같은 설정을 유지하면 됩니다.

첫 token까지 걸리는 시간: 버전별 차이 없음

streaming call로 warm read TTFT를 측정했습니다. gateway를 warm-up한 뒤 모델별로 5회 측정하고 중앙값을 사용했습니다. 약 811K token 규모의 prompt에서 TTFT는 대략 2.22.8초 구간에 머물렀으며, 버전별로 유의미한 추세는 없었습니다. 측정 범위가 서로 겹치므로 차이는 버전 효과가 아니라 jitter입니다.

다음 두 가지는 명확히 짚어야 합니다.

• 이 수치로 순위를 매기면 안 됩니다. 측정 범위가 크게 겹칩니다. 4.8의 최댓값인 4.38초는 outlier였습니다. 이 정도 prompt 크기에서는 model version보다 network와 queueing jitter가 TTFT를 좌우합니다. 네 모델 모두 약 2.2~2.8초를 warm 구간으로 보면 됩니다.
• cache로 줄어드는 TTFT는 prompt 길이에 따라 커집니다. 약 811K token에서는 cache hit로 절약되는 prefill이 작기 때문에 cold와 warm TTFT가 비슷합니다. warm-up된 gateway에서는 둘 다 약 23초입니다. prefill이 지배적인 100K+ token에서는 격차가 크게 벌어집니다. 이 구간에서는 warm cache가 수 초의 대기 시간을 빠른 첫 token 응답으로 줄여 줍니다. 자세한 동작 방식은 1편: KV Cache와 TTL의 동작 방식에서 설명합니다.

실제로 달라진 한 가지: tokenization(4.7부터)

migration 전에 다시 확인해야 할 사항입니다. 같은 system text도 4.7/4.8에서는 4.5/4.6보다 약 43% 많은 input token으로 계산됩니다.

token 수는 4.7 세대에서 증가했으며 4.8에서도 그대로입니다. 비용은 token 수와 거의 정확히 비례합니다. 비용 비율(4.8 / 4.5)은 1.43이고 token 비율은 1.429입니다. Opus 전체에서 token당 가격은 같습니다. 4.7/4.8의 비용이 더 높은 이유는 같은 text가 더 많은 token으로 계산되기 때문입니다.

실무적으로 다음 두 가지를 반영해야 합니다.

1. 할인율이 아니라 절대 비용을 기준으로 budget을 다시 잡으십시오. cache 할인율은 약 89%로 변함이 없습니다. 하지만 같은 영어 prompt의 절대 비용은 4.7/4.8에서 4.6보다 약 43% 높습니다. call당 budget을 4.6의 token 수에 맞췄다면 실제 비용과 차이가 생깁니다.
2. cache 적용 기준인 1,024 token을 다시 확인하십시오. Anthropic은 최소 크기 이상의 prefix만 cache합니다. 4.6에서 기준에 조금 못 미쳤던 prompt도 token 수가 늘어난 4.7/4.8에서는 기준을 넘을 수 있습니다. 기존 tokenizer의 token 수에 맞춰 설계한 prompt도 다시 측정해야 합니다. 실제 tokenizer와 다를 수 있는 local tokenizer로 추정하지 말고, live response의 cache_creation_input_tokens / cache_read_input_tokens를 항상 확인하십시오.

여기서 설명하는 것은 측정 결과입니다. 같은 text가 4.7/4.8에서 약 43% 많은 input token으로 보고됐으며, 이는 4.7 세대의 tokenizer/vocabulary update로 보는 것이 가장 타당합니다. 원인이 무엇이든 결론은 같습니다. cache 계산은 token을 기준으로 하므로 migration할 때 token 수를 다시 측정해야 합니다.

Migration 체크리스트(4.6/4.7 → 4.8)

• ✅ 캐싱 코드는 그대로 사용할 수 있습니다. cache_control marker, breakpoint 수(최대 4개), ttl: "1h", usage field 이름이 모두 같습니다.
• ✅ TTL 선택도 유지하면 됩니다. 실시간/session workload에는 5m, 간헐적으로 요청하거나 중간에 대기하는 agent에는 1h를 사용합니다.
• ✅ 할인 구조도 같습니다. read 약 89%, write 약 1.25배(5m), write 약 2배(1h)입니다.
• ⚠️ token 수를 다시 측정하십시오. 4.5/4.6에서 옮긴다면 같은 text의 input token이 약 40% 이상 증가할 수 있습니다. 이 변화는 4.7부터 적용됐습니다. 4.7에서 옮긴다면 동일한 수준입니다.
• ⚠️ 비용 dashboard를 다시 검증하십시오. 이전 세대에서 저장해 둔 추정치가 아니라 live response의 usage.cost와 *_input_tokens field를 기준으로 삼으십시오.

결론

이미 Opus에 캐싱을 적용한 engineering team이라면 claude-opus-4-8로 쉽게 upgrade할 수 있습니다. 캐싱과 TTL interface 전체가 그대로이므로 새로 익히거나 코드를 다시 작성할 필요가 없습니다. 4.6 이하에서 옮긴다면 tokenizer 변경을 budget에 반영하고, live usage object로 수치를 확인한 뒤 배포하면 됩니다.

prompt 구조, hit rate debugging, TTL을 고려한 pattern을 포함한 전체 캐싱 실전 가이드는 KV Cache와 TTL의 동작 방식부터 시작하는 prompt caching 시리즈와 실행 가능한 Python 튜토리얼을 참고하십시오.

FAQ

Opus 4.8을 사용하려면 cache_control 코드를 변경해야 하나요? 아니요. marker syntax, breakpoint 제한, TTL option이 4.7/4.6과 같습니다. model field만 변경하면 됩니다.

4.8에서 cache read 할인율이 바뀌었나요? 아니요. 4.5부터 4.8까지 warm read 비용은 cache를 사용하지 않을 때의 input 가격 중 약 11%이며, 할인율은 약 89%입니다. Anthropic이 문서에 명시한 요율과 일치합니다.

1시간 TTL 할증이 바뀌었나요? 아니요. 1시간 write 비용은 cache 미사용 input 가격의 약 2배이고, 5분 write 비용은 약 1.25배입니다. read 비용은 TTL과 관계없이 약 11%입니다. 4.7과 같습니다.

같은 prompt가 4.6보다 4.8에서 더 비싼 이유는 무엇인가요? token당 가격은 같습니다. 다만 prompt가 더 많은 token으로 계산됩니다. 측정 결과 같은 text가 4.5/4.6에서는 약 8.0K token, 4.7/4.8에서는 약 11.4K token으로 보고됐습니다. 약 43% 증가한 수치이며, 4.7 세대의 tokenizer 변경으로 보는 것이 가장 타당합니다. cache 할인율은 바뀌지 않았습니다.

4.8을 4.7의 drop-in replacement로 사용할 수 있나요? 캐싱/TTL 측면에서는 가능합니다. token 수와 비용 구조가 4.7부터 이미 같은 수준이므로, 4.7에서 migration해도 차이가 없습니다. 직접 실행하지 않은 capability benchmark는 공개하지 않습니다. 품질과 reasoning 관련 주장은 Anthropic의 model card를 참고하십시오.

검증: 모든 캐싱, TTL, token 수, 비용, TTFT 수치는 2026-05-29에 공식 anthropic SDK를 사용해 single tenant 환경에서 https://synthorai.io/를 대상으로 측정했습니다. 비용/token 수치는 순차적으로 한 번 실행한 결과입니다. TTFT는 gateway warm-up 후 모델별 5회 측정한 중앙값입니다. 할인/할증 비율은 Anthropic Prompt Caching 문서와 대조했습니다. 실제 수치는 prompt, region, load에 따라 달라집니다.

← 블로그로 돌아가기