geminilisted

# Gemini Orchestrator When the user invokes `/gemini <instruction>`, Claude delegates the implementation to Gemini CLI via its headless mode (`-p/--prompt`), monitors in real time, and reports. --- ## Known Limits Hard constraints of the Gemini CLI — not config options. ### 1. No `--max-turns` flag Vibe lets you cap turn count (`--max-turns 8`). Gemini CLI has no equivalent. **Timeout is the only runaway-control lever.** A stuck run burns the full timeout before dying. Set timeouts conservatively and decompose tasks. ### 2. High context overhead (~900–10k tokens before your task starts) Gemini CLI loads a large default system prompt on every run: - Simple prompt → ~883 tokens before the model responds - File-read task → ~10k tokens of context before first tool call This means: - Each run costs more than token-naive estimates suggest - Short timeouts can expire during context-loading on a slow connection - The overhead is mostly cached on repeated calls to the same model in a session ### 3. 503 backoff eats your timeout silently On the free-tier Gemini API, the model is frequently "under high demand." The CLI auto-retries with exponential backoff — observed taking **60–90s** before work even begins. This is invisible until you see the first tool call. Always add 90s buffer to your "real work" estimate: ``` Timeout budget = expected_work_secs + 90s backoff buffer + 30s context load ``` ### 4. No `--agent` flag Gemini CLI is single-mode only. There is no way to switch