ڈویلپرز نے پایا ہے کہ Claude کی prompt-caching خاموشی سے ناکام ہو سکتی ہے، جس کی وجہ سے زیرو cached tokens ملنے کے باوجود پریمیم ریٹس وصول کیے جاتے ہیں۔ ایک WhatsApp ہینڈلر پر ایک ہفتے تک چلنے والے لاگ (log) کے تجزیے سے معلوم ہوا کہ کوئی بھی cache read نہیں ہوا، پھر بھی API نے caching فیچر کے پیسے وصول کیے—جس سے اخراجات $1,890 سے کم ہو کر $406 ماہانہ تک گر سکتے تھے۔

یہ مسئلہ کیوں اہم ہے

Prompt caching کا مقصد پرامپٹ کے ایک ساکن حصے (جسے "prefix" کہا جاتا ہے) کو دوبارہ استعمال کر کے اخراجات کم کرنا اور جوابات کی رفتار بڑھانا ہے۔ جب یہ صحیح کام کرتا ہے، تو زیادہ ٹریفک والی ایپس اپنے ماہانہ بلوں میں سینکڑوں ڈالر بچا سکتی ہیں۔ جب یہ کام نہیں کرتا، تو ڈویلپرز اس فیچر کے پیسے دیتے ہیں جسے وہ اصل میں کبھی استعمال ہی نہیں کرتے، اور یہ خاموش ناکامی مسئلے کی طرف اشارہ کرنے کے لیے کوئی ایرر (error) یا وارننگ (warning) بھی نہیں دیتی۔

یہ بگ (bug) کیسے ظاہر ہوتا ہے

API ایک cache-control flag اور ایک prefix قبول کرتی ہے، اور پھر رپورٹ کرتی ہے کہ کیش (cache) سے کتنے tokens پڑھے گئے۔ مشاہدے میں آنے والے کیس میں، ہر درخواست (request) میں cache-read کی تعداد صفر تھی۔ کال کامیاب رہی، کوئی exception نہیں آیا، اور بلنگ میں پریمیم کیش کا خرچہ شامل تھا۔ یہ ناکامی اس وقت تک نظر نہیں آتی جب تک آپ واضح طور پر read count کو لاگ (log) نہ کریں۔

وہ عام طریقے جن سے کیش (cache) خراب ہو جاتا ہے

  • Prefix بہت مختصر ہے – Claude کا ہر ماڈل cacheable prefix کے لیے کم از کم token کی لمبائی متعین کرتا ہے۔ Haiku 4.5 کو کم از کم 4,096 tokens کی ضرورت ہوتی ہے؛ Sonnet 4.6 کو صرف 1,024 کی ضرورت ہوتی ہے۔ ایک مختصر تر prefix بھیجنے سے درخواست کا فارمیٹ تو پورا ہو جاتا ہے لیکن سروس کیش کی ہدایت کو نظر انداز کر دیتی ہے۔
  • ایک متحرک (volatile) بائٹ تبدیل ہو جاتا ہے – Caching کے لیے بائٹ بہ بائٹ (byte-for-byte) بالکل درست مماثلت ضروری ہے۔ سسٹم پرامپٹ کے شروع میں کوئی متحرک عنصر جیسے کہ timestamp، new Date()، یا صارف کا ای میل شامل کرنے سے بائٹ کی ترتیب بدل جاتی ہے، جس کی وجہ سے ہر درخواست کو ایک نئی، بغیر کیش شدہ (uncached) تحریر کے طور پر لیا جاتا ہے۔
  • ٹولز (tools) کی فہرست کی ترتیب بدل جاتی ہے – ٹولز کو پرامپٹ کے شروع میں شامل کیا جاتا ہے۔ اگر tool array کو object keys سے بنایا گیا ہو، تو کالز کے درمیان ان کی ترتیب (iteration order) بدل سکتی ہے، جس سے بائٹ کا لے آؤٹ تبدیل ہو جاتا ہے اور کیش ٹوٹ جاتا ہے۔

وہ حل جو آپ آج ہی لاگو کر سکتے ہیں

  • Prefix کی لمبائی کی تصدیق کریں – درخواست بھیجنے سے پہلے، ماڈل کی کم از کم حد کے مقابلے میں prefix کی token تعداد کا اندازہ لگائیں۔ اگر یہ کم ہو تو اسے مسترد کر دیں یا اس میں اضافی tokens شامل کر کے اسے مکمل کریں۔
  • ہر کال پر کیش ریڈز (cache reads) کو لاگ کریں – "cache read tokens" فیلڈ کو ریکارڈ کریں۔ مسلسل صفر کا آنا اس بات کی واضح علامت ہے کہ کیش استعمال نہیں ہو رہا۔
  • پرامپٹ کے ابتدائی بائٹس کو مستقل (freeze) رکھیں – متحرک ڈیٹا کو کیش شدہ حصے سے دور رکھیں۔ اگر آپ کو صارف سے متعلقہ معلومات شامل کرنی ہی ہیں، تو انہیں کیش شدہ prefix کے بعد رکھیں۔
  • ماڈل آئیڈنٹیفائرز (identifiers) کو ہم آہنگ کریں – اس بات کو یقینی بنائیں کہ راؤٹنگ (routing) میں استعمال ہونے والا model ID آپ کے کیش ٹیبل میں محفوظ کردہ ID سے مطابقت رکھتا ہو؛ آئی ڈیز کا فرق کیش تلاش (cache lookup) کو روک دیتا ہے۔

اخراجات کا پہلو

روزانہ ہزاروں کالز کرنے والی ایپ کے لیے، غیر کیش شدہ (uncached) سے کیش شدہ (cached) حالت میں منتقل ہونا ماہانہ اخراجات میں ڈرامائی کمی لا سکتا ہے—جیسا کہ رپورٹ شدہ کیس میں تقریباً $1,890 سے $406 تک کی کمی دیکھی گئی۔ کم ٹریفک میں بھی نمایاں بچت ہوتی ہے، اور ایک بڑے ساکن پرامپٹ کو دوبارہ استعمال کرنے سے کارکردگی میں بہتری آتی ہے جو لیٹنسی (latency) کو کم کر سکتی ہے۔

متقابل نقطہ نظر

تاہم، اس ناکامی کی خاموش نوعیت کا مطلب یہ ہے کہ اس بات کو یقینی بنانے کا واحد طریقہ کہ آپ ضرورت سے زیادہ ادائیگی نہیں کر رہے، ریڈ کاؤنٹ (read count) کو چیک کرنا ہے—جسے بہت سے لوگ نظر انداز کر دیتے ہیں۔

آگے کیا نظر رکھنا ہے

  • میٹرک ڈیش بورڈز (Metric dashboards) – درخواستوں کے حجم کے ساتھ ساتھ cache-read tokens کے لیے بھی ایک گیج (gauge) شامل کریں۔
  • ٹول آرڈرنگ کا استحکام (Tool-ordering stability) – اگر آپ متحرک طور پر تیار کردہ ٹولز کی فہرستوں پر انحصار کرتے ہیں، تو انہیں پرامپٹ میں شامل کرنے سے پہلے ایک طے شدہ ترتیب (deterministically) میں ترتیب دینے پر غور کریں۔

خلاصہ: Claude کی prompt caching آپ کی درخواست کو خاموشی سے نظر انداز کرنے پر کوئی ایرر نہیں دیتی۔ ریڈ ٹوکنز (read tokens) کو لاگ کر کے کیش کی تاثیر کی تصدیق کریں، مناسب prefix کی لمبائی کو یقینی بنائیں، اور پرامپٹ کے ابتدائی بائٹس کو ناقابل تبدیلی (immutable) رکھیں۔ صرف تب ہی آپ وعدہ کردہ لاگت اور رفتار کے فوائد حاصل کر سکیں گے۔