ஆல் Claude prompt caching: break-even கணக்கு
5 minute cache write 1.25x, read 0.1x என்பதால், ஒரே Claude prefix இரண்டாவது பயன்பாட்டிலேயே செலவை ஈடுகட்டும். API கணக்கைச் சரிபார்க்கவும்.
Prompt caching சேமிப்பை வழங்குவதற்கு முன் ஏற்படும் செலவு
Prompt caching மூலம், ஒவ்வொரு call-லும் உங்கள் prompt-ன் தொடக்கப் பகுதியை மீண்டும் படிப்பதற்குப் பதிலாக Claude அதை மீண்டும் பயன்படுத்தும். இந்த முடிவு, உங்கள் model-ன் அடிப்படை input விலைக்கு பொருந்தும் இரண்டு multipliers-ஐ அடிப்படையாகக் கொண்டது. August 2026 நிலவரப்படி, 5 minute lifetime கொண்ட cache write-க்கு base input விலையின் 1.25x செலவாகும். 1 hour lifetime கொண்ட cache write-க்கு 2x செலவாகும். Cache read-க்கு 0.1x செலவாகும். இந்த multipliers முழு model பட்டியலிலும் ஒரே மாதிரியாக இருக்கும். ஆகவே, ஒரு token-க்கான விலை மாறினாலும், கீழே உள்ள break-even கணக்கு மாறாது.
இங்கு இப்போது கூடுதல் கட்டணம் செலுத்தி, பின்னர் தள்ளுபடி பெறுகிறீர்கள். ஒரு prefix-ஐ சேமிக்க ஒருமுறை கூடுதல் கட்டணம் செலுத்த வேண்டும். அதன் பின்னர், அதே bytes-ஆகத் தொடங்கும் ஒவ்வொரு request-க்கும் அந்தப் பகுதியின் வழக்கமான input விலையின் பத்தில் ஒரு பங்கு மட்டுமே செலவாகும். ஒரு prefix அதன் lifetime-க்குள் ஒருபோதும் மீண்டும் பயன்படுத்தப்படாவிட்டால், எந்தப் பயனும் இல்லாமல் 25 percent கூடுதல் செலவு ஏற்படும்.
ஒரே algebra வரியில் break-even
Prefix-ஐ cache இல்லாமல் அனுப்பினால் ஏற்படும் அடிப்படை input cost-ஐ B என்று குறிப்பிடலாம். Caching இல்லாமல், N requests-க்கு B-ன் N மடங்கு செலவாகும். 5 minute cache பயன்படுத்தினால், முதல் request prefix-ஐ 1.25B செலவில் எழுதும்; மீதமுள்ள N minus 1 requests அதை 0.1B செலவில் வாசிக்கும். இரண்டையும் சமமாக வைத்தால் 0.9N = 1.15 கிடைக்கும்; ஆகவே N = 1.28. இரண்டாவது request-இலேயே caching செய்யாமல் இருப்பதைவிட செலவு குறைகிறது.
1 hour cache-ன் write cost 2x ஆக இருப்பதைப் பயன்படுத்தி இதையே கணக்கிட்டால் 0.9N = 1.9 கிடைக்கும்; ஆகவே N = 2.11. நீண்ட cache break-even அடைய இரண்டு reads தேவைப்படும். அதனால் இது default choice அல்ல.
கீழே உள்ள chart, Claude Opus 5-ல் 20,000 token prefix-க்கான செலவை காட்டுகிறது. August 2026 நிலவரப்படி அதன் base input rate ஒரு million tokens-க்கு $5. ஒரு million tokens-க்கு $3 செலவாகும் model-க்கு ஒவ்வொரு மதிப்பையும் 0.6-ஆல் பெருக்கவும். Curve-ன் வடிவம் மாறாது.
The data behind this chart
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]ஒரே request-க்கு caching இல்லாமல் $0.10 செலவாகும்; cache பயன்படுத்தினால் $0.125 செலவாகும். எனவே ஒருமுறை மட்டுமே பயன்படுத்தப்படும் prompt-ஐ cache செய்வது நேரடி இழப்பாகும். இரண்டாவது request-இல், 5 minute cache-ன் செலவு $0.135; caching இல்லாத செலவு $0.20. அந்த நேரத்தில் 1 hour cache இன்னும் அதிக செலவாகும்: $0.21, அதே caching இல்லாத செலவு $0.20. இது மூன்றாவது request-இல் மட்டுமே caching இல்லாத செலவைவிட குறையும்: $0.22, caching இல்லாத செலவு $0.30. 20 requests-க்கு, caching இல்லாத செலவு $2.00; cache பயன்படுத்திய செலவு $0.315.
Cache hit ஏற்பட்டால் அந்த entry-ன் lifetime மீண்டும் தொடங்கும். அதனால் வெளியிடப்பட்ட price table-ல் அந்த column-க்கு cache hits and refreshes என்று பெயரிடப்பட்டுள்ளது. எனவே busy endpoint ஒன்று 5 minute entry-ஐ read prices-ல் முடிவில்லாமல் active-ஆக வைத்திருக்கலாம். Traffic-ல் உண்மையான இடைவெளிகள் இருந்தால் மட்டுமே 1 hour lifetime-ன் 2x write cost பயனளிக்கும்.
குறைந்த cache hit rate ஏற்படுத்தும் செலவு
உண்மையான network traffic-ல் cache miss ஏற்படும். ஒரு request cache-ஐ தவறவிட்டாலும் அதில் breakpoint இருந்தால், அது write ஆகக் கணக்கிடப்படும். எனவே hit rate-ஐ அடிப்படையாகக் கொண்ட cost function மூலம் இதை கணக்கிடுவதே சரியான முறை. கீழே உள்ள chart 1,000 requests-க்கானது. ஒவ்வொரு request-லும் ஒரே 20,000 token prefix உள்ளது.
The data behind this chart
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]0 percent hit rate-ல், $125.00 செலுத்த வேண்டும்; cached ஆகாத நிலையில் இது $100.00 ஆகும். 1 hour cache பயன்படுத்தினால் bill இருமடங்காகி $200.00 ஆகும். 1.25 minus 1.15h = 1 என்ற சமன்பாட்டைத் தீர்த்தால், 5 minute cache சுமார் 22 percent hit rate-ல் இருந்து செலவைச் சேமிக்கத் தொடங்குவது தெரியும். அதனால் 25 percent hit rate-ல் ஏற்கனவே $96.25 காட்டப்படுகிறது. 2x write-க்கும் இதே கணக்கைச் செய்தால், 1 hour cache-க்கான வரம்பு சுமார் 53 percent ஆகும். எனவே 50 percent hit rate-லும் அதன் செலவு $105.00 ஆக இருக்கும்; இது uncached line-ஐவிட அதிகம். 90 percent hit rate-ல் இவை முறையே $21.50 மற்றும் $29.00 ஆகும். 99 percent hit rate-ல் short cache $11.15 அடையும். இது uncached price-ன் one tenth என்ற குறைந்தபட்ச செலவுக்கு அருகில் உள்ளது.
Prefix size நிர்ணயிக்கப்பட்ட பிறகு நீங்கள் கட்டுப்படுத்தக்கூடிய ஒரே input hit rate என்பதால், அதையே instrument செய்ய வேண்டும்.
எந்த prefixes-க்கு breakpoint அமைப்பது பயனுள்ளது
ஒரு request-ல் அதிகபட்சம் நான்கு cache breakpoints இருக்கலாம். எனவே, எந்த blocks-க்கு breakpoint தேவை என்பதே கேள்வி. Calls-க்கிடையே byte அளவில் ஒன்றேபோல் இருக்கும், மேலும் போதுமான அளவு பெரிய blocks-தான் பொருத்தமான candidates. கீழே உள்ள chart, 5 minute cache-ல் 90 percent hit rate கொண்டு 1,000 requests-க்கு நான்கு பொதுவான shapes-ன் செலவை காட்டுகிறது.
The data behind this chart
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]வெறும் 2,000 token system prompt, cache இல்லாத நிலையில் $10.00 செலவாகும் 1,000 requests-க்கு $7.85 சேமிக்கிறது. அதிக volume-ல் இது உண்மையான சேமிப்பு. ஆனால் caching சுவாரஸ்யமாக இருப்பதற்கான முக்கிய காரணம் இதல்ல. Tool definitions-ஐ சேர்த்தால், மொத்தம் 8,000 tokens ஆகும்; சேமிப்பு $31.40. ஒவ்வொரு request-லும் கேள்விகள் கேட்கப்படும் 25,000 token policy document, $98.12 சேமிக்கிறது. Architecture-ஐ மாற்றக்கூடியது கடைசி row: 120,000 tokens கொண்ட codebase அல்லது transcript context, cache இல்லாமல் $600.00 செலவாகும்; cache பயன்படுத்தினால் $129.00 மட்டுமே செலவாகும். இதனால் $471.00 சேமிக்கப்படுகிறது.
Savings, prefix size மற்றும் hit rate அதிகரிக்கும் அளவுக்கு அதிகரிக்கும். வேறு எந்த காரணியும் savings-ஐ மாற்றாது. எனவே prompt-ல் எதைச் சேர்ப்பது பயனுள்ளது என்பதும் மாறுகிறது: ஒரு million Claude tokens-ன் உண்மையான செலவு என்பதைக் காண்க. ஒன்றுக்கு மேற்பட்ட முறை அனுப்பப்படும் எந்த content-க்கும் sticker price-ன் பத்தில் ஒரு பகுதி மட்டுமே செலவாகும்.
மாதாந்திர bill-ல் இது எப்படி தெரியும்
கீழே உள்ள chart, மேலே குறிப்பிடப்பட்ட 8,000 token prefix-ஐ, ஒரு system prompt மற்றும் tool definitions-உடன், 90 percent hit rate-ல் எடுத்துக்கொண்டு, அதை மாதாந்திர request volumes-க்கு அளவிடுகிறது.
The data behind this chart
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]மாதத்திற்கு 10,000 requests இருக்கும் போது சேமிப்பு $314.00. இது $400.00 மற்றும் $86.00 ஆகியவற்றுக்கிடையிலான வித்தியாசம். 100,000 requests இருக்கும் போது சேமிப்பு $3,140.00. ஒரு million requests இருக்கும் போது caching இல்லாத input bill $40,000.00 ஆகும்; caching அதிலிருந்து $31,400.00-ஐ நீக்குகிறது. இவை input tokens-க்கு மட்டும் பொருந்தும். Output தனியாக price செய்யப்படுகிறது; caching அதில் எந்த மாற்றத்தையும் செய்யாது. எனவே, ஒருவரிடம் bill-ல் 90 percent குறைப்பு கிடைக்கும் என்று உறுதியளிப்பதற்கு முன் இதை நினைவில் கொள்ள வேண்டும். Caching என்பது VPS-ல் AI agent-ன் bill-ஐ கட்டுப்பாட்டில் வைத்திருக்கும் விரிவான நடைமுறைகளுடன் இணைந்து செயல்படும்.
cache செயல்படுகிறது என்பதை எவ்வாறு உறுதிப்படுத்துவது
வடிவமைப்பை மட்டும் நம்ப வேண்டாம். Response-இல் உள்ள usage block-ஐப் பாருங்கள். ஒவ்வொரு Messages API (application programming interface) reply-உம் அது எழுதிப் பதுக்கிய cached tokens, வாசித்த cached tokens, மேலும் புதிதாக process செய்ய வேண்டிய fresh tokens ஆகியவற்றின் எண்ணிக்கையைத் தெரிவிக்கும்.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)ஒரே document-ஐப் பயன்படுத்தி, வேறு question-உடன் இதை இரண்டு முறை இயக்கவும். முதல் call, பூஜ்ஜியமல்லாத cache_creation_input_tokens மற்றும் பூஜ்ஜியமான cache_read_input_tokens-ஐ காட்டும். Prefix கண்டறியப்பட்டதால், இரண்டாவது call இதற்கு மாறாகக் காட்டும். input_tokens, கடைசி breakpoint-க்கு பிறகு உள்ள tokens-ஐ மட்டும் எண்ணும். எனவே, சரியாகச் செயல்படும் இரண்டாவது call-ல் இது சிறியதாக இருக்கும்; பொதுவாக புதிய user message-க்கு மட்டும் சமமாக இருக்கும்.
நீங்கள் request.json-ல் சேமித்த request body-ஐப் பயன்படுத்தி, shell-லிருந்தும் இதே சோதனையைச் செய்யலாம்:
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'சரியாகச் செயல்படும் இரண்டாவது call, இதுபோன்ற ஒன்றை அச்சிடும்:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}ஒரே ஒரு line உண்மையைச் சொல்கிறது. Calls-களுக்கு இடையில் cache_read_input_tokens தொடர்ந்து 0-ஆக இருந்தால், ஒவ்வொரு முறையும் 1.25x write கட்டணத்தைச் செலுத்துகிறீர்கள்; அதற்குப் பதிலாக எதுவும் திரும்பப் பெறவில்லை.
1 hour lifetime-க்கு, breakpoint-ல் time to live (TTL) இருக்கும்:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}Automatic caching வசதியும் உள்ளது: request-ன் top level-ல் ஒரு cache_control field மட்டும் சேர்த்தால் போதும். அதன் பிறகு conversation வளரும்போது API breakpoints-ஐ நிர்வகிக்கும். இது உங்கள் நான்கு breakpoint slots-களில் ஒன்றைப் பயன்படுத்தும். முதலில் இதைப் பயன்படுத்தத் தொடங்குங்கள். Boundary துல்லியமாக எங்கு இருக்க வேண்டும் என்பதைத் தீர்மானிக்க வேண்டியபோது explicit breakpoints-க்கு மாறுங்கள்.
hit rate-ஐ அழிக்கும் ordering rule
Cache, request-ன் தொடக்கத்திலிருந்து byte-by-byte prefix-ஐ ஒப்பிடுகிறது. Request, நிலையான order-ல் உருவாக்கப்படுகிறது: முதலில் tools, அடுத்து system, பின்னர் messages. எந்த level-லாவது மாற்றம் ஏற்பட்டால், அந்த level-உம் அதற்குப் பிறகுள்ள அனைத்தும் invalidate ஆகும். ஒரு tool description-ஐ மட்டும் edit செய்தாலும், system prompt மற்றும் முழு message history-யும் அதனுடன் invalidate ஆகும்; அவற்றை நீங்கள் மாற்றாவிட்டாலும் இதுவே நடக்கும்.
இதிலிருந்து விதிவிலக்கில்லாத ஒரு rule கிடைக்கிறது. Calls-க்கு இடையில் மாறும் எதுவும், மாறாத அனைத்திற்குப் பிறகே இருக்க வேண்டும்.
பொதுவாக பிரச்சினையை ஏற்படுத்துவது timestamp. System prompt-ன் தொடக்கத்தில் Current time: 2026-08-03T14:07:11Z போன்ற ஒரு line இருந்தால், hit rate 0 percent ஆகும். ஒவ்வொரு call-லும் prefix hash மாறுவதால், முந்தைய எந்த entry-யும் அதனுடன் match ஆகாது. அதை user message-க்கு, அதன் முடிவில், மாற்றி வைக்கவும். Session identifier அல்லது ஒவ்வொரு request-க்கும் மாறும் nonce ஆகியவையும் இதேபோல் cache-ஐ பாதிக்கும்; அவற்றுக்கும் இதே தீர்வு பொருந்தும். ஒவ்வொரு request-க்கும் மாறும் retrieved documents-ஐயும் cached block-க்குப் பிறகு வைக்க வேண்டும். இல்லையெனில், நிலையான ஒவ்வொரு token-உம் நகரும் boundary-க்குப் பின்னால் தள்ளப்படும்.
இரண்டாவது பிரச்சினை, மாறும் block-லேயே breakpoint-ஐ வைப்பது. Breakpoint-ல் cache writes நடக்கும். ஆகவே அந்த block ஒவ்வொரு முறையும் மாறினால், நிலையான எதுவும் சேமிக்கப்படாது. Lookback, முந்தைய requests தங்களுடைய நகரும் breakpoints-ல் எழுதிய entries-ஐ மட்டுமே கண்டறியும். Requests அனைத்திலும் ஒரே content கொண்ட கடைசி block-ல் cache_control-ஐ வைக்கவும்.
மூன்றாவது பிரச்சினை, prompt content என நீங்கள் கருதாத parameter மாற்றம். வேறு model-க்கு வேறு cache இருக்கும். Tool choice-ஐ மாற்றினால் system level முதல் அடுத்துள்ள அனைத்தும் invalidate ஆகும். ஒரு tool-ஐ சேர்த்தாலும் அல்லது நீக்கினாலும், அனைத்தும் invalidate ஆகும்.
குறைந்தபட்ச prefix மற்றும் அமைதியான no-op
Model-ன் குறைந்தபட்ச அளவை விடக் குறுகிய prefix cache செய்யப்படாது. இதைத் தெரிவிக்கும் எந்த அறிகுறியும் இருக்காது. Error அல்லது warning எதுவும் வராது. Request வெற்றிகரமாக நிறைவேறும்; இரண்டு counters-உம் 0 எனக் காட்டும். August 2026 நிலவரப்படி வெளியிடப்பட்ட குறைந்தபட்ச அளவுகள்:
- Claude Opus 5 மற்றும் Claude Fable 5-க்கு 512 tokens
- Claude Sonnet 5 மற்றும் Claude Opus 4.8-க்கு 1,024 tokens
- Claude Haiku 4.5-க்கு 4,096 tokens
Cache செய்யப்பட்டிருக்க வேண்டும் என்று நீங்கள் கருதும் request-ல் இரண்டு counters-உம் 0 எனக் காட்டினால், முதலில் prefix length-ஐச் சரிபார்க்கவும். Caching workload-க்கு குறைந்த விலை model தானாகவே மிகக் குறைந்த செலவுடையதாக இருக்காது என்பதற்கும் இதுவே காரணம். Caching செயல்படுவதற்கு முன் Haiku 4.5-க்கு Opus 5-ஐ விட எட்டு மடங்கு நீளமான prefix தேவைப்படுகிறது. எனவே, 2,000 token system prompt ஒரு model-ல் cache செய்யப்படும்; மற்ற model-ல் அது அமைதியாகப் புறக்கணிக்கப்படும்.
Claude Code உங்களுக்காக cache செய்யும் இடமும், அது உதவ முடியாத இடமும்
Claude Code தனது சொந்த prefix-ஐ cache செய்கிறது. ஒவ்வொரு request-ன் தொடக்கத்திலும் system prompt மற்றும் tool definitions இடம்பெறும்; அவை மாறாததால், ஒருமுறை எழுதப்பட்ட பிறகு session-ன் மீதமுள்ள காலத்தில் மீண்டும் வாசிக்கப்படுகின்றன. அதனால், context size காட்டுவதைக் காட்டிலும் நீண்ட session-ன் ஒவ்வொரு turn-க்கான செலவு மிகவும் குறைவாக இருக்கும். இது Claude Code token usage-ஐ எவ்வாறு தெரிவிக்கிறது என்பதில் விளக்கப்பட்ட counters-ல் தெரியும்.
ஆனால் context-ன் தொடக்கத்துக்கு அருகிலுள்ள edit-களுக்கு இது உதவாது. Conversation history append-only ஆகும். எனவே, வழக்கமான புதிய turn-கள் ஏற்கனவே cache செய்யப்பட்ட prefix-ஐ நீட்டிக்கும். Session-ன் தொடக்கத்தில் வாசிக்கப்பட்ட file-ஐ edit செய்தால், அந்த prefix-ன் நடுப்பகுதியில் content மாறும். அந்த மாற்றத்திற்குப் பிறகு வரும் ஒவ்வொரு token-மும் மீண்டும் எழுதப்பட வேண்டும். நீண்ட idle gap இருந்தாலும் இதே நிலை ஏற்படும். Entry expire ஆகும்; அடுத்த turn முழு write-க்கான செலவைச் செலுத்தும். இவை இரண்டும் bug அல்ல. Prefix rule கூறுவது போலவே இவை செயல்படுகின்றன.
அதற்குப் பதிலாக உங்கள் சொந்த client-ஐ எழுதுகிறீர்கள் என்றால், பின்னர் layout-ஐ மாற்றாமல் முதல் request-இலிருந்தே சரியாக அமைக்கவும். VPS-ல் முதல் Claude API app-ஐ உருவாக்குவது காட்டும் முறையில் call-ஐ உருவாக்குங்கள். முதலில் நிலையான blocks-ஐவும், இறுதியில் மாறக்கூடிய blocks-ஐவும் வைக்கவும்.
தோல்வி நிலைகள் மற்றும் நீங்கள் காண்பது
ஒவ்வொரு call-உம் write ஆகும். ஒவ்வொரு request-இலும் cache_creation_input_tokens non-zero நிலையில் இருக்கும்; அதேவேளையில் cache_read_input_tokens 0 ஆகவே இருக்கும். Breakpoint-க்கு முன் அல்லது அதில் உள்ள ஏதோ ஒன்று, ஒவ்வொரு call-க்கும் இடையில் மாறுகிறது. தொடர்ச்சியான இரண்டு request-களில் உருவாக்கப்பட்ட prefix-ன் முதல் 200 characters-ஐ print செய்து, அவற்றை நேரடியாக ஒப்பிடவும்.
இரண்டு counters-உம் 0 ஆகும். Prefix, model minimum-ஐ விடக் குறைவாக இருக்கலாம்; அல்லது cache_control field API-யை அடையாமல் இருக்கலாம். முதலில் prefix tokens-ஐ count செய்யவும். பின்னர் உண்மையில் அனுப்பிய request body-ஐ log செய்யவும்.
Reads செயல்பட்டு, பின்னர் நிற்கும். முதலில் தொடர்ச்சியாக hits கிடைக்கும்; பின்னர் ஒரு write வரும்; அதன் பிறகு மீண்டும் hits கிடைக்கும். Requests-க்கு இடையிலான இடைவெளி lifetime-ஐ விட நீண்டதாக இருந்தது. அந்த write-ஐ ஏற்கவும். அல்லது உங்கள் hit rate 53 percent-ஐத் தாண்டுகிறது என்பதைச் சரிபார்த்த பிறகு 1 hour TTL-க்கு மாற்றவும்.
Deploy செய்த பிறகு hit rate குறையும். Tool description திருத்தப்பட்டிருக்கலாம் அல்லது model மாற்றப்பட்டிருக்கலாம். இவ்விரண்டும் முழு prefix-ஐ invalidate செய்யும். Prompt-ஐ பாதிக்கும் ஒவ்வொரு deploy-க்குப் பிறகும், செலவு அதிகமான ஒரு write round வரும் என எதிர்பார்க்கவும்.
Caching enabled செய்த பிறகு bill அதிகரித்தது. உங்கள் hit rate break-even அளவை விடக் குறைவாக உள்ளது. 5 minute cache-இல் சுமார் 22 percent-க்கும் குறைவாக இருந்தால், prefix-ஐ cache செய்யாமல் அனுப்புவது மலிவானது. 1 hour cache-இல் சுமார் 53 percent-க்கும் குறைவாக இருந்தாலும் இதே நிலைதான்.
FAQ
ஒரு prompt-ஐ cache செய்வது பயனளிக்கத் தொடங்குவதற்கு, அதை எத்தனை முறை மீண்டும் பயன்படுத்த வேண்டும்?
5 minute cache-இல் ஒருமுறை போதுமானது. Write-க்கு base input கட்டணத்தின் 1.25x செலவாகும்; read-க்கு 0.1x செலவாகும். ஆகவே, cache இல்லாத N requests-க்கு N செலவாகும். Cache செய்யப்பட்ட N requests-க்கு 1.25 plus 0.1 times N minus 1 செலவாகும். இவை N = 1.28-ல் சமமாகின்றன. எனவே, இரண்டாவது request முதலே cache பயன்பாடு அதிக செலவுச்செலுத்தலாக இருக்கும். 1 hour cache-இல் write கட்டணம் 2x. இது N = 2.11-ல் சமமாகும். ஆகவே, அதற்கு இரண்டு reads தேவைப்படும்.
cache_read_input_tokens எப்போதும் zero-ஆக இருப்பது ஏன்?
முதலில் prefix length-ஐச் சரிபார்க்கவும். Model minimum-க்குக் குறைவாக இருந்தால் caching அமைதியாகத் தவிர்க்கப்படும்; ஆகஸ்ட் 2026 நிலவரப்படி Claude Opus 5-க்கு 512 tokens-மும், Claude Haiku 4.5-க்கு 4,096 tokens-மும் குறைந்தபட்ச அளவாகும். அப்போது இரண்டு counters-உம் 0-ஆக இருக்கும். Prefix போதுமான நீளத்தில் இருந்தால், breakpoint-இல் அல்லது அதற்கு முன் calls-க்கு இடையில் மாறும் content உள்ளதா என்பதைப் பார்க்கவும். System prompt-இல் உள்ள timestamp அல்லது session identifier இதற்கான எடுத்துக்காட்டுகள். Counters முன்பு இயங்கி பின்னர் நின்றிருந்தால், requests-க்கு இடையிலான இடைவெளி cache lifetime-ஐவிட நீண்டதாக இருந்திருக்கலாம்.
prompt caching Claude-ன் answers-ஐ மாற்றுமா?
இல்லை. நீங்கள் ஏற்கனவே அனுப்பிய tokens-ன் processed form-ஐ cache சேமிக்கும். இரண்டு நிலைகளிலும் model அதே prompt-ஐப் பார்க்கும். இது billing மற்றும் latency feature; behaviour-ஐ மாற்றும் feature அல்ல. எனவே, ஏற்கனவே செயல்படும் prompt-இல் இதை enable செய்தாலும் evaluations-ஐ மீண்டும் இயக்க வேண்டியதில்லை.
1 hour cache-க்கு கட்டணம் செலுத்த வேண்டுமா?
உங்கள் traffic-க்கு 5 minutes-ஐவிட நீண்ட gaps இருக்கும் போது மட்டுமே செலுத்தவும். அப்போது hit rate தோராயமாக 53 percent-ஐத் தாண்டும் என்பதை உறுதிப்படுத்த வேண்டும். Cache miss ஏற்படும் போது, 2x write என்பது 1.25x write-ன் downside-ஐவிட இருமடங்கு. 5 minute entry ஒவ்வொரு hit-இலும் refresh ஆகும். எனவே, தொடர்ந்து வரும் traffic read prices-ல் அதை active-ஆக வைத்திருக்கும்; நீண்ட lifetime-க்கான கூடுதல் கட்டணத்தைச் செலுத்த வேண்டியதில்லை.