ஆல் Claude Prompt Caching: லாபகரமான பயன்பாட்டிற்கான கணக்கீடு
Claude prompt caching-ல் cache write 1.25x மற்றும் read 0.1x செலவாகும். உங்கள் API பயன்பாட்டில் எப்போது லாபம் கிடைக்கும் என்பதைத் துல்லியமாகக் கணக்கிடுவது எப்படி என்பதை அறியுங்கள்.
Prompt caching-ல் சேமிப்பிற்கு முன்பாக ஏற்படும் செலவுகள்
Prompt caching வசதியானது, ஒவ்வொரு அழைப்பின்போதும் உங்கள் prompt-ன் முன்பகுதியை மீண்டும் வாசிப்பதற்குப் பதிலாக, அதை மீண்டும் பயன்படுத்த Claude-ஐ அனுமதிக்கிறது. இதன் ஒட்டுமொத்த லாப-நட்ட கணக்கீடு, உங்கள் model-ன் அடிப்படை input விலையில் உள்ள இரண்டு பெருக்கிகளைப் (multipliers) பொறுத்தது. அக்டோபர் 2026 நிலவரப்படி, அனைத்து model-களிலும் 5 நிமிட காலாவதிக்கு cache write என்பது அடிப்படை input விலையில் 1.25 மடங்கு, அல்லது 1 மணிநேர காலாவதிக்கு 2 மடங்கு செலவாகும். பெரும்பாலான model-களில் cache read என்பது 0.1 மடங்கு செலவாகும், ஆனால் இந்த read பெருக்கி இப்போது எல்லா இடங்களிலும் ஒரே மாதிரியாக இல்லை. செப்டம்பர் 1, 2026 அன்று அறிமுகப்படுத்தப்பட்ட Claude Fable 5.1 மற்றும் Claude Mythos 5.1 ஆகியவற்றில் இது 0.025 மடங்கு ஆகும். Claude Opus 5.5 மற்றும் Claude Sonnet 5.5 ஆகியவற்றில் இது 0.05 மடங்கு ஆகும்; Sonnet 5.5-க்கான இந்த விகிதம் அக்டோபர் 7, 2026 அன்று 0.1 மடங்கிலிருந்து குறைக்கப்பட்டது. கீழே உள்ள கணக்கீடுகள் பொதுவான 0.1 மடங்கு read விகிதத்தைப் பயன்படுத்துகின்றன. மலிவான read விகிதங்கள் break-even புள்ளியை உங்களுக்குச் சாதகமாகச் சற்று மாற்றும்; அது எவ்வளவு என்பதை அடுத்த பகுதி விளக்குகிறது.
இந்த பரிமாற்றம் என்பது தற்போதைய கூடுதல் கட்டணத்திற்குப் பதிலாகப் பிற்காலத்தில் கிடைக்கும் தள்ளுபடி ஆகும். ஒரு prefix-ஐச் சேமிக்க நீங்கள் ஒருமுறை கூடுதல் கட்டணம் செலுத்துகிறீர்கள். அதன் பிறகு, அதே bytes-களுடன் தொடங்கும் ஒவ்வொரு கோரிக்கையும் அந்தப் பகுதிக்கு வழக்கமான input விலையில் பத்தில் ஒரு பங்கு அல்லது அதற்கு மேற்பட்ட விலையைச் செலுத்துகிறது (மேலே குறிப்பிட்ட model-களில் இன்னும் குறைவு). அதன் ஆயுட்காலத்திற்குள் மீண்டும் பயன்படுத்தப்படாத ஒரு prefix, உங்களுக்கு 25 சதவீதம் கூடுதல் செலவை மட்டுமே தரும்.
Break-even புள்ளியை இயற்கணிதச் சமன்பாட்டில் ஒரு வரியில் கூறுதல்
ஒரு prefix-ஐ cache செய்யாமல் அனுப்பினால் அதன் அடிப்படை உள்ளீட்டுச் செலவை B எனக் கொள்வோம். 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-ல் break-even அடைய இரண்டு வாசிப்புகள் தேவைப்படுகின்றன, இதனாலேயே இது இயல்புநிலைத் தேர்வாக (default choice) இல்லை.
மலிவான வாசிப்பு விலைகளில் இந்த அளவு மாறினாலும், பெரிய மாற்றம் இருப்பதில்லை. 0.05x வாசிப்பு விலையில் 5 நிமிட cache-க்கு 0.95N = 1.2, எனவே N = 1.26; 0.025x விலையில் 0.975N = 1.225, இதிலும் N = 1.26. 1 மணிநேர cache-க்கு இவை முறையே N = 2.05 மற்றும் N = 2.03 என மாறுகின்றன. நடைமுறைப் பதில் அனைத்து மாதிரிகளிலும் ஒன்றுதான்: 5 நிமிட cache இரண்டாவது கோரிக்கையிலிருந்தும், 1 மணிநேர cache மூன்றாவது கோரிக்கையிலிருந்தும் லாபகரமானதாக மாறுகிறது.
கீழே உள்ள அட்டவணை Claude Opus 5-ல் 20,000 token prefix-க்கான விலையைக் காட்டுகிறது. அக்டோபர் 2026 நிலவரப்படி, ஆகஸ்ட் மாதத்திலிருந்து மாறாமல், இதன் அடிப்படை உள்ளீட்டு விலை ஒரு மில்லியன் token-க்கு $5 ஆகும். Opus 5 தற்போது ஒரு legacy மாதிரி, இருப்பினும் இது இன்னும் கிடைக்கிறது. இதன் அடுத்த பதிப்பான Claude Opus 5.5, ஒரு மில்லியன் token-க்கு $4 விலையிலும் 0.05x வாசிப்பு விலையிலும் கிடைக்கிறது, எனவே அங்கு அதே prefix-ஐ எழுத $0.10 மற்றும் வாசிக்க $0.004 செலவாகும். ஒரு மில்லியன் token-க்கு $3 விலையுள்ள மாதிரிக்கு, தரமான 0.1x வாசிப்பு விலையில் அனைத்து எண்களையும் 0.6-ஆல் பெருக்கிக் கொள்ளவும். வளைகோட்டின் வடிவம் மாறாது.
இந்த விளக்கப்படத்தின் தரவு
[
{
"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.135 என்ற விலையில் உள்ளது, இது cache செய்யப்படாத $0.20 விலையை விடக் குறைவு. அந்த நிலையில் 1 மணிநேர cache இன்னும் பின்தங்கியே உள்ளது, அதாவது $0.21 எதிராக $0.20. இது மூன்றாவது கோரிக்கையில்தான் cache செய்யப்படாத விலையை விடக் குறைகிறது: $0.22 எதிராக $0.30. 20 கோரிக்கைகள் வரும்போது, வித்தியாசம் $2.00 எதிராக $0.315 என அமைகிறது.
Cache hit நிகழ்வது அந்தப் பதிவைப் புதுப்பிக்கிறது, இதனால்தான் வெளியிடப்பட்ட விலை அட்டவணையில் அந்த நெடுவரிசை "cache hits and refreshes" எனக் குறிப்பிடப்பட்டுள்ளது. எனவே, ஒரு பரபரப்பான endpoint, 5 நிமிட cache பதிப்பை வாசிப்பு விலையிலேயே தொடர்ந்து உயிர்ப்புடன் வைத்திருக்கும். 1 மணிநேர ஆயுட்காலம் என்பது உங்கள் traffic-ல் உண்மையான இடைவெளிகள் இருக்கும்போது மட்டுமே அதன் 2x எழுதும் செலவை ஈடுசெய்யும்.
குறைந்த hit rate-ஆல் ஏற்படும் செலவுகள்
உண்மையான traffic-ல் cache misses நிகழ்கின்றன. Cache-ல் கிடைக்காத, ஆனால் breakpoint-ஐக் கொண்ட ஒரு கோரிக்கை (request), write செயல்பாடாகக் கணக்கிடப்படுகிறது. எனவே, செலவை hit rate-ன் செயல்பாடாகக் கணக்கிடுவதே சரியான முறையாகும். கீழே உள்ள வரைபடம், தலா 20,000 token prefix கொண்ட 1,000 கோரிக்கைகளுக்கான செலவைக் காட்டுகிறது.
இந்த விளக்கப்படத்தின் தரவு
[
{
"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 என்ற சமன்பாட்டைத் தீர்த்தால், சுமார் 22 சதவீத hit rate-ல் 5 நிமிட cache பணத்தைச் சேமிக்கத் தொடங்குகிறது; இதனால்தான் 25 சதவீதத்தில் $96.25 என்று காட்டுகிறது. 2x write-க்கு இதே கணக்கீட்டைச் செய்தால் 1 மணிநேர cache-க்கு சுமார் 53 சதவீதம் கிடைக்கிறது. எனவே, 50 சதவீத hit rate-ல் கூட செலவு $105.00 ஆக உள்ளது, இது uncached கோட்டை விட அதிகம். 90 சதவீதத்தில், இவை $21.50 மற்றும் $29.00 ஆகிய புள்ளிகளை அடைகின்றன. 99 சதவீதத்தில், குறுகிய கால cache $11.15-ஐ அடைகிறது, இது uncached விலையில் பத்தில் ஒரு பங்கு என்ற குறைந்தபட்ச அளவை நெருங்குகிறது.
0.05x read கொண்ட ஒரு மாதிரியில், 5 நிமிட cache-க்கு வரம்பு சுமார் 21 சதவீதமாகவும், 1 மணிநேர cache-க்கு 51 சதவீதமாகவும் குறைகிறது. 0.025x read-ல், இவை சுமார் 20 மற்றும் 51 சதவீதமாகக் குறைகின்றன. Read விலை குறையும்போது, குறைந்தபட்ச செலவும் uncached விலையில் இருபதில் ஒரு பங்காகவோ அல்லது நாற்பதில் ஒரு பங்காகவோ குறைகிறது.
Prefix அளவு நிர்ணயிக்கப்பட்ட பிறகு, நீங்கள் கட்டுப்படுத்தக்கூடிய ஒரே காரணி hit rate என்பதால், அதைக் கண்காணிப்பது மிக முக்கியம்.
எந்தெந்த முன்னொட்டுகளுக்கு (prefixes) பிரேக் பாயிண்ட் (breakpoint) தேவை
ஒரு கோரிக்கையில் (request) அதிகபட்சம் நான்கு கேச் பிரேக் பாயிண்டுகளைப் பயன்படுத்தலாம். எனவே, எந்தெந்த பிளாக்குகளுக்கு (blocks) பிரேக் பாயிண்ட் தேவை என்பதுதான் கேள்வி. வெவ்வேறு அழைப்புகளிலும் (calls) ஒரே மாதிரியான பைட் அமைப்பைக் கொண்ட, மற்றும் குறிப்பிடத்தக்க அளவு பெரிய பிளாக்குகளே இதற்குத் தகுதியானவை. 5 நிமிட கேச் கால அளவில், 90 சதவீத ஹிட் ரேட் (hit rate) அடிப்படையில் 1,000 கோரிக்கைகளுக்கான நான்கு பொதுவான வடிவங்களின் விலை விவரம் கீழே உள்ள அட்டவணையில் உள்ளது.
இந்த விளக்கப்படத்தின் தரவு
[
{
"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 டோக்கன் சிஸ்டம் பிராம்ப்ட் (system prompt), கேச் செய்யப்படாத $10.00 செலவோடு ஒப்பிடும்போது, 1,000 கோரிக்கைகளுக்கு $7.85 சேமிப்பைத் தருகிறது. அதிக எண்ணிக்கையிலான கோரிக்கைகளின் போது இது உண்மையான பணச் சேமிப்புதான், ஆனால் இது மட்டும் கேச்சிங்கை (caching) சுவாரஸ்யமானதாக மாற்றுவதில்லை. இதனுடன் டூல் டெஃபினிஷன்களை (tool definitions) சேர்த்தால், அது 8,000 டோக்கன்களாக உயர்ந்து, $31.40 சேமிப்பைத் தருகிறது. ஒவ்வொரு கோரிக்கையிலும் கேட்கப்படும் 25,000 டோக்கன் பாலிசி ஆவணம் $98.12 சேமிப்பை வழங்குகிறது. கடைசி வரிதான் கட்டமைப்பையே மாற்றக்கூடியது: 120,000 டோக்கன் அளவுள்ள கோட் பேஸ் (codebase) அல்லது டிரான்ஸ்கிரிப்ட் சூழல் (transcript context), கேச் செய்யப்படாமல் இருந்தால் $600.00 செலவாகும், கேச் செய்யப்பட்டால் $129.00 செலவாகும்; இதன் மூலம் $471.00 சேமிக்கப்படுகிறது.
சேமிப்பு என்பது முன்னொட்டின் அளவு மற்றும் ஹிட் ரேட்டைப் பொறுத்தே அமைகிறது, மற்ற எதையும் பொறுத்ததல்ல. இது பிராம்ப்ட்டில் எதைச் சேர்க்கலாம் என்பதையே மாற்றுகிறது: ஒரு மில்லியன் Claude டோக்கன்களின் உண்மையான விலை என்பது, நீங்கள் ஒன்றுக்கும் மேற்பட்ட முறை அனுப்பும் எதற்கும், அதன் அசல் விலையில் பத்தில் ஒரு பங்காகவோ அல்லது அதற்கும் குறைவாகவோ குறைகிறது (குறைந்த ரீட் செலவு கொண்ட மாடல்களில்).
மாதாந்திர கட்டணத்தில் இது எவ்வாறு பிரதிபலிக்கும்
கீழே உள்ள அட்டவணை, மேலே குறிப்பிடப்பட்டுள்ள 8,000 டோக்கன் முன்னொட்டு (token prefix), ஒரு system prompt மற்றும் tool வரையறைகளை 90 சதவீத வெற்றி விகிதத்தில் (hit rate) எடுத்துக்கொண்டு, அவற்றை மாதாந்திர கோரிக்கை அளவுகளுக்கு (monthly request volumes) விரிவுபடுத்துகிறது.
இந்த விளக்கப்படத்தின் தரவு
[
{
"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-க்கு பிறகுதான் வர வேண்டும்; இல்லையெனில் அவை மாறாத tokens அனைத்தையும் நகரும் எல்லைக்கு பின் தள்ளிவிடும்.
இரண்டாவது தடை, மாறும் block-ல் breakpoint-ஐ வைப்பது. Cache பதிவுகள் breakpoint-ல் தான் நிகழ்கின்றன. எனவே, அந்த block ஒவ்வொரு முறையும் மாறினால், நிலையான எதுவும் சேமிக்கப்படாது. lookback தேடலில், முந்தைய கோரிக்கைகள் அவற்றின் சொந்த நகரும் breakpoint-களில் பதிந்தவை மட்டுமே கிடைக்கும். cache_control-ஐ கோரிக்கைகளுக்கு இடையே உள்ளடக்கத்தில் மாற்றமில்லாத கடைசி block-ல் வைக்கவும்.
மூன்றாவது, prompt உள்ளடக்கமாக நீங்கள் கருதாத parameter மாற்றம். வெவ்வேறு model-களுக்கு வெவ்வேறு cache இருக்கும். tool_choice-ஐ மாற்றினால், tools மற்றும் system prompt cached நிலையில் இருந்தாலும், message history செல்லாததாகிவிடும். ஒரு tool-ஐச் சேர்ப்பதோ அல்லது நீக்குவதோ அனைத்தையும் செல்லாததாக்கிவிடும்.
குறைந்தபட்ச முன்னொட்டு (prefix) மற்றும் அமைதியான no-op
ஒரு model-ன் குறைந்தபட்ச அளவை விடக் குறைவான முன்னொட்டு (prefix) cache செய்யப்படாது, இதைப் பற்றி எந்த அறிவிப்பும் வராது. பிழையோ அல்லது எச்சரிக்கையோ காட்டப்படாது. கோரிக்கை (request) வெற்றிகரமாக முடிவடையும், ஆனால் இரண்டு counters-ம் 0 என்றே காட்டும். அக்டோபர் 2026 நிலவரப்படி, வெளியிடப்பட்ட குறைந்தபட்ச அளவுகள் பின்வருமாறு:
- Claude Opus 5 மற்றும் Claude Fable 5, மற்றும் புதிய Opus 5.5, Sonnet 5.5, Fable 5.1 மற்றும் Haiku 5.5 ஆகியவற்றிற்கு 512 tokens.
- Claude Sonnet 5 மற்றும் Claude Opus 4.8 ஆகியவற்றிற்கு 1,024 tokens.
- Claude Haiku 4.5-க்கு 4,096 tokens.
cache செய்யப்பட்டதாக நீங்கள் கருதும் ஒரு கோரிக்கையில் இரண்டு counters-ம் 0 என்று காட்டினால், மற்ற எதையும் சரிபார்க்கும் முன் முன்னொட்டின் நீளத்தைச் சரிபார்க்கவும். இதனால்தான், caching பணிச்சுமைக்கு மலிவான model எப்போதும் மலிவானதாக இருப்பதில்லை. Haiku 4.5-ல் caching தொடங்குவதற்கு, Opus 5-ஐ விட எட்டு மடங்கு நீளமான முன்னொட்டு தேவைப்படுகிறது. எனவே, 2,000 tokens கொண்ட system prompt ஒன்றில் cache ஆகி, மற்றொன்றில் அமைதியாகப் புறக்கணிக்கப்படலாம்.
Claude Code எங்கு cache செய்கிறது மற்றும் எங்கு செய்ய முடியாது
Claude Code தனது prefix-ஐத் தானே cache செய்கிறது. System prompt மற்றும் tool definitions ஆகியவை ஒவ்வொரு கோரிக்கையின் தொடக்கத்திலும் இருப்பதால் அவை மாறாது; எனவே அவை ஒருமுறை எழுதப்பட்டு, அமர்வு முழுவதும் மீண்டும் படிக்கப்படுகின்றன. இதனால்தான் நீண்ட அமர்வுகளின் ஒவ்வொரு சுற்றின் (per-turn) செலவு, context அளவை விட மிகக் குறைவாக உள்ளது. இது Claude Code token பயன்பாட்டை எவ்வாறு தெரிவிக்கிறது என்பதில் விவரிக்கப்பட்டுள்ள counters-ல் காட்டப்படுகிறது.
Context-ன் தொடக்கத்திற்கு அருகில் மாற்றம் ஏற்படும்போது, cache-ஆல் உதவ முடியாது. உரையாடல் வரலாறு (conversation history) என்பது append-only முறையில் இருப்பதால், புதிய சுற்றுகள் ஏற்கனவே cache செய்யப்பட்ட prefix-ஐ நீட்டிக்கின்றன. அமர்வின் தொடக்கத்தில் படிக்கப்பட்ட ஒரு கோப்பைத் திருத்துவது cache-ஐப் பாதிக்காது; ஏனெனில் Claude Code அந்த கோப்பு மாறியது என்ற குறிப்பை இறுதியில் சேர்க்கிறது, மாறாக முந்தைய வாசிப்பை மீண்டும் எழுதுவதில்லை. மாடல்களை மாற்றும்போது cache உடைகிறது, ஏனெனில் ஒவ்வொரு மாடலுக்கும் தனித்தனி cache உள்ளது. அதன் கருவிகள் prefix-ல் ஏற்றப்படும் ஒரு MCP server-ஐ இணைப்பதும், உரையாடலைச் சுருக்குவதும் (compacting) cache-ஐ உடைக்கும். இவை ஒவ்வொன்றும் அடுத்த சுற்றில் prefix-ஐ மீண்டும் எழுதச் செய்யும். நீண்ட நேரம் செயலற்ற நிலையில் இருப்பதும் இதையே செய்யும், ஏனெனில் அந்த entry காலாவதியாகிவிடும் மற்றும் அடுத்த சுற்று முழுமையான எழுத்துச் செலவை (full write) ஏற்படுத்தும். இவை எதுவும் பிழைகள் அல்ல. இவை prefix விதியின்படி சரியாகச் செயல்படுகின்றன.
நீங்கள் சொந்தமாக client-ஐ உருவாக்குகிறீர்கள் என்றால், முதல் கோரிக்கையிலிருந்து layout-ஐப் பயன்படுத்துங்கள்; அதை மாற்றியமைக்க வேண்டாம்: VPS-ல் முதல் Claude API app செய்வது போல, நிலையான தொகுதிகளை (stable blocks) முதலில் வைத்து, மாறக்கூடியவற்றை (volatile ones) இறுதியில் வைத்து அழைப்பை உருவாக்குங்கள்.
தோல்வி முறைகள் மற்றும் நீங்கள் காண்பவை
ஒவ்வொரு அழைப்பும் ஒரு write. ஒவ்வொரு கோரிக்கையின் போதும் cache_creation_input_tokens பூஜ்ஜியமற்றதாக இருக்கும், அதே சமயம் cache_read_input_tokens 0 ஆகவே இருக்கும். அழைப்புகளுக்கு இடையே breakpoint-ல் அல்லது அதற்கு முன்னால் ஏதோ ஒன்று மாறுகிறது. அடுத்தடுத்த இரண்டு கோரிக்கைகளில் உங்கள் assembled prefix-ன் முதல் 200 எழுத்துக்களை print செய்து, அவற்றை கண்ணால் ஒப்பிட்டுப் பாருங்கள்.
இரண்டு counters-ம் 0. prefix என்பது model-ன் குறைந்தபட்ச அளவை விடக் குறைவாக உள்ளது, அல்லது cache_control புலம் API-ஐ ஒருபோதும் சென்றடையவில்லை. முதலில் prefix tokens-ஐ எண்ணுங்கள், பிறகு நீங்கள் உண்மையில் அனுப்பிய request body-ஐ log செய்யுங்கள்.
Reads வேலை செய்கிறது, பிறகு நின்றுவிடுகிறது. தொடர்ச்சியான hits, பிறகு ஒரு write, மீண்டும் hits. கோரிக்கைகளுக்கு இடையிலான இடைவெளி lifetime-ஐ விட அதிகமாக இருந்தது. write-ஐ ஏற்றுக்கொள்ளுங்கள், அல்லது உங்கள் hit rate 53 சதவீதத்தைத் தாண்டுவதை உறுதி செய்த பிறகு 1 hour TTL-க்கு மாறுங்கள்; 0.05x அல்லது 0.025x read கொண்ட model-ல் இது சுமார் 51 சதவீதமாக இருக்கும்.
Deploy செய்த பிறகு hit rate குறைகிறது. ஒரு tool description திருத்தப்பட்டது அல்லது model மாற்றப்பட்டது. இவை இரண்டும் முழு prefix-ஐயும் செல்லாததாக்கிவிடும். prompt-ஐ பாதிக்கும் ஒவ்வொரு deploy-க்குப் பிறகும் ஒரு விலையுயர்ந்த writes சுழற்சியை எதிர்பார்க்கலாம்.
Caching-ஐ செயல்படுத்திய பிறகு கட்டணம் அதிகரித்தது. உங்கள் hit rate break-even-க்கு கீழே உள்ளது. 5 minute cache-ல் சுமார் 22 சதவீதத்திற்கும் குறைவாக இருந்தால், prefix-ஐ cache செய்யாமல் அனுப்புவது மலிவானது; 1 hour cache-ல் 53 சதவீதத்திற்கும் குறைவாக இருந்தால் அதே நிலைதான். மலிவான-read கொண்ட model-களில் அந்த வரம்புகள் சுமார் 20 முதல் 21 சதவீதம் மற்றும் 51 சதவீதத்தில் உள்ளன.
FAQ
ஒரு prompt-ஐ எத்தனை முறை மீண்டும் பயன்படுத்தினால் caching லாபகரமாக இருக்கும்?
5 நிமிட cache-ல் ஒருமுறை பயன்படுத்தினாலே போதும். பெரும்பாலான மாடல்களில், ஒரு write என்பது அடிப்படை input விலையை விட 1.25 மடங்கு மற்றும் ஒரு read என்பது 0.1 மடங்கு ஆகும். எனவே, N எண்ணிக்கையிலான uncached கோரிக்கைகளுக்கு N செலவாகும், அதே சமயம் N cached கோரிக்கைகளுக்கு 1.25 பிளஸ் 0.1 பெருக்கல் (N minus 1) செலவாகும். இவை இரண்டும் N = 1.28 என்ற புள்ளியில் சந்திக்கின்றன, எனவே இரண்டாவது கோரிக்கையிலேயே லாபம் கிடைத்துவிடுகிறது. 0.05x அல்லது 0.025x read கொண்ட மாடல்களில், இந்த சந்திப்பு புள்ளி N = 1.26 ஆகும், இதுவும் அதே விடையையே தருகிறது. 1 மணிநேர cache-ல் write என்பது 2x செலவாகும் மற்றும் N = 2.11 என்ற புள்ளியில் சந்திக்கிறது, மலிவான read-களில் இது சுமார் 2.05 ஆகும், எனவே இதற்கு இரண்டு read-கள் தேவைப்படும்.
cache_read_input_tokens ஏன் எப்போதும் பூஜ்ஜியமாகக் காட்டுகிறது?
முதலில் prefix நீளத்தைச் சரிபார்க்கவும்: அக்டோபர் 2026 நிலவரப்படி, Claude Opus 5-ல் 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 சேமிக்கிறது, மாடல் எந்த வகையிலும் ஒரே மாதிரியான prompt-ஐயே பார்க்கிறது. இது billing மற்றும் latency தொடர்பான ஒரு வசதியே தவிர, செயல்பாட்டில் மாற்றம் செய்யும் ஒன்றல்ல. இதன் பொருள், நீங்கள் ஏற்கனவே சரியாகச் செயல்படும் ஒரு prompt-ல், உங்கள் evaluations-ஐ மீண்டும் இயக்காமலேயே இதை enable செய்யலாம்.
நான் 1 மணிநேர cache-க்கு பணம் செலுத்த வேண்டுமா?
உங்கள் traffic-ல் 5 நிமிடங்களுக்கு மேலான இடைவெளிகள் இருந்து, உங்கள் hit rate சுமார் 53 சதவீதம் அல்லது மலிவான read கொண்ட மாடலில் சுமார் 51 சதவீதம் இருக்கும்போது மட்டும் இதைப் பயன்படுத்தவும். ஒரு miss ஏற்படும்போது, 2x write செலவு 1.25x write-ஐ விட நான்கு மடங்கு அதிகமாகும். 1 மணிநேர cache-ல் ஒரு miss ஏற்பட்டால், prefix-ன் முழு அடிப்படை input விலையும் வீணாகும், அதே சமயம் 5 நிமிட cache-ல் ஒரு miss ஏற்பட்டால் அதில் கால் பங்கு மட்டுமே வீணாகும். 5 நிமிட cache ஒவ்வொரு hit-ன் போதும் புதுப்பிக்கப்படும், எனவே நிலையான traffic இருக்கும்போது நீண்ட கால ஆயுட்காலத்திற்கு பணம் செலுத்தாமலேயே read விலையிலேயே அதைத் தக்கவைக்க முடியும்.