AI agents and AWS spending limits: the 90-day deletion rule

AWS's new project spending limits, part of its simplified builder experience announced September 16, cap a project's monthly pre-tax charges and pause the project's resources when usage reaches the limit, with optional forecast-based controls that block new resource creation about seven days out and pause idle resources about five days out. AWS warns that a project paused for 90 days without action is permanently deleted, and that the minimum permitted limit is the greater of $20 or a conservative estimate of likely spend based on month-to-date activity, running resources and prior-month usage. The feature, currently in limited release and requiring a paid plan, follows calls such as Simon Willison's October 3 argument for default hard budget caps on usage-priced services.

AI agents can deploy a side project while you're making dinner. The resulting services can keep charging after the agent finishes. AWS's new project spending limits give that experiment an automatic stopping point, with an important recovery condition: after a project has been paused for 90 days without action, AWS says it permanently deletes the project data. I went through the documentation because a capped invoice and a recoverable project need different checks. On October 3, Simon Willison argued for default hard budget caps https://simonwillison.net/2026/Oct/3/default-hard-budget-caps/ on usage-priced services. He described the familiar warning-email problem: the budget notification arrives while you sleep, and the service continues spending until you intervene. Coding agents reduce the friction of building useful software. That software can call paid APIs, provision resources or consume storage. A successful deploy says very little about how much the resulting application is permitted to spend. The account owner inherits that question. Willison's proposal makes unlimited spending an explicit choice. He argues that many builders would accept an error response rather than an unexpected large invoice. The opposite preference is reasonable for some production workloads, where a shutdown has costs of its own. A provider needs to make that tradeoff understandable before the first runaway loop. The dates matter here. AWS announced its simplified builder experience on September 16 https://aws.amazon.com/about-aws/whats-new/2026/09/New-AWS-Builder-Experience/ . Google announced its related controls in July. Today's story is the fresh demand for stronger defaults and the conditions of controls that already exist. An agent-friendly signup page is only the start of the product contract. AWS's spend-limit guide https://docs.aws.amazon.com/accounts/latest/reference/create-spend-limit.html describes a ceiling for a project's monthly pre-tax charges. Credits are excluded. The feature belongs to the new project experience, which is currently being released to a limited number of customers. Anyone with project access can see the limit; project owners manage it. You need a paid plan to create one. These details determine who can rely on the control today. Check the settings for the specific project you intend to use, especially if you've had the AWS account for years. The minimum permitted value is the greater of $20 or a conservative estimate of likely spend. AWS considers month-to-date activity, resources currently running and activity in the prior month. It says the estimate is more than a strict linear extrapolation. A large collection of running resources can therefore produce a high minimum. AWS advises stopping resources first if you want a lower limit. This is relevant to the sandbox that started as a small demo and acquired an expensive supporting cast. Setting a smaller number in billing may require cleaning up the actual infrastructure. AWS sends notifications at 50%, 75% and 90% of the limit, or when the forecast indicates you will reach it within the next 10 days. Those notifications help the owner act early. The enforcement action arrives when usage reaches the limit: AWS pauses the project and stops its resources. The guide explicitly positions the feature for learning, experimentation and sandbox workloads. It allows production use where a resource pause is acceptable. I'd make that availability decision with the service owner, before letting an assistant deploy into the environment. Optional controls provide earlier interventions based on forecast spending. Their approximate timings describe different actions: | Control | Forecast point | Operational consequence | |---|---|---| | Stop new resource creation | About seven days before the limit | Existing resources keep running; new launches are blocked | | Pause idle resources | About five days before the limit | Eligible idle resources are paused | | Pause top cost drivers | About four days before the limit | Selected high-cost active resources are paused | The first option can affect autoscaling. An application may keep serving from its existing instances while additional instances fail to launch. That is a change in the application's capacity behavior worth knowing about before a traffic spike. Idle detection uses service-specific criteria. For a SageMaker endpoint, the guide gives a simple one: zero invocations over the previous 14 days. EC2 and RDS have their own conditions. Read the relevant criteria rather than assuming that a resource you personally haven't touched is idle. The top-cost-driver option can affect active resources and is explicitly disruptive. AWS lists EC2, RDS, Lambda, Bedrock and SageMaker for selection in that control. Enabling it is an operational choice; a useful forecast should lead to a deliberate action. I'd document the selected controls alongside the project's owner. “We have a budget” leaves too many possibilities open. The useful record says which actions can fire, which services they affect and how someone will hear about them. The documentation's first sentence about a triggered limit is reassuring: AWS pauses your project and stops all resources. Your data is preserved. The recovery instructions say to increase the limit in AWS Settings. Some resources may need manual restarts after reactivation. Then comes the important note: If you take no action within 90 days of your project being paused, AWS permanently deletes your project data. That condition starts with the project being paused. It says nothing about deleting data immediately when you hit the cap, and it isn't a general statement about every inactive AWS account. The distinction is central to this episode's title: the spending control can lead to data deletion when that paused state is left unresolved. The guide gives one clear reactivation path. I would use that documented path rather than assume any incidental console visit counts as sufficient action. If you need a different retention or recovery arrangement, confirm it before depending on the project for important data. My practical setup would include an owner who receives the notifications, a record of what must be restarted and a backup outside the project's failure boundary. Check that someone can access that backup without relying on the paused resources. A copy inside the same environment may inherit the same problem. Also decide what happens to an abandoned prototype. Some demos deserve a tidy deletion. Others contain work you will need in six months. The spending control makes that cleanup decision time-bound, so a forgotten email can become a forgotten project. Google's July announcement https://cloud.google.com/blog/topics/cost-management/new-early-anomalies-and-spend-caps-on-google-cloud-budgets describes public-preview caps on a single service inside a single project. The supported preview list contains Gemini API, Agent Platform, Cloud Run and Cloud Run Functions. Google says AI-service caps trigger within minutes of reaching the threshold. That is the provider's stated behavior; I haven't independently measured its enforcement latency. It also says the restriction preserves data and resources and leaves services outside the budget's scope unaffected. There is a billing exception worth keeping next to that description. Fixed contractual commitments, including Committed Use Discounts and Provisioned Throughput, continue charging at their contractual rates. Restricting new on-demand usage can coexist with an invoice for commitments already purchased. The usage block remains until it is manually lifted in the budgets interface. Recovery therefore deserves attention here too. “Cloud spend cap” is a category label; AWS's project pause and Google's service-specific restriction have distinct scopes and consequences. Aleph Alpha released Kolibri on October 3 https://aleph-alpha.com/en/blog/kolibri-has-landed-a-sovereign-open-weight-model/ , with German-English open weights under Apache 2.0. The model card https://huggingface.co/Aleph-Alpha/Kolibri-1 gives about 3.46 billion active parameters per token, out of 78.1 billion total. All the weights still need memory; its published FP8 weight footprint is about 78 GB. Tejas Kumar tested its tokenizer https://tej.as/blog/aleph-alpha-kolibri on Germany's Basic Law and its English translation. Kolibri used 35,190 tokens on the German text, against 41,482 for OpenAI's o200k base, about 15% fewer. The English results were effectively tied. Kumar congratulates friends on the Aleph Alpha team and says he hasn't run model inference; his measured experiment is narrow evidence about tokenization. Meanwhile, the COSMIC compositor PR template https://github.com/pop-os/cosmic-comp/blob/master/.github/PULL REQUEST TEMPLATE.md requires contributors to certify that they included no LLM-generated content, including code, comments and descriptions. The cosmic-flatpak template https://github.com/pop-os/cosmic-flatpak/blob/master/.github/PULL REQUEST TEMPLATE.md has a specific exception for their own app source code and manifest. The relevant repository's actual checklist is the rule to read. I welcome enforced spending limits. Before giving an agent the account, I'd check availability, covered charges and recovery. The 90-day condition needs a visible warning and a named owner. My abandoned weekend prototype should retire with dignity. Does AWS delete data immediately when a spend limit fires? AWS says data is preserved when the project pauses. Its deletion condition is 90 days paused without action. Can every existing AWS account set this project limit? The guide warns of a limited rollout of the new experience. Verify access for your project; creating a limit requires a paid plan. Can I use a $20 limit on any project? The minimum is the greater of $20 or AWS's conservative usage estimate. Running resources can make the minimum higher. Will Google's cap stop all charges? Its preview targets one service within one project, and fixed contractual commitments continue billing. Services outside the cap's scope stay unaffected. This article expands on an episode of The Daily Diff , a five-minute daily video on what shipped and what broke in tech. Watch the episode https://www.youtube.com/watch?v=u-msB6sz-dI · Subscribe on YouTube https://www.youtube.com/@dailydiffdev?sub confirmation=1 · the written diff lands in your inbox every morning at thedailydiff.dev https://thedailydiff.dev .