ડેવલપર્સે જોયું છે કે Claude નું prompt-caching ચુપચાપ નિષ્ફળ જઈ શકે છે, જે શૂન્ય cached tokens પર પ્રીમિયમ દરે ચાર્જ કરે છે. WhatsApp હેન્ડલર પર એક અઠવાડિયાના લોગ રન દરમિયાન કોઈ પણ cache reads જોવા મળ્યા નથી, તેમ છતાં API એ caching ફીચર માટે બિલિંગ કર્યું—જેથી ખર્ચ દર મહિને $1,890 થી ઘટીને $406 થઈ ગયો.

આ સમસ્યા શા માટે મહત્વની છે

Prompt caching નો હેતુ પ્રોમ્પ્ટના સ્થિર ભાગ (જેને “prefix” કહેવામાં આવે છે) ને ફરીથી ઉપયોગમાં લઈને ખર્ચ ઘટાડવાનો અને પ્રતિસાદની ઝડપ વધારવાનો છે. જ્યારે તે કામ કરે છે, ત્યારે વધુ ટ્રાફિક ધરાવતા એપ્સ તેમના માસિક બિલમાંથી સેંકડો ડોલર બચાવી શકે છે. જ્યારે તે કામ નથી કરતું, ત્યારે ડેવલપર્સ એવા ફીચર માટે ચૂકવણી કરે છે જેનો તેઓ ક્યારેય વાસ્તવમાં ઉપયોગ કરતા નથી, અને આ ચુપચાપ નિષ્ફળતા સમસ્યાનો સંકેત આપવા માટે કોઈ ભૂલ (error) કે ચેતવણી આપતી નથી.

આ બગ કેવી રીતે દેખાય છે

API એક cache-control flag અને prefix સ્વીકારે છે, અને પછી કેશમાંથી કેટલા tokens વાંચવામાં આવ્યા હતા તેનો રિપોર્ટ આપે છે. અવલોકન કરેલા કિસ્સામાં, દરેક વિનંતીએ (request) cache-read count શૂન્ય દર્શાવ્યો હતો. કોલ સફળ રહ્યો, કોઈ exception આવી નહોતી, અને બિલિંગમાં પ્રીમિયમ કેશ ખર્ચ દેખાતો હતો. જ્યાં સુધી તમે સ્પષ્ટપણે read count ને લોગ ન કરો ત્યાં સુધી આ નિષ્ફળતા અદ્રશ્ય રહે છે.

કેશ બગડવાના સામાન્ય રસ્તાઓ

  • Prefix ખૂબ ટૂંકો છે – દરેક Claude મોડેલ cacheable prefix માટે લઘુત્તમ token લંબાઈ નક્કી કરે છે. Haiku 4.5 ને ઓછામાં ઓછા 4,096 tokens ની જરૂર છે; Sonnet 4.6 ને માત્ર 1,024 ની જરૂર છે. ટૂંકો prefix મોકલવાથી request format સંતોષાય છે પરંતુ સેવા cache સૂચનાને અવગણે છે.
  • અસ્થિર (volatile) byte બદલાય છે – Caching માટે ચોક્કસ byte-for-byte મેચ હોવું જરૂરી છે. સિસ્ટમ પ્રોમ્પ્ટની શરૂઆતમાં timestamp, new Date(), અથવા યુઝર ઈમેલ જેવી ડાયનેમિક એલિમેન્ટ ઉમેરવાથી byte sequence બદલાઈ જાય છે, જેના કારણે દરેક વિનંતીને નવી, uncached write તરીકે ગણવામાં આવે છે.
  • Tool લિસ્ટનો ક્રમ બદલાય છે – Tools ને પ્રોમ્પ્ટની આગળ જોડવામાં આવે છે. જો tool array ઓબ્જેક્ટ કી (object keys) માંથી બનાવવામાં આવ્યું હોય, તો calls વચ્ચે તેની iteration order બદલાઈ શકે છે, જેનાથી byte layout બદલાઈ જાય છે અને કેશ બગડી જાય છે.

તમે આજે જ લાગુ કરી શકો તેવા ઉપાયો

  • Prefix લંબાઈ ચકાસો – વિનંતી મોકલતા પહેલા, મોડેલની લઘુત્તમ લંબાઈ સામે prefix ના token count નો અંદાજ લગાવો. જો તે ઓછું હોય તો prefix ને નકારી કાઢો અથવા તેને વધારો (pad).
  • દરેક કોલ પર cache reads લોગ કરો – “cache read tokens” ફિલ્ડ રેકોર્ડ કરો. સતત શૂન્ય આવવા એ સ્પષ્ટ સંકેત છે કે કેશનો ઉપયોગ થઈ રહ્યો નથી.
  • પ્રોમ્પ્ટના શરૂઆતના bytes ને ફ્રીઝ કરો – ડાયનેમિક ડેટાને cached segment ની બહાર રાખો. જો તમારે યુઝર-વિશિષ્ટ માહિતી શામેલ કરવી જ હોય, તો તેને cached prefix પછી મૂકો.
  • Model identifiers સિંક્રનાઇઝ કરો – ખાતરી કરો કે routing માં વપરાયેલ model ID તમારી cache table માં સંગ્રહિત ID સાથે મેળ ખાય છે; ખોટો ID કેશ લુકઅપને અટકાવે છે.

ખર્ચનો દ્રષ્ટિકોણ

દરરોજ હજારો કોલ કરતી એપ્લિકેશન માટે, uncached થી cached પર જવાથી માસિક ખર્ચમાં મોટો ઘટાડો થઈ શકે છે—અહેવાલ મુજબ આ કિસ્સામાં અંદાજે $1,890 થી ઘટીને $406 થઈ શકે છે. મધ્યમ ટ્રાફિકમાં પણ નોંધપાત્ર બચત જોવા મળે છે, અને મોટા સ્થિર પ્રોમ્પ્ટનો ફરીથી ઉપયોગ કરવાથી મળતો પરફોર્મન્સ વધારો લેટન્સી (latency) ઘટાડી શકે છે.

વિરોધ પક્ષ

જોકે, નિષ્ફળતાના ચુપચાપ સ્વભાવનો અર્થ એ છે કે તમે વધુ ચૂકવણી નથી કરી રહ્યા તેની ખાતરી કરવાની એકમાત્ર રીત read count તપાસવી છે—જે બાબત ઘણા લોકો અવગણે છે.

આગળ શું ધ્યાન રાખવું

  • Metric dashboards – Request volume ની સાથે cache-read tokens માટે ગેજ (gauge) ઉમેરો.
  • Tool-ordering stability