Cost and limits
What a bee run costs, the budgets and timeouts that bound it, and the rate limits on the API.
After reading this page you'll know roughly what a bee run costs, which limits stop a run from spending indefinitely, and how to keep your own asks cheap.
What a run costs
The infrastructure side of a run is small. A bee runs as a Fargate task (1 vCPU / 4 GB) for the duration of the run; at ~10 minutes a run, the whole fleet's compute comes to a few dollars a month. The dominant cost is model tokens: Swarm calls Claude Sonnet via AWS Bedrock, and token spend scales with how much the bee has to read, try, and retry. A tightly-scoped ask is usually cents to low single-digit dollars in tokens; an open-ended exploration of a large repo costs meaningfully more.
The full infra cost model is in docs/deployment.md §10.
Action budgets per phase
Every recipe splits its work into phases with action budgets; how Swarm thinks covers the phase shape and why it's budgeted. The swarm agent works the same way at a different grain: planning is capped at 6 turns, and each plan step gets a per-step execute budget (SWARM_AGENT_MAX_EXECUTE_TURNS, default 50).
Recipe phase budgets are soft: instructions to the model, not enforced by code. The hard backstops below are what actually stop a run.
Hard backstops
Three limits are enforced by code, not prompting:
- Turn caps.
GOOSE_MAX_TURNS(set to 100 in staging) force-stops a Goose run;BEE_SDK_MAX_TURNS(default 80) does the same for the SDK engine. These catch a run that ignores its soft budgets and won't converge. - Task timeout. The trigger runner abandons an ECS task after 60 minutes; agents are expected to finish well inside that.
- Cost caps. The orchestrator enforces two spend caps (ADRs 0051 and 0077): a per-pipeline burst cap that bounds a single runaway run, and a per-space monthly cap that bounds cumulative spend. The check is atomic (reserve-then-settle), so concurrent turns can't collectively blow past a cap. Hitting a cap doesn't kill the run: it pauses as a
budget-exceededneeds-input event, and a project lead approves continuation (for that run only) or cancels.
API rate limits
The versioned API at /api/v1 is rate-limited per caller (ADR 0091). Authenticated requests default to 120 requests/minute (RATE_LIMIT_RPM); public endpoints like the OpenAPI spec default to 30 (RATE_LIMIT_PUBLIC_RPM). Every response carries RateLimit-Limit / RateLimit-Remaining / RateLimit-Reset headers; over the limit you get a 429 with Retry-After, so back off and retry.
One caveat: the limiter is in-process per ECS task, so the effective limit is roughly the configured value times the task count. Treat it as abuse protection, not a quota. See API and CLI for how to call the API.
Keeping your runs cheap
Bounded asks cost less and succeed more. Tokens are spent on exploration, so an ask that names the repo, the file or page, and the expected outcome converges in fewer turns than "improve the app". Scoping instructions ("audit the homepage only; do not touch other pages") cut both cost and the odds of hitting a turn cap mid-run.
How to write that kind of ask is covered in writing a good ask. What a bee is allowed to touch while it spends those turns is in what bees can touch.