Claude Code 2.1.212 ਹੁਣ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਕਿ ਇੱਕ AI ਸੈਸ਼ਨ ਕਿੰਨੇ sub-agents ਅਤੇ web searches ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਕਿ ਬੇਕਾਬੂ ਖਰਚਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਇੱਕ ਪੱਕਾ ਸਾਧਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਇਹ ਅਪਡੇਟ ਦੋ ਕੌਂਫਿਗਰੇਬਲ ਕੈਪਸ (caps) ਜੋੜਦਾ ਹੈ – ਇੱਕ sub-agent spawns ਲਈ ਅਤੇ ਇੱਕ web-search calls ਲਈ – ਦੋਵੇਂ ਪ੍ਰਤੀ ਸੈਸ਼ਨ 200 ਦੇ ਡਿਫੌਲਟ ਮੁੱਲ 'ਤੇ ਹਨ। ਡਿਵੈਲਪਰ environment variables ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਹਨਾਂ ਨੰਬਰਾਂ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ MCP (Model-Control-Plane) ਕਾਲ ਜੋ ਦੋ ਮਿੰਟਾਂ ਤੋਂ ਵੱਧ ਸਮਾਂ ਚੱਲਦੀ ਹੈ, ਉਸਨੂੰ ਆਪਣੇ ਆਪ ਬੈਕਗ੍ਰਾਊਂਡ ਵਿੱਚ ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਮਾੜਾ (slow) ਟੂਲ ਪੂਰੇ ਵਰਕਫਲੋ ਨੂੰ ਰੋਕਣ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।

ਇਹ ਸੀਮਾਵਾਂ ਹੁਣ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹਨ

AI agents ਜੋ ਬਿਨਾਂ ਕਿਸੇ ਰੋਕ-ਟੋਕ ਦੇ ਦੂਜੇ agents ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹਨ ਜਾਂ ਵੈੱਬ ਨੂੰ ਸਕ੍ਰੇਪ (scrape) ਕਰ ਸਕਦੇ ਹਨ, ਉਹ ਉਪਯੋਗੀ ਹੁੰਦੇ ਹਨ, ਪਰ ਉਹ ਇੱਕ ਵਿੱਤੀ ਖਤਰਾ ਵੀ ਬਣ ਸਕਦੇ ਹਨ। ਇੱਕ ਅਸਪਸ਼ਟ ਪ੍ਰੋਂਪਟ (vague prompt) sub-agents ਦੀ ਇੱਕ ਲੜੀ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਵਿੱਚੋਂ ਹਰ ਇੱਕ tokens ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਬਾਹਰੀ ਟੂਲਸ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ ਇੱਕ ਅਜਿਹਾ ਬਿੱਲ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਕਿਸੇ ਦੇ ਨੋਟਿਸ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਧ ਸਕਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ ਟੀਮਾਂ ਨੇ ਇਹ ਦੱਸਿਆ ਹੈ:

  • ਅਚਾਨਕ token ਖਰਚਾ ਜੋ ਅਸਲ ਟਾਸਕ ਬਜਟ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਹੋ ਜਾਂਦਾ ਹੈ।
  • ਡੁਪਲੀਕੇਟ sub-agents ਜੋ ਇੱਕ ਦੂਜੇ ਦੇ ਐਡਿਟਸ ਵਿੱਚ ਦਖਲ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਵਿਰੋਧੀ ਨਤੀਜੇ ਨਿਕਲਦੇ ਹਨ।
  • ਅਧੂਰੇ ਆਉਟਪੁੱਟਸ ਦੀ ਇੱਕ ਲੜੀ ਜਿਸ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।
  • ਮਾੜੇ ਬਾਹਰੀ ਟੂਲਸ ਪੂਰੇ ਸੈਸ਼ਨ ਨੂੰ ਰੋਕ ਦਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਇੱਕ ਤੇਜ਼ ਕੁਐਰੀ (query) ਮਿੰਟਾਂ ਦੇ ਇੰਤਜ਼ਾਰ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ (hard ceiling) ਲਗਾ ਕੇ, Claude Code ਸਿਸਟਮ ਨੂੰ ਖਰਚਿਆਂ ਦੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਰੋਕਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਅਜੇ ਵੀ ਇੱਕ ਅਧੂਰਾ ਜਵਾਬ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਮਨੁੱਖ ਦੁਆਰਾ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਕੈਪਸ (caps) ਕਿਵੇਂ ਸੈੱਟ ਕਰਨੀਆਂ ਹਨ

ਤਿੰਨ ਨੋਬਸ (knobs) environment variables ਵਜੋਂ ਉਪਲਬਧ ਹਨ:

export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=12   # default 200
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=30   # default 200
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=120000   # 2 minutes

ਡਿਫੌਲਟ ਮੁੱਲ ਜ਼ਿਆਦਾਤਰ ਖੋਜਕਾਰੀ ਕੰਮਾਂ ਲਈ ਕਾਫ਼ੀ ਹਨ, ਪਰ ਟੀਮਾਂ ਕਿਸੇ ਖਾਸ ਕੰਮ ਦੇ ਜੋਖਮ ਦੇ ਅਨੁਸਾਰ ਉਹਨਾਂ ਨੂੰ ਘਟਾ ਸਕਦੀਆਂ ਹਨ। ਰਿਲੀਜ਼ ਦੀ ਘੋਸ਼ਣਾ ਕਰਨ ਵਾਲੇ ਲੇਖ ਵਿੱਚ ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਨੁਕਤੇ ਦਿੱਤੇ ਗਏ ਹਨ:

  • Local bug fix: 0-2 sub-agents, 0-5 searches.
  • PR review: 3-5 sub-agents, 0-10 searches.
  • Incident investigation: 2-4 sub-agents, 10-25 searches.
  • Broad architecture research: 1 synthesizer, 2-4 researchers, 20-40 searches.

ਇਹ ਕੋਈ ਪੱਕੇ ਨਿਯਮ ਨਹੀਂ ਹਨ; ਇਹ ਸਿਰਫ਼ ਇੱਕ ਬੇਸਲਾਈਨ (baseline) ਹਨ ਜਿਸ ਤੋਂ ਡਿਵੈਲਪਰ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹਨ।

ਸਮਝੌਤਾ (The trade-off)

Agent ਦੀ ਗਤੀਵਿਧੀ 'ਤੇ ਸਖ਼ਤ ਕੈਪ ਲਗਾਉਣ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਚੰਗੀ ਟਾਸਕ ਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਕੋਈ ਸਮੱਸਿਆ ਇੱਕ ਸੈਸ਼ਨ ਲਈ ਬਹੁਤ ਵੱਡੀ ਹੈ, ਤਾਂ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਗਈ ਵਿਧੀ ਇਸਨੂੰ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਣਾ, ਹਰੇਕ ਪੜਾਅ ਲਈ ਬਜਟ ਨਿਰਧਾਰਤ ਕਰਨਾ, ਅਤੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਮਨੁੱਖੀ ਚੈੱਕਪੁਆਇੰਟ (human checkpoint) ਰੱਖਣਾ ਹੈ। ਇੱਕ ਸੀਮਤ ਸਿਸਟਮ ਨੂੰ ਅਧੂਰੇ ਸਵਾਲਾਂ ਦੇ ਨਾਲ ਇੱਕ ਲਾਭਦਾਇਕ ਅਧੂਰਾ ਨਤੀਜਾ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਵਾਰ-ਵਾਰ ਚੱਲਣ ਵਾਲੇ ਲੂਪਸ 'ਤੇ ਪੈਸਾ ਖਰਚ ਕਰਦੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।

ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਖ਼ਤ ਕੈਪ ਦਾ ਖਤਰਾ ਇਹ ਹੈ ਕਿ agent ਇੱਕ ਵਿਹਾਰਯੋਗ ਹੱਲ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੁਕ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਉੱਚੀਆਂ ਸੀਮਾਵਾਂ ਦੇ ਨਾਲ ਕੰਮ ਨੂੰ ਦੁਬਾਰਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ। ਉਹ ਵਾਧੂ ਦੁਹਰਾਓ (iteration) ਵਾਧੂ ਖਰਚਾ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਬਿਨਾਂ ਚੈੱਕ ਕੀਤੇ ਸੈਸ਼ਨ ਦੀ ਕੀਮਤ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੀ ਹੈ।

ਇਸਨੂੰ production ਵਿੱਚ ਲਿਆਉਣਾ

  1. Upgrade ਕਰੋ Claude Code 2.1.212 ਨੂੰ ਇੱਕ staging environment ਵਿੱਚ।
  2. ਇੱਕ workflow ਚੁਣੋ – ਉਦਾਹਰਣ ਵਜੋਂ, PR review – ਅਤੇ ਇੱਕ ਸਾਵਧਾਨੀ ਵਾਲਾ ਬਜਟ ਸੈੱਟ ਕਰੋ।
  3. ਆਪਣੇ logs ਨੂੰ instrument ਕਰੋ ਤਾਂ ਜੋ ਲਾਂਚ ਕੀਤੇ ਗਏ sub-agents ਦੀ ਗਿਣਤੀ, ਕੀਤੇ ਗਏ web searches, ਅਤੇ ਕਿਸੇ ਵੀ MCP ਕਾਲ ਜੋ ਦੋ ਮਿੰਟ ਦੀ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ, ਨੂੰ ਕੈਪਚਰ ਕੀਤਾ ਜਾ ਸਕੇ।
  4. ਹਰ ਉਸ run ਦੀ review ਕਰੋ ਜੋ ਕੈਪ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਇਹ ਤੈਅ ਕਰੋ ਕਿ ਕੀ ਕੈਪ ਨੇ ਪੈਸੇ ਬਚਾਏ ਜਾਂ ਅਸਲ ਤਰੱਕੀ ਨੂੰ ਰੋਕ ਦਿੱਤਾ, ਅਤੇ ਉਸ ਅਨੁਸਾਰ ਸੀਮਾਵਾਂ ਨੂੰ ਐਡਜਸਟ ਕਰੋ।

ਕਿਉਂਕਿ ਕੈਪਸ runtime 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹ logs ਵਿੱਚ ਤੁਰੰਤ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ। ਉਹ ਟੀਮਾਂ ਜੋ ਇਹਨਾਂ ਮੈਟ੍ਰਿਕਸ (metrics) ਨੂੰ ਟ੍ਰੈਕ ਕਰਦੀਆਂ ਹਨ, ਉਹ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਬਣਾ ਸਕਦੀਆਂ ਹਨ: ਬਜਟ ਨੂੰ ਉਦੋਂ ਤੱਕ ਘਟਾਓ ਜਦੋਂ ਤੱਕ agent ਕੰਮ ਪੂਰਾ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਨਹੀਂ ਹੋ ਜਾਂਦਾ, ਫਿਰ ਇਸਨੂੰ ਕੇਵਲ ਮੁੱਖ ਟਾਸਕ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਉਨਾ ਹੀ ਵਧਾਓ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

ਰੋਲਆਊਟ (rollout) ਅਜੇ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਵਿੱਚ ਹੈ, ਇਸ ਲਈ ਲਾ