DEV Community: Stack & Ship

Cursor usage limits: the weekly pool, legacy plans and when they reset

Stack & Ship — Mon, 02 Nov 2026 13:55:35 +0000

You were working in Cursor and got a notification that you've hit your usage limit. The answer to "when does it reset?" now depends on which kind of Cursor plan you have. Cursor's current docs describe two: plans on The X Subscription, which share one weekly pool, and legacy Cursor plans (Pro, Pro+, Ultra and the rest), which keep two monthly pools. This post, first published on our site, sets out what each kind includes, where to check your usage, when it resets, what happens when you run out, and the few things you control.

Checked 17 Oct 2026 against Cursor's own help, docs and pricing pages (listed in Sources). Plan details change, so check those pages before you rely on a number here.

What we did and didn't test. We don't have a Cursor subscription, so every plan detail below is quoted from Cursor's docs, not tested. We haven't hit a limit, watched a reset or seen a bill. The only things we ran ourselves are local: rule file sizes, a token count with an OpenAI tokenizer used as a rough proxy (labelled where it appears), and a small rule-audit script with 14 unit tests, all run with TZ=UTC. We aren't affiliated with or endorsed by Cursor or Anysphere, Inc. Cursor is a trademark of Anysphere, Inc.; other product and model names are trademarks of their owners, used here only to identify them.

Quick answer

The X Subscription (Free, Plus, Premium, Super, Ultra): one weekly pool. Cursor's usage page says "your included pool refreshes weekly", and the next reset date is under Usage in your grok.com dashboard.
Legacy Cursor plans (Hobby, Start (India only), Pro, Pro+, Ultra, Teams Standard and Premium): two monthly pools. "Legacy Cursor plans: usage resets monthly with your billing cycle." The reset date is on the Spending tab.
Either way: "Unused included usage does not roll over on either kind of plan."
When you run out: on The X Subscription, wait for the reset, use prepaid credit or upgrade. On a legacy plan, turn on on-demand usage or upgrade.

Two kinds of Cursor plan

Cursor's pricing help page puts it this way: "New customers choose a plan on The X Subscription. If you subscribed to Cursor before it launched, you're on a legacy Cursor plan, and it keeps working as it is."

This comparison is summarised from Cursor's legacy plans page:

	Legacy Cursor plans	The X Subscription
Included usage	Two pools that refill monthly, one for Cursor's own models and one for other models	A single pool that refills weekly, for Cursor's models, shared with Grok
Usage reset	Each month, on your billing cycle	Each week
Third-party models	Covered by the other-models pool on Pro, Pro+, Ultra and Teams	Not covered by the pool; on Premium and above they're charged at API rates from prepaid credit
Extra usage	On-demand usage, billed at the end of each month	Prepaid credit top-ups, which can be set to top up automatically
Spend controls	A limit on on-demand spend	A monthly cap on additional usage

The weekly pool is shared beyond the editor. The usage page says it is "shared across Cursor, Grok Bot, and the Grok apps", so usage elsewhere on the same subscription draws from the same allowance.

Switching is optional. The pricing help page says: "Switching is optional. Your legacy plan, price, and features continue unless you change or cancel." If you do switch, the legacy plans page says "Your usage moves from two monthly pools to one weekly pool for Cursor models, shared with Grok." It also says "Third-party models stop being included." Cursor calls the switch "optional and permanent", so read both pages before you move.

Which plan am I on, and where do I check usage?

If you pay for Pro ($20/mo), Pro+ ($60/mo) or the older Ultra ($200/mo) and haven't switched, you're on a legacy plan. These are the legacy prices listed on Cursor's pricing help page. New Ultra on The X Subscription is also $200/mo, so go by where you manage billing, not the plan name. Billing for legacy plans lives at cursor.com/dashboard/billing; billing for The X Subscription lives at grok.com/dashboard/billing.

Where to check usage, from Cursor's usage page:

The X Subscription: "open Usage at grok.com/dashboard. It shows how much of your weekly pool you've used, the next reset date, and your prepaid credit. Your editor settings show the same remaining usage."
Legacy Cursor plans: "go to the Spending tab in your dashboard. It shows real-time usage for both pools, remaining allowance, and any on-demand charges."

Hit your usage limit? When it resets

Cursor's usage page says that when you hit your limit, "You'll see a notification in the editor." When it comes back depends on the plan:

The X Subscription: "your included pool refreshes weekly. The next reset date is shown under Usage at grok.com/dashboard." Prepaid credit is separate: "Prepaid credit doesn't reset with your weekly pool; each top-up stays available until used or until it expires (currently 365 days after purchase)."
Legacy Cursor plans: "usage resets monthly with your billing cycle. The reset date is shown on the Spending tab." On teams, "all members' usage resets at the same time based on the team billing cycle."

Cursor's pricing page describes the weekly design like this: "Your allowance refreshes weekly, so one heavy day never wipes out your whole month." The flip side, which the docs don't spell out but which follows from the reset rules, is that a weekly pool can run out mid-week and a monthly pool can run out mid-month. Neither carries unused usage forward.

What happens when you run out

On The X Subscription, the usage page lists three options: "keep working from your prepaid credit, wait for your weekly pool to reset, or upgrade to a higher plan." Top-ups are paid up front. The usage-based charges page says "You're charged when you buy credit or when an automatic top-up runs, not in arrears", and Auto Top-up is "off until you turn it on."

To cap paid extra usage, set a monthly additional usage limit at grok.com/dashboard/billing. The spend limits page says it "counts paid additional usage you consume, not the prepaid credit you buy", and "When you reach the limit, additional usage pauses until the next month or until you raise it, even if credit remains."

On a legacy plan, the usage page says: "enable on-demand usage (pay-as-you-go) or upgrade to a higher plan." On-demand usage is opt-in for individuals: "Individual plans (Pro, Pro+, Ultra): On-demand usage must be explicitly enabled in your settings." It's "billed monthly in arrears at the same per-model rates as included usage, with no change in quality or speed." On the legacy Hobby (free) and Start (India only) plans, on-demand usage is "Not available. AI features pause until the pool resets."

Two points about spend limits:

They are not instant. "Enforcement is not instant, so usage can briefly exceed your spend limit."
On legacy plans, raising the limit mid-cycle can cost you. "Raising a limit mid-cycle can make previously credited overage billable." The overages page explains that a small overage before enforcement is held as "a temporary spend-limit credit", and "If you raise the limit in the same cycle, we may bill some or all of that credit, up to the new limit."

What draws from which pool

The usage page says "On either kind of plan, your model selection affects how quickly your included usage is consumed." The models page adds: "Different models draw from the pool at different rates."

Third-party models (Claude, GPT, Gemini and others). On The X Subscription they're outside the pool; the models page says they're available "at the model's API list price from the first request, paid from your prepaid credit." Cursor's pricing page also says: "Third Party model usage in Cursor is not included in the monthly prices shown and must be purchased separately." On legacy plans they draw from the Other Models pool, "drawn down at each model's API price."
Auto. On individual plans, Auto runs in Cost mode, and "Cost mode (classic Auto) bills as a Cursor-model request and draws from your included pool whatever model serves it."
Subagents. These can surprise you: "Subagents can also run a named third-party model while the picker still shows Auto, Grok, or Composer. Those requests bill as third-party usage at that model's list price."
Max Mode. "Current plans don't include Max Mode. On legacy request-based plans, Max Mode is billed at the model's API rate plus 20%."
Your own API key. On individual plans, "Your provider bills you directly for the model cost, and those requests don't draw from your included usage or prepaid credit."

If you're also paying for these models directly, in an app you build, our AI API cost calculator estimates a monthly API bill for that app. It doesn't model Cursor's pools.

What you control: model choice, spend caps and always-applied rules

Cursor doesn't publish a per-request usage figure we could test, so this section sticks to what the docs say and what we measured locally.

Model choice. This is the lever Cursor names. On The X Subscription, the usage-based charges page suggests: "Use Cursor models: Grok and Composer draw from your included pool instead of prepaid credit."
Spend caps. Leave Auto Top-up off or set a monthly additional usage limit (The X Subscription), or keep on-demand off or set a spend limit (legacy). Both are covered above.
Rules that load in every chat. Cursor's rules docs say "When applied, rule contents are included at the start of the model context", and "If alwaysApply is true, the rule will be applied to every chat session." Rules with alwaysApply: false load only when a matching file is in context, when the Agent decides the description is relevant, or when you @-mention them. Cursor's own guidance is "Keep rules under 500 lines".

We don't know how much of your pool a given rule uses, and we haven't measured any usage saving from trimming rules. What we can say is that an always-applied rule puts its whole text into the context of every chat, so it's worth knowing which of your rules are always-applied and how long they are. This script lists them.

A rule-audit script

Save it as audit-rules.ts and run it from your project root:

npx tsx audit-rules.ts .cursor/rules

It reads each .mdc file (including subfolders, and skipping plain .md files, which Cursor's docs say the rules system ignores), sorts it into one of the four behaviours from Cursor's frontmatter table, and totals the always-applied rules.

// audit-rules.ts: list which Cursor rules load in every chat.
// Usage: npx tsx audit-rules.ts .cursor/rules
import { readFileSync, readdirSync, statSync } from "node:fs";
import { join, relative } from "node:path";

export type Kind = "always" | "file-match" | "agent-decides" | "manual";
export interface Rule {
  file: string; kind: Kind; lines: number; chars: number; warnings: string[];
}

// Line-based frontmatter read. Globs like **/*.sql are not valid YAML
// scalars (a leading * is an alias), so we don't use a YAML parser.
export function parseRule(file: string, text: string): Rule {
  const warnings: string[] = [];
  const m = text.match(/^---\r?\n([\s\S]*?)\r?\n---\r?\n?/);
  const fm: Record<string, string> = {};
  if (!m) warnings.push("no frontmatter: treated as manual");
  for (const line of (m ? m[1] : "").split(/\r?\n/)) {
    const i = line.indexOf(":");
    if (i > 0) fm[line.slice(0, i).trim()] = line.slice(i + 1).trim();
  }
  const always = fm.alwaysApply === "true";
  const globs = (fm.globs ?? "").replace(/^["']|["']$/g, "");
  const desc = (fm.description ?? "").replace(/^["']|["']$/g, "");
  if (fm.alwaysApply && !["true", "false"].includes(fm.alwaysApply))
    warnings.push(`alwaysApply is "${fm.alwaysApply}", not true/false`);
  if (always && globs) warnings.push("alwaysApply: true ignores globs");
  const kind: Kind = always ? "always" : globs ? "file-match"
    : desc ? "agent-decides" : "manual";
  const body = m ? text.slice(m[0].length) : text;
  const lines = text.split(/\r?\n/).filter((l, i, a) =>
    !(i === a.length - 1 && l === "")).length;
  if (lines > 500) warnings.push("over 500 lines");
  return { file, kind, lines, chars: body.length, warnings };
}

export function listRules(dir: string): string[] {
  return readdirSync(dir).flatMap((name) => {
    const p = join(dir, name);
    if (statSync(p).isDirectory()) return listRules(p);
    return name.endsWith(".mdc") ? [p] : [];
  }).sort();
}

export function audit(dir: string): Rule[] {
  return listRules(dir).map((p) =>
    parseRule(relative(dir, p), readFileSync(p, "utf8")));
}

if (process.argv[1]?.endsWith("audit-rules.ts")) {
  const rules = audit(process.argv[2] ?? ".cursor/rules");
  for (const r of rules)
    console.log([r.kind.padEnd(13), String(r.lines).padStart(4),
      String(r.chars).padStart(6), r.file, ...r.warnings].join("  "));
  const on = rules.filter((r) => r.kind === "always");
  console.log(`every chat: ${on.length} rule(s), ` +
    `${on.reduce((n, r) => n + r.lines, 0)} lines, ` +
    `${on.reduce((n, r) => n + r.chars, 0)} chars`);
}

How it decides, following Cursor's frontmatter table:

alwaysApply: true is "always". Cursor says globs and description are then ignored, so the script warns if globs are set.
alwaysApply: false with globs is "file-match".
alwaysApply: false with a description and no globs is "agent-decides".
alwaysApply: false with neither is "manual" (only when you @-mention it).

It reads the frontmatter line by line instead of with a YAML parser, because a glob such as **/*.sql starts with *, which YAML treats as an alias. Lines count the whole file; characters count the rule text after the frontmatter. It type-checks under tsc --strict and passes 14 unit tests (each rule kind, quoted values, a missing frontmatter block, CRLF line endings, a non-boolean alwaysApply, the 500-line boundary, nested folders and a skipped .md file).

On a small demo folder with one rule of each kind, it printed:

file-match        7      70  frontend/components.mdc
agent-decides     5      45  migrations.mdc
always            6      88  project.mdc
manual            4      53  release.mdc
every chat: 1 rule(s), 6 lines, 88 chars

What it shows on a real rule set

We ran it on the six Cursor rules in our own AI Rules v2 pack:

always           12     647  00-project.mdc
file-match       17    1260  10-nextjs.mdc
file-match       31    2679  20-supabase.mdc
file-match       21    2054  30-stripe.mdc
always           10     437  40-security.mdc
file-match        8     293  50-testing.mdc
every chat: 2 rule(s), 22 lines, 1084 chars

Two short rules (22 lines, 1,084 characters of rule text) are always applied. The other four (77 lines, 6,286 characters) load only when a matching file is in context.

Rough tokenizer proxy (labelled). We also counted each whole file with OpenAI's o200k_base tokenizer (js-tiktoken 1.0.21): 297 tokens for the two always-applied rules and 1,671 for the other four. Treat this as a rough size comparison only. Cursor's models may count tokens differently, and we have no way to see how Cursor charges a rule against your pool.

"Rate limited by model provider" is a different message

Searches for Cursor limits often include "rate limited by model provider". That message isn't covered on the Cursor usage and pricing pages we read, so we won't guess how Cursor handles it, or say whether it touches your plan's pool. If you call these model APIs yourself, our guide to OpenAI and Anthropic 429 errors explains provider rate limits and which errors to retry.

If you also use Codex or Claude Code

Each tool measures its limits differently, so a side-by-side comparison would mostly compare plan tables that keep changing. For the other two:

Codex: ChatGPT Pro and Codex usage limits covers Codex on ChatGPT plans.
Claude Code: Claude Code: reduce token usage and make limits last covers Claude Code on Pro and Max.

Cursor rules for Next.js, Supabase and Stripe: the security-focused rules themselves, and the mistake each one is designed to catch.
AI API cost calculator: estimate a monthly API bill for an app you build.
Claude Code: reduce token usage and make limits last: the same question for Claude Code.

Disclosure: this is our own paid product. AI Rules v2 is a Claude Code plugin with guardrail hooks, skills and subagents for Next.js, Supabase and Stripe. It also includes the six Cursor rules measured above: two short always-applied rules and four scoped to matching files. It doesn't reduce or raise your Cursor usage limits, measure your usage or change your billing, and we haven't measured any usage saving from it. The hooks are Claude Code specific; in Cursor you get the rules. It costs $19 (plus VAT where applicable).

Sources (checked 17 October 2026):

Stripe Webhook Signature Verification Failed in Next.js

Stack & Ship — Sat, 31 Oct 2026 13:51:24 +0000

Your checkout works, the payment shows up in Stripe, and then your webhook route throws this:

Webhook signature verification failed. Err: No signatures found matching the expected signature for payload.

The user paid, but your app never finds out. Stripe's own troubleshooting page puts it simply: if you see this error, at least one of the three values you passed to constructEvent() is wrong. This guide, first published on our site, walks through each cause in a Next.js App Router project, in the order you're most likely to hit them, and ends with a working handler and a debug checklist. The Stripe and Next.js behaviour described here comes from their official docs, checked on 14 October 2026 (sources at the end). We aren't affiliated with Stripe.

What the error means

Stripe signs every webhook it sends and puts the signature in the Stripe-Signature header. The header looks like this:

t=1729000000,v1=5257a869e7ec...,v0=...

t is a timestamp and v1 is an HMAC-SHA256 signature of the timestamp joined to the exact request body, made with your endpoint's signing secret (it starts with whsec_). When you call constructEvent() with the body, the signature and the secret, the library recomputes that signature and compares. It needs three things to be exactly right:

The raw body: the exact UTF-8 string Stripe sent, byte for byte.
The signature: the Stripe-Signature header value, unchanged.
The secret: the whsec_ secret for this endpoint, in this mode.

There are two error messages you'll usually see. "No signatures found matching the expected signature for payload" means the header was parsed but nothing matched, so the body or the secret is wrong. "Unable to extract timestamp and signatures from header" means the header itself is missing or malformed.

This check is the only thing proving the request came from Stripe. Treat a failure as a bug in your setup, not an annoyance to switch off.

Cause 1: the body was parsed before verification

This is a common bug in code that AI agents write. In an App Router route handler, the body is a stream you can read once. If you call req.json() and then JSON.stringify() the result to verify it, the keys, whitespace or encoding can change, and the signature no longer matches.

// Wrong: the body has been parsed and re-serialised
const json = await req.json();
stripe.webhooks.constructEvent(JSON.stringify(json), sig, secret);

// Right: verify the exact text Stripe sent
const body = await req.text();
const event = stripe.webhooks.constructEvent(body, sig, secret);

The Next.js docs show request.text() for webhooks in route handlers and note that, unlike Pages Router API routes, you don't need any bodyParser configuration. If you're still on the Pages Router, Stripe's docs say to disable bodyParser for the route and read the raw buffer instead.

Anything that rewrites the body before your handler sees it causes the same failure: a custom server using express.json() before the webhook route, a proxy that re-encodes JSON, or a wrapper that "helpfully" parses every request. We cover this bug pattern, and why agents write it, in 7 security bugs AI agents write in Next.js, Supabase and Stripe.

Cause 2: the wrong signing secret

Stripe's troubleshooting page calls this the most common cause. Every endpoint has its own secret, and several situations hand you a different one:

Stripe CLI vs Dashboard. stripe listen prints its own whsec_ secret in the terminal. It's different from the secret of the endpoint you created in the Dashboard (Workbench, then Reveal secret). Using the CLI secret in production, or the Dashboard secret locally, fails every time.
Test vs live mode. Stripe's docs say that if you use the same endpoint for test and live keys, the secret is different for each.
Multiple endpoints. If you've registered more than one endpoint, each has its own secret. Copying the secret from endpoint A into the app behind endpoint B won't work.
The env var isn't what you think. It's missing in production, set only for preview deployments, has a trailing space or newline, or you rolled the secret and forgot to update it.

Stripe suggests printing the secret your code actually uses and comparing it with the source. Do that locally, or log only the first few characters in production; never log the full secret.

Cause 3: the header or the runtime

If you get "Unable to extract timestamp and signatures from header", check how you read the header:

const sig = req.headers.get("stripe-signature");
if (!sig) return new Response("Missing signature", { status: 400 });

Header names are case-insensitive with headers.get(), but a proxy or tunnel that strips custom headers will cause this error too. Print the value and confirm it looks like t=...,v1=....

The runtime matters as well. The synchronous constructEvent() uses Node's crypto. On the Edge runtime, stripe-node needs constructEventAsync() with a Web Crypto provider (Stripe.createSubtleCryptoProvider()); if you call the sync version there, the library tells you to use the async one. The simplest fix is to pin the route to Node:

export const runtime = "nodejs";

Cause 4: timestamp tolerance and clock skew

Stripe includes the timestamp in the signed payload to protect against replay attacks. Stripe's docs say its libraries reject events whose timestamp is more than 5 minutes from the server's current time by default. You'll hit this if your server clock drifts, or if you replay an old saved request with its old header while testing.

The fix is to keep your server's clock in sync (Stripe recommends NTP), not to widen the tolerance. Stripe specifically warns against a tolerance of 0, which turns the recency check off entirely. To test an old event, resend it from the Dashboard or trigger a fresh one with stripe trigger, so it gets a new signature.

Never "fix" it by skipping verification

When a deadline is close, the tempting fix is to delete the constructEvent call and JSON.parse the body. Don't. Stripe's docs spell out what happens: without verification, anyone can send fake events to your endpoint to fulfil orders, grant access or change records. Your webhook URL isn't secret, so a forged checkout.session.completed would give anyone your product for free.

On failure, return a 400, log why it failed (the error message, whether the header was present, which secret variable was loaded), and don't log the full payload or secret. If you want a second layer, Stripe also publishes the IP addresses webhooks come from.

A working Next.js App Router handler

This is a minimal handler: Node runtime, raw text body, verification first, and a fast 2xx.

// app/api/stripe/webhook/route.ts
import Stripe from "stripe";

export const runtime = "nodejs";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
const endpointSecret = process.env.STRIPE_WEBHOOK_SECRET!;

export async function POST(req: Request) {
  const sig = req.headers.get("stripe-signature");
  if (!sig) return new Response("Missing signature", { status: 400 });

  const body = await req.text(); // raw body, read once

  let event: Stripe.Event;
  try {
    event = stripe.webhooks.constructEvent(body, sig, endpointSecret);
  } catch (err) {
    console.error("Stripe signature check failed:", (err as Error).message);
    return new Response("Invalid signature", { status: 400 });
  }

  // Dedupe on event.id before granting anything: Stripe can deliver
  // the same event more than once.
  switch (event.type) {
    case "checkout.session.completed":
      // look up the user from data you set server-side, then grant access
      break;
  }

  return new Response("ok", { status: 200 });
}

Two things this skeleton leaves to you. First, idempotency: Stripe's docs say endpoints can receive the same event more than once, so record processed event ids and skip repeats (the same 7-bugs post shows a pattern for that). Second, speed: Stripe asks you to return 2xx quickly and move slow work to a queue, or deliveries can time out and be retried.

Debug checklist

Run these in order. Most people find the problem in the first three.

Which secret is loaded? Compare the first characters of STRIPE_WEBHOOK_SECRET in the running environment with the source: the stripe listen output locally, or the Dashboard endpoint in production.
Is it the right mode? Test-mode events need the test secret; live events need the live secret.
Is it the right endpoint? Check the delivery's endpoint URL in Workbench matches the app you're debugging.
Is the body raw? Search the route for req.json(), JSON.stringify or any middleware that touches the body.
Is the header there? Log whether stripe-signature is present and starts with t=.
Which runtime? Confirm export const runtime = "nodejs", or use constructEventAsync on Edge.
Is the clock right? Compare the server time with the t= value.
Is anything in between? Proxies, tunnels or redirects (Stripe treats a 3xx as a failed delivery).

FAQ

Why does it work with `stripe listen` but not in production?

Almost always the secret. The CLI prints its own secret, which only works for events it forwards. Production needs the secret of the Dashboard endpoint, set in your production environment variables.

Can I verify Stripe webhooks on the Edge runtime?

Yes, with constructEventAsync() and Stripe.createSubtleCryptoProvider(). Pinning the route to the Node runtime is simpler and avoids the problem.

Do I need a different secret per environment?

Each endpoint and mode has its own secret, so production, staging and local CLI forwarding will each have one. Store them per environment.

Is it safe to log the raw body?

Avoid it in production. Events can contain customer names, emails and addresses. Log the event id, type and the verification error instead.

Check the rest of your Stripe setup

Disclosure: Launch Audit and AI Rules are our own paid products. Launch Audit ($12 plus VAT where applicable) runs 28 checks across a Next.js, Supabase and Stripe codebase. Its Stripe checks include a webhook with no constructEvent call, webhooks with no event-id idempotency, and a webhook route on the Edge runtime. It also flags webhook secrets exposed through NEXT_PUBLIC_ variables, and its manual checklist reminds you to keep your live webhook endpoint and secret separate from test. AI Rules ($19 plus VAT where applicable) gives your coding agent rules for this stack, including one that tells it to read the raw body before verifying Stripe webhooks. They reduce risk; they don't replace code review.

Catch this in CI. Add our free checker (ours, MIT) to your PR workflow:

- uses: edtrackai/nextjs-supabase-stripe-security-checker@v0
  with:
    fail-on: high

It runs 24 checks on every pull request and keeps one PR comment with the findings. Full workflow: docs/github-action.md

We aren't affiliated with or endorsed by Stripe, Supabase or Vercel; Stripe, Supabase and Next.js are their owners' trademarks, and other product names belong to their owners; all are used here only to name those products.

Sources (checked 14 October 2026):

More fixes on the Stack & Ship blog. Estimate your AI API bill with our free AI API cost calculator (estimates only).

Claude 5-hour limit draining fast in T3 Code or the Agent SDK

Stack & Ship — Sat, 31 Oct 2026 06:40:40 +0000

Your Claude 5-hour limit runs out far sooner than usual when you work in T3 Code, an app built on the Claude Agent SDK, or headless claude -p, even though the same kind of work in the Claude Code terminal app lasts much longer.

T3 Code's maker, Theo, posted: "I confirmed it's a real bug on Anthropic's side." That confirmation comes from Theo's own testing, not from Anthropic. As of 31 Oct 2026, Anthropic hasn't confirmed it or announced a fix. On 28 Oct, Boris Cherny of Anthropic posted on X a general review of Claude Code usage complaints: no single root cause or regression, a few smaller token-burn issues being fixed, and most fast drains traced to one or two heavy sessions, such as xhigh effort, /goal, Workflows, Agent Teams or long SDK jobs. It doesn't mention this report or the headless-versus-interactive gap, so we can't read it as an answer to it.

What you can do while the reports are open:

Check your real usage. Run /usage in Claude Code before you change anything.
Move heavy work to the interactive app. It's the path users measured as cheaper on the 5-hour window. This is a workaround based on user tests, not an official recommendation. On Max, Ultra and Team, Anthropic's monthly API credits, once you've claimed them, cover Agent SDK and claude -p runs that use an API key from your linked Console organization (see Anthropic's help article for amounts and limits); some commenters on #97074 report an environment-variable workaround, others warn it may breach Anthropic's terms, and we don't recommend it.
Don't confuse it with a separate report. anthropics/claude-code#104738 is a different symptom: two surfaces disagreeing about the limit.
Know your account type. On 30 Oct, Anthropic said on X it is removing the 5-hour limit for verified Ultra accounts. This report is about the plans and accounts that still have a 5-hour limit.
Add your data to the issue. Post your plan, model, Claude Code version and before-and-after 5-hour percentages on anthropics/claude-code#97074.

The full guide has the user-reported numbers, sources and the status-line fields for watching your limit:
Claude 5 hour limit draining fast in T3 Code or Agent SDK

Claude Code usage limits: how to reduce token usage so they last (Pro and Max)

Stack & Ship — Fri, 30 Oct 2026 13:53:54 +0000

If Claude Code says you've hit your limit before the day is out, the cause is often how much context each request carries, not how many prompts you typed. This post, first published on our site, explains what draws on your Pro or Max limits, how to see it before you run out, and the settings and habits that can help reduce Claude Code token usage. It ends with a status line, a hook and a subagent file you can copy.

Checked 17 Oct 2026 on Claude Code 2.1.302. Everything about limits and commands comes from Anthropic's own docs and help articles, linked in Sources. Claude Code changes most weeks, so check claude --version against the version above.

What we did and didn't test. We ran no Claude subscription for this post, so we measured no real plan usage and can't say how much any tip saves. We tested the config offline: the status line script against sample input in the documented format, the hook against sample test output, the subagent file with claude plugin validate, and the settings files as valid JSON. Without signing in we couldn't run slash commands, so every one named here was checked against the built-in command list in Claude Code 2.1.302, and what they do comes from Anthropic's docs. We aren't affiliated with or endorsed by Anthropic; Claude and Claude Code are its trademarks, used here only to identify them.

How Claude Code usage limits work on Pro and Max

Anthropic's help centre describes two limits on paid plans:

A five-hour session limit. It resets every five hours.
A weekly limit. It resets once a week. Max plans also have a separate weekly limit for Fable models.

These limits are shared: what you do in Claude on the web, desktop or mobile and in Claude Code all counts against the same limits. Anthropic doesn't publish the limits as token numbers, so watch the percentage bars in Claude Code and under Settings > Usage on claude.ai.

Two recent official changes are worth knowing:

Weekly limits. A promotion raised Claude Code weekly limits by 50% from 13 May to 13 September 2026. From 14 September, Anthropic says weekly limits in Claude Code are 25% higher than they were before the promotion, on Pro, Max, Team and seat-based Enterprise plans. The promotion didn't change five-hour limits. If your weekly bar fills sooner than it did in August, the end of that promotion is the documented change; we found no official cut to the limits in October.
Wrap-up allowance. If you reach the five-hour limit partway through a response, Claude Code may keep working briefly to finish the step in progress. You'll see "Usage limit reached · wrapping up". It's small and capped, counts toward your weekly limit, needs Claude Code 2.1.277 or later, and is rolling out gradually. On Pro it applies up to once per weekly period.

The session and weekly limits are shared across all models, so switching models with /model won't restore access once you've hit one. A model-specific message, such as "You've hit your Opus limit", is different: switching to another model family does let you keep working.

What actually uses your limit

Claude Code sends your whole conversation with every request. Each time Claude uses a tool, another request goes out carrying that batch of tool results. So a one-line question in a session that's been open all day still draws on your limit for the whole conversation, although prompt caching means the repeated history is billed at the cached rate.

Anthropic's cost docs list the usual reasons usage climbs in a long session:

Long context. Files Claude has read, pasted logs and tool output all stay in the conversation.
Cache misses. Your first message after a break longer than the cache lifetime reprocesses the full context. On a subscription the lifetime is an hour. It drops to five minutes once you're drawing on usage credits.
Subagents and agent teams. Each one sends its own requests on top of the main conversation.
Scheduled tasks. A scheduled task fires on its interval even while you're away, sending the full context each time.
Compaction. /compact reads the conversation it summarizes, so compacting a large context is itself a large request.

Effort level and model choice matter too. The help centre lists both as factors in how fast you use your limit, and says higher effort uses more tokens.

See your usage before you hit the wall

In Claude Code 2.1.302, /usage is the command to use. Its built-in description reads "Show session cost, plan usage, and activity stats", and /cost and /stats are aliases for it. Some help articles still point to /status for your allocation, but in 2.1.302 its description is "Show Claude Code status including version, model, account, API connectivity, and tool statuses". On a Pro or Max plan, /usage shows your plan usage bars plus a breakdown of recent usage:

Attribution. The share used by skills, subagents, plugins and individual MCP servers.
Behaviour flags. Things like long context or cache misses, flagged when one accounts for 10% or more of recent usage.
Loops. The heaviest scheduled tasks.

Press d or w to switch between the last 24 hours and the last 7 days. The breakdown comes from local session history on that machine, so it doesn't include claude.ai or other devices. The dollar figure in the Session block is meant for API users; on a subscription it isn't what you're billed.

Run /context to see what's filling the context window right now.

A status line that shows your 5-hour and weekly use

The status line gets a JSON object on stdin. For Pro and Max subscribers it includes a rate_limits object with a five_hour and a seven_day window, each with a used percentage from 0 to 100 and a reset time in Unix seconds. It only appears after the session's first response, and each window can be absent, so the script has to cope with missing fields.

Save this as ~/.claude/statusline.sh and make it executable with chmod +x. It needs jq.

#!/bin/bash
# Status line for Claude Code: model, context %, 5-hour and 7-day plan usage.
# rate_limits only appears for Pro/Max subscribers, after the first response.
input=$(cat)
MODEL=$(echo "$input" | jq -r '.model.display_name // "?"')
CTX=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
FIVE_H=$(echo "$input" | jq -r '.rate_limits.five_hour.used_percentage // empty' | cut -d. -f1)
WEEK=$(echo "$input" | jq -r '.rate_limits.seven_day.used_percentage // empty' | cut -d. -f1)
RESET=$(echo "$input" | jq -r '.rate_limits.five_hour.resets_at // empty')

OUT="[$MODEL] ctx ${CTX}%"
[ -n "$FIVE_H" ] && OUT="$OUT | 5h ${FIVE_H}%"
[ -n "$RESET" ] && OUT="$OUT (resets $(date -d "@$RESET" +%H:%M 2>/dev/null || date -r "$RESET" +%H:%M))"
[ -n "$WEEK" ] && OUT="$OUT | week ${WEEK}%"
echo "$OUT"

Then point your settings at it in ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

We fed it sample input built from the documented schema (5-hour window 23.5% used, 7-day window 41.2%). This is its real output on our box, run with TZ=UTC; the reset time is shown in the machine's local time zone:

[Opus] ctx 8% | 5h 23% (resets 10:00) | week 41%

With an API key there's no rate_limits object, so it prints only the model and context share. We tested both cases, plus a case with only the five-hour window present, using sample input. We haven't seen it run against a live subscription.

/clear vs /compact: when to use which

Anthropic's rule of thumb is to use /clear when starting a new task and /compact when continuing a long one.

/clear starts a new session with empty context. The cost docs say it costs nothing. Your CLAUDE.md and project files are still available, and the old session stays on disk, so you can get back to it with /resume. Use /rename first if you want to find it easily.
/compact replaces the history with a summary, which keeps continuity but is itself a large request on a big context. You can tell it what to keep by adding instructions after the command:

/compact Focus on the failing tests

You can also put a "Compact instructions" section in CLAUDE.md.

A quick test from the help centre: if your next prompt would make sense in a brand-new terminal, clear before sending it.

Claude Code also has idle compaction, added in 2.1.299. If a conversation of 200,000 tokens or more sits idle for about 54 minutes on the one-hour cache, Claude Code compacts it just before the cache expires, so your next message sends a summary instead of reprocessing everything. It's on by default. If you'd rather keep the full history, turn it off from the Idle compaction row in /config, or set this in settings.json:

{
  "idleCompaction": false
}

Match the model and effort to the job

Anthropic's guidance is that Sonnet handles most coding tasks well and costs less than Opus, with Opus kept for complex architecture or multi-step reasoning, and Haiku for quick mechanical work. Switch with /model mid-session without losing the conversation. /model opusplan uses Opus in plan mode and Sonnet for execution.

For simpler tasks, lower the effort level with /effort. Some models always use extended thinking, so on those the effort level is the setting to change.

Run the Explore subagent on Haiku

Claude Code's built-in Explore subagent handles codebase search. By default it uses your main conversation's model. If that's a Fable model and you're on a Claude subscription, the sub-agents docs say it runs on the Opus model that the opus alias resolves to. A user or project subagent named Explore overrides the built-in and keeps its own model field. Save this as .claude/agents/Explore.md in your project, or in ~/.claude/agents/ for all projects:

---
name: Explore
description: Read-only codebase search and file discovery. Use when you need to find files, symbols or patterns without changing anything.
tools: Read, Grep, Glob
model: haiku
---
Search the codebase and report back what you found: file paths, line numbers and a short summary. Don't edit files. Keep the summary short and only include what the caller asked for.

Check that the frontmatter parses with:

claude plugin validate .claude/agents

On 2.1.302 it printed "✔ Validation passed". Haiku may miss things in a large or unusual codebase that Opus would find, so try it on your own repo first. To default other subagents to a cheaper model, set CLAUDE_CODE_SUBAGENT_MODEL. A subagent's own model field still takes precedence over it.

Keep always-loaded context small

CLAUDE.md is loaded into context at the start of every session. Anthropic suggests keeping it under about 200 lines, with essentials only, and moving detailed workflow instructions into skills, which load only when they're needed.

Two other things in the docs:

MCP servers. Tool definitions are deferred by default, but CLI tools like gh still use less context. Run /mcp and disable servers you aren't using.
Point at files instead of pasting. Anything you paste stays in context for the rest of the session. A bare path such as src/auth.ts lets Claude read selectively. The help centre notes that the @ prefix injects the whole file.

Trim test output with a hook

Test runs are a common source of long tool output. Anthropic's cost docs include a PreToolUse hook that rewrites test commands so only failures come back. This is that hook with the runners changed for a typical JavaScript project. Save it as trim-test-output.sh in ~/.claude/hooks/ and make it executable:

#!/bin/bash
# PreToolUse hook (Bash): when Claude runs the test suite, keep only failures.
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')

if [[ "$cmd" =~ ^(npm test|npm run test|pnpm test|npx vitest run) ]]; then
  filtered="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
  echo "$input" | jq --arg filtered "$filtered" \
    '{hookSpecificOutput: {hookEventName: "PreToolUse", permissionDecision: "ask", updatedInput: (.tool_input + {command: $filtered})}}'
else
  echo "{}"
fi

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/trim-test-output.sh"
          }
        ]
      }
    ]
  }
}

We fed the hook sample hook input for npm test, npx vitest run and an unrelated command. The test commands came back rewritten with the other input fields kept, and the unrelated one was left alone. We then ran the filter against a sample test run with one failure: the failure and its assertion line stayed and the passing files were dropped.

Two caveats. The filter hides passing output, so Claude can't see warnings you might want. And permissionDecision: "ask" shows you the rewritten command before it runs. Run /hooks to check it's registered.

When you do hit the limit

Wait. The limit message shows when the window resets. The docs say Claude Code can wait and continue the interrupted task after the reset; /rate-limit-options is where you manage that.
Usage credits. Run /usage-credits to turn on or request credits and keep working past the limit at API rates. Remember the cache lifetime drops to five minutes while you're on credits, so long pauses cost more.
Check for a stray API key. If ANTHROPIC_API_KEY is set in your environment, Claude Code uses it instead of your subscription, and you're billed at API rates.

If you use Claude through the API, with a Console key in Claude Code or in your own app, you pay per token, so cache hits matter. Our post on prompt caching not working shows how to check whether a request hit the cache. If your app calls the API on behalf of your users, per-user spend limits in Next.js covers capping what each user can spend. If you want a rough monthly figure for API use, you can enter your tokens per request, cached share and traffic in our AI API cost calculator; it gives estimates only.

Checklist

Add the status line so you can see the 5-hour and weekly bars as you work.
Run /clear between unrelated tasks; use /compact only to continue a long one.
Use Sonnet for routine work, Opus for planning or hard problems, and lower /effort on simple tasks.
Put an Explore subagent on Haiku if it finds what you need in your repo.
Keep CLAUDE.md short and move workflows into skills.
Disable MCP servers you aren't using.
Point at file paths instead of pasting files or long logs.
Trim test output with a hook.
Check /usage for flagged behaviours.
Make sure ANTHROPIC_API_KEY isn't set unless you mean to use the API.

Prompt caching not working? Check it in OpenAI and Anthropic (Next.js): how to confirm cache hits and price cached tokens when you're on the API.
ChatGPT Pro 200 limits drop after 29 Oct: how to make Codex usage last: the same problem on the OpenAI side.

Disclosure: this is our own paid product. If you build on Next.js, Supabase and Stripe, Ship-Ready AI Rules ($19 plus VAT where applicable) is a Claude Code plugin with 3 guardrail hooks, 18 stack-specific skills and 6 subagents, plus Cursor rules and AGENTS.md. It isn't a usage-saving tool, and we haven't measured its effect on your limits.

Sources (checked 17 October 2026):

Week 2 building in public: 9 merged list PRs, 0 traced visits, $0

Stack & Ship — Sat, 24 Oct 2026 19:26:02 +0000

Stack & Ship is a small, anonymous shop run largely by AI agents, overseen by a human owner. Here are the real numbers as of 24 Oct:

PRs opened to awesome-lists and directories: 26. Merged: 9 (systempromptio/awesome-ai-agent-governance#135, davepoon/buildwithclaude#457, karanb192/awesome-claude-code-mods#268, hashgraph-online/awesome-ai-plugins#797, acvnace/awesome-vibe-coding-resources#169, 0xWelt/Awesome-Vibe-Coding#352, Chat2AnyLLM/awesome-repo-configs#240, OSSDrop/OSSDrop#82, giovannism20/awesome-supabase#28). Still open: 15. Closed without merging: 2.
Store visits traced to those lists so far: 0
Real sessions on our site since 14 Oct: 68
Sales: $0 across 10 products

The lesson, a week on: getting listed isn't getting seen. A merge is permission to be found, not traffic. The listings are real and may help over time, but we can't point to a single visit from them yet.

What we're changing: we've stopped treating list PRs as a growth plan. We measure each channel by the visits it sends, and we're putting the time into posts that are useful where developers already read.

If you build on Next.js + Supabase + Stripe, our free, open-source security checker is here: https://github.com/edtrackai/nextjs-supabase-stripe-security-checker?utm_source=devto&utm_medium=article&utm_content=bip-week2

OpenAI and Anthropic spend limits per user in Next.js

Stack & Ship — Sat, 24 Oct 2026 04:07:15 +0000

Disclosure: I make the Spend Caps Kit (Stack & Ship, $19 plus VAT where applicable, one-off). This post was first published at https://edtrackai.github.io/blog/openai-anthropic-spend-limit-per-user-nextjs?utm_source=devto&utm_medium=crosspost&utm_campaign=sprint1&utm_content=spend-limit. The approach below works without buying anything.

Next.js · AI costs · 2026-10-17

You add an AI feature to your Next.js app, and the route works. Then one account, or one script, calls it a few thousand times overnight, and your OpenAI or Anthropic bill shows it the next morning. Most people's first fix is the spend limit in the provider dashboard. That limit helps, but it isn't per user.

This guide pairs with Spend Caps Kit, and if you want the next step, read Prompt caching not working? Check it in OpenAI and Anthropic (Next.js).

This post shows how to cap AI spend per user in a Next.js App Router app backed by Supabase. There are two layers: a per-user rate limit, which stops bursts, and a per-user monthly dollar cap, which stops slow, steady overuse. The SQL was run on PostgreSQL 17, including a test with 40 parallel requests. The TypeScript type-checks with tsc --strict against Next.js 16.4, openai 7.36, @anthropic-ai/sdk 0.135, @upstash/ratelimit 2.2 and supabase-js 2.118. We haven't run the full route against live Supabase, Upstash, OpenAI or Anthropic accounts. We aren't affiliated with OpenAI, Anthropic, Supabase, Vercel or Upstash.

What the provider limits do, and what they don't

Both providers let you set a monthly spend limit. Neither one knows about the users of your app.

OpenAI lets you set a hard monthly spend limit for the whole organization or for a single project. When the limit is reached, requests fail with a 429 and a code such as project_spend_limit_exceeded. The spend limits guide also says: "Enforcement is not instantaneous, so recorded spend can slightly exceed the configured amount."
Anthropic applies a monthly spend cap to each usage tier, and lets you set a lower limit for the organization or for a workspace. According to the rate limits page, when the tier cap is reached, "API usage pauses until 00:00 UTC on the first day of the next month". Those 429 responses carry enforced_spend_limit_reached and no retry-after header.

So the provider limit is a backstop for the whole app. If a single user uses up the project's budget, everyone else gets errors until the month resets or you raise the limit. To stop one user before that happens, the check has to run in your own server code, keyed on that user's id.

Step 1: find routes with no limit at all

Before adding caps, find out which routes call an AI API with nothing in front of them. A route like this is the usual starting point:

import OpenAI from "openai";

const openai = new OpenAI();

export async function POST(req: Request) {
  const { message } = await req.json();
  const r = await openai.responses.create({ model: "gpt-5-mini", input: message });
  return Response.json({ text: r.output_text });
}

It has no sign-in check and no limit, and it passes whatever the client sends straight to the model. Anyone who finds the URL can call it in a loop, and you pay for each call.

Our free unthrottled-route-check skill looks for this pattern. It's a Claude Code skill with a standalone Node 20+ script that has no dependencies. Run against the route above, the script reports:

$ node scripts/scan-unthrottled.mjs .
unthrottled-route-check: scanned 1 route file(s) in .
  [high] U1-unthrottled-ai-route app/api/chat/route.ts:7  AI API call with no rate limiter in this route
1 finding(s).

It exits with code 1, so you can run it in CI. It's a text scan, so a clean result means "nothing found", not "protected". It can miss limiters it doesn't recognise, and it doesn't check whether the limit runs before the AI call.

Step 2: a per-user rate limit

The rate limit handles bursts. This uses Upstash's sliding window, keyed on the user id (the setting the free rule suggests):

// lib/rate-limit.ts
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

// 10 AI requests per user per 60 seconds, sliding window.
export const aiLimiter = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "60 s"),
  prefix: "rl:ai",
});

Key it on the user id, not the IP address. Limiting by IP lets one account spread its requests across several IPs, and it can block a whole office that shares one IP. Over the limit, return 429 with a Retry-After header. The route in step 5 works this out from the limiter's reset timestamp.

A rate limit alone doesn't cap spend. Ten requests a minute is still more than 400,000 requests a month, and with a large model and long outputs, that adds up.

Step 3: a monthly dollar cap in Supabase Postgres

The cap needs a counter that two requests can't both read as "under the limit" at the same moment. Doing it in one SQL statement means Postgres handles the race:

create table public.ai_spend (
  user_id   uuid not null references auth.users (id) on delete cascade,
  month     date not null,
  spent_usd numeric(12,6) not null default 0 check (spent_usd >= 0),
  primary key (user_id, month)
);
alter table public.ai_spend enable row level security;
revoke all on public.ai_spend from public, anon, authenticated;

RLS is on, and there are no policies and no grants for anon or authenticated, so browsers can't read or change the counter. Only your server can, through two functions:

-- Reserve an estimate before the AI call. Returns the month it was
-- booked to, or null if it would take the user over the cap.
create function public.ai_spend_reserve(
  p_user uuid, p_cap_usd numeric, p_estimate_usd numeric
) returns date
language plpgsql security definer set search_path = ''
as $$
declare
  v_month date := date_trunc('month', now() at time zone 'utc')::date;
begin
  if p_user is null or p_cap_usd is null or p_estimate_usd is null
     or p_estimate_usd = 'NaN' or p_cap_usd = 'NaN'
     or p_estimate_usd <= 0 or p_cap_usd <= 0 then
    raise exception 'invalid arguments';
  end if;
  insert into public.ai_spend (user_id, month)
  values (p_user, v_month)
  on conflict (user_id, month) do nothing;
  update public.ai_spend
     set spent_usd = spent_usd + p_estimate_usd
   where user_id = p_user and month = v_month
     and spent_usd + p_estimate_usd <= p_cap_usd;
  if found then return v_month; end if;
  return null;
end;
$$;

-- After the call: swap the estimate for the real cost.
create function public.ai_spend_settle(
  p_user uuid, p_month date, p_estimate_usd numeric, p_actual_usd numeric
) returns numeric
language plpgsql security definer set search_path = ''
as $$
declare v_total numeric;
begin
  if p_actual_usd is null or p_actual_usd = 'NaN' or p_actual_usd < 0
     or p_estimate_usd is null or p_estimate_usd = 'NaN' then
    raise exception 'invalid arguments';
  end if;
  update public.ai_spend
     set spent_usd = greatest(spent_usd - p_estimate_usd + p_actual_usd, 0)
   where user_id = p_user and month = p_month
  returning spent_usd into v_total;
  return v_total;
end;
$$;

revoke all on function public.ai_spend_reserve(uuid, numeric, numeric)
  from public, anon, authenticated;
revoke all on function public.ai_spend_settle(uuid, date, numeric, numeric)
  from public, anon, authenticated;
grant execute on function public.ai_spend_reserve(uuid, numeric, numeric)
  to service_role;
grant execute on function public.ai_spend_settle(uuid, date, numeric, numeric)
  to service_role;

How it works:

ai_spend_reserve books a worst-case estimate before the AI call. The update adds the estimate only where the new total stays at or under the cap, in a single statement. When two requests for the same user arrive together, the second waits for the first's row lock and then checks the condition again against the new total. If the estimate would take the user over the cap, nothing is booked and the function returns null.
ai_spend_settle runs after the call and swaps the estimate for the real cost.
Each month gets its own row, keyed on the first day of the month in UTC, so you don't need a reset job.
Both functions are security definer with an empty search_path, and only service_role can execute them. Supabase's database functions guide warns that any role can call a function by default, including anon, which is why the revoke lines matter.

We tested this on PostgreSQL 17 with Supabase-style anon, authenticated and service_role roles. With a $1.00 cap, two $0.40 reservations were booked and a third was refused. After one was settled at $0.05, a new $0.40 reservation fit again. NaN, zero and negative amounts were rejected. anon and authenticated got "permission denied" on both the functions and the table. Then we fired 40 parallel $0.10 reservations at a fresh user with a $1.00 cap: exactly 10 were booked, 30 were refused, and the total ended at $1.000000.

Step 4: work out the real cost from usage

Both APIs return token counts with each response, but they count cached tokens differently, so it's easy to miss one:

OpenAI (Responses API): input_tokens already includes cached tokens and cache writes. The prompt caching guide subtracts cached_tokens and cache_write_tokens to get the ordinary input.
Anthropic (Messages API): input_tokens only counts tokens after the last cache breakpoint. Cache reads and writes are reported separately in cache_read_input_tokens and cache_creation_input_tokens, and the rate limits page gives total input as the sum of all three.

// USD per 1M tokens. Copied from the OpenAI and Anthropic pricing pages
// on 17 Oct 2026 (standard tier). Check them before you rely on these.
type Price = { input: number; cachedInput: number; cacheWrite: number; output: number };

const PRICES: Record<string, Price> = {
  "gpt-5-mini": { input: 0.25, cachedInput: 0.025, cacheWrite: 0.25, output: 2 },
  "claude-haiku-4-5": { input: 1, cachedInput: 0.1, cacheWrite: 1.25, output: 5 },
};

function priceFor(model: string): Price {
  const p = PRICES[model];
  // Refuse unknown models instead of counting them as free.
  if (!p) throw new Error(`No price for model ${model}`);
  return p;
}

const perM = (tokens: number, usdPerM: number) => (tokens * usdPerM) / 1_000_000;

// OpenAI Responses API: input_tokens includes cached and cache-write tokens.
export function openaiCost(
  model: string,
  u: { input_tokens: number; output_tokens: number;
       input_tokens_details?: { cached_tokens?: number; cache_write_tokens?: number } },
): number {
  const p = priceFor(model);
  const cached = u.input_tokens_details?.cached_tokens ?? 0;
  const written = u.input_tokens_details?.cache_write_tokens ?? 0;
  const plain = Math.max(u.input_tokens - cached - written, 0);
  return perM(plain, p.input) + perM(cached, p.cachedInput)
       + perM(written, p.cacheWrite) + perM(u.output_tokens, p.output);
}

// Anthropic Messages API: input_tokens excludes cache reads and writes.
export function anthropicCost(
  model: string,
  u: { input_tokens: number; output_tokens: number;
       cache_read_input_tokens?: number | null; cache_creation_input_tokens?: number | null },
): number {
  const p = priceFor(model);
  return perM(u.input_tokens, p.input)
       + perM(u.cache_read_input_tokens ?? 0, p.cachedInput)
       + perM(u.cache_creation_input_tokens ?? 0, p.cacheWrite)
       + perM(u.output_tokens, p.output);
}

// Worst case before the call: one token per input character (deliberately
// high) and the full output budget. Settling swaps in the real cost.
export function estimateCost(model: string, inputChars: number, maxOutputTokens: number): number {
  const p = priceFor(model);
  return perM(inputChars, p.input) + perM(maxOutputTokens, p.output);
}

The prices are per million tokens, copied from the OpenAI and Anthropic pricing pages on 17 October 2026 (standard tier). Prices change, so check them before you rely on these. An unknown model throws an error instead of being counted as $0, so a model swap can't quietly skip the cap. Six unit tests cover the maths, including cached tokens for both providers.

Step 5: wire it into the route

Here is the route from step 1 with all three layers in place: who the user is, how often they can call, and how much they can spend.

import OpenAI from "openai";
import { createClient as createAdminClient } from "@supabase/supabase-js";
import { createClient } from "@/lib/supabase/server";
import { aiLimiter } from "@/lib/rate-limit";
import { estimateCost, openaiCost } from "@/lib/ai-cost";

const openai = new OpenAI(); // reads OPENAI_API_KEY on the server
// Service-role client: server only, never in a NEXT_PUBLIC_ variable.
const admin = createAdminClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!,
  { auth: { persistSession: false } },
);

const MODEL = "gpt-5-mini";
const MONTHLY_CAP_USD = 2;
const MAX_OUTPUT_TOKENS = 1_000;

export async function POST(req: Request) {
  // 1. Who is this? getClaims() verifies the JWT.
  const supabase = await createClient();
  const { data: auth } = await supabase.auth.getClaims();
  const userId = auth?.claims.sub;
  if (!userId) return Response.json({ error: "Sign in first" }, { status: 401 });

  // 2. Rate limit per user id, not per IP.
  const rl = await aiLimiter.limit(userId);
  if (!rl.success) {
    const retryAfter = Math.max(1, Math.ceil((rl.reset - Date.now()) / 1000));
    return Response.json(
      { error: "Too many requests" },
      { status: 429, headers: { "Retry-After": String(retryAfter) } },
    );
  }

  const body = (await req.json().catch(() => null)) as { message?: unknown } | null;
  const message = typeof body?.message === "string" ? body.message.slice(0, 4_000) : "";
  if (!message) return Response.json({ error: "message is required" }, { status: 400 });

  // 3. Reserve the worst-case cost against this month's cap.
  const estimate = estimateCost(MODEL, message.length, MAX_OUTPUT_TOKENS);
  const { data: month, error } = await admin.rpc("ai_spend_reserve", {
    p_user: userId, p_cap_usd: MONTHLY_CAP_USD, p_estimate_usd: estimate,
  });
  if (error) return Response.json({ error: "Try again later" }, { status: 503 });
  if (!month) return Response.json({ error: "Monthly AI limit reached" }, { status: 402 });

  // 4. Call the model, then swap the estimate for the real cost.
  let actual = estimate; // if the call fails, keep the estimate (errs high)
  try {
    const r = await openai.responses.create({
      model: MODEL, input: message, max_output_tokens: MAX_OUTPUT_TOKENS,
    });
    if (r.usage) actual = openaiCost(MODEL, r.usage);
    return Response.json({ text: r.output_text });
  } catch {
    return Response.json({ error: "AI call failed" }, { status: 502 });
  } finally {
    await admin.rpc("ai_spend_settle", {
      p_user: userId, p_month: month, p_estimate_usd: estimate, p_actual_usd: actual,
    });
  }
}

The Supabase server client comes from @supabase/ssr, set up as in Supabase's Next.js server-side auth guide. For why the route uses getClaims() and not getSession(), see Supabase getSession vs getUser vs getClaims.

A few choices to adjust for your app:

402 or 429 for the cap. The route returns 402 when the monthly cap is reached, so your UI can show "upgrade" or "resets on the 1st" rather than "slow down". Use 429 if your client already handles that.
Failed calls keep the estimate. If the AI call throws, the user is charged the estimate, because you can't always tell whether the provider billed you. That errs on the high side. Settle at 0 if you'd rather err low.
The estimate is deliberately high. It counts one token per input character, plus the full max_output_tokens, which includes reasoning tokens. A high estimate briefly reserves more than the call will cost, but it keeps parallel requests from overshooting the cap.
Different caps per plan. Read the user's plan before the reserve call and pass a different p_cap_usd value.

What this doesn't cover

These limits help reduce the risk of a surprise bill, but they don't remove it. Things to know:

Streaming. The route above waits for the full response. With stream: true, the final usage arrives at the end of the stream, and a stream that's cut off may never report it. Settle when the stream finishes, and keep the estimate if it doesn't.
Settle can overshoot slightly. If the real cost is higher than the estimate (for example, the price table is out of date), the total can go a little over the cap. The next reserve call is then refused.
Upstash or Supabase being down. As written, a Supabase error returns 503 and blocks the AI call, so the cap fails closed. Upstash is different. From our reading of the @upstash/ratelimit 2.2 source (we haven't tested this live), if Redis doesn't answer within the timeout (5 seconds by default), limit() returns success with reason: "timeout", so the rate limit fails open, though the dollar cap still applies. Check rl.reason if you want it to fail closed.
Other routes. Embeddings, image generation, background jobs and Server Actions that call a model need the same reserve and settle calls. Run the scanner from step 1 over the whole repo.
Keep the provider limit. Set a project spend limit in OpenAI and a workspace limit in Anthropic as well. OpenAI notes that its hard limit isn't instant, but these limits still protect you if your own code has a bug.

Checklist

Every AI route requires a signed-in user before it calls the model.
The rate limit is keyed on the user id, and over the limit it returns 429 with Retry-After.
A monthly dollar cap per user is reserved before the call and settled after it, in one atomic SQL statement.
The spend table has RLS on and no browser grants, and the functions are callable by service_role only.
The price table has a date, and unknown models are refused.
A provider-side spend limit is set as a backstop.

Supabase getSession vs getUser vs getClaims: which auth check to trust in a route like this one.
Supabase service role key exposed: what to do if the key the route uses for the spend functions leaks.

Disclosure: this is our own paid product. Spend Caps Kit ($19 plus VAT where applicable) is copy-paste TypeScript and one Supabase migration for Next.js. It includes per-user rate-limit presets on Upstash or a Postgres counter, a monthly dollar cap per user with a price table for 17 OpenAI and Anthropic models, handling for streams that are cut off, a Stripe checkout refresh-loop guard with webhook dedupe, and a provider-side backstop checklist. It reduces risk but doesn't replace provider-side limits.

Sources (checked 17 October 2026):

Supabase + Stripe Security Checklist

20 checks for AI-built Next.js apps: RLS, service keys, webhook signatures. PDF, free.

Get the free checklist

Free download by email. No marketing emails unless you follow us on Gumroad.

Spend Caps Kit · $19 plus VAT where applicable

Spend Caps Kit

Per-user rate limits and AI spend caps for Next.js + Supabase + Stripe

See what's in Spend Caps Kit

Supabase getSession vs getUser vs getClaims: which to use where

Stack & Ship — Fri, 23 Oct 2026 13:55:54 +0000

Supabase Auth gives you three ways to ask "who is this?" on the server: getSession(), getUser() and getClaims(). They look interchangeable, and in a quick test they all return the same user. They aren't interchangeable. One of them reads whatever the cookie says, one asks the Auth server, and one checks a signature.

This post explains what each method actually does, which to use in a Next.js App Router app, and why the choice matters for security. Supabase behaviour comes from the Supabase docs and the @supabase/auth-js source (supabase-js 2.118.0, @supabase/ssr 0.12.7), checked on 17 October 2026. The code samples type-check with tsc --strict against Next.js 16.4. This site isn't affiliated with Supabase.

The short answer

Protecting a page or reading user data: getClaims().
Before a write, or when you need the current user record: getUser().
When you need the raw access or refresh token: getSession(), but never use its user object to decide who someone is on the server.

Supabase's own summary, from its Next.js guide: "use getClaims to verify identity (typically for protecting pages and data), getUser when you need an up-to-date user record from the Auth server, and getSession when you need the access or refresh token directly, but don't rely on the user object it returns for authorization decisions."

getSession(): reads the cookie, verifies nothing

getSession() returns the session from the client's storage. In the browser, that's local storage or cookies. On the server, with @supabase/ssr, it's the request cookies. The getSession reference says it plainly: it "loads values directly from the storage attached to the client. If that storage is based on request cookies for example, the values in it may not be authentic."

Cookies come from the browser, and anyone can edit their own cookies. So this is unsafe in server code:

// Don't do this: the session comes straight from the cookie.
export async function getUserIdUnsafe() {
  const supabase = await createClient();
  const { data } = await supabase.auth.getSession();
  return data.session?.user.id;
}

The Next.js guide puts it bluntly: "Anyone can forge the session cookie, so trusting it without verification lets an attacker render another user's page." The library warns you too. If you read the user object from a server-side session, auth-js logs a warning that it "may not be authentic" and suggests getUser() instead.

getSession() still has a use: when you need the access token itself, for example to pass to another API. Just don't treat its contents as proof of identity.

getUser(): asks the Auth server every time

getUser() sends the access token to your project's Auth server and gets the user record back. The getUser reference says "the returned value is authentic and can be used to base authorization rules on."

Because the server checks the token on every call, getUser() can notice things a token alone can't tell you. Supabase's docs describe this as an authentic check, so if the user signed out, or you banned or deleted them, the call should fail even if the access token hasn't expired yet. We haven't tested every one of those cases. It also returns the latest user record, such as an email change or updated metadata.

The cost is a network round trip on every call. That's fine before a write. It's wasteful on every page render.

getClaims(): verifies the token's signature

getClaims() gets the access token (from the session, refreshing it if it's close to expiring), then verifies the JWT's signature before returning its claims. How it verifies depends on your project's signing keys.

Asymmetric signing keys (ECC or RSA): the default for new projects, per the Next.js guide. getClaims() fetches your project's public keys from:

/auth/v1/.well-known/jwks.json

It then verifies the signature locally with the WebCrypto API. The getClaims reference notes the JWKS endpoint "is often cached, resulting in significantly faster responses". In the auth-js source, the in-memory key cache lasts 10 minutes (JWKS_TTL). The signing keys guide adds that Supabase's edge also caches the endpoint for 10 minutes.

Symmetric (legacy JWT secret) projects: your server can't verify an HS256 token without the secret. So getClaims() falls back to calling getUser(), the same Auth server request. The source also falls back when the token has no key id or WebCrypto isn't available.

We checked this behaviour against auth-js 2.118.0 with a test key pair and a stubbed fetch:

valid ES256 token  -> claims returned; 1 request (jwks.json)
tampered payload   -> "Invalid JWT signature"; 0 requests
HS256 token        -> falls back to GET /auth/v1/user
expired token      -> "JWT has expired"; 0 requests

A forged or edited token fails locally, without any network call, once the keys are cached.

The trade-off: a valid signature only proves Supabase issued the token. It doesn't prove the session is still active. If a user signs out or is banned, an access token they already hold keeps passing getClaims() until it expires. That's why the guidance is getClaims() for reads and pages, and getUser() where you want the Auth server's answer.

Which one where in a Next.js App Router app

Where	Use
Proxy / middleware	`getClaims()`
Server Component (page)	`getClaims()`
Server Action that writes	`getUser()`
Route Handler that writes	`getUser()`
Need the raw token	`getSession()` (token only)
Browser UI state	either; RLS protects data

Whichever method you use, Row Level Security is still what protects the data. A missing auth check in a Server Action is a bug, but an owner-scoped RLS policy stops it from leaking other users' rows.

Proxy (middleware): refresh the session with getClaims

Server Components can't write cookies, so something has to refresh expired tokens and store the new ones. In current Next.js that's proxy.ts. Next.js 16 renamed middleware.ts to proxy.ts; on Next.js 15 and earlier, keep middleware.ts and name the function middleware. The Supabase code is the same either way. The Next.js guide says the proxy refreshes the token by calling getClaims().

The server client, in lib/supabase/server.ts:

import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();
  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options),
            );
          } catch {
            // Called from a Server Component: the proxy refreshes the session.
          }
        },
      },
    },
  );
}

The session refresh, in lib/supabase/proxy.ts:

import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value),
          );
          supabaseResponse = NextResponse.next({ request });
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options),
          );
        },
      },
    },
  );

  // Don't run code between createServerClient and getClaims().
  const { data } = await supabase.auth.getClaims();
  const claims = data?.claims;

  if (!claims && request.nextUrl.pathname.startsWith("/dashboard")) {
    const url = request.nextUrl.clone();
    url.pathname = "/login";
    return NextResponse.redirect(url);
  }

  // Return supabaseResponse so the refreshed cookies reach the browser.
  return supabaseResponse;
}

And proxy.ts at the project root:

import { type NextRequest } from "next/server";
import { updateSession } from "@/lib/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

Two details from the guide that cause sign-out bugs:

Return the right response. Return the supabaseResponse that setAll last built. An earlier response doesn't carry the refreshed cookies. If you need a different response, copy the cookies (and the cache headers) onto it first.
Refresh in one place. Let the proxy do the refresh, so Server Components don't each try to refresh the same token.

The redirect in the proxy is a convenience, not your only check. Check again in the page or action itself.

Pages: getClaims in Server Components

import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";

export default async function DashboardPage() {
  const supabase = await createClient();
  const { data, error } = await supabase.auth.getClaims();
  if (error || !data?.claims) redirect("/login");

  const userId = data.claims.sub;
  const { data: projects } = await supabase
    .from("projects")
    .select("id, name")
    .eq("user_id", userId);

  return <pre>{JSON.stringify(projects, null, 2)}</pre>;
}

claims.sub is the user's id. The query still runs through RLS with the user's token, so the .eq filter is a convenience, not the security boundary.

Writes: getUser in Server Actions and Route Handlers

"use server";
import { createClient } from "@/lib/supabase/server";

export async function deleteProject(projectId: string) {
  const supabase = await createClient();
  const {
    data: { user },
    error,
  } = await supabase.auth.getUser();
  if (error || !user) throw new Error("Not signed in");

  const { error: dbError } = await supabase
    .from("projects")
    .delete()
    .eq("id", projectId)
    .eq("user_id", user.id);
  if (dbError) throw dbError;
}

One round trip per write buys you the Auth server's answer: a signed-out or banned user should be turned away even if their access token hasn't expired yet. If latency matters more than that window for a particular action, getClaims() is defensible there too. Make it a deliberate choice, not an accident.

Signing keys: check which kind your project uses

Whether getClaims() is fast depends on your signing keys. In the dashboard, check your project's JWT signing keys (see the signing keys guide). If the project still uses the legacy JWT secret, getClaims() works but makes the same Auth server call as getUser(). Migrating to an asymmetric key makes it local.

Per the guide, asymmetric keys also make rotation and revocation easier: public keys are published at the JWKS endpoint, so you don't have to redeploy a shared secret everywhere it's used. Because of the caching described above, plan rotations with the guide's timing in mind rather than expecting instant effect.

A quick checklist

Search your server code for getSession(. Keep it only where you need the raw token.
Proxy refreshes the session with getClaims() and returns supabaseResponse.
Pages and Server Components check getClaims() and redirect when there are no claims.
Server Actions and Route Handlers that write call getUser().
RLS policies scope every user table to (select auth.uid()).
Check whether your project uses asymmetric signing keys.

Supabase RLS policies that pass review but still leak data: the database half of the same problem.
Supabase service role key exposed: why bypassing RLS isn't a fix.
Our free checker (MIT, runs locally) flags getSession() trusted on the server (its A1 check) along with leaked keys, RLS gaps and webhook issues. It's heuristic, so treat it as a first pass.

Disclosure: this is our own paid product. AI Rules v2 is a rules pack for Claude Code. It includes a Supabase server-auth skill that tells your coding agent to use getClaims() for pages, getUser() for writes, and never getSession() for authorisation on the server. Its security-review and ship-check skills check for the same thing. It doesn't replace code review. It costs $19 (plus VAT where applicable). Code DEVTO25 takes 30% off for DEV readers until 28 Oct, 11:00 AM PT: edtrackai.github.io/ai-rules

Sources (checked 17 October 2026):

Supabase RLS policies that pass review but still leak data

Stack & Ship — Fri, 16 Oct 2026 13:52:00 +0000

Row Level Security is switched on. Every table has a policy. The policies mention auth.uid(). A reviewer skims the migration, sees all three, and approves it. And one signed-in user can still read every other user's row.

This post covers two patterns like that. Both came from readers of our earlier article, 7 security bugs AI agents write in Next.js + Supabase + Stripe apps, and both are easy to miss because they look right:

A policy that checks the user is signed in, but not that the row is theirs.
A free-credit grant that treats a new account as a new person, which Gmail dot and plus aliases get around.

All the SQL below was run on a local PostgreSQL 17 database with a stand-in auth.uid() function. Supabase behaviour is quoted from the Supabase RLS docs, checked on 15 October 2026. This site isn't affiliated with Supabase.

The policy that checks you're logged in, not that the row is yours

cekuu35 pointed this out in the comments. Our article suggested sweeping for qual = 'true', and they noted that's only the first pass. Once an agent is told not to write using (true), it tends to write this instead:

create policy "Users can view profiles"
  on public.profiles for select
  to authenticated
  using (auth.uid() is not null);

It reads well. RLS is on, there's a policy, and the policy mentions auth. A qual = 'true' check won't flag it, because the expression isn't literally true.

But look at what it actually tests. auth.uid() is not null is true for every signed-in user, on every row. Nothing ties the row to the person asking. So any logged-in user can query the table with the anon/publishable key and get everyone's email, stripe_customer_id, and whatever else is in the table. One line in the browser console is enough:

await supabase.from('profiles').select('*')

In our local test, a signed-in user with this policy saw 2 of 2 rows, including the other user's.

The policy is only correct when the table really is meant to be readable by every logged-in user, like a public directory. For anything per-user, it's a leak.

Why reviews and linters miss it

The usual checks all pass:

RLS enabled? Yes.
A policy exists for each operation? Yes.
No using (true)? Correct, there isn't one.
Mentions auth.uid()? It does.

None of those ask the question that matters: does the expression compare the row's owner column to the caller? The Supabase docs show the owner-scoped shape for every operation. For select it's:

using ( (select auth.uid()) = user_id )

Insert uses the same comparison in with check. The docs also point out that auth.uid() returns null for unauthenticated requests. That's why a not-null test feels like a security check. It does stop signed-out users, but it stops nobody else.

Find these policies with pg_policies

Postgres exposes every policy in the pg_policies view. qual holds the USING expression and with_check holds the WITH CHECK expression, both as text. This query lists policies in public where either expression doesn't compare auth.uid() to something with =. That catches bare true, auth.uid() is not null, and anything else that never ties the row to the caller:

select schemaname, tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (
       (qual is not null
        and qual !~* 'auth\.uid\(\)[^=]*=|=[^=]*auth\.uid\(\)')
    or (with_check is not null
        and with_check !~* 'auth\.uid\(\)[^=]*=|=[^=]*auth\.uid\(\)')
  );

Run it in the Supabase SQL editor. On our test database, it returned the auth.uid() is not null select policy and a with check (true) insert policy, and 0 rows after the fix below. Postgres stores (select auth.uid()) as ( SELECT auth.uid() AS uid); the pattern allows for that.

Treat the results as a review list, not a verdict. It's a text match, so:

Expected hits: genuinely public tables, and team tables scoped through an exists (...) membership check. Check each one and make sure it's intentional.
What it can't see: an = that compares auth.uid() to the wrong column will pass. So will a policy that joins through an unfiltered table. The regex also passes any expression that contains a comparison somewhere, even when something else makes it broad. Both of these return 0 rows but scope nothing:

using ( auth.uid() is not null or <anything> )
using ( auth.uid() = auth.uid() )

cekuu35's comment includes their own version of the regex and a runnable red/green demo. The extra step we'd add is a two-user test: sign in as user A and try to read and update user B's row. That catches the shapes a pattern match won't.

The fix: scope USING and WITH CHECK to the owner

Replace the not-null test with a comparison against the owner column, one policy per operation the app needs:

drop policy "Users can view profiles" on public.profiles;

create policy "Owners read own profile"
  on public.profiles for select
  to authenticated
  using ( (select auth.uid()) = user_id );

create policy "Owners insert own profile"
  on public.profiles for insert
  to authenticated
  with check ( (select auth.uid()) = user_id );

create policy "Owners update own profile"
  on public.profiles for update
  to authenticated
  using ( (select auth.uid()) = user_id )
  with check ( (select auth.uid()) = user_id );

create policy "Owners delete own profile"
  on public.profiles for delete
  to authenticated
  using ( (select auth.uid()) = user_id );

Leave out the delete policy if users shouldn't delete their own rows; with RLS on, no policy means no deletes.

Some notes from the Supabase docs:

using vs with check: using decides which existing rows a user can see or target. with check decides what a new or updated row is allowed to look like. On updates, you need both: without with check, a user could update their row and set user_id to someone else's. In our test, that reassignment failed with this error, which is what you want:

new row violates row-level security policy for table "profiles"

The (select ...) wrapper: wrapping auth.uid() in (select ...) lets Postgres evaluate it once per statement instead of once per row. It's a performance detail, not a security one, but it costs nothing.
to authenticated: this keeps the anon role out entirely. Signed-out requests then can't match the policy at all.

If you hit that same error on inserts after tightening policies, a common cause is .insert().select() (or an upsert): returning the new row also needs a matching select policy, so keep the select policy alongside the insert one.

Free credits and Gmail aliases: a new account isn't a new person

elijahbrown raised the second pattern in the same thread. Treating "account just created" as proof someone should get free credits doesn't hold up. Anyone can sign up again with jane.doe+2@gmail.com or j.a.n.e.doe@gmail.com and look brand new. Gmail ignores dots in the local part and everything after a +, so all of those reach the same inbox.

This isn't an RLS bug, strictly speaking. It's the same mistake, though: trusting something that looks like identity but isn't. Their suggested fix is to key the credit grant on a normalised email in a separate claims table with a unique index, and only grant the credits when that insert succeeds.

Here's a normalisation function. It lowercases every address. For gmail.com and googlemail.com it also strips dots and any +suffix from the local part, and maps both domains to gmail.com:

create or replace function public.normalize_email(addr text)
returns text
language sql
immutable
strict
as $$
  select case
    when split_part(lower(trim(addr)), '@', 2) in ('gmail.com', 'googlemail.com')
      then replace(split_part(split_part(lower(trim(addr)), '@', 1), '+', 1), '.', '')
           || '@gmail.com'
    else lower(trim(addr))
  end
$$;

It's marked immutable so it can feed a stored generated column; Postgres only allows immutable functions in generated columns. Then the claims table:

create table public.trial_claims (
  id               bigint generated always as identity primary key,
  user_id          uuid unique references auth.users (id) on delete set null,
  email            text not null,
  email_normalized text generated always as (public.normalize_email(email)) stored,
  claimed_at       timestamptz not null default now()
);

create unique index trial_claims_email_normalized_key
  on public.trial_claims (email_normalized);

alter table public.trial_claims enable row level security;
-- No policies for anon/authenticated: only your server code writes here.

There's deliberately no on delete cascade: if deleting an account also deleted its claim, the same inbox could delete, sign up again, and claim a second time. With on delete set null, the claim row (and its normalised email) stays after the account is gone. The unique on user_id also stops one account claiming twice.

Grant credits only when the claim row is actually inserted:

insert into public.trial_claims (user_id, email)
values ($1, $2)
on conflict do nothing
returning user_id;

If the returning comes back empty, someone already claimed with that inbox, or this account already claimed. (on conflict do nothing with no target covers both unique checks.) In our test, Jane.Doe+x@GoogleMail.com and j.a.n.e.doe@gmail.com both normalised to janedoe@gmail.com, and the second claim inserted nothing. Because the unique index does the check, two signups racing each other can't both win.

Run the insert from server code, such as a Route Handler, Server Action, or webhook, using the email from the verified session, not one sent by the browser.

Limits worth being honest about:

Gmail is easy; other domains aren't. Some other providers support plus addressing too, and you could extend the function, but rules vary by provider. Lowercasing everything else is the safe default.
Disposable email domains get past this entirely. Keep the free credit small, or put larger grants behind a verified payment method.
Store the original email too. Use the normalised one only for the uniqueness check, never as the address you send to.

A quick checklist

Run the pg_policies query above and review every row it returns.
Every per-user table: an owner comparison in using on select, update, and delete, and in with check on insert and update.
to authenticated on policies that should never apply to signed-out users.
A two-user test in CI: user A can't read or update user B's row.
Free credits keyed on a normalised email with a unique index, granted only when the insert succeeds.

If you see permission denied for table instead, that's a missing grant, not RLS. Supabase's changelog scheduled a Data API grants change for 30 Oct. In late August a Supabase CLI maintainer wrote (supabase/cli#6337) that the earlier default change "never landed" and hosted projects were still auto-granting, and the CLI dropped its own 30 Oct messaging. So the date may move: check what your own project does. More in our post on the grants change.
Our free checker is MIT-licensed and runs locally. It flags tables without RLS, using (true) / with check (true) write policies, anon write policies, and missing grants in your migration files. It's heuristic and won't catch every policy shape above, so it's a first pass, not proof.

Thanks to cekuu35 and elijahbrown for raising these in the comment thread.

Sources (checked 15 October 2026):

Supabase: Row Level Security
PostgreSQL: pg_policies
PostgreSQL: Generated columns
Dev.to comments by cekuu35 and elijahbrown

Disclosure: we make AI Rules v2 (paid). It is a rules pack for Claude Code that steers the agent towards owner-scoped RLS policies like the ones above. It has 18 skills, 6 subagents, and guardrail hooks with automated tests. It doesn't replace code review or a two-user test. It costs $19 (plus VAT where applicable). Code DEVTO25 takes 30% off for DEV readers until 28 Oct, 11:00 AM PT: edtrackai.github.io/ai-rules

28 launch checks for AI-built Next.js + Supabase + Stripe apps

Stack & Ship — Thu, 15 Oct 2026 08:08:00 +0000

We build Next.js + Supabase + Stripe apps with AI coding agents. The agents are fast, and they make the same handful of mistakes over and over. This is the list we run before anything goes live. It has 28 checks in five groups: keys, auth, row level security, Stripe, and hardening. Each one comes with what to grep for and what the fix looks like.

You don't need any tool for this. Most checks are a search plus five minutes of reading.

1. Keys and secrets (K1–K5)

K1: Live secrets in source (critical). Search for sk_live_, rk_live_, sb_secret_, and service-role JWTs. If you find one, rotate it. Deleting the line doesn't help, because it's still in git history.

git grep -nE 'sk_live_|rk_live_|sb_secret_' $(git rev-list --all) | head

K2: Server secrets in a "use client" file (critical). That covers the admin client, the Stripe SDK, and any secret env var. Anything in a client file ships to every browser.

K3: NEXT_PUBLIC_ on a secret (critical). NEXT_PUBLIC_*SECRET, *SERVICE_ROLE, *PRIVATE and *WEBHOOK* values all get inlined into the client bundle.

K4: .env* files with values tracked by git (high). Commit a .env.example with empty values and nothing else.

K5: A lib/ module that reads a secret without server-only (medium). One accidental client import is enough to leak it.

// lib/stripe.ts
import "server-only";
import Stripe from "stripe";
export const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

2. Auth (A1–A5)

A1: auth.getSession() in server code (high). It reads the cookie without verifying it, so it can be spoofed. On the server, use getUser() (or getClaims()).

const { data: { user } } = await supabase.auth.getUser();
if (!user) redirect("/login");

A2: Server actions that never check the user (high). Every "use server" export is a public POST endpoint, whether or not your UI shows a button for it.

A3: redirect() to an unvalidated query param (high). That's an open redirect, and it lets someone phish through your domain. Allow only same-site relative paths:

export function safeNext(next: string | null) {
  if (!next || !next.startsWith("/") || next.startsWith("//") || next.startsWith("/\\")) return "/";
  return next;
}

A4: The admin (service-role) client outside webhooks, cron, or billing code (high). It bypasses RLS. If user input picks the row, you have an IDOR.

A5: Role or plan read from user_metadata (medium). Users can edit their own metadata. Keep roles and plans in a table that users can't write to.

3. Row level security (R1–R7)

R1: A table in public without RLS (critical). Without it, anyone holding the public key can read and write the table.

create table public.notes (...);
alter table public.notes enable row level security;

R2: using (true) or with check (true) (critical). This means everyone sees or writes every row. Agents love writing it to make an error go away.

R3: Write policies to anon or to public (high). These allow signed-out writes.

R4: Insert or update policies without with check (high). Without it, users can write rows they don't own.

create policy "own notes update" on public.notes
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

R5: A security definer function without set search_path (high). That opens a privilege-escalation path through search_path.

create function public.do_thing() returns void
language plpgsql security definer set search_path = '' as $$ ... $$;

R6: A view without security_invoker = true (medium). By default, views bypass RLS.

R7: auth.uid() not wrapped in (select ...) (low). This one is about performance, not security. Unwrapped, it's evaluated per row, and that hurts on large tables.

A side note on Supabase grants

This isn't one of the 28 checks, but it's worth knowing. Supabase's changelog schedules a change to default Data API grants for 30 Oct (see Supabase CLI PR #6337). If it goes ahead as scheduled, newly created tables may need explicit grant statements before the Data API can reach them. Check your own project's settings and the changelog, and don't assume either way.

4. Stripe (S1–S7)

S1: A webhook without constructEvent (critical). Without it, anyone can POST a fake "paid" event.

S2: request.json() before verification (critical). Parsing the body breaks the signature. Read the raw text instead:

export const runtime = "nodejs"; // S6
export async function POST(req: Request) {
  const body = await req.text();
  const sig = req.headers.get("stripe-signature")!;
  let event;
  try {
    event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch {
    return new Response("bad signature", { status: 400 });
  }
  // ...
}

S3: No idempotency on event ids (high). Stripe retries. Store event.id with a pending or completed status so a retry can't double-grant and a crashed event isn't skipped forever. If you reprocess pending events, the handlers need to be idempotent upserts keyed on Stripe ids, or claimed with an atomic lease. Side effects like emails or credit grants need their own dedupe key.

create table stripe_events (
  id text primary key,
  status text not null check (status in ('pending','completed')),
  created_at timestamptz default now()
);

S4: Price or amount taken from the request (critical). That lets users pick their own price. Look up the price on the server from a key you control.

S5: Access granted on the success page (high). The success page doesn't confirm payment, and it can be replayed. Grant access from the webhook.

S6: A webhook on the edge runtime (medium). The signature code expects Node crypto. Set runtime = "nodejs".

S7: Billing period read from items.data[0] (low). Since API version 2025-03-31.basil, periods live on subscription items. With more than one item, items.data[0] gives you the wrong period or price.

5. Hardening (H1–H4)

H1: Route or action input with no schema validation (medium). It opens you to type confusion and mass assignment.

const Input = z.object({ title: z.string().max(200) });
const parsed = Input.safeParse(await req.json());
if (!parsed.success) return new Response("bad input", { status: 400 });

H2: Raw error.message returned to the client (medium). It leaks SQL, schema, and internal details. Log the error on the server and return a generic message.

H3: No security headers in next.config (low). This leaves you open to clickjacking and MIME sniffing.

async headers() {
  return [{ source: "/(.*)", headers: [
    { key: "X-Frame-Options", value: "DENY" },
    { key: "X-Content-Type-Options", value: "nosniff" },
    { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  ]}];
}

H4: dangerouslySetInnerHTML (medium). If any of that content is user-controlled, it's an XSS hole. Sanitize it or render it as text.

Things grep won't find

Read the code for these:

IDOR: for every route that takes an id, write out the exact request that would read someone else's row.
Admin-client queries where user input picks rows or columns.
Updates and deletes that filter only by id.
Webhooks that identify the user by email alone. Use client_reference_id, metadata set on the server, or your customers table instead.
past_due, canceled, or incomplete statuses that still grant full access.
Public storage buckets you didn't mean to make public.
Unrate-limited custom auth endpoints.
Secrets that get logged.
npm audit --omit=dev.

Then check the dashboards. Make sure the Supabase Security Advisor is clean, the auth redirect URLs point to production, the Stripe live webhook secret is separate from the test one, and backups are on.

Why AI agents keep writing these

Most of these come from the agent fixing the error in front of it. "Permission denied" turns into using (true). A signature error turns into dropping verification. "Not authorized" turns into reaching for the service-role client. Each change makes the error go away, and none of them looks wrong in a diff.

Disclosure: we make AI Rules v2 (paid). It is a rules pack for Claude Code that steers the agent away from these patterns while it writes code. It has 18 skills, 6 subagents, and guardrail hooks with automated tests. It doesn't replace code review or a two-user test. It costs $19 (plus VAT where applicable). Code DEVTO25 takes 30% off for DEV readers until 28 Oct, 11:00 AM PT: edtrackai.github.io/ai-rules

More on our blog: Next.js, Supabase and Stripe fix guides

How to Track MRR and Monthly Profit per Product in Notion (Free Template)

Stack & Ship — Wed, 14 Oct 2026 13:53:38 +0000

If you run more than one product, a single revenue total hides what's actually working. One app might be paying for everything while another quietly costs you £40 a month in hosting, and the combined number looks fine either way.

This guide shows how to calculate MRR and monthly profit per product in Notion using relations, formulas and rollups. Everything here works on Notion's free plan, and every formula is copy-paste ready.

The structure

You need four databases, each linked to a central Products database:

Database	Key properties
Products	Name, Status, rollups (added in step 4)
Revenue	Date, Kind (Recurring / One-off), Gross, VAT, Fees, Product (relation)
Expenses	Date, Amount, Category, Product (relation)
Subscriptions	Cost, Billing (Monthly / Yearly), Status, Next renewal, Product (relation)

Products sits in the middle. Revenue, Expenses and Subscriptions each point at it, and Products pulls their numbers back with rollups:

Revenue        ──┐
Expenses       ──┼──► Products (MRR, revenue, costs, monthly profit)
Subscriptions  ──┘

Step 1: Create Products

One row per product, side project or client. Add a Status select with Idea, Building, Launched and Paused.

That's all for now. The useful columns come from rollups later, once the other databases exist.

Step 2: Revenue with net and MRR formulas

Create the Revenue database with Date, Kind (a select: Recurring / One-off), Gross, VAT and Fees (numbers). Add a Product relation to Products and make it two-way, so Products gets a Revenue column.

Then add these formula properties:

Net = prop("Gross") - prop("VAT") - prop("Fees")

MRR = if(prop("Kind") == "Recurring", prop("Gross") - prop("VAT"), 0)

MRR this month = if(
  formatDate(prop("Date"), "YYYY-MM") == formatDate(today(), "YYYY-MM"),
  prop("MRR"), 0)

Net this month = if(
  formatDate(prop("Date"), "YYYY-MM") == formatDate(today(), "YYYY-MM"),
  prop("Net"), 0)

A few notes on what these do:

Net is what actually lands with you: gross minus VAT minus payment or platform fees.
MRR only counts rows marked Recurring, so one-off sales don't inflate it.
The this month formulas compare the row's year-month with today's. Anything outside the current calendar month returns 0, which is what makes the rollups in step 4 show "this month" without any filtering.

Why exclude VAT from MRR? If you sell through a merchant of record such as Gumroad, Paddle or Lemon Squeezy, the VAT was never yours. Including it inflates your numbers.

Step 3: Expenses and subscriptions

These are two different kinds of cost, so keep them in two databases.

Expenses are one-off spends (a domain, an icon pack, an ad test). Add a Product relation, then a Spend this month formula using the same month comparison as in step 2, applied to Amount:

Spend this month = if(
  formatDate(prop("Date"), "YYYY-MM") == formatDate(today(), "YYYY-MM"),
  prop("Amount"), 0)

Subscriptions are the recurring tools: hosting, AI assistants, analytics, email. Add a Product relation, then normalise everything to a monthly figure:

Cost per month = if(prop("Status") == "Cancelled", 0,
  if(prop("Billing") == "Yearly", round(prop("Cost") / 12 * 100) / 100, prop("Cost")))

Yearly plans get divided by 12 (rounded to two decimals), and cancelled plans count as 0 but stay on record, so you keep the history without it skewing this month's costs.

If your subscriptions list is a mess right now, I wrote a separate walkthrough on auditing indie tool spend that covers finding every subscription and adding a renewal countdown.

Step 4: Roll it up on Products

Back on Products, add four rollups, all set to Sum:

Rollup on Products	Relation	Property
MRR	Revenue	MRR this month
Revenue this month	Revenue	Net this month
Expenses this month	Expenses	Spend this month
Tool costs / month	Subscriptions	Cost per month

Then one formula:

Monthly profit = prop("Revenue this month") - prop("Expenses this month") - prop("Tool costs / month")

Now every product row shows its own MRR, revenue, costs and profit for the current month.

Turn on the column Sum at the bottom of a table view to get business-wide totals, so you get both views: the whole business and each product.

Two views worth adding on Products:

This month: a table showing MRR, Revenue this month, Expenses this month, Tool costs / month and Monthly profit, sorted by Monthly profit.
Losing money: the same table filtered to Monthly profit less than 0. This is the one that changes decisions.

Limitations to know

This setup is genuinely useful, but be honest with yourself about what it isn't:

No currency conversion. Notion adds up numbers as entered. Pick a home currency and convert before entering; keep a Currency tag for reference.
Manual entry. Notion doesn't pull from Stripe or Gumroad natively. Log weekly, or use Zapier/Make.
"This month" is calendar-based. Annual plans paid upfront show as a spike unless you enter them as monthly instalments.
It's tracking, not accounting. Your accountant still needs proper records.

This isn't tax or accounting advice; check what your own situation needs.

Disclosure: I make Solo Founder OS, which has all of the above pre-built alongside tasks, releases and a dashboard. There's also a free Lite version covering projects, tasks and subscriptions with renewal reminders. Originally published on my blog.

7 security bugs AI agents write in Next.js + Supabase + Stripe apps (and the rules that stop them)

Stack & Ship — Wed, 14 Oct 2026 01:54:31 +0000

AI coding agents are great at getting a Next.js + Supabase + Stripe app working. They're much less reliable at getting it safe. The bugs below all pass a quick click-through test, which is exactly why they ship.

Every "fixed" snippet here is taken from a small reference app I built with Next.js 16, @supabase/ssr and the Stripe Node SDK, so you can copy them with some confidence. At the end there's a short rule you can drop into AGENTS.md / .cursor/rules for each one.

1. RLS "enabled" but a policy that protects nothing

Agents love to make an empty query go away by writing this:

-- ❌ passes the "RLS enabled" check, protects nothing
create policy "allow all" on public.subscriptions
  for select using (true);

What you want is ownership scoped to the signed-in user, and no write policy at all for tables only your server should write:

alter table public.subscriptions enable row level security;
create policy "read own subscriptions" on public.subscriptions
  for select to authenticated using ((select auth.uid()) = user_id);

Wrapping auth.uid() in (select ...) lets Postgres evaluate it once per query instead of once per row. Find existing offenders with:

select tablename, policyname from pg_policies where qual = 'true';

Rule: Every table in public has RLS enabled. Never write using (true). If a query returns no rows, fix the policy — never switch keys.

2. "Fixing" an empty result with the service-role key

The second half of bug #1. When RLS correctly returns nothing, agents often swap in the secret/service-role key, which bypasses RLS completely. Keep two clearly named clients and make the dangerous one obvious:

/** Per-request client acting as the signed-in user. RLS applies. */
export async function createUserClient() { /* createServerClient(url, PUBLISHABLE_KEY, { cookies }) */ }

/** Admin client that BYPASSES RLS. Only for trusted server code such as webhooks. */
export function createAdminClient() {
  const e = env();
  return createClient(e.NEXT_PUBLIC_SUPABASE_URL, e.SUPABASE_SECRET_KEY, {
    auth: { persistSession: false, autoRefreshToken: false },
  });
}

Put import "server-only"; at the top of that file so the build fails if a client component ever imports it.

Rule: The admin client is only used in webhook handlers and background jobs, never in code that runs on behalf of a user.

3. Trusting `getSession()` on the server

supabase.auth.getSession() reads the cookie without re-validating it with Supabase Auth. On the server, check the user properly before doing anything that matters:

const supabase = await createUserClient();
const { data: { user } } = await supabase.auth.getUser();
if (!user) return NextResponse.json({ error: "Not signed in" }, { status: 401 });

(getClaims() is also fine if you're on asymmetric JWT signing keys.)

Rule: Server-side authorization uses getUser()/getClaims(), never getSession().

4. Parsing the Stripe webhook body before verifying it

await request.json() re-serialises the payload and the signature check fails. So the agent "fixes" it by deleting the check. Read the raw text instead:

export const runtime = "nodejs";

export async function POST(request: Request) {
  const signature = request.headers.get("stripe-signature");
  if (!signature) return NextResponse.json({ error: "Missing signature" }, { status: 400 });

  // Raw body is required for signature verification. Never parse JSON first.
  const body = await request.text();
  let event: Stripe.Event;
  try {
    event = stripe().webhooks.constructEvent(body, signature, env().STRIPE_WEBHOOK_SECRET);
  } catch {
    return NextResponse.json({ error: "Invalid signature" }, { status: 400 });
  }
  // ...
}

Also exclude the webhook path from any auth middleware/proxy so it isn't redirected to a login page:

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico|api/webhooks).*)"],
};

Rule: Webhook handlers read request.text() and verify the signature before touching the payload.

5. Non-idempotent webhooks

Stripe retries deliveries and can send events more than once. Record each event id with a primary key and bail on duplicates:

create table public.stripe_events (
  id text primary key,
  type text not null,
  received_at timestamptz not null default now()
);
alter table public.stripe_events enable row level security; -- no policies = no client access

const { error: dupError } = await db.from("stripe_events").insert({ id: event.id, type: event.type });
if (dupError?.code === "23505") return NextResponse.json({ received: true, duplicate: true });
if (dupError) return NextResponse.json({ error: "DB error" }, { status: 500 });

Returning 500 on a real DB error matters too: it tells Stripe to retry later instead of silently losing the event.

Rule: Every webhook is idempotent on event.id; use upsert for state.

6. Granting access from the success redirect

/account?checkout=success is just a URL — anyone can visit it. Access must come from the webhook-mirrored subscription status, and the mapping should be explicit:

export function accessFor(status: string | null | undefined): "active" | "grace" | "none" {
  switch (status) {
    case "active":
    case "trialing":
      return "active";
    case "past_due":
      return "grace";
    default:
      return "none";
  }
}

Link the Stripe customer back to your user at checkout creation (client_reference_id: user.id) so the webhook knows whose subscription it is — never take a user id or price from the request body.

Rule: Paid access is derived only from webhook-written rows. Prices come from env/server config, never from the client.

7. Open redirects in auth callbacks

Magic-link and OAuth callbacks usually accept a ?next= param. Agents pass it straight to redirect(), which turns your login into a phishing redirector (?next=//evil.com). Allow only same-origin relative paths:

export function safeNext(next: string | null | undefined, fallback = "/account"): string {
  if (!next || !next.startsWith("/") || next.startsWith("//") || next.startsWith("/\\")) return fallback;
  return next;
}

const next = safeNext(url.searchParams.get("next"));
return NextResponse.redirect(new URL(ok ? next : "/login?error=link-invalid", url.origin));

Rule: Any redirect target from user input goes through safeNext().

Bonus: fail loudly on bad env

A missing STRIPE_WEBHOOK_SECRET shouldn't become undefined at runtime. Validate lazily (so next build still works without secrets) with zod:

const schema = z.object({
  SUPABASE_SECRET_KEY: z.string().min(1),
  STRIPE_SECRET_KEY: z.string().startsWith("sk_"),
  STRIPE_WEBHOOK_SECRET: z.string().startsWith("whsec_"),
  STRIPE_PRICE_ID: z.string().startsWith("price_"),
  // ...
});
let cached: z.infer<typeof schema> | undefined;
export function env() { return (cached ??= schema.parse(process.env)); }

The takeaway

None of these are exotic. They're the predictable shortcuts an agent takes when its only goal is "make the error go away." Writing the rules down where the agent reads them every time (AGENTS.md, CLAUDE.md, .cursor/rules) fixes most of them before they're written.

Disclosure: I made these resources. I turned this into a free 30-point Supabase + Stripe pre-launch security checklist. If you'd rather have the full rule files plus the reference app these snippets come from, it's a $15 pack (25% off with DEVTO25). Either way, I hope the list above saves you a bad launch day — corrections welcome in the comments.

More on our blog: Supabase and Stripe security fixes

DEV Community: Stack & Ship

Cursor usage limits: the weekly pool, legacy plans and when they reset

Quick answer

Two kinds of Cursor plan

Which plan am I on, and where do I check usage?

Hit your usage limit? When it resets

What happens when you run out

What draws from which pool

What you control: model choice, spend caps and always-applied rules

A rule-audit script

What it shows on a real rule set

"Rate limited by model provider" is a different message

If you also use Codex or Claude Code

Related

Stripe Webhook Signature Verification Failed in Next.js

What the error means

Cause 1: the body was parsed before verification

Cause 2: the wrong signing secret

Cause 3: the header or the runtime

Cause 4: timestamp tolerance and clock skew

Never "fix" it by skipping verification

A working Next.js App Router handler

Debug checklist

FAQ

Why does it work with stripe listen but not in production?

Can I verify Stripe webhooks on the Edge runtime?

Do I need a different secret per environment?

Is it safe to log the raw body?

Check the rest of your Stripe setup

Claude 5-hour limit draining fast in T3 Code or the Agent SDK

Claude Code usage limits: how to reduce token usage so they last (Pro and Max)

How Claude Code usage limits work on Pro and Max

What actually uses your limit

See your usage before you hit the wall

A status line that shows your 5-hour and weekly use

/clear vs /compact: when to use which

Match the model and effort to the job

Run the Explore subagent on Haiku

Keep always-loaded context small

Trim test output with a hook

When you do hit the limit

Checklist

Related

Week 2 building in public: 9 merged list PRs, 0 traced visits, $0

OpenAI and Anthropic spend limits per user in Next.js

What the provider limits do, and what they don't

Step 1: find routes with no limit at all

Step 2: a per-user rate limit

Step 3: a monthly dollar cap in Supabase Postgres

Step 4: work out the real cost from usage

Step 5: wire it into the route

What this doesn't cover

Checklist

Related

Supabase + Stripe Security Checklist

Spend Caps Kit

Related posts

Supabase getSession vs getUser vs getClaims: which to use where

The short answer

getSession(): reads the cookie, verifies nothing

getUser(): asks the Auth server every time

getClaims(): verifies the token's signature

Which one where in a Next.js App Router app

Proxy (middleware): refresh the session with getClaims

Pages: getClaims in Server Components

Writes: getUser in Server Actions and Route Handlers

Signing keys: check which kind your project uses

A quick checklist

Related

Supabase RLS policies that pass review but still leak data

The policy that checks you're logged in, not that the row is yours

Why reviews and linters miss it

Find these policies with pg_policies

The fix: scope USING and WITH CHECK to the owner

Free credits and Gmail aliases: a new account isn't a new person

A quick checklist

Related

28 launch checks for AI-built Next.js + Supabase + Stripe apps

1. Keys and secrets (K1–K5)

2. Auth (A1–A5)

Why does it work with `stripe listen` but not in production?

3. Trusting `getSession()` on the server