Architecture: Why does Vitto chat hit 'Max iterations (25) reached' before...

Documentation for Sessions

🏗️ Architecture: Why does Vitto chat hit 'Max iterations (25) reached' before...

Date: 2026-03-08
Time: 15:39:12 UTC
Session: gspace1-190.3
Agent: angular
Confidence: 95%
Status: ✅ Documented


📋 Decision Context

Question:

Why does Vitto chat hit 'Max iterations (25) reached' before module generation completes?

Task: S190: Fix max iterations reached during module generation via Vitto chat


🎯 Decision Made

Chosen:

Made start_module_generation tool BLOCKING (awaits completion via waitForCompletion polling internally, 10min timeout) and increased maxIterations from 25 to 40 for web chat when module gen tools present. Eliminates LLM polling loop entirely — 1 iteration instead of 15+.

Options Considered:

  1. Make tool blocking (chosen)
  2. Just raise maxIterations to 50 (band-aid)
  3. Use CostGuardService task-type-aware limits (future improvement)
  4. SSE-based completion callback (complex, not needed with blocking)

💭 Reasoning

Root cause: start_module_generation was fire-and-forget (returned sessionId immediately). LLM then polled check_module_generation every ~30s. Each poll = 1 iteration. 6-phase pipeline takes 3-8min = 10-16 polls + reasoning turns = exceeded 25 hard cap. Three options evaluated: (A) Blocking tool — most robust, 1 iteration, but ties up agent loop thread; (B) Raise maxIterations — quick but doesn't solve inefficiency; (C) Task-type-aware limits from CostGuardService — best long-term. Chose A+B combination: blocking eliminates polling waste, raised limit provides safety margin. CostGuardService already has 40-iteration limit for module-generation task type but web chat hardcoded 25.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation