എന്റെ Agent Orchestrator ഓരോ ടാസ്കിനും 1-2 മില്യൺ Opus ടോക്കണുകൾ ഉപയോഗിച്ചു തീർത്തു.

ചിലവ് ഇത്രയധികം വർദ്ധിക്കാൻ കാരണമെന്ത്

Claude Code-ന് വേണ്ടി നിർമ്മിച്ച ഈ ഓർക്കസ്ട്രേറ്റർ സബ്-ഏജന്റുകളുടെ (sub-agents) ഒരു ശ്രേണി ഉപയോഗിച്ചിരുന്നു. ഓരോ സബ്-ഏജന്റും പാരന്റ് ഏജന്റിന്റെ സെറ്റിംഗുകൾ സ്വീകരിക്കുകയും, സ്വന്തമായി പ്രോംപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുകയും, ഒരു റിവ്യൂവർ ഔട്ട്പുട്ട് "clean" ആണെന്ന് പ്രഖ്യാപിക്കുന്നത് വരെ ഫലം ലൂപ്പിലേക്ക് തിരികെ നൽകുകയും ചെയ്തിരുന്നു. ടൂൾ ടാസ്ക്കുകൾ പൂർത്തിയാക്കി എങ്കിലും, അതിന്റെ ചിലവ് അമിതമായിരുന്നു.

മൂന്ന് ഒളിഞ്ഞിരിക്കുന്ന "ടാക്സുകൾ" (taxes) ടോക്കൺ എണ്ണത്തെ വർദ്ധിപ്പിച്ചു:

  • Model tax – സബ്-ഏജന്റുകൾ ഒരു മോഡലും പ്രത്യേകം നിശ്ചയിച്ചിരുന്നില്ല, അതിനാൽ അവ ഏറ്റവും ചിലവേറിയ Opus മോഡലിലേക്ക് തനിയെ മാറി (defaulted). കുറഞ്ഞ ചിലവിലുള്ള ഒരു മോഡലിൽ (Haiku അല്ലെങ്കിൽ Sonnet) ചെയ്യാവുന്ന ചെറിയ ജോലികൾ പോലും Opus നിരക്കിൽ ബില്ല് ചെയ്യപ്പെട്ടു.
  • Cache tax – പ്രോംപ്റ്റ് കാഷിംഗ് (Prompt caching) കൃത്യമായ ബൈറ്റ്-ടു-ബൈറ്റ് മാച്ചുകൾ മാത്രമേ വീണ്ടും ഉപയോഗിക്കൂ. ഓരോ സബ്-ഏജന്റും കസ്റ്റം ഇൻസ്ട്രക്ഷനുകൾ ചേർക്കുന്നതിനാൽ, ഓരോ തവണ വിളിക്കുമ്പോഴും പുതിയ കാഷ് എഴുതേണ്ടി വന്നു (cold cache write). പാരന്റ് ഏജന്റിന്റെ കാഷ് വീണ്ടും ഉപയോഗിക്കാൻ സാധിക്കാത്തതിനാൽ, ഒരു ഷെയർഡ് കാഷ് സാധാരണ നൽകുന്ന ലാഭം ഇവിടെ നഷ്ടമായി.
  • Loop tax – "loop until clean" എന്ന നിയമം കാരണം, ഒരു റിവ്യൂവർ എന്തെങ്കിലും പിശക് കണ്ടെത്തുന്നിടത്തോളം കാലം പ്രക്രിയ തുടർന്നു കൊണ്ടിരുന്നു. കൃത്യമായ ഒരു പരിധി (hard ceiling) ഇല്ലാത്തതിനാൽ, മോഡൽ നിൽക്കുന്നത് വരെ ലൂപ്പ് പ്രവർത്തിച്ചുകൊണ്ടിരുന്നു.

ഇവയെല്ലാം ചേർന്ന് ഏതാനും വരി കോഡുകളെ ടോക്കണുകളുടെ ഒരു വലിയ പ്രളയമാക്കി മാറ്റി.

പ്രോംപ്റ്റിലെ ബജറ്റ് നിയമം പരാജയപ്പെട്ടത് എന്തുകൊണ്ട്

സിസ്റ്റം പ്രോംപ്റ്റിൽ നേരിട്ട് ഒരു ബജറ്റ് നിയമം ഉൾപ്പെടുത്തിക്കൊണ്ട് ചിലവ് നിയന്ത്രിക്കാനാണ് ആദ്യത്തെ ഡിസൈൻ ശ്രമിച്ചത്. സിദ്ധാന്തപരമായി പറഞ്ഞാൽ, "X ടോക്കണുകളിൽ താഴെ നിൽക്കുക" എന്ന് മോഡലിനോട് പറയുന്നത് ഉപയോഗം പരിമിതപ്പെടുത്തേണ്ടതായിരുന്നു. എന്നാൽ പ്രായോഗികമായി, പ്രോംപ്റ്റ് അടിസ്ഥാനമാക്കിയുള്ള ഒരു നിയമം വെറുമൊരു മുൻഗണന മാത്രമാണ്. സെഷൻ വളരുന്നതിനനുസരിച്ച്, മോഡൽ കോൺടെക്സ്റ്റ് കംപ്രസ്സ് ചെയ്യുകയും ആ നിർദ്ദേശങ്ങൾ പൂർണ്ണമായും ഒഴിവാക്കുകയോ അവഗണിക്കുകയോ ചെയ്തേക്കാം. ഫലമോ: ആ നിയമം നിലവിലില്ലാത്തതുപോലെ മോഡൽ പ്രവർത്തിച്ചു.

നിയന്ത്രണങ്ങൾ പ്രോംപ്റ്റിൽ നിന്ന് കോഡിലേക്ക് മാറ്റുന്നു

പുതിയ ഡിസൈനിൽ ബജറ്റ് ലോജിക് പ്രോംപ്റ്റിൽ നിന്ന് നീക്കം ചെയ്യുകയും, മോഡലിന് മാറ്റാൻ കഴിയാത്ത ഒരു ഡെറ്റർമിനിസ്റ്റിക് ഹുക്ക് സിസ്റ്റത്തിൽ (deterministic hook system) ഉൾപ്പെടുത്തുകയും ചെയ്തു.

  1. Explicit model selection – ഓരോ സബ്-ഏജന്റ് ഡിസ്പാച്ചും (dispatch) ഇനി മുതൽ കൃത്യമായ ഒരു മോഡൽ തിരഞ്ഞെടുക്കേണ്ടതുണ്ട് (Haiku, Sonnet, അല്ലെങ്കിൽ Opus). പഴയതുപോലെ തനിയെ മോഡൽ മാറുന്ന രീതി ഒഴിവാക്കിയതോടെ, കുറഞ്ഞ ചിലവിലുള്ള ജോലികൾ കുറഞ്ഞ ചിലവിൽ തന്നെ തീരുന്നു.
  2. Hard guards via a PreToolUse hook – ഏതൊരു ടൂൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പും, ഈ ഹുക്ക് താഴെ പറയുന്നവ പരിശോധിക്കുന്നു:
    • സെഷനിൽ ഇതിനകം എത്ര ഡിസ്പാച്ചുകൾ നടന്നു എന്നത്.
    • തിരഞ്ഞെടുത്ത മോഡൽ ഒരു മിനിമം ടയറിലാണോ എന്ന് (അബദ്ധത്തിൽ Opus ഉപയോഗിക്കുന്നത് ഒഴിവാക്കാൻ).
    • ലൂപ്പ് ഇറ്ററേഷനുകളുടെ പരമാവധി എണ്ണം, ഇത് കഴിഞ്ഞാൽ പ്രക്രിയ തടയപ്പെടും.

ഏതെങ്കിലും നിയന്ത്രണം ലംഘിക്കപ്പെട്ടാൽ, കോഡ് സബ്-ഏജന്റിനെ തടയുന്നു; ലാംഗ്വേജ് മോഡലിന് അതിനെ തിരുത്തി മുന്നോട്ട് പോകാൻ കഴിയില്ല.

ഡെവലപ്പർമാർക്ക് ഇതിന്റെ അർത്ഥമെന്താണ്

ചിലവ് പരിധികൾ (spend caps), സുരക്ഷാ നയങ്ങൾ, അല്ലെങ്കിൽ വിനാശകരമായ കമാൻഡുകൾക്കുള്ള നിയന്ത്രണങ്ങൾ എന്നിവ ഏർപ്പെടുത്തുന്ന ഏതൊരു സിസ്റ്റവും ആ നിയന്ത്രണങ്ങളെ ഒരു സംഭാഷണ നിർദ്ദേശമായിട്ടല്ല, മറിച്ച് കോഡായിട്ടാണ് കാണേണ്ടത്. ഒരു പ്രോംപ്റ്റ് മാറ്റം വരുത്താനോ, അവഗണിക്കാനോ, അല്ലെങ്കിൽ മോഡലിന്റെ ഇന്റേണൽ കംപ്രഷനിൽ നഷ്ടപ്പെടാനോ സാധ്യതയുണ്ട്. എന്നാൽ കോഡ്, കൃത്യമായ രീതിയിൽ (deterministically) പ്രവർത്തിക്കുകയും ഓഡിറ്റ് ചെയ്യാൻ സാധിക്കുകയും ചെയ്യുന്നു.