DEV Community: Dave Kurian

Buy the Arcade kit when the product is a games store

Dave Kurian — Sun, 27 Sep 2026 13:41:20 +0000

If the product you are shipping this quarter is a games store, buy the Arcade kit. The product page is a React Native and Expo template for that job: a five-tab store, hero carousels, an HTML5 game catalog, and a player profile, at $99. Browse, play, a library, and a player profile are the product. This is the SKU that already names those objects.

The other kits you can buy alone today at $99 are the SaaS Dashboard and the Fitness kit. Pricing lists those three as the live kits. Booking remains a preview on the bundle path until it is live. Marketplace is coming soon and is not sold on its own. Waiting on either one leaves the catalog, the library, and the profile unbuilt. If you already need two or more live kits in the same purchase, use pricing and the pack-versus-one-kit post. If the only product is the games store, checkout is the Arcade kit.

Name the product before you open checkout

A games store, for this decision, is a specific object. People open a home, scan a featured row, browse by genre, open a game, play it, keep a library, and return to a profile that remembers them. Search, filters, and wishlists sit on that path. Sign-in exists so the library belongs to someone.

Catalog, play, library, and profile means this SKU. A dashboard product means the SaaS Dashboard. A fitness product means the Fitness kit. All three live kits are $99. The product object is the difference. Booking and Marketplace appear beside them as other cards. Pricing does not sell those two as solo live kits, so they stay off this checkout.

What you already have on day one

The Arcade product page is the inventory. The hero describes one template: React Native and Expo, a five-tab games store, hero carousels, a real HTML5 game catalog, and a player profile.

Discover and play is a dark-first home with a featured hero carousel, genre browsing, full game-detail pages, and instant search. The labels in that block are Home, Store, Browse by Genre, Game Detail, and Search.

The library block is instant-play picks, the player's game library, and a profile with level, coins, and an Arcade Pass state. Its labels are Instant Play, My Library, and Player Profile.

Sign-in is a first-run onboarding flow plus email, Google, and guest, listed as wired. Its labels are Onboarding, Sign In, and Sign Up.

The same page checks off hero carousels, a game store, a real game catalog, game detail pages, category browsing, search and filters, a player library, wishlists, and a player profile.

The storefront on the page is seeded: genre chips for Action, Racing, Puzzle, Arcade, and Sports, a top-this-week list of titles, an Arcade Pass line, and a free-games count. That chrome is the UI. It is not your license count, and it is not a player-count claim.

The stack block names Expo SDK 54, with one codebase for iOS, Android, and a web export; React Native 0.81; TypeScript 5.9; a Hono API; and Postgres with Drizzle, including schema, migrations, and seed data. The page says iOS and Android are tested. An Expo Go preview on SDK 54 opens the live kit with no build step.

Every kit ships with CLAUDE.md, .cursorrules, and 26 tested prompts, aimed at Cursor, Claude, Lovable, and Bolt. That hands the repo to an assistant. You still read the catalog and the profile.

The purchase line is one-time, source on GitHub, demo stays free, kit price $99.

Run this checklist before you pay

This quarter	Checkout
Games store only: browse, play, library, player profile	Arcade kit, $99
Dashboard product only	SaaS Dashboard template
Fitness product only	Fitness kit template
Two or more live kits, or a live kit plus a run of landings	Pricing bundle
Booking or Marketplace as the games-store base	Neither is a solo live kit, and neither is this catalog

Stay on the Arcade row when the rest is also true.

You would otherwise build the catalog, the library, and the profile before launch. You need iOS, Android, and a web export from the Expo SDK 54 codebase the page names. A marketing site on its own belongs with the landing templates. The free SDK versus paid kit post is that fork. Day-one sign-in matches email, Google, or guest. You want the Hono API and the Postgres plus Drizzle setup the page names, including schema, migrations, and seed data. A server or database you have already committed to elsewhere is a port, so price that port before you pay.

Pricing describes each live kit as login, payments, and a database already wired. The Arcade page names email, Google, and guest, plus Postgres. It does not print a payment-provider name in the stack list, so read that surface in the repo you receive.

A second live kit already funded beside the games store moves the decision to pricing and the pack post. This kit is the games-store purchase. The pack is the purchase you make when a second live kit, or a stack of landings, is already on the plan.

The other live kits are different products

Pricing's solo buy row is SaaS Dashboard, Fitness, and Arcade, each at $99.

The SaaS Dashboard template is the dashboard kit. Use it when that dashboard is the product. The Fitness kit template is the fitness product. Both can ship on a phone. A fitness product does not include the Arcade page's genre browse, playable HTML5 catalog, or profile with level, coins, and an Arcade Pass.

The bundle post is where pack versus one kit gets decided. This post stays on the single games-store SKU.

When you do not need this kit

Skip this kit when the product is a SaaS dashboard or a fitness app, and decide on those template pages.

Skip it when you need components and themes, and the critical path has no catalog, library, sign-in, or database. Stay on the free SDK.

Skip the single-SKU button when two or more live kits, or a live kit plus a run of landings, are already planned. The prices that govern the pack are printed on the pricing page.

Skip the wait for a solo Booking or Marketplace buy button. Pricing marks Booking as a preview on the bundle path until it is live, and Marketplace as coming soon and not sold individually. A games catalog is not what those rows describe.

Skip the purchase when you already run a catalog, accounts, and a profile service and only wanted a look at the UI. Open the demo. The kit is source for a store you intend to own.

What you still do after the repo is yours

The storefront is seed data rendered through the Drizzle schema: genres, a ranked list, search, and an Arcade Pass state. Replace that seed with the catalog you have rights to ship. Ratings, play counts, and free-game figures in the demo chrome stay demo figures until they are your numbers.

Level, coins, and Arcade Pass are profile fields you can keep or rename. Coin sources, pass price, and what the demo's "no ads" and "cloud save" lines mean for your titles are still your call. The page shows those words on the pass line. Your economy is a later edit.

Guest sign-in lets someone play before creating an account. You still decide how that session becomes an account and what happens to the library. New fields, wishlist rules, and the entitlement behind Arcade Pass land on the Hono API and the Drizzle schema. CLAUDE.md, .cursorrules, and the 26 prompts describe the repo to an assistant. Game licensing and the store listing stay with you.

The versions printed on the page today are Expo SDK 54, React Native 0.81, and TypeScript 5.9. The Expo Go preview is pinned to SDK 54. Schedule any later upgrade on purpose.

Check the demo, then use this checkout

Open the live demo once at https://arcade-preview.otf-kit.dev and walk home, the carousel, genre browse, a game detail, search, the library, and the profile. When that path is the product, buy it here: Arcade kit, $99. The page states a one-time purchase and source on GitHub.

When the walk-through is a different product, use the checklist. The other live $99 pages are the SaaS Dashboard and the Fitness kit. When you need more than one live kit, the bundle decision stays on the pricing page.

Sources

Arcade kit product page: https://otf-kit.dev/templates/arcade-kit
Arcade demo: https://arcade-preview.otf-kit.dev
Pricing: https://otf-kit.dev/pricing
SaaS Dashboard template: https://otf-kit.dev/templates/saas-dashboard
Fitness kit template: https://otf-kit.dev/templates/fitness-kit
Everything Bundle versus one kit: https://otf-kit.dev/blog/everything-bundle-vs-single-kit
Free SDK versus a paid kit: https://otf-kit.dev/blog/free-sdk-vs-paid-kit-when-to-buy

Re-measure one fixed task before you trust a harness savings claim

Dave Kurian — Sun, 27 Sep 2026 09:41:58 +0000

After a coding-agent harness change ships, a SaaS team should re-measure one fixed task before it books a vendor percentage as its own bill. Keep a short standing file in the repo. Load each skill only when that task needs it. Run the same prompt on the same commit twice, once before the file change and once after, and keep a savings line only when the task still finishes.

On 23 September 2026, Jediah Katz, Connor O'Keefe, and Calvin Yee published Cursor's account of harness work that reduced token costs for Cursor's users by 7% without reducing agent quality. That 7% is their result on their traffic. Your invoice moves when the same task, on your repo, uses fewer tokens and still finishes.

What Cursor changed in the harness

Agents now run longer and carry context from step to step. Each turn resends tools, system instructions, setup, and the conversation, with a stable opening and a growing end. Cursor's production view splits spend into output, uncached input, and cached input. System and tool definitions in that view include compaction summaries. User text includes skills attached by hand. Skills and plugins include skill descriptions, MCP tool descriptions, and rules that sit in static context.

Cursor controls the system prompt on every turn. As models improved, long lists of "do not," "you must," and "important" gave way to a shorter description of how a tool behaves. Cursor trimmed roughly 66% of that system prompt, across model families. They still add and remove lines when a new model needs guidance. They judge those edits with A/B tests on a large user base, because evals often represent hard problems and miss the true mix of requests.

Tool definitions grew with background shell monitoring, cloud subagents, and more reliable web access. Most of those tools matter, and each is needed in fewer than 20% of conversations. Cursor had moved MCP tools into dynamic context earlier, which reduced total tokens by 46.9% on sessions that called an MCP tool. They applied the same pattern to built-in tools and A/B tested which ones stay visible from the first turn, watching tokens, cost, latency, tool-call errors, and agent usage. Reading, searching, editing, and the shell stayed in static context, along with ask_question, because some models invented calls to it, and flow tools such as create_plan in Plan Mode. The rest load when the agent needs them. That offload cut static-context description tokens by 60%.

They then placed cache breakpoints after the stable layers and before the growing conversation. Before GPT-5.6 the cache boundary followed the latest request. Since GPT-5.6 the OpenAI API accepts explicit breakpoints beside its implicit cache. Cursor kept rarely changing tools and system instructions in front of that boundary, and moved skills, subagents, and environment info into a "phantom user message." Those cache changes reduced the rate of cold cache misses by 20%.

The Read tool now numbers every tenth line. One line number uses around three to five tokens, and numbering every tenth line reduced cache-read tokens by 1.6% with no reduction in quality. Cursor also dropped instructions that strongly pushed subagents for codebase exploration, and a subagent switches model only when the user or the harness directs it. Those edits stay in their harness.

Why the 7% stays on their traffic

The 7% is the combined result on Cursor's users, with no reduction in agent quality. The inner figures use other denominators. The 66% is Cursor's system prompt. The 60% is static tool-description tokens after the built-in-tool offload. The 20% is the rate of cold cache misses. The 46.9% is total tokens on sessions that called an MCP tool. The 1.6% is cache-read tokens from the Read tool's line numbers. Keep each figure on its denominator. Your figure is the gap between two finished runs of one task you already ship.

Evals on Cursor's side often represent hard problems and miss everyday requests. A one-off hard task has the same limit, so pick a task from a normal week. Hold the model fixed. Model choice is a separate decision, in how to route a coding agent across models. Hold the effort setting fixed too, as in the effort knob on a coding agent. When the model, the effort setting, or the commit changes between runs, label the pair mixed and rerun with those three held still.

Keep a short standing file

A long standing file rides along on tasks that never use most of it. Keep that file short. Put each skill in its own file and read it only for the matching task. Cursor put skills in the phantom user message so variable setup sat past the cache boundary. The block below is a team file shape. Cursor left the repo layout to the team.

# agent/standing.md
# Short on purpose. Change it in a reviewed diff.
# Keep skill bodies in their own files.

Run the app with the command in the README.
The fixed billing task is: add a usage row for the signed-in workspace and show it on the dashboard.
Tests for that task are the usage tests named in the README.
Edit the usage path and its test. Leave payment webhooks on their current path.
When the task is the usage row, read agent/skills/usage-row.md.
For any other task, leave that skill unread.

A reviewer should read this file in one sitting. Keep project instructions that short. A skill body inside this file makes every later task pay for one task's steps.

Load the skill only for that task

The standing file names the path. The agent reads it for the usage-row task and skips it otherwise. That follows the same idea as Cursor loading a built-in tool when the turn needs it, using files in your repo.

# agent/skills/usage-row.md
# Read this only when the task is the usage row.

Read the workspace id from the session the app already uses.
Write one usage row for that workspace.
Show the row on the dashboard page that already lists usage.
If the workspace id is missing, stop and leave the workspace list unchanged.

Edit the skill in place. The next run that reads the path sees the diff. Point the agent at that path like any other file in the repo. There is no extra service to call. Leave one short rule in the standing file when every task needs it. Move a second skill out when unrelated tasks would carry it.

Measure the same task twice

Use one prompt, one commit, and one model. Start each run in a fresh chat. Record only fields the product shows.

# agent/checks/usage-row-remeasure.txt
# Fill both columns from the product. Leave an unknown cell blank.

prompt: (paste the exact task prompt)
commit:
model:
effort setting, if the product has one:

                before                 after
standing file:  previous copy          short file + skill path
task finished:
input tokens:
cached input:
uncached input:
output tokens:
cost shown:

Completion comes first. A lower token count is a candidate saving only when the after run still finishes. Cursor paired their 7% with no reduction in agent quality. Your check is this task's diff and its test.

Fill token cells from the product. When you only have a monthly invoice, write "not shown" and note the invoice period. A monthly total that mixes other people and other tasks stays a monthly total. Change one thing between the columns: shorten the standing file, or move one skill out of it. When a Cursor update lands in the same window, rerun after it settles, with the file as the only change.

When you don't need this

Skip the files when this repo has no coding agent. The post is still worth reading. The re-measure is for a team about to book a savings line.

Skip the pair while this repo still runs the build from before the harness change. Skip a second pair when someone already recorded two runs of this prompt and the standing file is unchanged. Run again when the next sprint would copy 7% onto a forecast.

Skip the skill split when one short rule serves every task. Leave Cursor's tool list, cache breakpoints, and tenth-line numbering in their harness. The 60%, the 20%, and the 1.6% stay on the denominators in their post.

Commit the standing file, the skill file, and the re-measure note together. Fill the before column from a run you trust. Run the after column in a fresh chat at that commit. Write a savings line only after both runs finish and the token cells come from the product.

Ship the usage surface that task edits from the SaaS dashboard template: https://otf-kit.dev/templates/saas-dashboard

The template is the product shell for that dashboard. You add the standing file and the skill in the repo you already ship.

Sources

https://cursor.com/blog/improved-token-efficiency

Pin a short skill allowlist instead of shopping the registry

Dave Kurian — Sun, 27 Sep 2026 07:45:35 +0000

A SaaS team should pin a short agent-skills allowlist in the repo instead of shopping the public registry every sprint. Amelia Charles, Andrew Qu, and Jonathan Hefner published the report behind that decision on the Vercel blog on 25 September 2026. The useful finding is concentration. Nearly half of all skills on the skills.sh registry were installed exactly once. 375 skills, 0.04% of the registry, account for 62% of installs. The most-installed skill is still under 1% of installs. There is no default skill to buy.

Install figures in that report are aggregate registry counters. They do not represent unique people, and they do not necessarily represent independent choices. A high count can be one script repeating an install. A count of one can be a skill that fit a single setup. Neither count shows that an agent does the job better with the skill than without it. Pin the public skills that match jobs this repo already runs, and write the private rule only your company knows. The report names the shape of that rule: when a customer gets a refund, or what can ship without another review. Those are files you maintain, not rows in the registry.

What the install curve actually says

The top 1.2% of skills account for 94% of installs. Skills installed exactly once sit in what remains.

That concentration is not one winner. Skills compete inside a job and stack across jobs. Once a team has an expense-report skill, it has little reason to install a second one for the same job. It can still add a different skill for spreadsheets, research, or a presentation. Each job has a small winner, and those winners together carry most installs. The allowlist is that set of jobs, written in the repo.

A leaderboard is a poor source for the file. First place can be a job you do not run, and even that skill is under 1% of installs. Catalog totals count unique listings, and the report notes that figures may be revised as the data and the method improve. Treat the percentages as the shape on 25 September 2026. Treat the file as the decision that survives a revision.

Why an install count is a weak buy signal

The report says the best public signal of quality today is install count. It is still a counter, not a test that the job got better. A skill justifies itself only when the agent does the job better with the skill than without it, and the report expects skills to gain tests for that. Until a test exists for the listing you want to add, the count cannot close the review.

Category shares describe a classified sample, not every listing. No category draws more than a fifth of installs. Software engineering is the largest share at 18%, agent workflows follow at 15%, and business operations and writing sit near 11% each. None of those shares names a package.

In that same sample, skills for work shared across industries are 66% of classified skills and 87.5% of installs. They draw 3.6 times as many installs per listing as industry-specific skills. That supports a short list of shared jobs. It does not let a public listing stand in for your refund rule.

Pin the allowlist in the repo

The pin is a file you review. The report does not define a command, an endpoint, or a schema for an allowlist, so this draft does not invent one. One job per block. The registry id stays blank until a reviewer has opened that listing. The date is the merge date. A second block for the same job needs a reason the first skill cannot do the work.

# agent/skills-allowlist.txt
# One public skill per job. Add a block only in a reviewed change.
# Install counts are aggregate counters, not unique people.

job: expense-report
registry-id:
pinned: 2026-09-27
note: one skill for this job

job: spreadsheet-cleanup
registry-id:
pinned: 2026-09-27
note: tidy an export before a person reads it

Those job names follow the report's examples. They are not packages it ranked. A blank registry-id is not approved for install. Fill it in the same change that reviewed the listing. Do not paste an id from a leaderboard nobody opened.

The pull request should name the weekly job, say why the current block is not enough if one exists, and say what a later review will re-check. If it cannot name a job in this repo, it does not merge. The next sprint reads the file. It does not browse the registry.

Delete a block unused for a month. On sprint day, a filled id does not get a replacement search. A blank id gets one reviewed listing, or the job is marked private. A new job starts as a blank block. The install happens after the merge.

Write the private rule next to the list

The report says public skills will turn general know-how into the baseline. More of what sets a company apart will then sit in judgment only that company has. The examples it names are when a customer gets a refund, and what can ship without another review. Write them in ordinary language: the steps, what good looks like, and when to stop. The report describes a skill as a file of that kind. The registry cannot rank yours, because it does not know your window or which paths touch billing.

The numbers below are a shape, not thresholds from the report, and not a default for every team. Replace each one with the rule a person on your team already follows.

# agent/skills/company-rules.md

When a refund is allowed

Read the charge on the current workspace only.
Allow the refund only when every line is true:
- The charge posted within 14 days.
- This workspace has no refund recorded in the current quarter.
- The caller is an owner of this workspace.
If any line is false, stop. Write the failed line on the ticket and leave the charge.

What can ship without another review

A change may ship with no extra reviewer only when every line is true:
- It does not change a price, a limit, or who can sign in.
- It touches no migration and no billing file.
- The diff is at most 40 lines.
If any line is false, open a review and stop. Do not merge.

Change the rule by editing the file. A window that moves from 14 days to 7 days is a diff, and the agent sees it the next time it reads the path. Point the agent at that file the same way you point it at any other instruction file in the repo. There is no extra service to call.

Keep three cases beside the file: a refund that meets every line, a refund that fails one line, and a diff that must wait. Re-run them when the file changes. That check stays private. It is not a registry count. Once a public skill is on the allowlist, measure whether that skill does the job before you add another beside it.

When the catalog is already finite

Some tools ship a small catalog for their own surface. Installing it once is a closed list. Install that catalog and record those jobs as blocks whose note names the vendor catalog as the source, so the next sprint does not add a second public skill for a covered job.

Do not paste that catalog into the private rule. It knows the tool. It does not know when your company refunds a charge. If a job still has a blank registry id, review one listing or keep the job private.

When you don't need this

Skip the allowlist when no agent runs against this repo. The concentration in the report matters when someone is about to install a skill.

Skip it when one person installs skills and already keeps that list in a note they open. The pin matters when the next person, or the next sprint, would shop again and treat a fresh count as a reason to switch.

Skip the refund lines and the ship lines when a person still makes every call and the agent is not allowed to take them. Write the file when the agent is about to act.

Skip a second public skill for a job that already has a block. Add a block for a new job instead. You also do not need the file merely to read the report.

Put both files in one reviewed change. The list records which public skills are allowed. The rule records what only your company knows. Commit them in the SaaS repo you already ship. The SaaS dashboard template is here: https://otf-kit.dev/templates/saas-dashboard

Sources

Delete one tenant's files without scanning a shared Blob store

Dave Kurian — Sat, 26 Sep 2026 15:45:30 +0000

A multi-tenant app on Vercel can keep every customer's files in one Blob store under a pathname prefix, or give each customer a store. On 23 September 2026 Vercel removed the caps of 100 stores on Hobby, 500 on Pro, and 1,000 on Enterprise. One store per tenant is worth the create when export and delete must be a credential boundary. A mistaken pathname then cannot read or delete another tenant, because that credential does not open the other store. A prefix is still the right layout when your server builds every pathname from the authenticated tenant id and deletes from URLs saved on that tenant's rows.

Creating a store is one Blob Advanced Operation, the same class as put(), copy(), and list(). On Pro that class is $5.00 per million. On Hobby it counts toward the 2,000 advanced operations included each month. Deleting a store is free. Storage, operations, and data transfer for the same bytes cost the same in one store or in many. The create buys a unit you can hand to a job, wipe, or destroy. It does not buy a cheaper disk.

What still bills when stores are unlimited

Storage size, simple operations, advanced operations, and data transfer still bill on use. Storage is the monthly average size. A simple operation is a cache-miss read by URL, or head(). An advanced operation is put(), copy(), list(), or a store create. Data transfer bills when a blob is downloaded. Every URL access is also an edge request, and a cache miss adds fast origin transfer. A blob larger than 512 MB is never cached, so every read of it is a miss.

del() is free of charge. A batched del([urls]) still counts each blob toward the rate limit, so 100 pathnames are 100 operations against that limit, not one HTTP call. Hobby allows 1,200 simple and 900 advanced operations per minute. Pro allows 7,200 and 4,500. Dashboard browsing and uploads count as advanced operations too.

Hobby includes 1 GB of storage, the first 10,000 simple operations, the first 2,000 advanced operations, and the first 10 GB of transfer each month. Past that, Blob access stops and the overage is not billed. Extra stores do not raise the 1 GB ceiling. About 2,000 creates in a month, with no put() or list() beside them, spend the Hobby advanced allowance on empty stores.

Private and public stores share storage and operation prices. A private file is read by your server, then streamed to the caller, so both hops bill. A public URL is fetched by the client. Tenant documents belong in a private store. Access mode and region are fixed at create time. The CLI uses iad1 when you omit --region.

When a pathname prefix is enough

One store, one credential. On Vercel the SDK pairs a short-lived OIDC token with one BLOB_STORE_ID and refreshes that token. Outside Vercel, or for a signed browser upload, the credential is BLOB_READ_WRITE_TOKEN. An explicit token argument always beats OIDC.

import { del, list, put } from '@vercel/blob';

export async function putTenantFile(tenantId: string, name: string, body: Blob) {
  return put(`tenants/${tenantId}/${name}`, body, {
    access: 'private',
    addRandomSuffix: true,
  });
}

export async function deleteTenantPrefix(tenantId: string) {
  const prefix = `tenants/${tenantId}/`;
  let cursor: string | undefined;

  do {
    const page = await list({ prefix, cursor, limit: 1000 });
    if (page.blobs.length > 0) {
      await del(page.blobs.map((blob) => blob.url));
    }
    cursor = page.hasMore ? page.cursor : undefined;
  } while (cursor);
}

addRandomSuffix defaults to false. Turn it on so two uploads of the same name do not collide, then delete the URL put() returned. Each list() page is one advanced operation. The default page size is 1,000. del() does not throw if the URL is already gone, so a bad delete can look finished. Removed objects can stay on the CDN for up to a minute. Objects your rows forgot stay until a later list sees them.

Keep the prefix when your server is the only writer, you never hand the credential to a tenant or another service, and tenants are small enough that the sweep is a few list() calls. A leaked server credential that already exposes the rest of the account is not fixed by a second store. A public store fails even with a perfect prefix: anyone with the URL can read the file.

When a store per tenant is worth the create

Create a user-created store when the unit you export, revoke, or destroy is the tenant. POST https://api.vercel.com/storage/stores/blob takes name (required, at most 70 characters), access (private or public, default public), and an optional region. Set access to private. That POST is one advanced operation. vercel blob create-store <name> --access private is the same create.

The published 200 schema for that POST lists access, region, kind, size, and project metadata. It does not list an id, so do not invent body.store.id. Match the name you sent with vercel blob list-stores --all, save that id on the tenant row, and pass it as storeId. Leave the project's single BLOB_STORE_ID on the production store. Pointing it at a tenant store moves production traffic.

import { put } from '@vercel/blob';

export async function putInTenantStore(storeId: string, name: string, body: Blob) {
  return put(name, body, {
    access: 'private',
    addRandomSuffix: true,
    storeId,
  });
}

export async function deleteTenantStore(storeId: string, platformToken: string) {
  const response = await fetch(
    `https://api.vercel.com/storage/stores/blob/${encodeURIComponent(storeId)}`,
    {
      method: 'DELETE',
      headers: { Authorization: `Bearer ${platformToken}` },
    },
  );
  if (!response.ok) {
    throw new Error(`Blob store delete failed: ${response.status}`);
  }
  const body = (await response.json()) as { id: string };
  return body.id;
}

Pass storeId as store_<id> or <id>. Leave VERCEL_OIDC_TOKEN in the environment. Copying it into oidcToken skips refresh, and later calls fail with 403. A read-write token is the override for a job outside Vercel, and it opens only that store.

Read the tenant row before you POST. A retry opens a second store and bills another advanced operation. An owned API stores the first success and replays it. The first create is the one you keep.

The platform token that may create and delete stores can destroy every tenant store. Keep it off the customer request path. Rotate that secret with dual-key overlap. A project-default store is a different object: private, lazy, OIDC, and the mutation APIs do not manage it. Delete only a user-created store.

Export is still list() with no prefix, then get() or the download URL. There is no export-store call. This storeId cannot return the next tenant. Listing a large tenant still costs one advanced operation per thousand objects. Delete can skip that list.

vercel blob empty-store <store-id> deletes every blob and keeps the store id. vercel blob delete-store <store-id> removes the store. Both take --yes in a script. Empty the store when the tenant stays. Delete it when the tenant is gone. Store deletion is free.

Split production, staging, and preview

Production, staging, and shared preview are three stores. Three advanced operations, once, stop a preview write from landing on production objects. Make that split even when every production tenant shares one store.

One preview store still mixes branches. Every deployment that shares BLOB_STORE_ID can list the others. For a disposable branch, create a store, pass that storeId only into that deployment, and DELETE /storage/stores/blob/{id} when the branch closes. The delete is free. Bytes the preview wrote still bill until then. Do not point preview at the production store id to skip the create.

When you don't need this

Skip a store per tenant for a single customer, or for public assets. Skip it when every blob URL already sits on the tenant row: offboarding is del() of that list, and production still stays off the preview store. Skip it on Hobby if signups would create thousands of stores. About 2,000 creates consume the monthly advanced allowance. Stay on one private store and a server-built prefix until the plan can absorb them.

Sweep a prefix as a paced job, not a tight loop. Refuse that burst before it melts the rate limit. Each list() page is an advanced operation, and each URL in a batched del() counts toward the rate limit.

OTF kits do not ship a per-tenant Blob layout yet. The owned upload path starts from the templates at https://otf-kit.dev/templates.

Sources

Write the outbox row in the same Postgres transaction as the business row

Dave Kurian — Fri, 25 Sep 2026 09:34:21 +0000

A welcome email, a webhook fan-out, and a search-index update are the same problem. The route has decided the business row. Another system still has to hear about it. Commit the user, then publish to the broker, and a broker that is down, or a process that dies, leaves a row with no event.

That gap is a dual write. The database committed. The queue did not. Retrying the HTTP request can insert a second user, and it still may not send the first email. An owned API stores idempotency keys in Postgres and replays the first response. That row remembers the HTTP result. It does not publish an event you never wrote down.

Write the outbox row in the same Postgres transaction as the business row. Commit both, or roll both back. A relay reads unpublished rows after commit and publishes them. The request does not talk to the broker. This is the transactional outbox. The route is a Next.js handler. The database is Supabase Postgres.

The loss is the gap after commit

Two writes that are not one transaction can succeed in either order, or only one of them.

Publish first, then commit. The broker has the event and the transaction rolls back. Consumers act on a user who does not exist.

Commit first, then publish. The user exists. The publish throws, times out, or never runs because the process was killed after commit. The client may already have a 201. Nothing in the database says the email is still owed.

Holding the transaction open while you call the broker pins a session on the network. A broker error then rolls back a signup you were ready to keep. Do that only when you would rather fail the request.

The outbox is the other choice. The business write must stick even if the broker is down, and the event must still leave later.

Write the event in the same transaction

The handler builds one unit of work: insert or update the business row, insert the outbox row, commit. supabase-js sends each statement as its own request. Those calls do not share a transaction. Put both writes in one Postgres function and call that function once, or use a client that holds a single transaction. If either insert fails, neither remains.

Copy into payload what the consumer must see as of this commit. A later update can change the user before the relay runs. A snapshot of the address belongs in the row. An event that means "read the user now" should say so in the type. Mixing the two indexes the wrong version.

One event of a given type per aggregate gets a unique pair. A signup emits one user.created for that user. A retried transaction hits the unique constraint and does not queue a second welcome. A stream of many events, such as every order change, uses its own id and does not use that pair.

The outbox table

published_at null means the relay still owes the broker this row. claimed_at is a lease, not a receipt. attempts counts how many times a relay has taken the row.

create table outbox (
  id uuid primary key,
  aggregate_type text not null,
  aggregate_id uuid not null,
  event_type text not null,
  payload jsonb not null,
  created_at timestamptz not null default now(),
  published_at timestamptz,
  claimed_at timestamptz,
  attempts integer not null default 0,
  unique (aggregate_id, event_type)
);

create index outbox_unpublished_idx
  on outbox (created_at)
  where published_at is null;

id is the event id the consumer will dedupe. Generate it in the route and store the same value in payload. The partial index is the relay's queue. Published rows stay out of that index.

The unique pair is the signup case. Drop it when the same event type can fire more than once, and keep id as the primary key.

Poll with a claim, wake with notify

The relay is a process that stays up. A Next.js route returns. It should not sit on LISTEN. LISTEN needs a session that stays open. The durable record is the table. NOTIFY only wakes a relay that is already listening. In the default configuration the payload must be shorter than 8000 bytes, so it cannot carry the event. A notify sent while the relay is down is gone. The next poll still sees published_at is null.

Claim a batch with FOR UPDATE SKIP LOCKED so two relays do not take the same row. The lease lets a crashed claim be taken again. Thirty seconds in the sketch is a lease you choose, not a measured optimum. Set published_at after the broker accepts the message. A relay that dies after publish and before that update will publish again. That is at least once.

with due as (
  select id
  from outbox
  where published_at is null
    and (claimed_at is null or claimed_at < now() - interval '30 seconds')
  order by created_at
  for update skip locked
  limit 20
)
update outbox as o
set claimed_at = now(),
    attempts = o.attempts + 1
from due
where o.id = due.id
returning o.id, o.event_type, o.payload, o.attempts;

Polling on a timer is enough when a short delay is fine. NOTIFY from the function that inserts the row, using the event id and not the body, shortens the wait when a listener is up. It does not replace the poll. A relay that only listens loses every event emitted while it was restarting.

At least once, then the consumer

The broker and the consumer will see duplicates. Publish, crash, lease expires, publish again. The handler must treat id as already done once it has run. Store that id the way an owned API stores an idempotency key and replays the first response. Record id before the mailer call, or the second delivery sends a second email. How you hash a request body, and how long you keep the key, belong on that post.

Do not set published_at before the broker accepts the message. If the update that sets it fails, the duplicate is the consumer's problem. That is why the id was in the message.

This table does not order events across aggregates. One relay can publish a single aggregate in created_at order. Two relays, or parallel handlers, will not. If user.updated must follow user.created, the consumer serializes on aggregate_id.

When the relay keeps failing

A payload the broker rejects, or a bug in the publisher, increments attempts forever if every failure only drops the lease. Cap the attempts. Past the cap, stop selecting the row.

Parking it, with the reason and enough of the payload to replay, is a dead-letter decision. Park failed jobs in a DLQ with the reason, the snapshot, and a replay. This post does not build that queue. The outbox's job ends when a person, or a replay tool, can see the event that did not leave.

The relay is a loop and a publish. Background jobs for AI features covers queues and retries for that worker. Use the outbox when you must not lose the fact that the business row committed. Use an ordinary job when the caller may fail the request instead of owing an event.

When a sync enqueue is enough

Skip the outbox when there is no second system. A column update that nothing else consumes is one write. An outbox row would publish a message nobody reads.

Skip it when you would rather fail the signup than accept a user with no event. Publish to the broker before commit. If that call fails, roll back and return an error. The client retries the whole command. You still need the idempotency key so the retry is not a second user, and a broker outage is an outage of the route. That trade is right when the event is part of success, not a follow-up you can owe.

Skip it when a miss is repaired without a queue. A search index that rebuilds from the table, or a welcome email the user resends from a button, does not need a durable event. The outbox is for an event you cannot rebuild, or cannot afford to miss until someone notices.

A publish after commit, with no outbox row, is the dual write again. It is enough only where a miss is repaired by retrying the request, by a rebuild, or by a button. It is not enough for a 201 returned while the broker was down.

OTF kits do not ship an outbox table or a relay yet. The route you own still commits the business row and the event in one transaction, and a process that stays up still publishes what that transaction left behind.

Sources

An owned API stores idempotency keys in Postgres and replays the first response

Dave Kurian — Fri, 25 Sep 2026 07:50:11 +0000

A retry, a double-click, and a webhook redelivery are the same failure when the handler charges or inserts. The second attempt has to come back with the first result: a key, a row in Postgres, and a rule for the request that is still running.

The stack is a Next.js route handler in front of Supabase Postgres. The guarantee is a unique constraint and INSERT ... ON CONFLICT, not a map in the process. Two colors of a deploy share one database. A key held in memory splits when the retry lands on the other color. A drain that ends the process does the same once that handler is gone.

Which writes need a key

RFC 9110 treats GET, HEAD, PUT, DELETE, OPTIONS, and TRACE as idempotent. POST and PATCH are not. Put a key on a call that can charge, book, grant, send, or insert a row the caller would notice twice: create-order, capture-payment, grant-credit, send-invoice, or a webhook with a side effect.

A read can run twice, and so can a PUT that replaces a resource with a full representation. The command that appends needs a record of the first attempt. A circuit breaker stops the process waiting on a vendor that is already failing. It does not remember that the write succeeded. The idempotency row does.

Where the key lives

The caller sends Idempotency-Key when this click is the same attempt. The same SKU and address, five minutes apart, can be a second purchase. Mint the UUID once per button press.

Stripe's API takes that header on POST, suggests a v4 UUID or another high-entropy string, caps the value at 255 characters, and tells you to keep personal identifiers out of the key. The HTTPAPI Idempotency-Key draft (draft-07, October 2025) asks for the same uniqueness. It is an Internet-Draft, not an RFC, and the datatracker entry lists that revision expired. Copy the behavior. Publish your own retention window. The draft leaves expiry to the resource.

Verify the webhook signature, then use the id on the verified event. A header the sender can change is a new attempt. Scope a derived id to the endpoint or connected account, and a client key to the session owner. The unique pair is (owner_id, idempotency_key). The draft's security notes want the session owner in that pair, so a short key cannot read another caller's stored response.

A missing key is HTTP 400 on a route that requires the header.

How long you keep the row

Stripe removes idempotency keys after they are at least 24 hours old. A phone that queues an order for several days needs a longer window. Publish that window next to the header name. After expires_at, the same key is a new operation.

Delete expired rows. Index expires_at so the delete is not a sequential scan. The stored body can hold a name, an address, or a client secret, and past the published window it is not a debugging archive. Recover a crashed charge only while Stripe still remembers the outbound key.

What you store with the key

Store the scoped key, a request hash, a state, the response status, the response body, and expires_at. Hash method, path, and the fields that define the operation, in a fixed order. The draft allows a checksum of the payload or of selected fields. JSON.stringify of a parsed object, with no stable key order, answers 422 when a retry only reorders fields. Include the path, or a key for POST /api/orders can replay against POST /api/refunds.

Stripe saves the status and body of the first execution that started, including a 500. Validation failures and in-flight conflicts are not saved. Validate before you claim the key, so a 400 leaves it free. Once the row exists, a different hash is 422 and the second body does not run. Store a failure after an insert or a charge, or the retry repeats that side effect.

Concurrent duplicates

INSERT ... ON CONFLICT DO NOTHING is the claim. Unique constraints and ON CONFLICT close the select-then-insert race.

A double-click does not retry a 409, so the loser waits on SELECT ... FOR UPDATE. The row lock holds until the winner commits, then the loser returns the stored status and body. The route timeout caps that wait. A client that retries non-success can take 409 while the first request runs. Stripe saves nothing for that conflict. If the locked read finds no row, the winner rolled back. Return 409.

Return non-2xx until a webhook stores success, then return the stored 2xx. A 409 after success keeps that vendor going. Commit in_progress before the charge, call Stripe with the same key or a fixed derivative, and write the response in a second transaction. A new Stripe key on the crash retry is a second charge. The handler below commits the claim, the order, and the 201 in one transaction.

The table and the route

owner_id is the session user, or the endpoint or account for a derived id. response_status stays null until the handler finishes. supabase-js runs each statement alone, so the claim and the insert share one Postgres transaction, or one SQL function called with RPC. requireUser, parseOrder, sha256Hex, insertOrder, and withTransaction belong to the route.

create table idempotency_keys (
  owner_id uuid not null,
  idempotency_key text not null,
  request_hash text not null,
  state text not null check (state in ('in_progress', 'completed')),
  response_status integer,
  response_body jsonb,
  created_at timestamptz not null default now(),
  expires_at timestamptz not null,
  primary key (owner_id, idempotency_key)
);

create index idempotency_keys_expires_at_idx
  on idempotency_keys (expires_at);

export async function POST(request: Request) {
  const ownerId = await requireUser(request);
  const key = request.headers.get("idempotency-key")?.trim() ?? "";
  if (key.length === 0 || key.length > 255) {
    return Response.json({ error: "invalid_idempotency_key" }, { status: 400 });
  }

  let payload: unknown;
  try {
    payload = await request.json();
  } catch {
    return Response.json({ error: "invalid_json" }, { status: 400 });
  }
  const order = parseOrder(payload);
  if (!order.ok) {
    return Response.json({ error: order.error }, { status: 400 });
  }

  const requestHash = await sha256Hex(
    JSON.stringify({ method: "POST", path: "/api/orders", order: order.value }),
  );

  const outcome = await withTransaction(async (tx) => {
    await tx.query(
      `delete from idempotency_keys
        where owner_id = $1 and idempotency_key = $2 and expires_at <= now()`,
      [ownerId, key],
    );
    const claimed = await tx.query(
      `insert into idempotency_keys
         (owner_id, idempotency_key, request_hash, state, expires_at)
       values ($1, $2, $3, 'in_progress', now() + interval '24 hours')
       on conflict (owner_id, idempotency_key) do nothing
       returning owner_id`,
      [ownerId, key, requestHash],
    );
    if (claimed.rows.length === 0) {
      const found = await tx.query(
        `select request_hash, state, response_status, response_body
           from idempotency_keys
          where owner_id = $1 and idempotency_key = $2
          for update`,
        [ownerId, key],
      );
      const row = found.rows[0];
      if (!row) return { kind: "retry" as const };
      if (row.request_hash !== requestHash) return { kind: "mismatch" as const };
      if (row.state !== "completed") return { kind: "in_progress" as const };
      return {
        kind: "replay" as const,
        status: row.response_status as number,
        body: row.response_body,
      };
    }
    const created = await insertOrder(tx, ownerId, order.value);
    const body = { id: created.id };
    await tx.query(
      `update idempotency_keys
          set state = 'completed', response_status = 201, response_body = $3::jsonb
        where owner_id = $1 and idempotency_key = $2`,
      [ownerId, key, JSON.stringify(body)],
    );
    return { kind: "created" as const, status: 201, body };
  });

  if (outcome.kind === "mismatch") {
    return Response.json({ error: "idempotency_key_reused" }, { status: 422 });
  }
  if (outcome.kind === "retry" || outcome.kind === "in_progress") {
    return Response.json({ error: "idempotency_in_progress" }, { status: 409 });
  }
  return Response.json(outcome.body, { status: outcome.status });
}

parseOrder keeps a stable field order. The delete removes only an expired row. In this shape, for update sees the winner's committed completed row.

When you don't need this

A GET does not need a key. A PUT of the representation the client already holds does not need one. A DELETE by primary key is finished when the row is absent. Add a key on delete only when the retry must receive the original body.

A unique email, an overlapping booking, or one ledger line per natural id can already reject the second write. Add this table when the retry must receive the original response, or when the same body is allowed twice and only the attempt id tells them apart. Leave page views, beacons, and intentional counters unkeyed.

The kits do not ship an idempotency-key layer, so on an API you own this table is the piece you add where a retry can charge or create twice.

Sources

When to cut traffic to a warm standby instead of a rolling replace

Dave Kurian — Fri, 25 Sep 2026 05:31:12 +0000

Rolling deploys are the default on an owned backend: one fleet, old and new serving together until the old instances are gone. Blue-green is the other move. A second stack stays warm, and you cut traffic to it in one switch.

The choice is whether the two builds can share a request path, how fast you must leave a bad build, and whether the last good state still exists after the new code has written data. A second full stack idles until the cut. Idle memory is a bill you take on purpose.

Surge, unavailability, and instance order belong to the rolling deploys piece. This post decides when you stop mixing versions and move a load balancer, a Service selector, or a weighted route.

Cut when versions must not share a request path

A mixed fleet is safe only while a request can land on either version and finish correctly.

A wire change breaks that. The new process speaks a shape the old one rejects: a required field, a renamed header, a content type, an RPC the old binary does not register. Callers split across the two shapes. A retry draws the same mix. Failures follow the ratio.

A schema the old process rejects fails the same way in stored data. Green writes a column, an enum, or a payload blue cannot read. Traffic left on blue errors, including reads of rows green already wrote.

The write path is stricter. When every peer must already speak the new contract — a lock format, an outbox event, a cache key — the mixed fleet splits writes. Soak green on real dependencies with user traffic held off: same database, same queues, same downstreams. Move the balancer or Service selector once, and green becomes the only version taking production requests.

Rollback is that switch in reverse. It works while blue is up and can still serve the data that now exists. Keep blue warm until you trust the cut.

Cut when time-to-rollback matters more than spare capacity

A gradual replace unwinds through startup, readiness, and the surge budget. That wait fits a slow failure: latency on a slice, an error rate that climbs with the mix. It fits an immediate failure poorly. A bad config, an auth check that rejects every token, or a startup path that corrupts a shared cache should be left before the next health interval.

A flip moves a selector or a weight from 100/0 to 0/100. The bill is two full stacks, both ready, for as long as the old color stays. On a small service the second Deployment is cheap beside the time you get back. On a memory-heavy tier the idle half is the decision. The same heap doubles resident memory until blue scales down.

A ramp, small weight then larger, stays gradual. Use it when versions coexist and the blast radius should stay limited. Blue-green here means the full cut onto a stack that was already warm.

Stay gradual when a flip would not restore the last good state

Two colors, one database. Drop a column, rewrite data, or change what a field means, and blue cannot read what green wrote. The selector can point at blue again. Blue then fails on current rows. Sequence the schema as expand, deploy, contract. Expand keeps the old shape valid for every process still running. Deploy writes both shapes, or writes the new one so old code ignores it. Contract removes the old shape only after nothing that might still run depends on it. The standby hands you the previous binary, which has to read the rows green left behind.

Call green warm only once real requests can succeed. Pools are open. Hot-path caches are filled, or misses are priced and the downstream is sized. A shadow load has run that path against production dependencies, users still on blue. A readiness route that returns 200 before any real query will take the herd. Readiness is the ability to do the work. A first wave that opens pools and times out downstreams survives one probe, then falls over.

Graceful shutdown and drain still apply on the way out. In-flight work on blue continues after the selector moves. Drain it. New requests go to green. Old ones finish, or hit their deadline, on blue. Scale blue down after the drain, once you are finished with the reverse switch.

Stay gradual when versions can share the path

Stay on a rolling replace when the versions can coexist. A parser, a timeout, a log field, a query that returns the same rows: one contract, and a retry may land on either build. This change ships on the fleet you already have.

Stay there when the copy will not fit. A cache sized to the host, a heap tuned to the box, or one GPU means the overlap is another tier. Rolling spends the surge already configured, a slice of the same fleet.

Stay there when the fault should hit a slice. A slower query or a higher error rate shows while most instances still run the old build. Stopping the replace leaves most callers on the last good build. A full cut reports the same bug after every caller has moved. Prefer the fast reverse across all traffic, or the slower slice with most of the fleet still on the old build.

A slice can still stampede a cache, storm a lock, or retry into a downstream. Circuit breakers cap the amplification while you halt. Whether the two versions can share a path stays a separate decision.

	Blue-green cutover	Rolling gradual replace
Traffic	One switch of all new requests onto a warm stack	Batches, with old and new serving together
Capacity	Two full stacks for the overlap	One fleet, within maxUnavailable and maxSurge
Fits when	A shared path would fail, or rollback must beat the next health interval	Coexistence is safe, spare capacity is a slice, or the fault should stay small
Rollback	Reverse the selector or weight while the previous color is up and can read current data	Stop the replace; the wait is startup and readiness
Data	The flip leaves migrations and other writes where they are	Mixed versions split writes when the contract has changed
You operate	Two Deployments, a selector or ingress weight, then a drain	One Deployment; the controller walks the replace

The flip puts one version on the request path. The batch replace stays mixed until the old instances are gone.

What you move, and what stays up

Kubernetes Deployments perform the gradual replace with maxUnavailable and maxSurge on one Deployment. The cut is two Deployments and a selector or ingress weight you move once green is warm. Warm means pools open, caches filled or misses priced, a shadow load finished, and readiness held closed until then. Drain blue before scaling it to zero. In-flight requests outlive the selector change, and the time blue stays up is the rollback window.

Where coexistence is safe and the idle cost is already accepted, keep the gradual replace. Where a shared path would fail, or leaving a bad build cannot wait on startup and readiness, cut to the warm standby and keep the previous color until that cut has earned it.

Sources

otf-kit vs Shadcn Studio: a decision checklist before you buy

Dave Kurian — Fri, 25 Sep 2026 03:15:08 +0000

Write down the file you expect on disk tomorrow morning. If the sentence is "a block inside the React app we already run," you are looking at one product. If the sentence is "a repo that already signs a user in and charges a card, on web and on mobile," you are looking at the other. Pay only after that sentence is boring and specific. This checklist is adapted from the full comparison on OTF, which I update when a price changes.

I am Dave Kurian, and I build OTF. One branch of this checklist ends in our kit. Another ends in Shadcn Studio. A third ends in spending nothing. I would rather you take the third than buy a skeleton for a button.

Sort the job into one sentence

Use one of these, and drop the other:

The app already exists. The missing work is blocks, pages, and templates copied into it, plus a Figma file and a theme tool.
The product is still a folder. The missing work is login, data, and Stripe, for web and mobile, in a repo you will keep.

Both can be true across a year. They are rarely both true this month. Buy the month you are in. Screens: catalog. A stranger who still cannot pay you: kit.

Shadcn Studio is the catalog, on a one-time license. OTF is a free SDK plus paid kits. The SDK is $0 and MIT. A landing template is a separate $9 file. A kit is the wired product.

Checklist A — buy the catalog

Mark yes or no. Buy Shadcn Studio when the yeses are the ones that match your week.

A React app already exists. Accounts and data are already settled.
You want a dense gallery in that app: marketing blocks, dashboard and application blocks, ecommerce blocks, pages, templates.
You want the Figma kit, the theme generator, the MCP server, the builder, and the IDE extension on the same license.
The path you will actually use is the CLI, the MCP server, or a prompt. The work is paste-into-this-repo.
You have read two clocks, not one: lifetime access, with new components, blocks, and templates monthly, and one year of premium support.
Day one does not need to charge a card. Your app already knows how, or that work is out of scope.

Smaller door: Flow, one template, was $59 on the 2026-09-24 fetch. The same view also showed "Get all access." If the template is the whole purchase, confirm the control you click is the $59 template.

Sampling is free. Community is the free tier. The license page adds a Commons Clause to MIT: no resale of the components, and no product that competes with Shadcn Studio. Free MCP reaches free components and blocks only. Paid blocks are a separate gate.

A kit does not satisfy this list. You would be cloning a login flow to get a dashboard shell.

Checklist B — buy the kit

Buy an OTF kit when these are the yeses.

Someone still has to stand up login, stored data, and a card charge.
Web and mobile should come from one SDK, in one repo you keep.
You can live with 12 months of updates on a $99 kit, or you want lifetime updates and will take the Everything Bundle or Team.

Three kits are on sale at $99: SaaS Dashboard, Fitness, and Arcade. Choose by the product, not by collecting all three. For a standard SaaS, start with SaaS Dashboard, on its template page.

The SDK stays free. There is no paid badge on a component. Checklist B fails, correctly, when the only hole is a control you could ship this afternoon.

A landing is not a kit. Fifteen landing templates are $9 each. Buy one for a page.

Checklist C — spend nothing

You need a button, a form, or one settings screen. Use the free SDK, or the free Community pieces if the catalog's app is the one you already have.
You need Booking or Marketplace shipped today. Skip us for now. Booking is a Preview. Marketplace isn't for sale yet and isn't part of the Bundle.
The real wish was a Figma kit and a monthly run of new blocks for an app that already runs. That wish is checklist A.

Prices to paste into the note

Shadcn Studio numbers are as fetched on 2026-09-24. Check their pricing page before you buy. Struck figures sat beside the live price that day. I am not translating them into a discount. OTF numbers are the public ladder. Team has no printed dollar amount, so this note has none.

Line	Shadcn Studio, as fetched 2026-09-24	OTF
Free	Community, $0	SDK, $0, MIT
Entry paid	Basic $99, a $219 figure beside it, 1 seat, 48 business hours	Landing template $9, fifteen of them
Main paid	Pro $199, a $359 figure beside it, marked Best Value, 1 seat	Kit $99, 12 months of updates: SaaS Dashboard, Fitness, Arcade
Team	$449, a $719 figure beside it, 15 seats, 24 business hours	5 seats, by email, lifetime updates, no dollar amount
Top	Enterprise $849, a $1,299 figure beside it, unlimited seats	Everything Bundle $149, struck $531, Save $382, lifetime updates
Single file	Flow, $59	A landing, $9
Updates	One-time payment, lifetime access, new pieces monthly, unlimited projects	12 months on a kit. Lifetime on the Bundle and on Team
Support	FAQ: one year of premium support	The printed promise is the update window. No support-year figure is added here

Copy two Studio sentences into the note, separately. You pay once and the FAQ describes later components, blocks, templates, and AI tools as included. Support on that purchase lasts one year. People keep the first sentence and lose the second.

On our side the mix-up runs the other way. A $99 kit includes 12 months, then you still hold the code, and you do not hold a claim on the following year. The $149 Bundle is the lifetime-updates line. Team updates are lifetime too.

OTF figures live on the pricing page. Kit status changes are posted on the changelog.

Score the sheet once

Checklist A matches the week: buy Shadcn Studio, or Flow alone if one template is the deliverable.
Checklist B matches the week: buy one named kit, or the Bundle if you want lifetime updates, the live kits, and the fifteen landings.
Checklist C matches: do not pay. Stay on the free SDK.
A and B both look half true: buy the artifact for this month's work. A catalog license leaves payments in the app you already wrote. A bundle does not include their Figma kit, their theme generator, or their block gallery.

I keep the full, updated comparison on OTF.

Cursor Automations last mile: Security Review plus Rollouts, not hope-CI

Dave Kurian — Thu, 24 Sep 2026 11:39:50 +0000

Last-mile confidence is not a vibe and it is not “CI was green.” For Teams and Enterprise, Cursor Automations now cover the two gaps that still eat merge-and-ship weekends: exploitable-bug review on pull requests, and per-environment deploy health after merge—with notify and a revert path when a named regression shows up. Bugbot stays the style and nits bot. Do not replace it. Do not treat Expo OTA staged updates as the same product.

The buyer question is specific: how do you enable Cursor Automations last-mile bots so every ready PR gets an attack-path-plus-fix security pass before merge, and so each environment gets deploy-health and named-regression handling after—without throwing out Bugbot? One stack answers it. Security Review on the PR. Rollouts on the deploy. Same Automations surface. One last mile.

This is not two co-equal posts. Security Review without Rollouts is a merge ritual that still hopes production is fine. Rollouts without Security Review is a health dashboard on a change nobody attacked on the way in. Together they are last-mile confidence. Expo’s staged EAS Update guide is a different last mile: JS bundle percentage on devices. Cursor Rollouts are PR-to-environment health, notify, and revert for the thing you just merged. Do not mix the runbooks.

Primary source: Cursor’s changelog for Rollouts and the security reviewer (2026-09-23) at cursor.com/changelog/rollouts-and-security-reviewer.

What last-mile actually means here

Most teams already have required checks, CODEOWNERS, and a bot that comments on unused imports. That is not last mile. Last mile is the window where a ready PR can still ship an exploitable bug, and the window after merge where a “healthy” deploy is actually a named regression in one environment.

Security Review is the first window: exploitable issues with an attack path a reviewer can follow and a fix path a patcher can take. It is not a style pass. Rollouts is the second window: after merge, health per named environment, notify when it is not, and a revert path when a named regression is the story. Bugbot stays the third bot—style and consistency—cheap on purpose. Folding style into Security Review trains people to skip security comments. Folding security into Bugbot trains people to treat attack paths as nits. Keep the lanes. Pair this with an AI app security checklist for boundaries Security Review cannot invent for you.

Hope-CI-was-enough looks like: tests passed, linter passed, two approvals, merge, assume staging and prod will tell you later. Security Review + Rollouts Automations looks like: every ready PR gets exploitable-bug review with attack path and fix; after merge, Rollouts watches per-environment health, notifies on named regressions, and can open a revert PR for review. Same PR object. Different failure modes. Different bots.

Enable Security Review on every ready PR

Treat ready (non-draft) as the trigger, not “when someone remembers to @ the bot.” Drafts are for incomplete work. The moment a PR leaves draft, it is in the merge funnel.

Wire the Automation so:

Scope is Teams/Enterprise Automations, not a personal rule you cannot audit.
Event is ready pull request (opened ready, or converted from draft). Re-runs on relevant pushes keep the review honest as the diff moves.
Output is exploitable-bug review: attack path plus fix. If the model cannot name a path, it should not invent a CVE-shaped essay.
Bugbot is unchanged. Do not disable Bugbot to “reduce bots.” Reduce overlap by job, not by count.

What “attack path + fix” means in practice: untrusted input reaches a sink (authz skip, template, shell, deserialization, IDOR), and the fix is the concrete change in this PR—guard, query bound, deny-by-default, or drop the endpoint. If the Automation cannot point at a hunk, it is not last-mile.

Required status is a policy choice. If Security Review is advisory, people will merge around it the week you are busy. Teams that already require Bugbot for nits should not assume that requirement covers exploitable bugs. It does not.

Enable Rollouts for PR → environment health

After merge, the PR is a candidate in each environment you actually ship to. Rollouts attaches monitoring to the change, reports health per environment, notifies when health is not the story you wanted, and—depending on configuration—can open a revert PR for review or hand the finding to a cloud agent. Per Cursor’s changelog, it does not merge or roll back on its own today.

Name environments the way you operate (preview, staging, prod). Rollouts is not Expo’s rollout percent. For OTA percentages, stay on the EAS Update staged rollout guide. For “this merged PR’s deploy is sick in staging,” stay on Cursor Rollouts.

Health has to be named. Named regression means a check, error class, or SLO you already believe—checkout, auth, a critical job, a latency budget you page on. Wire notify to the people who can revert. You should answer: which PR, which env, which signal, who was notified, was a revert opened.

Nothing in that spine is Bugbot. Nothing is an Expo runtime version. Ready is the security gate. Merge is the handoff. Per-env health is the deploy gate. Notify and revert are how you leave without a war room as the default.

Do not confuse Cursor Rollouts with Expo staged OTA

Expo / EAS Update staged rollout ships a JavaScript bundle to a fraction of clients and watches crash and runtime signals. The unit is the update on a channel. The client is a device. Use eas-update-staged-rollout-guide when the question is “what fraction of phones get this bundle.”

Cursor Rollouts (Automations, Teams/Enterprise, changelog 2026-09-23) asks whether the merged PR’s deploy is healthy in each environment, who hears about a named regression, and whether a revert path opens. The blast radius is an environment, not a device cohort. You can run both in one company. Document them as two last miles.

Keep Bugbot for style

Bugbot owns dead code, naming, and review hygiene. Security Review owns exploitable bugs on ready PRs. Rollouts owns post-merge per-environment health, notify, and revert path. Three bots is not a failure. One bot with three jobs is. For owned backends you already operate, keep structured logging agents can triage so Rollouts has signals worth trusting.

A enablement path that does not stall

Confirm Automations on Teams or Enterprise.
Turn on Security Review for ready PRs. Convert-from-draft must count. Sample a week of comments: keep only findings with a path and a fix.
Leave Bugbot on. If volume is high, tune Bugbot, not Security Review.
Turn on Rollouts for the environments you deploy. Attach signals you already trust. Wire notify to the on-call who can revert.
Practice one revert in non-prod so revert is not a rumor.
Write two sentences in the team doc: Cursor Rollouts ≠ EAS staged updates; Bugbot ≠ Security Review.

The failure mode is a fourth bot that restates CI. The other failure mode is skipping Security Review because Rollouts “will catch it.” Rollouts catch deploy health. They do not reconstruct an IDOR from a 200 OK.

What “good” looks like after a week

A ready PR that touches auth gets a Security Review comment that names the path and the fix. Bugbot still nags about a leftover console.log. A merge to staging trips a named regression; Rollouts notifies; a revert path opens in the same spine. If Security Review only ever says “looks fine” on risky diffs, tighten the ready-PR trigger and demand path + fix. If someone asks whether this replaces Expo rollout percent, send them the EAS guide and this post.

What we are not claiming

The changelog is the source for Rollouts and the security reviewer as of 2026-09-23. This post does not invent plan SKUs beyond Teams/Enterprise Automations, does not invent package versions, and does not quote unpublished metrics. It does not claim Security Review finds every exploitable bug. It claims you can put exploitable-bug review with attack path and fix on ready PRs, keep Bugbot on style, and put PR-to-environment health, notify, and a revert path on the other side of merge.

Last-mile confidence is that pair, on Automations, not a feeling that CI was enough.

Owned kits still help when the app itself is the thing you review and roll out: browse templates for full-stack starting points with agent configs already in the repo.

Sources

Wire TanStack AI agents to OAuth-protected MCP via Vercel Connect

Dave Kurian — Thu, 24 Sep 2026 09:45:09 +0000

If you already run TanStack AI agents that call MCP tools, the boring failure mode is not that the model is dumb. It is that you pasted a long-lived MCP token into env, shipped it with the deployment, and now every rotate is a redeploy plus a hope that no screenshot of $CONNECT_* ever leaked. Vercel’s changelog for Vercel Connect + TanStack AI (2026-09-24) is aimed at that boundary: install @vercel/connect/tanstack-ai, send MCP traffic through connectMCPTransport, and when the server returns a consent challenge, catch getConsentChallenge and redirect the user. Tokens are issued at runtime at an owned route. They do not live in env for you to rotate.

This post is the keep-path PSEO for that wiring. It is not the EAS/Claude connector path in Expo MCP connector for Claude. Different runtime, different consent surface, different place the secret is allowed to exist.

What Connect is doing at the agent boundary

TanStack AI already knows how to call tools. MCP already knows how to expose tools behind OAuth. The missing piece on a Vercel deployment is a first-party transport that refuses to treat “bearer in $CONNECT_TOKEN” as the integration.

connectMCPTransport is that transport. You point the agent at MCP the same way you would any other tool host, except the bytes do not leave your app with a static secret. When the MCP server needs a user (or org) to grant access, Connect surfaces a consent challenge. Your route handles it with getConsentChallenge and redirects. After consent, a runtime token is bound to that session at the route you own.

That is the product claim worth keeping: owned-route MCP auth. The agent never becomes a secret store. Env never becomes a token locker. Rotation is “consent again,” not “edit production env and pray.”

If you still think in gateway terms — one billed path for model calls, one for tools — pair this with AI Gateway delegation. Gateway is the model hop. Connect is the OAuth hop for MCP. Do not collapse them.

Install and the only import that matters

From the changelog: install @vercel/connect/tanstack-ai. That package is the TanStack-specific adapter. Do not cargo-cult a mobile EAS connector, a generic MCP SDK auth helper, or a “put the token in $CONNECT_MCP_TOKEN” snippet from an older thread.

Keep Connect configuration in env as connection config — whatever $CONNECT_* names your dashboard emits — not as the user’s MCP access token. Path-only on the app side: your route owns consent and the agent endpoint.

Honest skeleton from the changelog: TanStack AI (chat, createMCPClient) with MCP attached through connectMCPTransport — not a raw fetch with Authorization from .env. The same HTTP handler catches getConsentChallenge and redirects; it does not retry the model with a guessed token. Storing the resulting token in env to “make CI simpler” undoes the feature.

`connectMCPTransport`: keep the agent ignorant of OAuth

The agent’s job is tool names, arguments, and when to stop. OAuth is not a tool. If you shove authorize URLs into system prompts, you will get a model that pastes tokens into logs.

connectMCPTransport sits under the tool layer. The provider is called before every MCP request, so the token is always fresh. Failed auth is not a chat message; it is a control-flow exception your route understands. That is why getConsentChallenge exists as a catchable object rather than a string the model might echo.

Trace transport errors and redirects, not bearer prefixes. Treat consent timeouts as user-wait. Multiple MCP servers can share the Connect consent pattern — not one shared env token.

`getConsentChallenge` and the redirect you actually ship

Consent is a browser problem. When getConsentChallenge fires on the agent route the UI posts to, that route should:

Stop the current agent turn. Do not half-apply tool results.
Redirect the user to the consent URL Connect gave you (changelog uses a 303).
Land back on a path you own after the user accepts or denies.
Resume the agent only after a runtime token exists for that session.

“Owned route” is load-bearing. If consent returns to a third-party page you do not control, someone else’s cookie becomes your security model. Keep the callback on your deployment — path-only, like /connect/consent next to the agent route.

Denied consent is first-class. Show that MCP tools are unavailable. Do not fall back to a pasted env token “just this once.”

Catch the challenge before the model runs. The changelog is explicit: if a consent error is raised inside a tool call instead, it reaches the model as an error string rather than the user as a redirect.

Runtime tokens vs env tokens

	Pasted MCP token in env	Connect consent at the route
Where the secret lives	Deployment env, often copied into previews	Issued at runtime after `getConsentChallenge` redirect
Rotate	Change env, redeploy, invalidate every replica	Re-consent; old runtime token dies with the session
Blast radius	Anyone with env or a leaked preview	Bound to the user/session that consented
Agent code	Tempted to log headers	Transport handles OAuth; agent sees tools
Fits TanStack on Vercel	Works until the first leak	What `@vercel/connect/tanstack-ai` is for

Env is fine for which Connect app you are, $CONNECT_* identifiers, and public MCP URLs. Env is not fine for the OAuth access token that talks to a customer’s MCP. If your runbook still says “rotate MCP_TOKEN quarterly,” you adopted a rename, not Connect.

Sequence you can keep in your head

UI hits your owned agent route.
TanStack AI starts a turn and needs an MCP tool.
connectMCPTransport talks to the MCP server without a long-lived env bearer.
Server demands OAuth. Transport yields a consent challenge.
Route catches getConsentChallenge, redirects the browser.
User consents. Connect issues a runtime token at your callback path.
Agent retries the tool call. MCP sees a valid OAuth token. Env never held it.

If step 5 is “stuff the token into $CONNECT_MCP_TOKEN so we skip redirects in staging,” staging will ship to production.

Hard split from the Claude MCP connector

We already covered Expo MCP connector for Claude: EAS builds, Claude, a connector aimed at that editor/runtime pair. This Vercel Connect + TanStack path is a different product surface — different package (@vercel/connect/tanstack-ai), host (Vercel route + TanStack), auth UX (getConsentChallenge on your web route), and secret home (runtime token at the Vercel boundary). Copy-pasting those snippets into a TanStack Vercel app gives you two half-wired OAuth stacks.

Failure modes that are on you

Redirect loops mean the callback did not persist enough session state — fix the session, not the transport. Ignoring getConsentChallenge so the model “tries another tool” leaks partial work; abort the turn. Log that a challenge happened, not URL query params that may carry one-time codes. Use connectMCPTransport in local and preview too, or those environments invent env tokens again. Keep AI Gateway credentials (model inference) separate from MCP OAuth (tools) — see AI Gateway model picks.

A minimal implementation checklist

Grounded in the changelog — not invented API:

import { chat, toServerSentEventsResponse } from '@tanstack/ai';
import { createMCPClient } from '@tanstack/ai-mcp';
import { vercelGatewayText } from '@tanstack/ai-vercel-gateway';
import {
  connectMCPTransport,
  getConsentChallenge,
} from '@vercel/connect/tanstack-ai';

export async function POST(request: Request) {
  const { messages } = await request.json();
  const userId = await getUserId(request);
  try {
    const linear = await createMCPClient({
      transport: connectMCPTransport(
        { type: 'http', url: process.env.CONNECT_MCP_URL! },
        'oauth/linear',
        { subject: { type: 'user', id: userId } },
      ),
    });
    const stream = chat({
      adapter: vercelGatewayText('anthropic/claude-opus-5'),
      messages,
      mcp: { clients: [linear] },
    });
    return toServerSentEventsResponse(stream);
  } catch (err) {
    const challenge = getConsentChallenge(err);
    if (challenge) return Response.redirect(challenge.url, 303);
    throw err;
  }
}

Checklist: @vercel/connect/tanstack-ai adapter; connectMCPTransport; catch getConsentChallenge on the agent route; owned-path consent callback; no MCP access token in env; deny disables tools (no static fallback); logs omit tokens. If the changelog is silent on a step, do not invent it — read the entry.

Owned-route auth is the pattern we want when an agent can spend money or read a private repo: the browser user is in the loop, the serverless function is the boundary, and the model is a guest. Install @vercel/connect/tanstack-ai, send tools through connectMCPTransport, catch getConsentChallenge and redirect, let tokens issue at runtime. Leave env for $CONNECT_* config. Keep the Claude connector in its own post. For a durable product surface under the agent churn, start from the OTF templates you own — Connect still owns the OAuth hop.

Sources

Queue backpressure on an owned backend: refuse the burst before the pool melts

Dave Kurian — Thu, 24 Sep 2026 07:54:05 +0000

Agent runs, vendor webhook fan-out, and retry storms arrive as a sudden pile of HTTP calls on an API you operate. The database pool and the worker processes behind that API are a fixed budget. Once every extra call is allowed to pin a connection, the burst becomes latency for every tenant, including the ones that sent a normal amount of traffic.

Backpressure is the refusal at that edge. Cap in-flight work. Cap how many requests may wait, and for how long. When both caps are exhausted, answer with a status code and a Retry-After value the caller can honor. A process that keeps an ever-growing list of HTTP requests in memory is betting the pool will catch up. Under this load, it will not.

What owned capacity means here

Owned capacity is the part you restart and pay for: database connections, worker processes, and the concurrency budget of the next service you run. The caller does not know those numbers. An agent loop will keep issuing work. Admission turns your budget into a yes, a short wait, or a reject on the backend that holds the pool.

Matthew Palma's notes on HTTP API admission control describe that gate as a concurrency cap, a bounded queue with a maximum wait, and a reject that carries 503 and Retry-After. Readiness fails when the process should leave rotation. Size the knobs from your pool: $DB_POOL_SIZE, $MAX_INFLIGHT, $MAX_QUEUE_DEPTH, $QUEUE_WAIT_MS, and $RETRY_AFTER_SEC.

API gateway guidance from API7 separates two knobs dashboards often mash together. A rate limit counts arrivals in a window. Concurrency counts work still inside the system. A client under its rate limit can still occupy every database connection when each call is slow. Rate limiting an owned API is the arrival window. This piece is occupancy. You want the pair.

Keep the other queues in their own posts

This series already uses "queue" for three different jobs. Mixing them buffers the wrong thing.

Circuit breakers on an owned backend fail fast on outbound calls when a vendor is already failing. Inbound admission decides whether a new request may enter your database at all.

Dead letter queues for background jobs quarantine a message after its retries are spent. That storage sits later than the HTTP gate. A request you have not admitted yet has nothing to dead-letter.

A client-side offline queue holds mutations on the device and replays them when the network returns. The replay still has to pass the server gate, or the reconnect wave becomes the burst this post is about.

An unbounded in-process queue stores the overload until memory, file descriptors, or the database pool fail together. Bounded concurrency plus a short wait, then 429 or 503 with Retry-After, spends the pool on work already admitted and tells everyone else to come back.

Admit, wait briefly, or reject

Per process, or per worker behind a load balancer, take a semaphore of size $MAX_INFLIGHT. Derive it from $DB_POOL_SIZE and any downstream budget the handler also consumes. If each admitted request holds one pool connection for the life of the call, $MAX_INFLIGHT must stay inside what that pool can finish. Extra handlers wait inside the driver, and the reject you wanted becomes a timeout.

When several workers share one database, the fleet total is the real cap. Four processes each sized at the full $DB_POOL_SIZE admit four times what the pool can serve. Divide the pool across the processes, and leave a remainder for migrations, health checks, and admin work.

In front of the semaphore, a wait queue is optional and short. Cap it with $MAX_QUEUE_DEPTH and $QUEUE_WAIT_MS. When the queue is full, or a waiter exceeds the wait budget, reject without checking out a connection.

API7 frames that choice as bounded delay or reject, and names load shedding for the moment shared capacity is already gone.

429 is the caller or the tenant. This API key, this agent, this customer has too much in flight relative to the share you assigned them. RFC 6585 section 4 defines 429 Too Many Requests and allows a Retry-After header so the client knows when another attempt is reasonable.

503 is shared capacity. The process, the pool, or the worker fleet is full no matter who called. RFC 9110 specifies Retry-After as either a delay in seconds or an HTTP-date. For this gate, send Retry-After: $RETRY_AFTER_SEC on both 429 and 503. Callers that honor the header back off. Callers that ignore it still hit the same cheap reject on the next try.

Do not answer the shed with a 200 whose body claims the work was queued while the process has nowhere to run it. That hides the overload and invites the client to poll.

Occupancy moves when latency moves

API7 points at Little's Law for a first estimate: average concurrency is about arrival rate multiplied by time in the system. When a dependency slows and handler latency doubles, the same arrival rate doubles how many calls are in flight. The rate limit still says the tenant is fine. The semaphore sees the extra occupancy and starts to wait or reject.

That is why $MAX_INFLIGHT is tied to $DB_POOL_SIZE, then revised when handler time changes. Keep the rate limit beside the semaphore: rate stops one tenant from filling $MAX_QUEUE_DEPTH with cheap arrivals; concurrency stops a slow dependency from holding $DB_POOL_SIZE until every other request times out.

Metrics, readiness, and the path

Emit queue_depth and admission_rejected. Split rejects by 429 and 503 if both exist. Shedding is the gate working. A dashboard that only alerts on 500 stays green while you turn traffic away.

Fail readiness when queue_depth or processing lag crosses the threshold for this process. Readiness is what the platform checks before it sends new work. Liveness can remain true so the process finishes requests it already admitted. Palma includes readiness in the admission story for that reason: a live, saturated process should drop out of rotation until the wait queue recedes.

Draining an owned backend on shutdown is the same refusal with a different trigger. Shutdown stops new work, then waits for in-flight handlers to finish. Backpressure stops new work while the process is supposed to stay up, because the pool is already committed.

The path is a straight line. In-flight below $MAX_INFLIGHT means the handler runs. In-flight full, and queue depth below $MAX_QUEUE_DEPTH, means the request waits up to $QUEUE_WAIT_MS. Wait expired, or queue full, means 429 or 503 with Retry-After, and the pool is never checked out.

A gate in front of the handler

One process-wide semaphore, one bounded waiter list, one reject response. A per-tenant cap uses the same shape under the process cap. Scope "tenant" maps to 429. Scope "process" maps to 503. Call release in a finally. Skip the database until admit returns ok.

// Pseudocode: semaphore + bounded waiters + reject
async function admit(scope: "tenant" | "process"): Promise<Admit> {
  if (inflight < Number(process.env.MAX_INFLIGHT)) {
    inflight += 1;
    return { ok: true, release };
  }
  if (queueDepth >= Number(process.env.MAX_QUEUE_DEPTH)) {
    return {
      ok: false,
      status: scope === "tenant" ? 429 : 503,
      retryAfterSec: Number(process.env.RETRY_AFTER_SEC),
    };
  }
  // wait up to QUEUE_WAIT_MS, then same reject shape
}

Increment admission_rejected whenever admit returns ok: false, and return that status with Retry-After: $RETRY_AFTER_SEC.

Broker backlog vs HTTP buffer

A durable job broker with retention and a consumer concurrency setting is a real queue. Consumer count still has to respect $DB_POOL_SIZE, or the jobs pin the same pool the HTTP gate just protected. An array on the API process has no retention and no bound until you add $MAX_QUEUE_DEPTH.

Agent clients retry on their own timer. Every extra attempt still gets a cheap reject: no pool checkout. Log admission_rejected and the scope.

Checklist

Set $MAX_INFLIGHT per process from $DB_POOL_SIZE. Across workers, the sum still has to fit the pool.
Cap any wait queue with $MAX_QUEUE_DEPTH and $QUEUE_WAIT_MS.
On a full gate, return 429 for a caller or tenant budget and 503 for shared capacity, both with Retry-After: $RETRY_AFTER_SEC.
Emit queue_depth and admission_rejected. Fail readiness when depth or lag crosses the threshold.
Keep a rate limit on arrivals. Keep HTTP request buffering bounded.

Scaffolding the API, the worker, and the repo you deploy is a separate decision from this gate. OTF ships full-stack kits you own — Booking, Fitness, and SaaS Dashboard at $99 each, or the Everything Bundle at $149 — plus a free SDK under MIT. The templates live at otf-kit.dev/templates.

Protect owned capacity under load with a hard in-flight cap, a short wait budget, and an honest 429 or 503 with Retry-After at your edge. Infinite buffering is not backpressure. It is a deferred outage.

Sources

RFC 6585 §4, 429 Too Many Requests — defines 429 and allows Retry-After on that response.
RFC 9110, Retry-After — delay in seconds or an HTTP-date; the time to wait before the next request.
Matthew Palma, HTTP API admission control — concurrency caps, a bounded queue with maxWaitMs, 503 plus Retry-After, and readiness.
API7, API gateway concurrency control — rate versus concurrency, Little's Law as an estimate, 429 for a caller or tenant versus 503 for shared capacity, bounded delay or reject, and load shedding.

Circuit breakers on an owned backend: fail fast when the AI vendor fails

Dave Kurian — Thu, 24 Sep 2026 05:31:34 +0000

When a downstream AI or vendor HTTP dependency starts failing, the owned API should stop waiting on it. A circuit breaker opens after a measured run of failures and returns a cached, stale, or degraded response immediately. The process stays available. Threads and event-loop slots are not pinned to a vendor that is already down. Retries alone do the opposite: every caller keeps burning the timeout budget and the retry budget, which multiplies load on a dependency that is already sick.

This post is the breaker state machine. Outbound wait and retry live in timeouts and retries for AI backends. Parking work for later is a dead-letter queue concern. The breaker decides whether this dependency may be called right now.

What cascading failure looks like without a breaker

Martin Fowler's circuit breaker note and Microsoft's Azure Architecture Center pattern describe the same operator failure mode. A remote call hangs or errors. Callers retry. Each attempt occupies a worker or a promise until the client timeout fires. The owned API's latency SLO collapses even though its own code is fine, because capacity is stuck on calls that cannot succeed.

AI providers make this sharp: a chat or embeddings call can sit for tens of seconds before a 503, a 429, or a transport error. Retries multiply in-flight work. Health checks that also call the vendor start failing. Autoscaling adds instances that open more connections to the same broken endpoint. A breaker does not fix the vendor. It bounds the blast radius so routes you still own — auth, database reads, previously computed answers — keep returning.

Closed, open, half-open

The state machine used by Azure Architecture Center, AWS Prescriptive Guidance, Resilience4j, and the Node and Go libraries below is the same three states Fowler sketched.

Closed. Calls go through. Outcomes are recorded. Failures count only when they are dependency failures. If the failure rate over the window stays under the threshold, the breaker stays closed.

Open. Calls are not attempted. The owned handler returns the fallback immediately and logs that the call was rejected because the circuit is open. A timer ($CB_WAIT_OPEN_MS) must elapse before any probe is allowed.

Half-open. After the wait, a small number of trial calls ($CB_HALF_OPEN_CALLS) are permitted. Success closes the breaker. Failure opens it again and restarts the wait. Half-open discovers recovery without dumping full QPS onto a vendor that just came back.

While open, the fallback is a product decision: cached completion, last-known embeddings, a static degraded payload, or a 503 with a short Retry-After you control. You do not learn the vendor is still down by waiting for $AI_PROVIDER_BASE_URL to time out again.

Why retries without a breaker amplify load

	Retries only	Breaker plus fallback
Vendor 503 storm	Every request waits, then retries	After the threshold, new requests skip the network
In-flight work	Grows with concurrency × attempts	Caps at calls already in flight when the breaker opens
User latency	Sum of timeouts and backoffs	Fallback latency, typically a cache read
Recovery	All callers slam the vendor on the first green blip	Half-open probes, then close
4xx from your bug	Often retried if classified poorly	Ignored by the breaker; you still fix the client

Azure's pattern page is explicit: a circuit breaker is not a substitute for retry. Retries and timeouts wrap one attempt sequence; if the breaker is open, do not start that sequence. CallNotPermittedException (Resilience4j) and opossum's reject event are the signals to stop.

A DLQ is the wrong tool for this request path — it parks work you already accepted. A user on POST /v1/answer needs fail-fast plus degraded body; background enrichment can use the DLQ separately.

What to count as failure

Resilience4j documents a 50 percent failure-rate threshold, sliding windows, minimumNumberOfCalls, slow-call rate, wait in open state, half-open permits, and recordExceptions / ignoreExceptions.

Count toward the breaker: outbound client timeouts; connection resets, DNS failures, TLS handshake errors; HTTP 5xx; HTTP 429 and 503 treated as dependency health signals.

Do not count: HTTP 4xx that are your bug or bad user input (400, 404, 422); client cancellations; business outcomes you already decided. Opening on 4xx lets a malformed-body deploy take the dependency "down" while the vendor is healthy.

Slow calls deserve a separate rate: a body that always arrives in 28 seconds will not trip failure-rate and will still exhaust your pool. Use Resilience4j's slow-call threshold or opossum's timeout — pick one definition of "too slow."

One breaker per dependency

Do not share one breaker across unrelated providers or shards. A search vendor and a chat vendor fail independently. Key by dependency name: chat-provider, embeddings-provider, not outbound-http. Extra breakers are cheap; a false open on unrelated traffic is not.

Name them in metrics and logs. On transition and reject, log breaker name, new state, correlation id, and route — the same discipline as production structured logging for agents.

Libraries and settings

Prefer a maintained implementation. Resilience4j (JVM): sliding windows, failureRateThreshold default 50, slow-call rate, minimum calls, open wait, half-open permits, CallNotPermittedException, exception filters. opossum (Node): timeout, errorThresholdPercentage, resetTimeout, fallback, plus reject/open/halfOpen/close events. sony/gobreaker (Go): ready-to-trip, open-state timeout, max half-open requests. AWS Prescriptive Guidance and Microsoft Azure Architecture Center describe the same machine without a library.

Read at process start: $CB_FAILURE_RATE_THRESHOLD, $CB_SLIDING_WINDOW, $CB_WAIT_OPEN_MS, $CB_HALF_OPEN_CALLS, and $AI_PROVIDER_BASE_URL. Require a minimum number of calls before evaluating rate — opening on the first failure flaps.

TypeScript sketch for one outbound AI client

The timeout and retry wrapper is the one from the timeouts post. The breaker sits outside it so an open circuit never enters the retry loop.

type AiResult =
  | { ok: true; body: unknown; servedBy: "live" | "cache" }
  | { ok: false; degraded: true; reason: "circuit_open" | "upstream_failed" };

// settings: $CB_FAILURE_RATE_THRESHOLD $CB_SLIDING_WINDOW
// $CB_WAIT_OPEN_MS $CB_HALF_OPEN_CALLS ; URL: $AI_PROVIDER_BASE_URL

async function completeWithBreaker(
  correlationId: string,
  input: { promptHash: string; prompt: string }
): Promise<AiResult> {
  const breaker = breakers.get("chat-provider");

  if (!breaker.tryAcquire()) {
    logger.warn({
      msg: "circuit_rejected",
      breaker: "chat-provider",
      state: breaker.state(),
      correlationId,
    });
    const cached = await cache.get(input.promptHash);
    if (cached) return { ok: true, body: cached, servedBy: "cache" };
    return { ok: false, degraded: true, reason: "circuit_open" };
  }

  try {
    const body = await withTimeoutAndRetry(() =>
      postChat($AI_PROVIDER_BASE_URL, input)
    );
    breaker.recordSuccess();
    await cache.set(input.promptHash, body);
    return { ok: true, body, servedBy: "live" };
  } catch (err) {
    if (isDependencyFailure(err)) breaker.recordFailure();
    else breaker.recordSuccess(); // 4xx business: not vendor health
    const cached = await cache.get(input.promptHash);
    if (cached) return { ok: true, body: cached, servedBy: "cache" };
    return { ok: false, degraded: true, reason: "upstream_failed" };
  }
}

tryAcquire returns false when open or when half-open already has $CB_HALF_OPEN_CALLS in flight. Count timeouts, connection errors, 429, 503, and other 5xx as failures; ignore 4xx for the window. Invoke withTimeoutAndRetry only after acquire succeeds.

Checklist for the owned API

One breaker per independent dependency, named in logs and metrics.
Record failures for timeouts, connection errors, 5xx, and vendor 429/503.
Ignore 4xx that indicate a bad request rather than a bad dependency.
Evaluate failure rate only after a minimum number of calls in $CB_SLIDING_WINDOW.
Open when the rate exceeds $CB_FAILURE_RATE_THRESHOLD.
While open, skip $AI_PROVIDER_BASE_URL; return cache or degraded body; log breaker name, state, correlation id.
After $CB_WAIT_OPEN_MS, allow $CB_HALF_OPEN_CALLS probes; close on success, re-open on failure.
Emit metrics on every transition and reject.
Keep timeouts and a small retry budget for the closed state. Stop retrying when the call is not permitted.
Do not use the breaker as a DLQ, and do not use a DLQ as a live fail-fast.

How this sits next to the other controls

Timeouts cap one call. Retries spend a fixed budget on transient faults. The breaker removes the dependency from the hot path after that budget is clearly wasted. Rate limiting protects you from your callers; it does not protect you from a vendor that accepts the connection and then stalls. Background jobs that call the same vendor should use a sibling breaker with a looser threshold so batch volume does not open the circuit for interactive traffic — when retries are spent and the breaker is open, park the job in the DLQ.

While open, return a cache hit marked servedBy: "cache", a stale-but-bounded row, a stable degraded JSON object with your correlation id, or a null optional enrichment while the primary database read still returns. Do not fall through an open breaker into an unbounded call to a second vendor — give the backup its own breaker.

If you own the repo, put the breaker next to the HTTP client that already holds timeouts and structured log fields. OTF's owned-repo kits are built around that client boundary; add the breaker in the same module instead of inventing a second outbound stack.

The vendor will fail again. The owned API should notice quickly, stop calling, serve the fallback, and try a few probes later. That is the whole machine.

Sources

Martin Fowler, CircuitBreaker: https://martinfowler.com/bliki/CircuitBreaker.html
Microsoft Azure Architecture Center, Circuit Breaker pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker
Resilience4j CircuitBreaker: https://resilience4j.readme.io/docs/circuitbreaker
AWS Prescriptive Guidance, Circuit breaker pattern: https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html
opossum (Node): https://www.npmjs.com/package/opossum
sony/gobreaker (Go): https://github.com/sony/gobreaker
Related: https://otf-kit.dev/blog/api-timeouts-retries-ai-backends
Related: https://otf-kit.dev/blog/dead-letter-queue-background-jobs
Related: https://otf-kit.dev/blog/production-structured-logging-for-agents

DEV Community: Dave Kurian

Buy the Arcade kit when the product is a games store

Name the product before you open checkout

What you already have on day one

Run this checklist before you pay

The other live kits are different products

When you do not need this kit

What you still do after the repo is yours

Check the demo, then use this checkout

Sources

Re-measure one fixed task before you trust a harness savings claim

What Cursor changed in the harness

Why the 7% stays on their traffic

Keep a short standing file

Load the skill only for that task

Measure the same task twice

When you don't need this

Sources

Pin a short skill allowlist instead of shopping the registry

What the install curve actually says

Why an install count is a weak buy signal

Pin the allowlist in the repo

Write the private rule next to the list

When the catalog is already finite

When you don't need this

Sources

Delete one tenant's files without scanning a shared Blob store

What still bills when stores are unlimited

When a pathname prefix is enough

When a store per tenant is worth the create

Split production, staging, and preview

When you don't need this

Sources

Write the outbox row in the same Postgres transaction as the business row

The loss is the gap after commit

Write the event in the same transaction

The outbox table

Poll with a claim, wake with notify

At least once, then the consumer

When the relay keeps failing

When a sync enqueue is enough

Sources

An owned API stores idempotency keys in Postgres and replays the first response

Which writes need a key

Where the key lives

How long you keep the row

What you store with the key

Concurrent duplicates

The table and the route

When you don't need this

Sources

When to cut traffic to a warm standby instead of a rolling replace

Cut when versions must not share a request path

Cut when time-to-rollback matters more than spare capacity

Stay gradual when a flip would not restore the last good state

Stay gradual when versions can share the path

What you move, and what stays up

Sources

otf-kit vs Shadcn Studio: a decision checklist before you buy

Sort the job into one sentence

Checklist A — buy the catalog

Checklist B — buy the kit

Checklist C — spend nothing

Prices to paste into the note

Score the sheet once

Cursor Automations last mile: Security Review plus Rollouts, not hope-CI

What last-mile actually means here

Enable Security Review on every ready PR

Enable Rollouts for PR → environment health

Do not confuse Cursor Rollouts with Expo staged OTA

Keep Bugbot for style

A enablement path that does not stall

What “good” looks like after a week

What we are not claiming

Sources

Wire TanStack AI agents to OAuth-protected MCP via Vercel Connect

What Connect is doing at the agent boundary

Install and the only import that matters

connectMCPTransport: keep the agent ignorant of OAuth

getConsentChallenge and the redirect you actually ship

`connectMCPTransport`: keep the agent ignorant of OAuth

`getConsentChallenge` and the redirect you actually ship