ஆல் Claude Prompt Caching: லாபகரமான பயன்பாட்டிற்கான கணக்கீடு
Cache write 1.25x மற்றும் read 0.1x விலையில் கிடைப்பதால், இரண்டாவது பயன்பாட்டிலேயே லாபம் கிடைக்கிறது. உங்கள் API பயன்பாட்டிற்கு ஏற்ப break-even புள்ளியை கணக்கிடுவது எப்படி?
Prompt caching சேமிப்பைத் தொடங்கும் முன் அதன் செலவுகள்
Prompt caching மூலம், ஒவ்வொரு அழைப்பின் போதும் உங்கள் prompt-ன் முன்பகுதியை மீண்டும் வாசிப்பதற்குப் பதிலாக, Claude அதை மீண்டும் பயன்படுத்திக்கொள்ள முடியும். இந்த முழு முடிவும் உங்கள் model-ன் அடிப்படை input விலையில் உள்ள இரண்டு பெருக்கிகளைப் (multipliers) பொறுத்தது. ஆகஸ்ட் 2026 நிலவரப்படி, 5 நிமிட ஆயுட்காலத்திற்கு cache write என்பது அடிப்படை input விலையில் 1.25x ஆகவும், 1 மணிநேர ஆயுட்காலத்திற்கு 2x ஆகவும் உள்ளது. ஒரு cache read என்பது 0.1x செலவாகும். இந்த பெருக்கிகள் அனைத்து model பட்டியலுக்கும் பொருந்தும், எனவே per-token விலை மாறினாலும் கீழே உள்ள break-even புள்ளி மாறாது.
இது இப்போது கூடுதல் கட்டணம் செலுத்தி, பின்னாளில் தள்ளுபடி பெறும் ஒரு பரிமாற்றமாகும். ஒரு prefix-ஐச் சேமிக்க நீங்கள் ஒருமுறை கூடுதல் கட்டணம் செலுத்துகிறீர்கள். அதன் பிறகு, அதே bytes-ஐக் கொண்டு தொடங்கும் ஒவ்வொரு கோரிக்கையும், அந்தப் பகுதிக்கு சாதாரண input விலையில் பத்தில் ஒரு பங்கு மட்டுமே செலுத்தும். அதன் ஆயுட்காலத்திற்குள் மீண்டும் பயன்படுத்தப்படாத ஒரு prefix, உங்களுக்கு 25 சதவீதம் கூடுதல் செலவை மட்டுமே தரும்.
Break-even புள்ளியை ஒரு வரி இயற்கணிதத்தில் (algebra) கணக்கிடுதல்
B என்பது cache செய்யப்படாத நிலையில் ஒரு prefix-க்கான அடிப்படை உள்ளீட்டுச் செலவு (base input cost) எனக் கொள்வோம். Caching இல்லையெனில், N கோரிக்கைகளுக்கு (requests) N முறை B செலவாகும். 5 நிமிட cache-ஐப் பயன்படுத்தினால், முதல் கோரிக்கை 1.25B செலவில் prefix-ஐ எழுதுகிறது, மீதமுள்ள N minus 1 கோரிக்கைகள் 0.1B செலவில் அதை வாசிக்கின்றன. இரண்டையும் சமப்படுத்தினால் 0.9N = 1.15 கிடைக்கும், எனவே N = 1.28. இரண்டாவது கோரிக்கையிலேயே cache செய்யாததை விட இது மலிவானதாகிவிடுகிறது.
இதே கணக்கீட்டை 1 மணிநேர cache-ன் 2x எழுதும் செலவோடு ஒப்பிட்டால், 0.9N = 1.9 கிடைக்கும், எனவே N = 2.11. நீண்ட கால cache லாபகரமாக மாற இரண்டு வாசிப்புகள் தேவைப்படுகின்றன, இதனாலேயே இது இயல்புநிலைத் தேர்வாக (default choice) இல்லை.
கீழே உள்ள வரைபடம், ஆகஸ்ட் 2026 நிலவரப்படி ஒரு மில்லியன் tokens-க்கு $5 அடிப்படை உள்ளீட்டு விலையைக் கொண்ட Claude Opus 5-ல் 20,000 token prefix-க்கான விலையைக் காட்டுகிறது. ஒரு மில்லியன் tokens-க்கு $3 விலை கொண்ட மாடலுக்கு, ஒவ்வொரு மதிப்பையும் 0.6-ஆல் பெருக்கிக்கொள்ளவும். வரைபடத்தின் வடிவம் மாறாது.
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"
}
]ஒரு தனிப்பட்ட கோரிக்கையின் விலை cache செய்யப்படாத நிலையில் $0.10 மற்றும் cache செய்யப்பட்ட நிலையில் $0.125 ஆகும், எனவே ஒருமுறை மட்டும் பயன்படுத்தப்படும் prompt-ஐ cache செய்வது நஷ்டத்தையே தரும். இரண்டாவது கோரிக்கையிலேயே, 5 நிமிட cache-ன் விலை $0.20-க்கு எதிராக $0.135 ஆகக் குறைகிறது. அந்த நிலையில் 1 மணிநேர cache இன்னும் பின்தங்கியே உள்ளது, அதாவது $0.20-க்கு எதிராக $0.21 ஆக உள்ளது. இது மூன்றாவது கோரிக்கையில்தான் cache செய்யப்படாத விலையை விடக் குறைகிறது: $0.30-க்கு எதிராக $0.22. 20 கோரிக்கைகள் வரும்போது, இடைவெளி $2.00-க்கு எதிராக $0.315 என அமைகிறது.
ஒரு cache hit அந்தப் பதிவைப் புதுப்பிக்கிறது, இதனால்தான் வெளியிடப்பட்ட விலை அட்டவணையில் அந்த நெடுவரிசை 'cache hits and refreshes' என்று அழைக்கப்படுகிறது. எனவே, ஒரு பிஸியான endpoint, 5 நிமிடப் பதிவை வாசிப்பு விலையிலேயே காலவரையின்றி உயிர்ப்புடன் வைத்திருக்கும். உங்கள் traffic-ல் உண்மையான இடைவெளிகள் இருக்கும்போது மட்டுமே 1 மணிநேர ஆயுட்காலம் அதன் 2x எழுதும் செலவை ஈடுசெய்கிறது.
குறைந்த hit rate-ஆல் ஏற்படும் செலவு
உண்மையான traffic-ல் cache misses நிகழ்கின்றன. ஒரு request cache-ல் கிடைக்காமல், அதே சமயம் breakpoint-ஐக் கொண்டிருந்தால், அது write-ஆகக் கணக்கிடப்படும். எனவே, hit rate-ன் செயல்பாடாகச் செலவைக் கணக்கிடுவதே சரியான முறையாகும். கீழே உள்ள வரைபடம் 1,000 requests-க்கான செலவைக் காட்டுகிறது; ஒவ்வொன்றும் ஒரே மாதிரியான 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 சதவீத hit rate-ல், நீங்கள் $100.00-க்கு பதிலாக $125.00 செலுத்த வேண்டியிருக்கும். 1 மணிநேர cache இந்தச் செலவை $200.00 என இரட்டிப்பாக்குகிறது. 1.25 minus 1.15h = 1 என்ற சமன்பாட்டைத் தீர்த்தால், 5 நிமிட cache சுமார் 22 சதவீத hit rate-ல் லாபத்தைத் தரத் தொடங்கும். இதனால்தான் 25 சதவீதத்தில் $96.25 எனக் காட்டப்படுகிறது. 2x write-க்கு இதே கணக்கீட்டைச் செய்தால், 1 மணிநேர cache-க்கு சுமார் 53 சதவீதம் தேவைப்படுகிறது. எனவே, 50 சதவீத hit rate-ல் கூட செலவு $105.00 என uncached விலையை விட அதிகமாகவே இருக்கும். 90 சதவீதத்தில் இவை முறையே $21.50 மற்றும் $29.00 ஆகிய புள்ளிகளை அடைகின்றன. 99 சதவீதத்தில், குறுகிய கால cache $11.15 என்ற நிலையை அடைகிறது, இது uncached விலையில் பத்தில் ஒரு பங்கு என்ற குறைந்தபட்ச அளவை நெருங்குகிறது.
Prefix அளவு நிர்ணயிக்கப்பட்ட பிறகு, நீங்கள் கட்டுப்படுத்தக்கூடிய ஒரே காரணி hit rate என்பதால், அதையே நீங்கள் கண்காணிக்க (instrument) வேண்டும்.
எந்தெந்த முன்னொட்டுகள் (prefixes) breakpoint-க்கு தகுதியானவை
ஒரு கோரிக்கையில் (request) நான்கு cache breakpoints வரை இருக்கலாம், எனவே எந்தெந்த தொகுதிகள் (blocks) இதற்குத் தகுதியானவை என்பதுதான் கேள்வி. வெவ்வேறு அழைப்புகளிலும் (calls) ஒரே மாதிரியான பைட் (byte-identical) கொண்ட மற்றும் குறிப்பிடத்தக்க அளவுள்ள தொகுதிகள் இதற்கான வேட்பாளர்கள். கீழே உள்ள அட்டவணை, 5 நிமிட cache-ல் 90 சதவீத வெற்றி விகிதத்தில் (hit rate), 1,000 கோரிக்கைகளுக்கு நான்கு பொதுவான வடிவங்களின் விலையை விளக்குகிறது.
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 கோரிக்கைகளுக்கு $7.85 சேமிப்பைத் தருகிறது. அதிகப்படியான பயன்பாட்டில் இது உண்மையான பணச் சேமிப்புதான், ஆனால் இது மட்டும் cache-ஐ சுவாரஸ்யமாக்குவதில்லை. இதனுடன் tool definitions-ஐச் சேர்த்தால், நீங்கள் 8,000 tokens-ஐப் பெறுவீர்கள் மற்றும் $31.40 சேமிக்கப்படும். ஒவ்வொரு கோரிக்கையிலும் வினவப்படும் 25,000 token கொண்ட policy ஆவணம் $98.12 சேமிப்பை வழங்குகிறது. கடைசி வரிசைதான் கட்டமைப்பையே மாற்றக்கூடியது: 120,000 tokens கொண்ட codebase அல்லது transcript context, cache செய்யப்படாத நிலையில் $600.00 செலவாகிறது, ஆனால் cache செய்யப்பட்ட நிலையில் $129.00 மட்டுமே செலவாகிறது; இதன் மூலம் $471.00 சேமிக்கப்படுகிறது.
சேமிப்பானது முன்னொட்டின் அளவு (prefix size) மற்றும் வெற்றி விகிதத்தைப் (hit rate) பொறுத்து மட்டுமே அமையும், வேறு எதையும் பொறுத்ததல்ல. இது ஒரு prompt-ல் எதைச் சேர்க்கலாம் என்பதையே மாற்றுகிறது: நீங்கள் ஒன்றுக்கு மேற்பட்ட முறை அனுப்பும் எதற்கும், ஒரு மில்லியன் Claude tokens-ன் உண்மையான விலை அதன் அசல் விலையில் பத்தில் ஒரு பங்காகக் குறைகிறது.
மாதாந்திர கட்டணத்தில் இது எவ்வாறு பிரதிபலிக்கும்
கீழே உள்ள அட்டவணை, மேலே குறிப்பிடப்பட்டுள்ள 8,000 டோக்கன் முன்னொட்டு (token prefix), ஒரு system prompt மற்றும் tool வரையறைகளை 90 சதவீத வெற்றி விகிதத்தில் (hit rate) எடுத்துக்கொண்டு, அவற்றை மாதாந்திர கோரிக்கை அளவுகளுக்கு (monthly 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 கோரிக்கைகள் என்ற அளவில், சேமிப்புத் தொகை $314.00 ஆகும். இது $400.00 மற்றும் $86.00 ஆகியவற்றுக்கு இடையேயான வித்தியாசமாகும். 100,000 கோரிக்கைகளுக்கு இந்த சேமிப்பு $3,140.00 ஆக இருக்கும். பத்து லட்சம் கோரிக்கைகளுக்கு, caching இல்லாத உள்ளீட்டு கட்டணம் (uncached input bill) $40,000.00 ஆகும், இதில் caching மூலம் $31,400.00 சேமிக்கப்படுகிறது. இவை உள்ளீட்டு டோக்கன்களுக்கு (input tokens) மட்டுமே பொருந்தும். வெளியீட்டு டோக்கன்கள் (output) தனித்தனியாக விலை நிர்ணயிக்கப்படுகின்றன, அவற்றுக்கு caching எந்தப் பலனையும் தராது. எனவே, யாருக்காவது 90 சதவீத கட்டணக் குறைப்பு கிடைக்கும் என்று வாக்குறுதி அளிக்கும் முன் இதை நினைவில் கொள்வது அவசியம். Caching என்பது VPS-ல் AI agent-ன் கட்டணத்தை கட்டுக்குள் வைத்திருத்தல் தொடர்பான விரிவான நடைமுறைகளுடன் இணைந்து செயல்படுகிறது.
cache சரியாகச் செயல்படுகிறதா என்பதை உறுதிப்படுத்துவது எப்படி
வடிவமைப்பை மட்டும் நம்ப வேண்டாம். response-ல் உள்ள usage பகுதியை கவனிக்கவும். ஒவ்வொரு Messages API (application programming interface) பதிலும் அது எழுதிய cached tokens, வாசித்த cached tokens மற்றும் அது கையாள வேண்டிய 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)ஒரே ஆவணத்தைப் பயன்படுத்தி, வெவ்வேறு கேள்விகளுடன் இதை இரண்டு முறை இயக்கவும். முதல் அழைப்பு பூஜ்ஜியமற்ற cache_creation_input_tokens மற்றும் பூஜ்ஜியமான cache_read_input_tokens மதிப்பைக் காட்டும். இரண்டாவது அழைப்பு இதை மாற்றியமைக்கும், ஏனெனில் prefix கண்டறியப்பட்டது. input_tokens என்பது கடைசி breakpoint-க்கு பிறகுள்ள tokens-ஐ மட்டுமே கணக்கிடும், எனவே சரியாகச் செயல்படும் இரண்டாவது அழைப்பில் இதன் மதிப்பு குறைவாக, பொதுவாக புதிய பயனர் செய்தியாக மட்டுமே இருக்கும். இரண்டு அழைப்புகளுக்கும் கட்டணம் வசூலிக்கப்படும், ஏனெனில் the Claude API has no free tier, இருப்பினும் மேலே குறிப்பிடப்பட்ட 20,000 token prefix-க்கு இந்த ஜோடிக்கு சுமார் பதினான்கு சென்ட்கள் செலவாகும்.
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'சரியாகச் செயல்படும் இரண்டாவது அழைப்பு இது போன்ற வெளியீட்டைத் தரும்:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}ஒரு வரி உங்களுக்கு உண்மையைச் சொல்லும். அழைப்புகளுக்கு இடையிலும் cache_read_input_tokens மதிப்பு 0-ஆகவே இருந்தால், நீங்கள் ஒவ்வொரு முறையும் 1.25x write கட்டணத்தைச் செலுத்துகிறீர்கள், ஆனால் அதற்குப் பதிலாக எதையும் பெறவில்லை என்று அர்த்தம்.
1 மணிநேர ஆயுட்காலத்திற்கு, breakpoint ஒரு time to live (TTL)-ஐக் கொண்டுள்ளது:
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}தானியங்கி caching வசதியும் உள்ளது: request-ன் மேல் மட்டத்தில் ஒரு cache_control புலம் உள்ளது, உரையாடல் வளரும்போது API-யே breakpoint-களை நிர்வகிக்கும். இது உங்கள் நான்கு breakpoint slots-ல் ஒன்றை எடுத்துக்கொள்ளும். அங்கிருந்து தொடங்கவும். எல்லை எங்கு அமைய வேண்டும் என்பதை நீங்கள் துல்லியமாகத் தீர்மானிக்க வேண்டியிருக்கும் போது, explicit breakpoint-களுக்கு மாறவும்.
Hit rate-ஐ பாதிக்கும் வரிசைமுறை விதி
Cache ஆனது கோரிக்கையின் தொடக்கத்திலிருந்து ஒவ்வொரு byte-ஆக prefix-ஐ ஒப்பிடுகிறது. கோரிக்கைகள் ஒரு நிலையான வரிசையிலேயே கட்டமைக்கப்படுகின்றன: முதலில் tools, பிறகு system, இறுதியாக messages. ஏதேனும் ஒரு நிலையில் மாற்றம் ஏற்பட்டால், அந்த நிலையும் அதற்குப் பின் வரும் அனைத்தும் செல்லாததாகிவிடும். நீங்கள் ஒரு tool விளக்கத்தை மட்டும் மாற்றினாலும், system prompt மற்றும் முழு message history-யும் அதனுடன் சேர்ந்து செல்லாததாகிவிடும்; நீங்கள் அவற்றை மாற்றவில்லை என்றாலும் இதுவே நடக்கும்.
இதற்கு விதிவிலக்கற்ற ஒரே ஒரு விதி உள்ளது. ஒவ்வொரு அழைப்பிற்கும் இடையில் மாறும் எதையும், மாறாத அனைத்திற்கும் பின்பே வைக்க வேண்டும்.
பொதுவாக இதற்குத் தடையாக இருப்பது timestamp ஆகும். ஒரு system prompt-ன் தொடக்கத்தில் Current time: 2026-08-03T14:07:11Z என்று ஒரு வரி இருந்தால், அது 0 சதவீத hit rate-ஐ உறுதி செய்கிறது. ஏனெனில், ஒவ்வொரு அழைப்பிலும் prefix hash மாறுவதால், அதற்கு முந்தைய எந்தவொரு பதிவும் பொருந்தாது. அதை user message-ன் இறுதியில் நகர்த்தவும். ஒரு session identifier அல்லது ஒவ்வொரு கோரிக்கைக்கும் உரிய nonce ஆகியவையும் இதே சிக்கலை உருவாக்கும், அவற்றுக்கும் அதே தீர்வே பொருந்தும். ஒவ்வொரு கோரிக்கைக்கும் மாறுபடும் ஆவணங்களும் (retrieved documents) cached block-க்கு பின்பே வர வேண்டும்; இல்லையெனில் அவை மாறக்கூடிய எல்லைக்கு பின்னால் அனைத்து நிலையான token-களையும் தள்ளிவிடும்.
இரண்டாவது சிக்கல், மாறும் தன்மையுள்ள block-ல் breakpoint-ஐ வைப்பது. Cache எழுதும் பணி breakpoint-ல் தான் நடக்கும். எனவே, அந்த block ஒவ்வொரு முறையும் மாறினால், நிலையான எதுவும் சேமிக்கப்படாது. மேலும், lookback தேடலில் முந்தைய கோரிக்கைகள் அவற்றின் சொந்த நகரும் breakpoint-களில் எழுதிய பதிவுகள் மட்டுமே கிடைக்கும். cache_control-ஐ அனைத்து கோரிக்கைகளிலும் உள்ளடக்கத்தில் மாற்றமில்லாத கடைசி block-ல் வைக்கவும்.
மூன்றாவது சிக்கல், நீங்கள் prompt-ன் உள்ளடக்கம் என்று கருதாத ஒரு parameter மாற்றம். வெவ்வேறு model-களுக்கு வெவ்வேறு cache இருக்கும். Tool தேர்வை மாற்றினால், system நிலையிலிருந்து அனைத்தும் செல்லாததாகிவிடும். ஒரு tool-ஐச் சேர்ப்பதோ அல்லது நீக்குவதோ அனைத்தையும் செல்லாததாக்கிவிடும்.
குறைந்தபட்ச முன்னொட்டு (prefix) மற்றும் அமைதியான no-op
மாதிரியின் (model) குறைந்தபட்ச அளவை விடக் குறைவான முன்னொட்டு cache செய்யப்படாது, இது குறித்து எந்த அறிவிப்பும் வராது. பிழையோ அல்லது எச்சரிக்கையோ காட்டப்படாது. கோரிக்கை வெற்றிகரமாக நிறைவேறும், ஆனால் இரண்டு counters-ம் 0 என்றே காட்டும். ஆகஸ்ட் 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 செய்யப்பட வேண்டிய கோரிக்கையில் இரண்டு counters-ம் 0 என்று காட்டினால், முதலில் முன்னொட்டின் நீளத்தைச் சரிபார்க்கவும். இதனால்தான், caching பணிச்சுமைக்கு மலிவான மாதிரி எப்போதும் மலிவானதாக இருப்பதில்லை. Haiku 4.5-ல் caching தொடங்குவதற்கு, Opus 5-ஐ விட எட்டு மடங்கு நீளமான முன்னொட்டு தேவைப்படுகிறது. எனவே, 2,000 tokens கொண்ட system prompt ஒரு மாதிரியில் cache ஆகலாம், மற்றொன்றில் எந்த அறிவிப்பும் இன்றி தவிர்க்கப்படலாம்.
Claude Code எங்கு cache செய்கிறது, எங்கு செய்ய முடியாது
Claude Code தனது prefix-ஐத் தானே cache செய்துகொள்கிறது. System prompt மற்றும் tool definitions ஆகியவை ஒவ்வொரு கோரிக்கையின் தொடக்கத்திலும் இருப்பதால் அவை மாறுவதில்லை; எனவே, அவை ஒருமுறை எழுதப்பட்டு, அமர்வு முழுவதும் மீண்டும் படிக்கப்படுகின்றன. இதனால்தான் நீண்ட அமர்வுகளின் ஒவ்வொரு turn-க்கான செலவு, context அளவை விட மிகக் குறைவாக உள்ளது. இது Claude Code token பயன்பாட்டை எவ்வாறு காட்டுகிறது என்பதில் விவரிக்கப்பட்டுள்ள counters-ல் பிரதிபலிக்கும்.
Context-ன் தொடக்கத்திற்கு அருகில் நீங்கள் மாற்றம் செய்யும்போது, இந்த வசதி உதவாது. உரையாடல் வரலாறு (conversation history) என்பது append-only முறையில் இருப்பதால், புதிய turn-கள் ஏற்கனவே cache செய்யப்பட்ட prefix-ஐ நீட்டிக்கின்றன. அமர்வின் தொடக்கத்தில் படிக்கப்பட்ட ஒரு கோப்பைத் திருத்தும்போது, அந்த prefix-ன் நடுவில் உள்ள உள்ளடக்கம் மாறுகிறது; எனவே, மாற்றத்திற்குப் பிறகுள்ள ஒவ்வொரு token-ம் மீண்டும் எழுதப்பட வேண்டும். நீண்ட நேரம் பயன்படுத்தாமல் இருந்தாலும் இதே நிலைதான் ஏற்படும், ஏனெனில் அந்த entry காலாவதியாகிவிடும், அடுத்த turn-ல் முழுமையாக மீண்டும் எழுத வேண்டியிருக்கும். இவை இரண்டும் பிழைகள் அல்ல. இவை prefix விதியின்படி சரியாகச் செயல்படுவதையே குறிக்கின்றன.
நீங்கள் சொந்தமாக client உருவாக்கினால், ஏற்கனவே உள்ளதை மாற்றியமைப்பதற்குப் பதிலாக, முதல் கோரிக்கையிலிருந்தே சரியான layout-ஐப் பயன்படுத்துங்கள்: VPS-ல் முதல் Claude API app உருவாக்குவது போல, மாறாத blocks-ஐ முதலில் வைத்தும், அடிக்கடி மாறும் தகவல்களைக் கடைசியிலும் வைத்து கட்டமைக்கவும்.
தோல்வி முறைகள் மற்றும் நீங்கள் காண்பவை
ஒவ்வொரு அழைப்பும் ஒரு write ஆகும். ஒவ்வொரு கோரிக்கையின் போதும் cache_creation_input_tokens பூஜ்ஜியமற்றதாக இருக்கும், அதே சமயம் cache_read_input_tokens 0 ஆகவே இருக்கும். அழைப்புகளுக்கு இடையே breakpoint-ல் அல்லது அதற்கு முன்னால் ஏதோ ஒன்று மாறுகிறது. அடுத்தடுத்த இரண்டு கோரிக்கைகளின் போது, நீங்கள் உருவாக்கிய prefix-ன் முதல் 200 எழுத்துக்களை print செய்து, அவற்றை ஒப்பிட்டுப் பார்க்கவும்.
இரண்டு counters-ம் 0. prefix ஆனது model minimum-க்குக் குறைவாக உள்ளது, அல்லது cache_control புலம் API-ஐ ஒருபோதும் அடையவில்லை. முதலில் prefix tokens-ஐ எண்ணுங்கள், பிறகு நீங்கள் உண்மையில் அனுப்பிய request body-ஐ log செய்யுங்கள்.
Reads வேலை செய்கிறது, பிறகு நின்றுவிடுகிறது. சில வெற்றிகள் (hits), பிறகு ஒரு write, மீண்டும் வெற்றிகள். கோரிக்கைகளுக்கு இடையிலான இடைவெளி, lifetime-ஐ விட அதிகமாக இருந்தது. அந்த write-ஐ ஏற்றுக்கொள்ளுங்கள், அல்லது உங்கள் hit rate 53 சதவீதத்தைத் தாண்டிவிட்டதை உறுதி செய்த பிறகு 1 hour TTL-க்கு மாறுங்கள்.
Deploy செய்த பிறகு hit rate குறைகிறது. ஒரு tool விளக்கம் திருத்தப்பட்டது அல்லது ஒரு model மாற்றப்பட்டது. இவை இரண்டும் முழு prefix-ஐயும் செல்லாததாக்குகின்றன. prompt-ஐ பாதிக்கும் ஒவ்வொரு deploy-க்குப் பிறகும், ஒரு விலையுயர்ந்த write சுழற்சியை எதிர்பார்க்கலாம்.
Caching-ஐ செயல்படுத்திய பிறகு கட்டணம் அதிகரித்தது. உங்கள் hit rate break-even புள்ளிக்குக் கீழே உள்ளது. 5 minute cache-ல் சுமார் 22 சதவீதத்திற்குக் கீழே இருந்தால், prefix-ஐ cache செய்யாமல் அனுப்புவது மலிவானது; 1 hour cache-க்கும் இதே நிலைதான், அது 53 சதவீதத்திற்குக் கீழே இருந்தால் பொருந்தும்.
FAQ
ஒரு prompt-ஐ எத்தனை முறை மீண்டும் பயன்படுத்தினால் caching லாபகரமாக இருக்கும்?
5 நிமிட cache-ல் ஒருமுறை பயன்படுத்தினாலே போதுமானது. ஒரு write என்பது அடிப்படை input-ஐ விட 1.25 மடங்கு செலவாகும், ஒரு read என்பது 0.1 மடங்கு செலவாகும். எனவே, N எண்ணிக்கையிலான cache செய்யப்படாத கோரிக்கைகளுக்கு N செலவாகும்; அதேசமயம் N எண்ணிக்கையிலான cache செய்யப்பட்ட கோரிக்கைகளுக்கு 1.25 + 0.1 * (N - 1) செலவாகும். இவை இரண்டும் N = 1.28 என்ற புள்ளியில் சந்திக்கின்றன, எனவே இரண்டாவது கோரிக்கையிலேயே லாபம் கிடைக்கத் தொடங்கிவிடும். 1 மணிநேர cache-க்கு write செலவு 2 மடங்கு, இது N = 2.11-ல் சந்திக்கிறது, எனவே இதற்கு இரண்டு read-கள் தேவைப்படும்.
ஏன் cache_read_input_tokens எப்போதும் பூஜ்ஜியமாகக் காட்டுகிறது?
முதலில் prefix நீளத்தைச் சரிபார்க்கவும்: ஆகஸ்ட் 2026 நிலவரப்படி, Claude Opus 5 மற்றும் 4-க்கு 512 tokens, Claude Haiku 4.5-க்கு 4,096 tokens என்ற குறைந்தபட்ச அளவிற்கு குறைவாக இருந்தால், caching அமைதியாகத் தவிர்க்கப்படும் மற்றும் இரண்டு counters-ம் 0 என்று காட்டும். prefix போதுமான நீளமாக இருந்தால், ஒவ்வொரு அழைப்பிற்கும் இடையில் மாறும் உள்ளடக்கம் (உதாரணமாக, system prompt-ல் உள்ள timestamp அல்லது session identifier) breakpoint-க்கு முன்னால் அல்லது அதிலேயே இருக்கிறதா என்று பார்க்கவும். counters வேலை செய்துகொண்டிருந்து திடீரென நின்றிருந்தால், கோரிக்கைகளுக்கு இடையிலான இடைவெளி cache ஆயுட்காலத்தை விட அதிகமாக இருந்திருக்கலாம்.
prompt caching, Claude-ன் பதில்களை மாற்றுமா?
இல்லை. நீங்கள் ஏற்கனவே அனுப்பிய tokens-ன் செயலாக்கப்பட்ட வடிவத்தையே cache சேமிக்கிறது, எனவே model இரண்டு முறைகளிலும் ஒரே prompt-ஐத்தான் பார்க்கிறது. இது billing மற்றும் latency தொடர்பான ஒரு வசதி, செயல்பாட்டில் மாற்றம் அல்ல. இதன் பொருள், நீங்கள் ஏற்கனவே சரியாகச் செயல்படும் prompt-ல், உங்கள் evaluations-ஐ மீண்டும் இயக்காமலேயே இதை enable செய்யலாம்.
நான் 1 மணிநேர cache-க்கு பணம் செலுத்த வேண்டுமா?
உங்கள் traffic-ல் 5 நிமிடங்களுக்கு மேலான இடைவெளிகள் இருந்து, உங்கள் hit rate சுமார் 53 சதவீதம் வரை இருந்தால் மட்டுமே இதற்குப் பணம் செலுத்தலாம். நீங்கள் miss செய்யும்போது, 2 மடங்கு write செலவு என்பது 1.25 மடங்கு write செலவை விட இரண்டு மடங்கு நஷ்டத்தை ஏற்படுத்தும். 5 நிமிட cache, ஒவ்வொரு hit-ன் போதும் புதுப்பிக்கப்படும், எனவே சீரான traffic இருக்கும்போது நீண்ட கால ஆயுட்காலத்திற்குப் பணம் செலுத்தாமலேயே read விலையிலேயே அதைத் தக்கவைக்க முடியும்.