Pimp My IDE / cost protection
Back to garage
October 3, 2026 | coding agents / cloud cost / hard stops

Alerts are not brakes.

An email can tell you that an agent crossed the budget. Only an enforced limit can stop the next paid call.

Put one stop inside the job and another at the provider. Write down what gets blocked, how quickly it acts, which charges continue, and who can restore service.

A warning is a message. A cap changes execution.

Simon Willison argues that pay-by-usage products need hard budget caps by default. His test is concrete: after the configured amount, the service stops accepting more paid work instead of sending an email while charges continue.[1]

That distinction matters more when an agent can create resources, retry a failed call, or keep working after the operator leaves. An alert depends on a person noticing it. A hard stop changes what the system can do.

Do not ask one limit to do two jobs. Stop the task locally. Stop the bill at the provider.

The provider's stop has a shape.

AWS now documents project-level spend limits for part of its new account experience. When a project reaches the limit, AWS pauses the project and stops its resources. The docs say the feature is aimed at experiments, learning, and sandbox work. They also warn that rollout is limited and that the minimum limit is the greater of $20 or AWS's conservative spend estimate.[2]

Google Cloud's public-preview Spend Caps take a narrower route. A cap applies to one service in one project for a fixed monthly period. Google says it restricts further cost-incurring usage after the threshold. Other services remain active. Fixed commitments can continue billing. For supported AI services, Google says enforcement happens within minutes, not at the exact instant the displayed total crosses the line.[3]

Both controls are useful. Neither supports the sentence "cloud spend cannot exceed this number" without qualification. Scope, billing delay, minimums, existing commitments, paused resources, and preview availability all belong in the run card.

The task needs its own fuse.

A provider cap is the last wall. Put a smaller stop in the agent job. Count the paid calls, elapsed time, retries, created resources, or estimated cost that the runtime can observe. Refuse another unit of work when the first local boundary opens.

The local fuse should fail closed when metering disappears. A missing price, unknown provider route, or unreadable usage response is not zero cost. Stop, retain the partial receipt, and require a person to choose the restart route.

Design the failure before turning the key.

Name the workload that may stop. Decide whether partial output remains readable. Keep the cleanup path outside the failed agent loop. Give one owner permission to raise or reset the limit. Record the old limit, new limit, reason, and time whenever that owner changes it.

A monthly cap is too coarse for a five-minute task. A per-task fuse is too weak for a leaked key used by another process. Use both. Test them with a small disposable workload before an unattended run depends on them.

Interactive makeover / spend circuit breaker

Wire the stop before the run.

This replaces one budget field with a task fuse, provider posture, failure controls, and a copyable run card. The values are planning inputs. This page does not read billing data or change a provider account.

Task fuse
Provider cap
Fail closed
Receipt

Breaker cabinet

Choose the provider behavior you have verified. Set separate job and monthly limits. Then select the controls the run card will require.

Provider posture
$8
$1 per run$50 per run
$25
$20 monthly$500 monthly
Run-card controls

Trip sheet

The load gauge compares the task fuse with the monthly cap. It is a planning ratio, not provider telemetry.

Review gate open2 controls missing
Task share of monthly cap32%At most 3 full-fuse runs fit below the monthly cap.
32%
This cabinet drafts a control plan. It does not verify provider availability, inspect an account, forecast a bill, stop a job, or prove that a provider denied usage. Attach settings, timestamps, a blocked-request result, and continuing-charge notes before marking a real route tested.

Sources read

Source log and evidence boundary
  1. Simon Willison, "We're going to need default hard budget caps on pretty much everything", published and read October 3, 2026. It distinguishes an enforced cutoff from a warning and points to the new AWS and Google Cloud controls.
  2. AWS Account Management, "Create a spend limit in AWS Settings", read October 3, 2026. It documents project scope, pause behavior, intended workloads, minimum values, notifications, early controls, pre-tax treatment, and limited rollout.
  3. Google Cloud, "New early anomalies and spend caps on Google Cloud Budgets", published July 28 and read October 3, 2026. It documents the public-preview project-and-service scope, manual recovery, fixed-commitment exception, supported services, and enforcement timing.
  4. Hacker News discussion 49949235, read October 3, 2026. It was used as a reader-response source, not as proof of provider behavior.

Evidence boundary. The two-stop policy, fail-closed metering rule, reset record, and circuit-breaker interface are Pimp My IDE's recommendations. No paid provider account was changed or driven into a cap for this article. Provider behavior above is limited to the cited documentation.