gemini-cli - 💡(How to fix) Fix Headless mode (-p): 429 retry output is excessively noisy and indistinguishable from permanent failures

What happened?

When running gemini --yolo -p "prompt" in a headless/automated context (orchestrated by a supervisor process), 429 responses generate verbose error output on every retry attempt. The CLI correctly retries with backoff, but each retry dumps error text to stdout/stderr that is:

1. Repetitive — the same error message appears for every retry attempt
2. Indistinguishable from permanent failures — a supervisor process reading the output cannot tell if this is a transient 429 (will resolve) or a permanent error (should abort)
3. Pollutes log output — in automated agent pipelines where stdout is captured and parsed, the retry noise buries the actual useful output

What did you expect to happen?

In non-interactive (-p) mode, transient 429 retries should either:

1. Be silent — only emit output if the retry ultimately fails permanently (all attempts exhausted)
2. Use a structured format — e.g., with --output-format json or stream-json, emit a typed event like {"type": "retry", "status": 429, "attempt": 3, "next_retry_in": 30} so supervisors can programmatically distinguish retries from failures
3. Be controllable via a flag — e.g., --quiet-retries or a log-level flag that suppresses transient errors

Context: Why this matters for agent orchestration

Many users run gemini-cli as a subprocess in automated pipelines (agent harnesses, cron jobs, CI). The supervisor reads stdout to determine what the agent did. When 429 retries flood the output, the supervisor either:

• Incorrectly interprets the session as failed
• Has to implement fragile regex filtering to strip retry noise
• Loses actual error messages in the noise

Related issues: #27187 (runaway retry loop), #24937 (429 capacity tracking), #24290 (empty responses in non-interactive mode)

Suggested solutions (any would help)

• Minimal: In -p mode, print a single line on first 429 ("Rate limited, retrying...") and suppress subsequent retries. Print final outcome only.
• Better: Add --log-level flag (error/warn/info/debug). Default to warn in -p mode.
• Best: With -o json or -o stream-json, emit structured retry events that supervisors can parse programmatically.

Client information

CLI Version: 0.42.0
Mode: non-interactive (-p / --prompt)
Auth: OAuth (Google One AI Pro)
OS: Ubuntu 24.04 (headless server)

Reproduction

# Run during peak hours when 429s are likely:
gemini --yolo -p "Hello" 2>&1 | grep -c "429\|retry\|error"
# Output: dozens of lines for what should be a single transient retry