મારા Agent Orchestrator એ દરેક કાર્ય માટે 1-2 મિલિયન Opus ટોકન્સ ખર્ચ કરી નાખ્યા.

ખર્ચ કેવી રીતે આસમાને પહોંચ્યો

આ ઓર્કેસ્ટ્રેટર Claude Code માટે બનાવવામાં આવ્યું હતું અને તેમાં સબ-એજન્ટ્સનું એક શ્રેણીબદ્ધ માળખું (hierarchy) હતું. દરેક સબ-એજન્ટ પેરન્ટ સેટિંગ્સ વારસામાં મેળવતું, પોતાનું પ્રોમ્પ્ટ ચલાવતું અને જ્યાં સુધી રિવ્યુઅર આઉટપુટને “clean” જાહેર ન કરે ત્યાં સુધી પરિણામને ફરીથી લૂપમાં મોકલતું હતું. ટૂલે કાર્યો પૂર્ણ કર્યા, પરંતુ તેની કિંમત આસમાને હતી.

ત્રણ છુપા “ટેક્સ” (taxes) એ ટોકન સંખ્યામાં વધારો કર્યો:

  • Model tax – સબ-એજન્ટ્સ ક્યારેય મોડેલ સ્પષ્ટ કરતા નહોતા, તેથી તેઓ ડિફોલ્ટ તરીકે સૌથી મોંઘા સ્તર (tier) Opus નો ઉપયોગ કરતા હતા. એક નાનું ઓપરેશન જે સસ્તા મોડેલ (Haiku અથવા Sonnet) પર થઈ શક્યું હોત, તેનું બિલિંગ Opus ના દરે કરવામાં આવતું હતું.
  • Cache tax – પ્રોમ્પ્ટ કેશિંગ (Prompt caching) ફક્ત બરાબર બાઈટ-ટુ-બાઈટ મેચ થતા ડેટાનો જ ફરીથી ઉપયોગ કરે છે. દરેક સબ-એજન્ટ કસ્ટમ સૂચનાઓ ઉમેરતું હોવાથી, દરેક કોલ વખતે નવું કેશ લખવું (cold cache write) પડતું હતું. પેરન્ટનું કેશ ફરીથી વાપરી શકાતું નહોતું, જેના કારણે શેર કરેલા કેશ દ્વારા મળતી બચતનો બગાડ થતો હતો.
  • Loop tax – “loop until clean” ના નિયમ હેઠળ, જ્યાં સુધી રિવ્યુઅરને કોઈ ખામી ન મળે ત્યાં સુધી પ્રક્રિયા ચાલુ રહેતી હતી. કોઈ મર્યાદા (hard ceiling) ન હોવાને કારણે, મોડેલ જ્યાં સુધી અટકી ન જાય ત્યાં સુધી લૂપ ચાલતું રહ્યું.

આ તમામ પરિબળોએ મળીને થોડી લાઈનોના કોડને ટોકન્સના પહાડમાં (avalanche) ફેરવી દીધો.

પ્રોમ્પ્ટમાં બજેટનો નિયમ કેમ નિષ્ફળ ગયો

મૂળ ડિઝાઇનમાં સિસ્ટમ પ્રોમ્પ્ટમાં સીધો જ બજેટનો નિયમ સામેલ કરીને ખર્ચ ઘટાડવાનો પ્રયાસ કરવામાં આવ્યો હતો. સૈદ્ધાંતિક રીતે, મોડેલને “stay under X tokens” કહેવાથી વપરાશ મર્યાદિત થવો જોઈતો હતો. પરંતુ વ્યવહારમાં, પ્રોમ્પ્ટ-આધારિત નિયમ માત્ર એક પસંદગી (preference) છે. જેમ જેમ સેશન વધતું જાય છે, તેમ તેમ મોડેલ કોન્ટેક્સ્ટને કોમ્પ્રેસ કરે છે અને તે સૂચનાઓને સંપૂર્ણપણે છોડી શકે છે અથવા અવગણી શકે છે. પરિણામ: મોડેલે એવી રીતે વર્તન કર્યું જાણે કે તે નિયમ ક્યારેય હતો જ નહીં.

અમલીકરણને પ્રોમ્પ્ટમાંથી કોડમાં ખસેડવું

રીડિઝાઇનમાં બજેટ લોજિકને પ્રોમ્પ્ટમાંથી