Claude Opus 5 యొక్క కొత్త prompt-caching API, మార్పులేని వచనాన్ని (unchanged text) మళ్ళీ చదవాల్సిన అవసరం లేకుండా చేయడం ద్వారా చాట్-శైలి యాప్ల కోసం టోకెన్ బిల్లులను భారీగా తగ్గిస్తుంది. మొదటి రిక్వెస్ట్కు స్వల్ప అదనపు రుసుము ఉంటుంది; ప్రతి తదుపరి హిట్ బేస్ రేటులో సుమారు పത്തിലొక వంతు మాత్రమే ఖర్చవుతుంది, తద్వారా పునరావృతమయ్యే ఖర్చును ఒకేసారి చేసే ఛార్జీగా మారుస్తుంది.
డెవలపర్లు ఒకే పదాల కోసం రెండుసార్లు ఎందుకు చెల్లిస్తారు
చాలా సంభాషణాత్మక ఇంటర్ఫేస్లు ప్రతిసారీ పూర్తి ప్రాంప్ట్ను మళ్ళీ నిర్మిస్తాయి: ఒక యూజర్ ఫాలో-అప్ ప్రశ్న అడిగిన ప్రతిసారీ, 8,000-టోకెన్ల సిస్టమ్ ప్రాంప్ట్, జత చేసిన PDFలు మరియు పూర్తి సంభాషణ చరిత్ర (dialogue history) మోడల్కు కలిసి వెళ్తాయి. ఆ వచనం యొక్క ఎక్కువ భాగం ఎప్పుడూ మారకపోయినప్పటికీ, మోడల్ ప్రతి టోకెన్ను మళ్ళీ ప్రాసెస్ చేస్తుంది. ప్రస్తుత ధరల ప్రకారం, ఆ అదనపు ప్రక్రియ (redundancy) బిజీగా ఉండే బాట్ ఖర్చులో ప్రధాన పాత్ర పోషిస్తుంది.
క్యాష్ (cache) గణితాన్ని ఎలా మారుస్తుంది
ఈ API ఒక నిర్ణీత బ్రేక్పాయింట్ వరకు ప్రతి "బ్లాక్" టోకెన్ల కోసం ఒక క్యాష్ ఎంట్రీని సృష్టిస్తుంది. తదుపరి రిక్వెస్ట్లో అదే బ్లాక్ ముందు భాగంలో ఉన్నప్పుడు, సర్వీస్ దానిని మళ్ళీ టోకెనైజ్ చేసే బదులు క్యాష్ నుండి చదువుతుంది. ఆదా అయిన పనిని బట్టి ధరల విభజన ఇలా ఉంటుంది:
- Cache write – 5-minute TTL: 1.25 × base price
- Cache write – 1-hour TTL: 2 × base price
- Cache read (hit): 0.1 × base price
ఆచరణలో, కొత్త బ్లాక్కు చేసే మొదటి కాల్ సాధారణ రిక్వెస్ట్ కంటే కొంచెం ఎక్కువ ఖర్చవుతుంది. క్యాష్ను ఉపయోగించే ప్రతి తదుపరి కాల్ 90% చౌకగా ఉంటుంది, కాబట్టి సంభాషణ ముందుకు సాగే కొద్దీ నికర ఖర్చు గణనీయంగా తగ్గుతుంది.
ప్రాంప్ట్లను రూపొందించడానికి "గోల్డెన్ రూల్"
క్యాష్ సామర్థ్యం అనేది మీరు స్టాటిక్ (static) మరియు డైనమిక్ (dynamic) కంటెంట్ను ఎక్కడ ఉంచుతారనే దానిపై ఆధారపడి ఉంటుంది. మారకుండా ఉండే అంశాలన్నింటినీ ముందు భాగంలో ఉంచండి మరియు నిరంతరం మారుతూ ఉండే భాగాలను చివరన ఉంచండి. నమ్మదగిన క్రమం ఇలా ఉంటుంది:
- Tools – మోడల్ పిలవగలిగే ఏవైనా బాహ్య ఫంక్షన్ల నిర్వచనాలు (definitions).
- System instructions – మోడల్ అనుసరించాలని మీరు కోరుకునే ఉన్నత స్థాయి ప్రవర్తన.
- Documents – PDFలు, నాలెడ్జ్ బేస్లు లేదా పాలసీ ఉల్లేఖనల వంటి సుదీర్ఘ సందర్భం (long context).
- User questions – ప్రతిసారీ మారే ప్రత్యక్ష ప్రశ్న.
మీరు బ్రేక్పాయింట్ కంటే ముందు ఏ టోకెన్నైనా సవరించినట్లయితే, క్యాష్ ఎంట్రీ చెల్లదు (invalidated) మరియు మోడల్ దాని తర్వాత ఉన్నవన్నీ మళ్ళీ ప్రాసెస్ చేయాల్సి ఉంటుంది.
మీరు పాటించాల్సిన దాగి ఉన్న పరిమితులు
- Minimum block size – Opus 5 కనీసం 512 టోకెన్లను కలిగి ఉన్న బ్లాక్లను మాత్రమే క్యాష్ చేస్తుంది. అంతకంటే తక్కువ ఉన్నవి పూర్తిగా క్యాష్ నుండి బయటపడతాయి.
- Timestamp bug – క్యాష్ చేయబడిన బ్లాక్ లోపల మారుతున్న టైమ్స్టాంప్ను (timestamp) చేర్చడం వల్ల క్యాష్ మిస్ (miss) అవ్వడం ఖాయం, ఎందుకంటే బ్లాక్ యొక్క వచనం ఎప్పుడూ ఖచ్చితంగా సరిపోలదు.
- 20-block look-back – సర్వీస్ మ్యాచ్ కోసం చివరి 20 బ్లాక్లను మాత్రమే స్కాన్ చేస్తుంది. వేగంగా ముందుకు సాగే సుదీర్ఘ సెషన్లు క్యాష్ విండోను దాటిపోవచ్చు.
- Parallel requests – ఒకే సమయంలో అనేక ఒకే రకమైన రిక్వెస్ట్లను పంపితే అవి అన్నీ మిస్ అవుతాయి, ఎందుకంటే మొదటి రిక్వెస్ట్ పూర్తయిన తర్వాత మాత్రమే క్యాష్ నింపబడుతుంది. మొదట ఒకే కాల్తో క్యాష్ను సిద్ధం (warm) చేసి, ఆపై మిగిలిన వాటిని పంపండి.
మీ API రెస్పాన్స్లో ఆదాను చూడటం
ప్రతి రెస్పాన్స్ మూడు టోకెన్ కౌంటర్లను రిపోర్ట్ చేస్తుంది:
cache_read_input_tokens– క్యాష్ హిట్ నుండి వచ్చిన టోకెన్లు.cache_creation_input_tokens– ఈ రిక్వెస్ట్లో క్యాష్లోకి వ్రాయబడిన టోకెన్లు.input_tokens– క్యాష్ చేయబడని కొత్త టోకెన్లు.
ఆ టర్న్ కోసం మోడల్ పరిగణనలోకి తీసుకున్న మొత్తం టోకెన్లను పొందడానికి ఈ మూడు సంఖ్యలను కలపండి. రెండు క్యాష్ ఫీల్డ్లు సున్నా అయితే, రిక్వెస్ట్ క్యాష్ను మిస్ అయిందని అర్థం; మీ బ్లాక్ సైజు మరియు బ్రేక్పాయింట్ ప్లేస్మెంట్ను తనిఖీ చేయండి.
ముఖ్య గమనిక (Takeaway): మార్చలేని సందర్భాన్ని (immutable context) ముందుగా ఉంచడం మరియు Claude Opus 5 యొక్క prompt-caching APIని ప్రధాన పనిని చేయడానికి అనుమతించడం ద్వారా, మీరు పునరావృతమయ్యే టోకెన్ ఖర్చును ఒకేసారి చేసే ఛార్జీగా మార్చవచ్చు. టోకెన్ ఫ్లోర్ను గౌరవిస్తూ, క్యాష్ చేయబడిన బ్లాక్ల లోపల మారుతున్న మార్కర్లను నివారించి, మీ క్యాష్-అర్హత కలిగిన కంటెంట్ను 20-బ్లాక్ పరిధిలో ఉంచినట్లయితే—ఒకే సిస్టమ్ ప్రాంప్ట్ లేదా డాక్యుమెంట్ సెట్ను పదేపదే రిఫరెన్స్ చేసే ఏ చాట్బాట్కైనా ఇది భారీ ఖర్చు తగ్గింపుకు దారితీస్తుంది.