What happens to an ongoing Claude Code run when Bedrock access is revoked?

A proxy or gateway is usually better for enforcing a usage limit. It can count input and output tokens before each invocation and return a rate-limit error once the budget is reached. Service quotas can also limit usage by model, region, or token count, but those typically surface as throttling errors rather than cleanly ending an existing workflow.

One practical setup is to track usage per user and model with inference profiles and periodically update a metric or tag when a budget is exceeded. An organization-level deny policy can then block future invocations. That approach avoids operating a proxy, but it has some reporting and propagation delay, so it isn’t suitable when the cap must be exact to the last token.

Each Claude Code turn is a separate Bedrock invocation. A request that is already in flight will generally finish and still be billed, but once the process makes another Bedrock call, the new request should receive an access-denied or quota error. IAM changes can also take a short time to propagate, so they aren’t an exact instant cutoff.

Be careful to distinguish a denied API call from the entire run stopping. The client may treat the denial as a recoverable error, retry it, or try another route before eventually failing. If revoking access is your safety mechanism, you may also need to terminate the agent process or otherwise prevent retries.