எனது Agent Orchestrator ஒரு பணிக்கு 1-2 மில்லியன் Opus டோக்கன்களைச் செலவழித்தது.

செலவு எவ்வாறு அதிகரித்தது

இந்த orchestrator Claude Code-க்காக உருவாக்கப்பட்டது மற்றும் துணை ஏஜென்ட்களின் (sub-agents) படிநிலையைப் பயன்படுத்தியது. ஒவ்வொரு துணை ஏஜென்ட்டும் அதன் பெற்றோர் ஏஜென்ட்டின் அமைப்புகளைப் பெற்றுக்கொண்டது, அதன் சொந்த ப்ராம்ப்ட்டை (prompt) இயக்கியது, மேலும் ஒரு மதிப்பாய்வாளர் (reviewer) வெளியீட்டை "சுத்தமானது" (clean) என்று அறிவிக்கும் வரை அதன் முடிவை மீண்டும் லூப்பிற்கு (loop) அனுப்பியது. இந்தத் கருவி பணிகளை முடித்தது, ஆனால் அதன் விலை மிக அதிகமாக இருந்தது.

மூன்று மறைமுகமான "வரிகள்" (taxes) டோக்கன் எண்ணிக்கையை பலமடங்கு அதிகரித்தன:

  • Model tax – துணை ஏஜென்ட்கள் ஒரு மாடலைத் (model) தீர்மானிக்கவில்லை, எனவே அவை மிகவும் விலையுயர்ந்த Opus மாடலைத் தானாகவே தேர்ந்தெடுத்தன. ஒரு மலிவான மாடலில் (Haiku அல்லது Sonnet) செய்யக்கூடிய சிறிய பணி கூட Opus விலையிலேயே கணக்கிடப்பட்டது.
  • Cache tax – Prompt caching என்பது துல்லியமான byte-for-byte பொருத்தங்களை மட்டுமே மீண்டும் பயன்படுத்தும். ஒவ்வொரு துணை ஏஜென்ட்டும் தனிப்பயனாக்கப்பட்ட வழிமுறைகளை (custom instructions) சேர்த்ததால், ஒவ்வொரு அழைப்பும் ஒரு புதிய கேச் பதிவை (cold cache write) கட்டாயப்படுத்தியது. பெற்றோர் ஏஜென்ட்டின் கேச் மீண்டும் பயன்படுத்தப்படவில்லை, இதனால் ஒரு பகிரப்பட்ட கேச் (shared cache) வழக்கமாக வழங்கும் சேமிப்பு வீணானது.
  • Loop tax – "சுத்தமாகும் வரை லூப் செய்" (loop until clean) என்ற விதி, மதிப்பாய்வாளர் ஏதேனும் குறையைக் கண்டறியும் வரை செயல்முறையைத் தொடரச் செய்தது. இதற்கு எந்தக் கட்டுப்பாடும் இல்லாததால், மாடல் நிற்கும் வரை லூப் இயங்கிக்கொண்டே இருந்தது.

இவை அனைத்தும் இணைந்து, சில வரிக் குறியீடுகளை (lines of code) ஒரு டோக்கன் பனிச்சரிவாக (token avalanche) மாற்றின.

ப்ராம்ப்ட்டில் இருந்த பட்ஜெட் விதி ஏன் தோல்வியடைந்தது

அசல் வடிவமைப்பு, சிஸ்டம் ப்ராம்ப்ட்டிலேயே (system prompt) ஒரு பட்ஜெட் விதியை இணைப்பதன் மூலம் செலவைக் குறைக்க முயன்றது. கோட்பாட்டளவில், மாடலிடம் "X டோக்கன்களுக்குள் இரு" என்று சொல்வது பயன்பாட்டைக் கட்டுப்படுத்தியிருக்க வேண்டும். ஆனால் நடைமுறையில், ப்ராம்ப்ட் அடிப்படையிலான விதி என்பது ஒரு விருப்பம் மட்டுமே. செஷன் (session) வளர வளர, மாடல் சூழலைச் (context) சுருக்குகிறது, இதனால் அந்த வழிமுறைகளை முற்றிலும் புறக்கணித்துவிடக்கூடும். இதன் விளைவாக: அந்த விதி இருந்ததே இல்லை என்பது போல மாடல் செயல்பட்டது.

கட்டுப்பாட்டை ப்ராம்ப்ட்டிலிருந்து குறியீட்டிற்கு (code) மாற்றுதல்

மறுவடிவமைப்பு, பட்ஜெட் தர்க்கத்தை (budget logic) ப்ராம்ப்ட்டிலிருந்து நீக்கிவிட்டு, மாடலால் மாற்றியமைக்க முடியாத ஒரு தீர்மானிக்கப்பட்ட ஹூக் சிஸ்டத்தில் (deterministic hook system) அமைத்தது.

  1. Explicit model selection – ஒவ்வொரு துணை ஏஜென்ட் அழைப்பிற்கும் (dispatch) இப்போது ஒரு குறிப்பிட்ட மாடல் தேர்வு (Haiku, Sonnet, அல்லது Opus) தேவைப்படுகிறது. தானாகவே மாடலைத் தேர்ந்தெடுக்கும் முறை நீக்கப்பட்டுவிட்டதால், மலிவான பணிகள் மலிவாகவே உள்ளன.
  2. Hard guards via a PreToolUse hook – எந்தவொரு கருவியும் (tool) இயங்குவதற்கு முன், அந்த ஹூக் பின்வருவனவற்றைச் சரிபார்க்கிறது:
    • செஷனில் ஏற்கனவே செய்யப்பட்ட அழைப்புகளின் எண்ணிக்கை.
    • தேர்ந்தெடுக்கப்பட்ட மாடல் குறைந்தபட்சத் தரத்தில் உள்ளதா என்பது (தவறுதலாக Opus பயன்படுவதைத் தடுக்கிறது).
    • லூப் சுழற்சிகளின் அதிகபட்ச எண்ணிக்கை, அதன் பிறகு செயல்முறை நிறுத்தப்படும்.

ஏதேனும் ஒரு கட்டுப்பாடு மீறப்பட்டால், குறியீடு அந்த துணை ஏஜென்ட்டை நிறுத்திவிடும்; மொழி மாடலால் அதைத் தடுத்து நிறுத்தவோ அல்லது மீண்டும் தொடரவோ முடியாது.

டெவலப்பர்களுக்கு இதன் பொருள் என்ன

செலவு வரம்புகள் (spend caps), பாதுகாப்பு கொள்கைகள் அல்லது அழிவுகரமான கட்டளைகளுக்கான (destructive commands) கட்டுப்பாடுகளை விதிக்கும் எந்தவொரு அமைப்பும், அந்தத் தடைகளை உரையாடல் வழிகாட்டுதலாகக் கருதாமல், குறியீடாகவே (code) கருத வேண்டும். ஒரு ப்ராம்ப்ட் மாற்றப்படலாம், புறக்கணிக்கப்படலாம் அல்லது மாடலின் உள் சுருக்கத்தின் போது (internal compression) காணாமல் போகலாம். ஆனால், குறியீடு என்பது தீர்மானிக்கப்பட்ட முறையில் இயங்கக்கூடியது மற்றும் தணிக்கை (audit) செய்யப்படக்கூடியது.