[FEATURE] Request: Require user confirmation before spawning expensive agents

Status Open
Maintainer reply None cached
Activity 8 comments · opened Sep 18, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

Problem
There is currently no gate between a model deciding to spawn agents and actually doing it. The model picks the agent count, the agent model, and fires — no confirmation, no budget estimate, no limit.
This has real cost consequences:
• My case: Fable 5.1 in a Claude Code Remote session created a send_later loop checking a draft PR every hour for 3.5 days — 84 wake-ups, 6 tool calls each, zero useful output. The weekly Fable limit was burned to 100%. The user did not request monitoring. The PR had no CI and no reviewers — every cycle was guaranteed empty.
• Reddit report: A user asked Fable to do research. Fable spawned 75 Fable-tier agents in under a minute. The account was locked.
In both cases the user did not ask for this behavior and had no opportunity to stop it before the damage was done.

Proposed Solution

Proposed solution
Before any agent spawn that uses a premium-tier model (Fable, Opus), require an explicit confirmation step showing:

  1. How many agents will be created
  2. Which model each agent will run on (and its relative cost tier)
  3. Estimated budget impact — approximate % of the user's weekly plan limit this will consume

The user confirms or cancels before anything runs. This is the same pattern as in-app purchase confirmation — you don't charge without asking.
For send_later loops specifically: a visible cap on total iterations (or total cost) before the chain self-terminates, even if no one is watching.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Performance and speed

Use Case Example

  1. User opens a Claude Code Remote session and asks a simple setup question about Apple Watch data collection.
  2. Claude (Fable 5.1) answers the question, then autonomously decides to "monitor" a draft PR the user never asked it to watch.
  3. Fable creates a send_later wake-up for 1 hour later. That wake-up fires, runs 6 tool calls (check PR status, check CI, check reviewers — all empty), finds nothing, and schedules another send_later for 1 hour later.
  4. This chain runs every hour for 3.5 days — approximately 84 cycles, ~500 tool calls total. The user is asleep or away and has no idea.
  5. The PR has no CI pipeline and no reviewers. Every single cycle is guaranteed to find nothing. The model never stops.
  6. By the time the user notices, their entire weekly Fable limit is at 100%. Had usage credits been enabled, this would have been real charges at Fable's $10/$50 per MTok rate — with no confirmation and no receipt.
  7. The user has to manually switch the session to a cheaper model (Opus) to break the loop, because there is no kill switch, no iteration cap, and no budget gate.

With the proposed feature: At step 3, the user would see: "I'd like to monitor this PR hourly. This will use Fable 5.1 (~X% of your weekly limit per cycle). Approve?" The user says no. Done.

Additional Context

Why this matters now
Fable at $10/$50 per MTok is 2x–5x other models. An uncontrolled agent swarm or monitoring loop on Fable burns weekly limits (or real money via usage credits) at a rate that makes the subscription model untenable. Users who have usage credits enabled would face actual billing with no confirmation step — that is not a bug, that is a liability.

View original on GitHub ↗

3 Comments

burneramina-stack · 26 days ago

Second example (reported by another user):

  1. User asks Fable 5.1 to research a topic.
  2. Fable decides the research requires parallel agents and spawns 75 Fable-tier agents in under one minute — no confirmation, no count shown, no cost estimate.
  3. The user's account is immediately locked due to extreme usage spike.
  4. The user never requested parallel agents, never saw a number, and had no opportunity to cancel.

With the proposed feature: At step 2, the user would see: "I'd like to spawn 75 research agents on Fable 5.1. Estimated cost: ~Y% of your weekly limit. Approve?" No sane user approves 75 Fable agents for a single research question. Problem solved before it starts.

burneramina-stack · 26 days ago
  1. Model cap per thread: "Agents run on Opus only; Fable is coordinator-only" — so a research task doesn't silently spin up 10 Fable threads at $50/MTok output
  2. Tool-call limit per thread: e.g. 30 tool calls max, then stop and report — prevents any single thread from running forever
  3. Thread cap: "No more than 3 parallel threads" — limits fan-out before it starts
  4. Schedule window: "Work between 02:00–05:00 only" — for overnight or background projects that shouldn't run 24/7

Think of it as a project budget: the coordinator works freely inside these constraints, and asks for approval only when it needs to exceed them. Without this, the new Projects feature scales the same uncontrolled behavior that already burns limits — it just adds a nicer UI on top.

chenhz01 · 26 days ago

Your Fable loop is a textbook silent failure: 84 wake-ups, zero useful output, and nothing ever marked the loop as failed — so nothing stopped it. I hit the same bug class with scheduled automations and fixed it with a three-state result contract: SUCCESS carries artifacts, EXPLICIT_FAILURE carries a reason, and SILENT_TIMEOUT counts as failure. Under that rule, empty-output cycles become visible failures and can trip a kill switch, which complements exactly the confirmation gate you're proposing. A pre-spawn confirmation plus terminal-state detection would have caught this at wake-up two instead of day three. Curious: in your design, who computes the budget estimate — the agent self-reporting intended work, or the harness metering actual tool calls?

Showing cached comments. Read the full discussion on GitHub ↗