ਮੇਰੇ Agent Orchestrator ਨੇ ਪ੍ਰਤੀ ਟਾਸਕ 1-2 ਮਿਲੀਅਨ Opus tokens ਖ਼ਰਚ ਦਿੱਤੇ।

ਖ਼ਰਚਾ ਕਿਵੇਂ ਵਧ ਗਿਆ

ਇਹ orchestrator Claude Code ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ ਅਤੇ ਇਸ ਵਿੱਚ sub-agents ਦੀ ਇੱਕ ਲੜੀ (hierarchy) ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ। ਹਰੇਕ sub-agent ਮੇਨ (parent) ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਅਪਣਾਉਂਦਾ ਸੀ, ਆਪਣਾ ਖ਼ੁਦ ਦਾ prompt ਚਲਾਉਂਦਾ ਸੀ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਉਦੋਂ ਤੱਕ ਲੂਪ (loop) ਵਿੱਚ ਵਾਪਸ ਭੇਜਦਾ ਰਹਿੰਦਾ ਸੀ ਜਦੋਂ ਤੱਕ ਇੱਕ reviewer ਆਉਟਪੁੱਟ ਨੂੰ “clean” ਨਹੀਂ ਕਰ ਦਿੰਦਾ ਸੀ। ਟੂਲ ਨੇ ਟਾਸਕ ਤਾਂ ਪੂਰੇ ਕੀਤੇ, ਪਰ ਇਸਦੀ ਕੀਮਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੀ।

ਤਿੰਨ ਲੁਕਵੇਂ “taxes” ਨੇ token ਦੀ ਗਿਣਤੀ ਨੂੰ ਕਈ ਗੁਣਾ ਵਧਾ ਦਿੱਤਾ:

  • Model tax – sub-agents ਨੇ ਕਦੇ ਵੀ ਕੋਈ ਮਾਡਲ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤਾ ਸੀ, ਇਸ ਲਈ ਉਹ ਆਪਣੇ ਆਪ ਸਭ ਤੋਂ ਮਹਿੰਗੇ ਤਹਿ (tier) Opus 'ਤੇ ਚਲੇ ਗਏ। ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਕੰਮ ਜੋ ਕਿ ਸਸਤੇ ਮਾਡਲ (Haiku ਜਾਂ Sonnet) 'ਤੇ ਹੋ ਸਕਦਾ ਸੀ, ਉਸਦਾ ਬਿੱਲ Opus ਦੀਆਂ ਦਰਾਂ 'ਤੇ ਭੇਜਿਆ ਗਿਆ।
  • Cache tax – Prompt caching ਸਿਰਫ਼ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹੇ (byte-for-byte) ਮੈਚਾਂ ਨੂੰ ਹੀ ਦੁਬਾਰਾ ਵਰਤਦੀ ਹੈ। ਕਿਉਂਕਿ ਹਰੇਕ sub-agent ਨੇ ਆਪਣੀਆਂ ਵੱਖਰੀਆਂ ਹਦਾਇਤਾਂ (custom instructions) ਜੋੜੀਆਂ ਸਨ, ਇਸ ਲਈ ਹਰ ਵਾਰ ਇੱਕ ਨਵਾਂ 'cold cache write' ਕਰਨਾ ਪਿਆ। ਮੇਨ (parent) ਦੇ ਕੈਸ਼ (cache) ਦੀ ਦੁਬਾਰਾ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਸੀ, ਜਿਸ ਨਾਲ ਇੱਕ ਸਾਂਝੇ ਕੈਸ਼ ਤੋਂ ਹੋਣ ਵਾਲੀ ਬਚਤ ਖ਼ਤਮ ਹੋ ਗਈ।
  • Loop tax – “loop until clean” ਨਿਯਮ ਨੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਦੋਂ ਤੱਕ ਚਲਾਇਆ ਰੱਖਿਆ ਜਦੋਂ ਤੱਕ reviewer ਨੂੰ ਕੋਈ ਵੀ ਕਮੀ ਮਿਲਦੀ ਰਹੀ। ਕੋਈ ਸਖ਼ਤ ਸੀਮਾ (hard ceiling) ਨਾ ਹੋਣ ਕਾਰਨ, ਇਹ ਲੂਪ ਉਦੋਂ ਤੱਕ ਚੱਲਦਾ ਰਿਹਾ ਜਦੋਂ ਤੱਕ ਮਾਡਲ ਰੁਕ ਨਹੀਂ ਗਿਆ।

ਇਹਨਾਂ ਸਾਰੇ ਕਾਰਕਾਂ ਨੇ ਮਿਲ ਕੇ ਕੁਝ ਲਾਈਨਾਂ ਦੇ ਕੋਡ ਨੂੰ tokens ਦੇ ਹੜ੍ਹ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।

Prompt ਵਿੱਚ ਬਜਟ ਨਿਯਮ ਕਿਉਂ ਅਸਫਲ ਰਿਹਾ

ਅਸਲ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਸਿਸਟਮ prompt ਦੇ ਅੰਦਰ ਹੀ ਬਜਟ ਨਿਯਮ ਨੂੰ ਜੋੜ ਕੇ ਖ਼ਰਚੇ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਗਈ ਸੀ। ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਮਾਡਲ ਨੂੰ “stay under X tokens” ਕਹਿਣ ਨਾਲ ਵਰਤੋਂ ਸੀਮਤ ਹੋ ਜਾਣੀ ਚਾਹੀਦੀ ਸੀ। ਪਰ ਅਸਲ ਵਿੱਚ, prompt 'ਤੇ ਅਧਾਰਤ ਨਿਯਮ ਸਿਰਫ਼ ਇੱਕ ਤਰਜੀਹ (preference) ਹੁੰਦਾ ਹੈ। ਜਿਵੇਂ-ਜਿਵੇਂ ਸੈਸ਼ਨ ਵਧਦਾ ਹੈ, ਮਾਡਲ context ਨੂੰ ਸੰਕੁਚਿਤ (compress) ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਹਦਾਇਤਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਜਾਂ ਅਣਦੇਖਾ ਕਰ ਸਕਦਾ ਹੈ। ਨਤੀਜਾ ਇਹ ਨਿਕਲਿਆ: ਮਾਡਲ ਇਸ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਨ ਲੱਗਾ ਜਿਵੇਂ ਉਹ ਨਿਯਮ ਕਦੇ ਸੀ ਹੀ ਨਹੀਂ।

Enforcement ਨੂੰ prompt ਤੋਂ ਕੋਡ ਵਿੱਚ ਲੈ ਕੇ ਆਉਣਾ

ਨਵੇਂ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਬਜਟ ਲੌਜਿਕ ਨੂੰ prompt ਵਿੱਚੋਂ ਕੱਢ ਕੇ ਇੱਕ deterministic hook ਸਿਸਟਮ ਵਿੱਚ ਰੱਖ ਦਿੱਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਨੂੰ ਮਾਡਲ ਬਦਲ (override) ਨਹੀਂ ਸਕਦਾ।

  1. Explicit model selection – ਹੁਣ ਹਰੇਕ sub-agent dispatch ਲਈ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਾਡਲ ਦੀ ਚੋਣ (Haiku, Sonnet, ਜਾਂ Opus) ਜ਼ਰੂਰੀ ਹੈ। ਪਹਿਲਾਂ ਵਾਲੀ 'silent inheritance' ਹੁਣ ਖ਼ਤਮ ਹੋ ਗਈ ਹੈ, ਇਸ ਲਈ ਸਸਤੇ ਕੰਮ ਸਸਤੇ ਹੀ ਰਹਿੰਦੇ ਹਨ।
  2. PreToolUse hook ਰਾਹੀਂ ਸਖ਼ਤ ਸੁਰੱਖਿਆ (Hard guards) – ਕੋਈ ਵੀ ਟੂਲ ਚੱਲਣ ਤੋਂ ਪਹਿਲਾਂ, hook ਇਹ ਚੈੱਕ ਕਰਦਾ ਹੈ:
    • ਸੈਸ਼ਨ ਵਿੱਚ ਹੁਣ ਤੱਕ ਕਿੰਨੇ dispatches ਕੀਤੇ ਜਾ ਚੁੱਕੇ ਹਨ।
    • ਕੀ ਚੁਣਿਆ ਗਿਆ ਮਾਡਲ ਘੱਟੋ-ਘੱਟ ਤਹਿ (minimum tier) ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ (ਗਲਤੀ ਨਾਲ Opus ਦੀ ਵਰਤੋਂ ਨੂੰ ਰੋਕਣ ਲਈ)।
    • ਲੂਪ ਦੇ ਚੱਲਣ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਗਿਣਤੀ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਪ੍ਰਕਿਰਿਆ ਰੋਕ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਜੇਕਰ ਕੋਈ ਵੀ ਸੁਰੱਖਿਆ ਨਿਯਮ (guard) ਟੁੱਟਦਾ ਹੈ, ਤਾਂ ਕੋਡ sub