Summary

The current Kanban defaults can unexpectedly launch many paid model-backed worker agents across every local board as soon as the gateway is running.

This is not only a single task retry bug. The unsafe default shape is the combination of:

• kanban.dispatch_in_gateway defaults to true
• the gateway-embedded dispatcher sweeps every non-archived board every tick
• kanban.auto_decompose defaults to true
• no safe default max_spawn / max_in_progress cap is applied on personal installs
• workers are full hermes -p <profile> ... chat -q ... model sessions, often inheriting the user's paid default provider/model

For users on ChatGPT/Codex, Claude, Grok, or other quota-backed providers, a board state change can silently become a multi-agent paid workload.

Impact

High quota / billing risk and poor operator predictability.

On a personal macOS install, the gateway-embedded dispatcher spawned workers across multiple local boards for roughly an hour. The WebUI itself had no active user run, but background Kanban workers were consuming OpenAI Codex / ChatGPT quota.

Observed patterns in local logs included per-tick batches like:

kanban dispatcher [board-a]: spawned=8 ...
kanban dispatcher [board-b]: spawned=7 ...
kanban dispatcher [board-b]: spawned=10 ...
kanban dispatcher [board-b]: spawned=12 ...
kanban dispatcher [board-c]: spawned=3 ...
kanban dispatcher [board-d]: spawned=2 ...

Worker logs showed these were real paid model calls, not lightweight queue bookkeeping:

Provider: openai-codex  Model: gpt-5.5
Endpoint: https://chatgpt.com/backend-api/codex
...
Primary model failed — switching to fallback: gpt-5.4 via openai-codex

Some workers retried, compressed long contexts many times, or fell back to another paid model before exiting. That made quota drain much faster than the number of visible cards suggested.

Environment

• Hermes Agent: current main at the time of report, plus v0.14-era Kanban behavior
• Host: macOS personal install
• Gateway: embedded dispatcher enabled through normal config
• Config before mitigation:

kanban:
  dispatch_in_gateway: true
  dispatch_interval_seconds: 60
  failure_limit: 2

No max_spawn, no max_in_progress, no auto_decompose: false.

Actual behavior

Starting the gateway is enough to start the embedded dispatcher. It sweeps all local boards, auto-decomposes triage work by default, promotes eligible work, and spawns assigned workers without a safe default per-host cap.

This means a user can think they are only running the gateway/WebUI, while Hermes is actually running many background model-backed worker sessions.

Expected behavior

The default behavior should fail safe for personal installs and paid/quota-backed providers.

At minimum, one of these should be true by default:

• embedded Kanban dispatch is opt-in, not on by default; or
• the default embedded dispatcher is capped to a very small concurrency, e.g. one worker total; or
• auto-decompose is manual by default; or
• the dashboard/gateway requires an explicit operator acknowledgement before launching paid workers; or
• there is a global budget/quota/rate guard before spawning worker swarms.

A user should not need to discover this only after seeing provider quota drop.

Related issues

This broader default-safety issue overlaps with, but is not identical to:

• #29014 — blocked/manual-gate tasks repeatedly respawn and drain provider quota
• #29027 — review-required: blocks are retried and duplicate work
• #28805 — config surface for dispatcher concurrency caps
• #28706 — CPU spikes from uncoordinated Kanban worker parallelism
• #28992 — proposal to use oneshot mode for workers instead of long chat -q

Those are concrete failure modes. This issue is about the higher-level product/runtime default: the gateway should not silently turn local board state into uncapped paid background model work.

Local mitigation used

Disabled embedded dispatch and added conservative caps for future re-enable:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 60
  failure_limit: 2
  max_spawn: 1
  max_in_progress: 1
  auto_decompose: false

After this, the gateway can be restarted without immediately resuming the worker swarm.

Suggested fixes

1. Change first-run / default config to kanban.dispatch_in_gateway: false, or gate it behind explicit dashboard/CLI enablement.
2. If embedded dispatch remains default-on, apply a safe global default cap such as kanban.max_in_progress: 1.
3. Make kanban.auto_decompose manual by default, or require a board-level opt-in.
4. Add a visible dashboard warning when auto-dispatch or auto-decompose is enabled and the active provider is quota-backed.
5. Add a global per-host spawn/budget guard so one gateway cannot fan out across all boards without operator intent.
6. Surface an emergency pause switch in the dashboard and CLI that parks dispatch without stopping the whole gateway.

Why this matters

Kanban is useful, but it changes Hermes from an interactive agent into an autonomous worker fleet. That needs a stronger default safety model than ordinary chat or cron. The current defaults make the fleet behavior too easy to activate accidentally and too hard to notice until quota or host resources are already being consumed.