프롬프트 캐싱은 API 요금을 최대 90% 아껴 준다고 알려져 있습니다. 맞는 말입니다. 그런데 켜 놓고 청구서를 봤더니 오히려 늘었다는 이야기도 심심찮게 나옵니다.

둘 다 사실입니다. 캐싱은 90% 할인이 아니라 조건부 할인이라서, 조건을 못 맞추면 웃돈만 냅니다.

캐시 적중과 실패를 대비한 3D 에디터리얼 콘셉트 씬 캐시 적중과 실패를 대비한 3D 에디터리얼 콘셉트 씬 — 출처: 개념 컷 · agy 자가 생성

캐싱이 아끼는 원리

같은 내용을 매번 다시 보내는 대신, 한 번 처리한 입력을 서버가 잠시 들고 있다가 재사용하는 구조입니다. 긴 시스템 프롬프트, 문서 한 뭉치, 대화 앞부분처럼 매 호출에 똑같이 들어가는 앞부분이 대상이에요.

입력 단가를 1로 뒀을 때 프롬프트 캐싱 배수 입력 단가를 1로 뒀을 때 프롬프트 캐싱 배수 — 출처: Anthropic 공식 가격 문서 기준 자가 렌더

재사용에 성공하면(캐시 히트) 그 부분의 입력 단가가 0.1배로 떨어집니다. 원래 값의 10분의 1만 내는 셈이니 흔히 말하는 90% 할인이 여기서 나옵니다.

함정은 쓰기에 있습니다

캐시는 공짜로 만들어지지 않습니다. 처음 올려 저장하는 순간(캐시 쓰기)에는 오히려 기본 입력보다 냅니다. Anthropic 기준으로 유효시간(TTL)이 5분이면 1.25배, 1시간이면 2배예요.

정리하면 단가가 세 층입니다.

단가 층 배율
기본 입력 1배
캐시 쓰기 1.25배(5분) · 2배(1시간)
캐시 읽기 0.1배

읽기만 보면 분명히 싸지만, 읽기가 일어나려면 먼저 쓰기를 해 둬야 합니다. 쓰기 웃돈을 읽기 할인으로 회수하느냐가 전부입니다.

실제 단가로 보면 Claude Fable 5는 입력이 100만 토큰에 1만 4,000원(10달러)인데, 5분 캐시 쓰기가 1만 7,500원(12.50달러), 1시간 캐시 쓰기가 2만 8,000원(20달러), 캐시 읽기가 1,400원(1달러)입니다.

몇 번 재사용해야 이득인가

같은 앞부분을 다시 쓸 때 누적 비용 같은 앞부분을 다시 쓸 때 누적 비용 — 출처: Anthropic 공식 배수 기반 직접 계산·자가 렌더

계산은 단순합니다. 캐싱을 안 쓰면 호출마다 1배씩 내지만, 캐싱을 쓰면 첫 호출에만 쓰기 값을 내고 그다음부터는 히트마다 0.1배만 냅니다.

5분 캐시(쓰기 1.25배)로 같은 캐시를 H번 재사용하면, 캐싱 쪽은 1.25 + 0.1H, 안 쓴 쪽은 1 + H입니다. 부등식을 풀면 H가 1 이상이면 캐싱이 이깁니다. 즉 유효시간 안에 한 번만 다시 불러도 이득입니다.

1시간 캐시(쓰기 2배)는 웃돈이 커서 두 번은 재사용해야 안 쓴 쪽을 이깁니다.

캐시 유형 쓰기 배수 이득이 되는 재사용 히트가 0이면
5분 1.25배 1회부터 25% 더 낸다
1시간 2배 2회부터 100% 더 낸다

문제는 히트가 0인 경우입니다. 유효시간 안에 재사용이 한 번도 없으면, 저장만 해 두고 읽지 못해 웃돈이 고스란히 손해로 남습니다.

최신 모델은 읽기가 더 싸졌습니다

2026년 9월 1일 나온 Claude Fable 5.1과 Mythos 5.1은 캐시 읽기 단가만 따로 내렸습니다. 다른 모델이 기본 입력의 0.1배인데 이 둘은 0.025배예요. 토큰 단가로는 100만 토큰에 1,400원(1달러)에서 350원(0.25달러)으로 75% 인하입니다. 기본 입력·출력 단가는 그대로 두고 캐시 읽기만 건드렸어요.

할인율로 보면 90%가 아니라 97.5%가 됩니다. 손익분기 횟수 자체는 그대로(5분 1회, 1시간 2회)지만, 재사용이 많은 쪽일수록 차이가 커집니다. 같은 앞부분을 100번 재사용하면 읽기 0.1배는 원가의 11%를 내는데, 0.025배는 3.7%만 냅니다.

에이전트처럼 긴 시스템 프롬프트를 수백 번 되부르는 워크로드가 이 인하의 대상입니다.

캐싱이 손해가 되는 패턴

핵심은 호출 간격과 유효시간의 관계 하나입니다.

호출이 5분 안에 몰리면 저장해 둔 캐시를 그 안에 다시 읽으니 계속 이득입니다. 반대로 호출 간격이 유효시간보다 길면, 다음 호출이 올 때쯤 캐시가 이미 사라져 있어서 매번 새로 쓰기만 하고 읽기는 한 번도 못 합니다. 배수로는 1.25배씩, 매 호출 25%를 더 내는 구조가 됩니다.

이런 자리가 실제로 흔합니다.

[사이드 프로젝트] 하루에 몇 번만 호출, 사이가 몇 시간씩 벌어짐

[야간 배치] 새벽에 한 번, 다음 실행은 24시간 뒤

[사내 도구] 점심때 한 번, 퇴근 전 한 번

세 경우 다 유효시간을 한참 넘겨 호출되니, 캐싱을 켜 두면 읽기 할인은 못 받고 쓰기 웃돈만 냅니다. 트래픽이 몰리는 서비스에서 이득인 기능이 트래픽이 뜸한 곳에서는 반대로 작동합니다.

최소 길이, 모델마다 8배 차이 납니다

일정 길이를 넘어야 캐시가 잡힙니다. 그 하한이 모델마다 다른데, 차이가 작지 않아요.

하한 해당 모델
512토큰 Fable 5.1 · Mythos 5.1 · Opus 5 · Fable 5 · Mythos 5
1,024토큰 Opus 4.8 · Sonnet 5 · Sonnet 4.6 · Opus 4.1
2,048토큰 Opus 4.7 · Haiku 3.5
4,096토큰 Opus 4.6 · Opus 4.5 · Haiku 4.5

가장 낮은 512와 가장 높은 4,096이 8배 차이입니다. 1,500토큰짜리 시스템 프롬프트를 캐싱한다고 짰다면, Fable 5.1에서는 잡히지만 Haiku 4.5로 모델을 바꾸는 순간 조용히 안 잡힙니다.

하한에 못 미치면 오류가 나지 않습니다. 그냥 캐싱이 안 될 뿐이에요. 그래서 모델을 갈아탄 뒤 요금이 안 줄었다면 이 하한부터 확인해야 합니다.

제공사마다 구조가 다릅니다

같은 “프롬프트 캐싱”이라도 요금을 매기는 방식이 갈립니다.

OpenAI는 켜고 끄는 게 아니라 기본 동작입니다. GPT-5.6부터는 Anthropic과 비슷해져서 쓰기 1.25배·읽기 0.1배가 붙고 유효시간은 30분(쓰거나 읽을 때마다 갱신)입니다. 그 이전 모델들은 쓰기 웃돈이 아예 없어서 캐싱이 손해가 될 수 없었어요. 세대가 바뀌면서 구조가 바뀐 겁니다. 최소 길이는 GPT-5.6 이상 1,024토큰, 그 이전은 2,048토큰입니다.

Gemini가 제일 다릅니다. 읽기 단가는 똑같이 0.1배(90% 할인)인데, 직접 만들어 두는 캐시(explicit)에는 시간당 저장 요금이 따로 붙습니다. Gemini 3.8 Flash 기준으로 100만 토큰을 1시간 들고 있으면 700원(0.50달러)이에요. 쓰든 안 쓰든 나갑니다.

그래서 Gemini는 손익분기가 “몇 번 재사용하느냐”가 아니라 “시간당 몇 번 재사용하느냐”로 바뀝니다. 10만 토큰을 캐시해 두면 저장료가 시간당 70원(0.05달러)인데, 히트 한 번이 아껴 주는 값은 95원(0.0675달러)입니다. 10만 토큰분 입력이 1,050원에서 105원으로 줄어드는 만큼이에요. 시간당 한 번만 다시 불러도 본전을 넘습니다. 반대로 큰 문맥을 담아 두고 몇 시간씩 안 쓰면 그동안 저장료만 나갑니다.

한 가지 더, Gemini에는 자동으로 걸리는 캐싱(implicit)이 따로 있고, 이쪽은 저장 요금이 없습니다. 2.5 이상 모델에 기본으로 켜져 있어요. 최소 길이는 3.5 Flash 이상이 4,096토큰, 2.5 세대가 2,048토큰입니다.

제공사 쓰기 웃돈 읽기 유효시간 저장 요금
Anthropic 1.25배 / 2배 0.1배 (5.1은 0.025배) 5분 / 1시간 없음
OpenAI (5.6+) 1.25배 0.1배 30분(갱신) 없음
Gemini (자동) 없음 0.1배 자동 없음
Gemini (직접) 없음 0.1배 지정 시간당 별도

제대로 쓰는 법

고정된 부분을 프롬프트 맨 앞으로 몹니다. 캐시는 앞에서부터 일치하는 구간까지만 잡힙니다. 시스템 지침·예시·문서처럼 매번 같은 내용을 앞에 두고, 사용자 질문처럼 매번 바뀌는 부분을 뒤로 보내야 일치 구간이 길어집니다. 고정부 중간에 날짜나 사용자 이름 같은 변수가 끼면 그 지점부터 캐시가 깨집니다.

유효시간은 호출 빈도에 맞춥니다. 연속으로 몰아 부르면 5분으로 충분하고, 1시간짜리는 웃돈이 두 배라 재사용이 확실할 때만 켭니다. Anthropic 문서는 캐시를 읽을 때마다 유효시간이 추가 비용 없이 갱신된다고 밝히고 있어서, 자주 부르는 워크로드는 사실상 처음 한 번만 쓰기 값을 냅니다.

청구서 대신 usage를 봅니다. 응답에 딸려 오는 사용량 정보에 캐시 쓰기 토큰(cache_creation_input_tokens)과 읽기 토큰(cache_read_input_tokens)이 따로 찍힙니다. 둘 다 0이면 캐싱이 아예 안 걸린 것이고, 쓰기만 쌓이고 읽기가 안 잡히면 그 워크로드는 캐싱이 손해라는 뜻입니다.

상황 할 것
고정 시스템 프롬프트 맨 앞으로 몰기
호출 간격이 유효시간보다 김 캐싱 끄기
자주·연속 호출 5분이면 충분, 1시간은 신중
모델을 바꿨다 최소 길이 하한 다시 확인
확인 usage의 캐시 읽기·쓰기 토큰 대조

캐싱은 켜면 무조건 싸지는 기능이 아니라, 호출 패턴을 보고 켜는 조건부 최적화입니다. 트래픽이 몰리는 엔드포인트에는 켜고, 뜸한 배치에는 끄는 것만으로도 웃돈을 걷어낼 수 있습니다.

참고 출처