Exempt paid organizations from the execution rate-limit backstop - #1695
Merged
Conversation
Contributor
Cloudflare previewTorn down — the PR is closed. |
@executor-js/codemode-core
@executor-js/runtime-quickjs
@executor-js/plugin-file-secrets
@executor-js/plugin-graphql
@executor-js/plugin-keychain
@executor-js/plugin-mcp
@executor-js/plugin-onepassword
@executor-js/plugin-openapi
@executor-js/cli
@executor-js/config
@executor-js/execution
@executor-js/sdk
executor
commit: |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-cloud | bae4a7b | Aug 20 2026, 03:25 PM |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-marketing | bae4a7b | Commit Preview URL Branch Preview URL |
Aug 20 2026, 03:25 PM |
The per-org hourly cap was sized for free-tier abuse but applied to every org regardless of plan, so a paying customer running a heavy workload was blocked mid-run. Paid orgs now skip the cap. The exemption is resolved only once the counter reports an org over the limit, so the common path is unchanged, and the result is cached per org. An unresolved exemption does not fail open: that would disable the backstop during exactly the billing outage it exists to cover, so a stale positive is reused when available and the cap otherwise applies. Blocks are logged, which nothing did before.
RhysSullivan
force-pushed
the
rhys/paid-plan-rate-limit-exemption
branch
from
August 20, 2026 15:22
47f3c8a to
bae4a7b
Compare
RhysSullivan
marked this pull request as ready for review
August 20, 2026 15:28
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The per-org hourly execution cap is an abuse backstop sized for the free tier, but it applied to every organization regardless of plan. A paid org running a heavy workload crossed it and was blocked mid-run — the client saw
Rate limit exceeded: too many executions this hour, and the agent stopped using the product and switched to a direct integration instead.What changed
hasPaidOrganizationSubscriptionfromextensions/billing/plans.ts— the samePAID_AUTUMN_PLAN_IDSconfig the org-creation and seat gates already read, so it means one thing across the app.isExemptpredicate, and the Autumn coupling lives inexecution-stack-metered.ts, which already owns that dependency.Fail-open behaviour
The counter still fails open: an unreachable or slow counter DO allows the execution, unchanged.
An unresolved exemption deliberately does not. The balance gate already fails open when Autumn is unreachable, so if the exemption did too, a billing outage would switch the backstop off entirely — which is the exact "billing outage plus runaway automation" case it exists to cover. A stale positive is reused when one is cached, so a blip cannot flip a known-paid org into a block mid-workload; otherwise the cap applies.
Verification
apps/cloud/src/engine/execution-rate-limit.node.test.ts— 9 new unit tests: no lookup under the cap, blocked when not exempt, allowed when exempt, cached, re-resolved after TTL, fail-closed with nothing cached, stale positive honoured on later failure, counter failure still fails open.cloud/mcp-execution-limits.test.ts: a paid org runs past the cap and every execution is still metered. It uses a newautumn.attachPlansurface helper and Enterprise, which the emulator activates inline (no price, no card-required trial) and whose unlimited executions isolate the backstop as the only guard under test.lint,typecheck,formatclean.mcp-execution-limitspassed on a cold run (5/5, including the new scenario).Note on e2e reruns: this suite only passes on the first local run; every rerun fails all scenarios at MCP connect with
InvalidGrantError: The code is invalid or has been used. Confirmed environmental — unmodifiedmainfails identically in the same shell. Worth a look separately; it is not introduced here.