The API's rate limits and quotas as a product surface — whether they protect the system while staying fair, predictable, and workable for real consumers.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge the API's rate limits and quotas from the consumer's side — whether they protect the platform without punishing well-behaved developers, and whether a client can see and adapt to them instead of hitting a wall.
Read-only pass. Read the limiting logic, its responses, and its documentation; change nothing but the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
the endpoints and actions with no limit that should have one
per-key or per-tenant limits versus one global bucket; noisy neighbors
standard headers (limit, remaining, reset) so clients can self-regulate
clear 429s with Retry-After; no silent throttling or opaque failure
absorbing legitimate bursts without punishing them; token bucket vs fixed window
limits matched to plan tiers; documented quotas; defined overage behavior
limits published and discoverable, not learned by hitting them
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Retry-After behavior to make limits self-regulatingEvery Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Find where limits and quotas are enforced and where they are absent.
Limits exist — the endpoints and actions with no limit that should have one.
Rank by impact on legitimate consumers and on system safety.
Create QUOTAS.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:rate-limit-quota.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-rate-limit-quota:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=114 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/114.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Rate-Limit & Quota Design You are working inside this repo. Mission: judge the API's rate limits and quotas from the consumer's side — whether they protect the platform without punishing well-behaved developers, and whether a client can see and adapt to them instead of hitting a wall. Read-only pass. Read the limiting logic, its responses, and its documentation; change nothing but the report file. ## Phase 1 — Map the limits - Find where limits and quotas are enforced and where they are absent. - Note how a client learns its limit and its remaining budget. - See what happens when a limit is hit: the status, the message, the guidance. ## Phase 2 — Audit through 7 lenses 1. **Limits exist** — the endpoints and actions with no limit that should have one 2. **Fairness & granularity** — per-key or per-tenant limits versus one global bucket; noisy neighbors 3. **Communicated limits** — standard headers (limit, remaining, reset) so clients can self-regulate 4. **Predictable behavior** — clear 429s with `Retry-After`; no silent throttling or opaque failure 5. **Burst vs sustained** — absorbing legitimate bursts without punishing them; token bucket vs fixed window 6. **Tiering & quotas** — limits matched to plan tiers; documented quotas; defined overage behavior 7. **Documentation** — limits published and discoverable, not learned by hitting them ## Phase 3 — Curate - Rank by impact on legitimate consumers and on system safety; an unlimited expensive endpoint is both a fairness and a reliability gap. - For each, name the fix — a header, a `Retry-After`, per-key buckets, a documented quota. - Separate "protect the system" from "be fair and clear"; good limits do both. ## Phase 4 — Report Create `QUOTAS.md` at repo root: 1. **Limit posture** — per surface: limited? fair? communicated? 2. **Findings** — each: lens · surface · the gap · the fix 3. **Consumer experience** — the headers and `Retry-After` behavior to make limits self-regulating 4. **Tiering** — the quota-per-tier and overage design to adopt Start the report with today's date. If `QUOTAS.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - A limit the client cannot see is a trap; publish it in headers - Rate limiting is a product feature, not just a defense - No rate-limited API surface in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which limit changes to make first
reports/ directory exists at the repo root, write the report there instead of the root.The webhooks this product sends and receives — delivery guarantees, retries, signing, and whether a consumer can actually build on them reliably.
The client libraries developers use to call this product — how fast they reach a first successful call, and how the SDK behaves when things go wrong.
How the API evolves without breaking the people who built on it — the versioning scheme, breaking-change discipline, and how deprecations are announced and retired.
The first hour a developer spends with this API — from landing on the docs to a working integration — and where they stall, guess, or give up.
Runs inside these playbooks — curated sequences you can launch with one paste: