Background multi-agent runs can stall the CLI and cascade into provider timeouts / event-loop errors

Title: Background multi-agent runs can stall the CLI and cascade into provider timeouts / event-loop errors

What version of Kimi Code CLI is running?

Source checkout on main at commit a8f09bce1570fc76092dfba018bedc2429cba2af
pyproject.toml version: 1.30.0

Which open platform/subscription were you using?

Please fill in the actual /login or /setup target used in your session.

Which model were you using?

Please fill in the model shown in the status bar during reproduction.

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

When many agents are launched in a short period, the CLI becomes noticeably sluggish. After that, repeated provider failures begin to appear, such as:

• LLM provider error: Connection error.
• LLM provider error: Request timed out.

Background task failures then appear in bursts, for example:

• Background task failed: 创建SF-001群聊模式详解文档
• Background task failed: 创建ER-002重试策略配置指南
• Background task failed: 创建NI-001 Rust助手引擎配置指南
• Background task failed: 创建HF-004角色分割系统配置
• Background task failed: 创建SF-003 Canvas协同编辑文档
• Background task failed: 创建TP-002高级指令完全指南

In some runs, the TUI eventually ends with:

Unhandled exception in event loop:
Exception None
Press ENTER to continue...

Reducing concurrency to 4 makes the CLI noticeably more stable, but bursty multi-agent runs can still feel laggy before terminal failures happen.

What steps can reproduce the bug?

1. Start an interactive Kimi CLI session on Windows.
2. Launch multiple independent background agents in a short time window.
3. Let them stream output concurrently while some of them hit provider retries or timeouts.
4. Observe the shell becoming sluggish, followed by Connection error / Request timed out.
5. In some cases, the prompt_toolkit UI ends with Unhandled exception in event loop.

A practical repro pattern is bulk documentation or batch task generation where many agent jobs are started or restarted in bursts.

What is the expected behavior?

• Background agents should remain responsive under bursty multi-agent workloads.
• Provider timeouts should not cascade simply because multiple agents are producing output concurrently.
• The shell/TUI event loop should not crash with Unhandled exception in event loop.
• Lowering concurrency may improve throughput stability, but the CLI should not become visibly sluggish even before the hard task limit is reached.

Additional information

This does not look like a missing concurrency limit.

From code inspection:

• src/kimi_cli/config.py sets max_running_tasks = 4 by default.
• src/kimi_cli/background/manager.py enforces that limit before creating background agent tasks.
• src/kimi_cli/background/agent_runner.py writes background-agent wire output continuously.
• src/kimi_cli/subagents/output.py currently appends transcript output synchronously per message and tee-writes to task output logs.
• src/kimi_cli/notifications/notifier.py polls every second, and shell mode wires that poller to background_tasks.reconcile().

A plausible explanation is:

1. bursty background-agent output increases synchronous local I/O and task reconciliation pressure;
2. the event loop becomes sluggish;
3. provider/network timeouts become more likely;
4. the shell eventually destabilizes and may surface a prompt_toolkit event-loop error.

This is a code-level hypothesis, not a confirmed fix.

Start with src/kimi_cli/background/agent_runner.py and src/kimi_cli/subagents/output.py, then trace reconciliation from src/kimi_cli/notifications/notifier.py and src/kimi_cli/background/manager.py. Reproduce the bursty background-agent workload on Windows with concurrency set to 4 and observe local I/O, task reconciliation, provider failures, and TUI behavior. Done means bursty runs remain responsive without cascading timeouts or an unhandled event-loop error.