ನನ್ನ Agent Orchestrator ಪ್ರತಿ ಕಾರ್ಯಕ್ಕೆ 1-2 ಮಿಲಿಯನ್ Opus ಟೋಕನ್‌ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡಿತು.

ವೆಚ್ಚ ಹೇಗೆ ಅತಿಯಾಯಿತು

ಈ orchestrator ಅನ್ನು Claude Code ಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿತ್ತು ಮತ್ತು ಇದು sub-agents ಗಳ ಶ್ರೇಣೀಕೃತ ವ್ಯವಸ್ಥೆಯನ್ನು (hierarchy) ಬಳಸುತ್ತಿತ್ತು. ಪ್ರತಿಯೊಂದು sub-agent ಕೂಡ ಪೋಷಕ (parent) ಏಜೆಂಟ್‌ನ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತಿತ್ತು, ತನ್ನದೇ ಆದ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಚಲಾಯಿಸುತ್ತಿತ್ತು ಮತ್ತು ವಿಮರ್ಶಕರು (reviewer) ಔಟ್‌ಪುಟ್ "clean" ಎಂದು ಘೋಷಿಸುವವರೆಗೆ ಫಲಿತಾಂಶವನ್ನು ಮತ್ತೆ ಲೂಪ್‌ಗೆ ಕಳುಹಿಸುತ್ತಿತ್ತು. ಈ ಸಾಧನವು ಕಾರ್ಯಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತಿತ್ತು, ಆದರೆ ಅದರ ಬೆಲೆ ಮಾತ್ರ ಆಕಾಶಕ್ಕೇರಿದೆ.

ಮೂರು ಗುಪ್ತ "ತೆರಿಗೆಗಳು" (taxes) ಟೋಕನ್ ಸಂಖ್ಯೆಯನ್ನು ಗುಣಾಕಾರದಲ್ಲಿ ಹೆಚ್ಚಿಸಿದವು:

  • Model tax – sub-agents ಗಳು ಎಂದಿಗೂ ಯಾವುದೇ ಮಾಡೆಲ್ ಅನ್ನು ನಿರ್ದಿಷ್ಟಪಡしていರಲಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವು ತಾನಾಗಿಯೇ ಅತ್ಯಂತ ದುಬಾರಿ ಹಂತವಾದ Opus ಅನ್ನು ಬಳಸುತ್ತಿದ್ದವು. ಕಡಿಮೆ ಬೆಲೆಯ ಮಾಡೆಲ್‌ನಲ್ಲಿ (Haiku ಅಥವಾ Sonnet) ಸುಲಭವಾಗಿ ಆಗಬಹುದಾದ ಸಣ್ಣ ಕೆಲಸಕ್ಕೂ Opus ದ ದರದಲ್ಲಿ ಬಿಲ್ ಮಾಡಲಾಗುತ್ತಿತ್ತು.
  • Cache tax – Prompt caching ಎಂಬುದು ನಿಖರವಾದ (exact byte-for-byte) ಹೊಂದಾಣಿಕೆಗಳನ್ನು ಮಾತ್ರ ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ. ಪ್ರತಿಯೊಂದು sub-agent ಕೂಡ ತನ್ನದೇ ಆದ ಕಸ್ಟಮ್ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸಿದ್ದರಿಂದ, ಪ್ರತಿ ಬಾರಿ ಕರೆ ಮಾಡಿದಾಗಲೂ ಹೊಸದಾಗಿ (cold cache write) ಬರೆಯಬೇಕಾಗುತ್ತಿತ್ತು. ಪೋಷಕ ಏಜೆಂಟ್‌ನ ಕ್ಯಾಶ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತಿರಲಿಲ್ಲ, ಇದರಿಂದಾಗಿ ಹಂಚಿಕೆಯ ಕ್ಯಾಶ್ (shared cache) ನೀಡುವ ಉಳಿತಾಯವು ವ್ಯರ್ಥವಾಗುತ್ತಿತ್ತು.
  • Loop tax – "clean ಆಗುವವರೆಗೆ ಲೂಪ್ ಮಾಡಿ" ಎಂಬ ನಿಯಮವು ವಿಮರ್ಶಕರಿಗೆ ಯಾವುದೇ ದೋಷ ಕಂಡುಬರುವವರೆಗೆ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮುಂದುವರಿಸುತ್ತಿತ್ತು. ಯಾವುದೇ ಗರಿಷ್ಠ ಮಿತಿಯಿಲ್ಲದ ಕಾರಣ, ಮಾಡೆಲ್ ನಿಲ್ಲುವವರೆಗೆ ಲೂಪ್ ಚಲಿಸುತ್ತಲೇ ಇರುತ್ತಿತ್ತು.

ಒಟ್ಟಾರೆಯಾಗಿ, ಈ ಗುಣಕಗಳು (multipliers) ಕೆಲವೇ ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ಟೋಕನ್‌ಗಳ ಮಹಾಪೂರವನ್ನಾಗಿ ಬದಲಿಸಿದವು.

ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿನ ಬಜೆಟ್ ನಿಯಮ ಏಕೆ ವಿಫಲವಾಯಿತು

ಮೂಲ ವಿನ್ಯಾಸವು ಸಿಸ್ಟಮ್ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿಯೇ ಬಜೆಟ್ ನಿಯಮವನ್ನು ಅಳವಡಿಸುವ ಮೂಲಕ ವೆಚ್ಚವನ್ನು ನಿಯಂತ್ರಿಸಲು ಪ್ರಯತ್ನಿಸಿತ್ತು. ಸಿದ್ಧಾಂತದ ಪ್ರಕಾರ, ಮಾಡೆಲ್‌ಗೆ "X ಟೋಕನ್‌ಗಳಿಗಿಂತ ಕಡಿಮೆ ಇರಿ" ಎಂದು ಹೇಳುವುದು ಬಳಕೆಯನ್ನು ಮಿತಿಗೊಳಿಸಬೇಕಿತ್ತು. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಪ್ರಾಂಪ್ಟ್ ಆಧಾರಿತ ನಿಯಮವು ಕೇವಲ ಒಂದು ಆದ್ಯತೆಯಾಗಿರುತ್ತದೆ (preference). ಸೆಷನ್ ಬೆಳೆದಂತೆ, ಮಾಡೆಲ್ ಸಂದರ್ಭವನ್ನು (context) ಸಂಕುಚಿತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಆ ಸೂಚನೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬಿಟ್ಟುಬಿಡಬಹುದು ಅಥವಾ ನಿರ್ಲಕ್ಷಿಸಬಹುದು. ಇದರ ಪರಿಣಾಮ: ಆ ನಿಯಮವೇ ಇಲ್ಲದಂತೆ ಮಾಡೆಲ್ ವರ್ತಿಸಿತು.

ಜಾರಿಗೊಳಿಸುವಿಕೆಯನ್ನು ಪ್ರಾಂಪ್ಟ್‌ನಿಂದ ಕೋಡ್‌ಗೆ ಬದಲಾಯಿಸುವುದು

ಮರುವಿನ್ಯಾಸವು ಬಜೆಟ್ ತರ್ಕವನ್ನು (logic) ಪ್ರಾಂಪ್ಟ್‌ನಿಂದ ತೆಗೆದುಹಾಕಿ, ಮಾಡೆಲ್ ಅತಿಕ್ರಮಿಸಲು ಸಾಧ್ಯವಾಗದ ಒಂದು ನಿರ್ಧಾರಿತ (deterministic) ಹೂಕ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ (hook system) ಇರಿಸಿತು.

  1. Explicit model selection – ಪ್ರತಿಯೊಂದು sub-agent ಡಿಸ್ಪ್ಯಾಚ್ ಈಗ ನಿರ್ದಿಷ್ಟ ಮಾಡೆಲ್ ಆಯ್ಕೆಯನ್ನು (Haiku, Sonnet, ಅಥವಾ Opus) ಬಯಸುತ್ತದೆ. ಅತಿಕ್ರಮಿಸುವ ಅಥವಾ ತಾನಾಗಿಯೇ ಪಡೆಯುವ (silent inheritance) ವ್ಯವಸ್ಥೆ ಈಗ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಕಡಿಮೆ ವೆಚ್ಚದ ಕೆಲಸಗಳು ಕಡಿಮೆ ವೆಚ್ಚದಲ್ಲೇ ಇರುತ್ತವೆ.
  2. Hard guards via a PreToolUse hook – ಯಾವುದೇ ಟೂಲ್ ರನ್ ಆಗುವ ಮೊದಲು, ಹೂಕ್ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ:
    • ಸೆಷನ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಮಾಡಲಾದ ಡಿಸ್ಪ್ಯಾಚ್‌ಗಳ ಸಂಖ್ಯೆ.
    • ಆಯ್ಕೆ ಮಾಡಿದ ಮಾಡೆಲ್ ಕನಿಷ್ಠ ಹಂತವನ್ನು (minimum tier) ತಲುಪುತ್ತಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ (ಅಕಸ್ಮಾತ್ Opus ಬಳಕೆಯಾಗುವುದನ್ನು ತಡೆಯಲು).
    • ಲೂಪ್‌ನ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಅವಧಿ, ಅದರ ನಂತರ ಪ್ರಕ್ರಿಯೆಯು ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ.

ಯಾವುದೇ ಗಾರ್ಡ್ (guard) ನಿಯಮ ಉಲ್ಲಂಘನೆಯಾದರೆ, ಕೋಡ್ sub-agent ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸುತ್ತದೆ; ಭಾಷಾ ಮಾಡೆಲ್‌ಗೆ ಅದನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ಅಥವಾ ವಾದಿಸಲು ಯಾವುದೇ ದಾರಿಯಿಲ್ಲ.

ಇದು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಏನನ್ನು ಸೂಚಿಸುತ್ತದೆ

ವೆಚ್ಚದ ಮಿತಿಗಳು (spend caps), ಭದ್ರತಾ ನೀತಿಗಳು ಅಥವಾ ವಿನಾಶಕಾರಿ ಕಮಾಂಡ್‌ಗಳ ಮೇಲೆ ಮಿತಿಗಳನ್ನು ಹೇರುವ ಯಾವುದೇ ವ್ಯವಸ್ಥೆಯು ಆ ನಿರ್ಬಂಧಗಳನ್ನು ಸಂಭಾಷಣೆಯ ಮಾರ್ಗದರ್ಶನದಂತೆ ನೋಡದೆ, ಕೋಡ್‌ನಂತೆ ಪರಿಗಣಿಸಬೇಕು. ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮರುಬರೆಯಬಹುದು, ನಿರ್ಲಕ್ಷಿಸಬಹುದು ಅಥವಾ ಮಾಡೆಲ್‌ನ ಆಂತರಿಕ ಸಂಕುಚನದಲ್ಲಿ (internal compression) ಕಳೆದುಹೋಗಬಹುದು. ಆದರೆ ಕೋಡ್, ನಿರ್ಧಾರಿತವಾಗಿ (deterministically) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಪರಿಶೀಲಿಸಬಹುದು (audited).