DEV Community: GDS K S

Your bundle is 4000x bigger than Quake. The 9-step audit that fixes it.

GDS K S — Thu, 14 May 2026 04:29:48 +0000

In February 2026 a developer named daivuk shipped a playable Quake-like first person shooter in a 64 kilobyte Windows executable. Multiple levels, four enemy types, textures, music, the whole game. The trick was not magic. He wrote a custom language and a custom virtual machine because the standard toolchain shipped too many features he did not use. Two extra kilobytes of generic runtime would have killed the fourth level.

That story sat with me for a week, because almost every web app I open is 30 to 60 times the size of QUOD. The page you are reading right now, by the time it finishes loading on Dev.to, weighs more than four hundred copies of QUOD running at once. The marketing page for the framework your app is built on is heavier than QUOD by three orders of magnitude. We have collectively forgotten what bytes cost.

This article is the audit playbook I use when a Next.js or Vite project crosses my desk and the Lighthouse score reads orange. Nine steps, in the exact order, with the commands, the expected output, and the typical wins. Everything you need to cut your bundle by 50 to 90 percent in a single afternoon. No "rewrite in Rust" theater. Just deletions.

TL;DR

Step	What you run	Typical win
1. Baseline	`npx next build` then read the output table	knowing where you stand
2. Visualise	`@next/bundle-analyzer` or `rollup-plugin-visualizer`	the map
3. Kill date libraries	swap `moment` for `date-fns` or native `Intl`	50 to 90 KB
4. Kill icon sets	one import per icon, never the full pack	20 to 200 KB
5. Kill lodash	swap `lodash` for `lodash-es` or native	60 to 80 KB
6. Audit polyfills	drop IE 11 support; target ES2022	30 to 100 KB
7. Code-split routes	dynamic imports for non-critical pages	100 KB to 1 MB
8. Replace images	AVIF or modern WebP, properly sized	200 KB to 2 MB
9. Re-baseline	run step 1 again, write the number down	confidence

The numbers in the table come from documented case studies on web.dev, the HTTP Archive 2025 annual report, and the Vercel Next.js docs. Your mileage will vary. The order will not.

1. Baseline

You cannot improve what you have not measured. Before you touch anything, get an honest number.

# Next.js
npx next build
# read the "First Load JS" table at the bottom

# Vite
npx vite build
# read the dist/ output sizes

The number you want is "First Load JS shared by all," and then your largest individual route. Write both down. This number will be your accountability for the rest of the audit. If it does not go down by at least 30 percent by step 9, you skipped something or you have a genuinely small project, which is fine, you are done.

The HTTP Archive's 2025 annual web almanac reports a median JavaScript transfer size of 612 KB on desktop and 555 KB on mobile. If your number is meaningfully bigger than that, you have low hanging fruit. If it is meaningfully smaller, you are already ahead of most of the industry.

2. Visualise the bundle

A list of files is not a map. You need the map.

# Next.js
npm install --save-dev @next/bundle-analyzer
# in next.config.js wrap your config with the analyzer
ANALYZE=true npm run build

# Vite
npm install --save-dev rollup-plugin-visualizer
# add it to vite.config.ts
npx vite build

The analyzer opens a treemap in your browser. The treemap is the entire audit's source of truth. Every fat block is a question. Every question is one of the next seven steps.

Spend ten minutes here. Hover the rectangles. Find the ones that are unfamiliar. The ones you cannot explain are the ones that have the most byte fat.

3. Kill the date library

The single most common bundle bloat in the entire JavaScript ecosystem. Moment.js is 67 KB minified before gzip. day.js is 7 KB. date-fns with tree shaking can drop to 12 KB. Native Intl.DateTimeFormat is zero.

// before
import moment from 'moment'
const formatted = moment(date).format('YYYY-MM-DD')

// after, native, zero bytes added
const formatted = new Intl.DateTimeFormat('en-CA').format(date)

// or with date-fns, tree shakes cleanly
import { format } from 'date-fns'
const formatted = format(date, 'yyyy-MM-dd')

Run a global grep for moment and dayjs in your codebase. If you find moment, you have a 50 to 90 KB win sitting on the floor. The migration is mechanical and well documented.

4. Kill the icon set import

The second most common bundle bloat, especially in dashboards built on Material UI, Chakra, or any "we have icons" library. The trap is the default import.

// before, ships the entire icon set
import { Search, User, Menu } from '@mui/icons-material'

// after, ships only the three icons
import Search from '@mui/icons-material/Search'
import User from '@mui/icons-material/Person'
import Menu from '@mui/icons-material/Menu'

The default barrel import in many icon packs is the entire 2 MB of SVG. The per-icon import path ships only what you reference. Material UI's documentation explicitly warns about this. Many teams ignore it. Check yours.

For Lucide, Heroicons, and Phosphor, tree-shaking generally works correctly if your bundler is set up right. Verify it in the analyzer. If you see the full icon library in your treemap, the tree shake did not happen and you need to fix the import path.

5. Kill the utility library

Lodash is 70 KB. Most apps use seven functions from it. The fix is either lodash-es with tree shaking, or replacing the seven functions with native equivalents.

// before
import _ from 'lodash'
const grouped = _.groupBy(items, 'category')
const unique = _.uniq(ids)

// after, native
const grouped = Object.groupBy(items, item => item.category)
const unique = [...new Set(ids)]

// or, tree shaken
import groupBy from 'lodash-es/groupBy'
import uniq from 'lodash-es/uniq'

Object.groupBy shipped in 2024 and is widely available. Map.groupBy is also there. The Set constructor handles uniqueness in one line. Underscore is even worse than lodash for the same reason. Check your dependency tree, find them, replace them, save bytes.

6. Audit the polyfill load

If your project supports browsers older than the last two years of Chrome, Safari, and Firefox, you are shipping polyfills you do not need. The .browserslistrc or browserslist field in package.json governs this.

// package.json before
"browserslist": ["> 0.5%", "last 2 versions", "Firefox ESR", "not dead"]

// package.json after, modern targets only
"browserslist": ["last 2 chrome versions", "last 2 firefox versions",
                 "last 2 safari versions", "last 2 edge versions"]

The wins here vary by project. A React app that explicitly targets IE 11 ships about 50 KB more than the same app targeting last-two-versions. Vue and Svelte have similar ratios. Check the analyzer for core-js, regenerator-runtime, @babel/runtime. Each of those is a polyfill bundle, and each shrinks meaningfully when you raise the target.

The honest tradeoff: if you serve enterprise customers stuck on Internet Explorer, you cannot do this. Almost everyone else can.

7. Code split by route

The biggest single lever. Most apps load every component on every page because the bundler does not know which routes need what. The fix is dynamic imports for non-critical paths.

// before, eager import
import HeavyDashboard from './HeavyDashboard'

// after, lazy
import { lazy, Suspense } from 'react'
const HeavyDashboard = lazy(() => import('./HeavyDashboard'))

function App() {
  return (
    <Suspense fallback={<Spinner />}>
      <HeavyDashboard />
    </Suspense>
  )
}

In Next.js the App Router does most of this automatically per route. The wins come from splitting heavy components inside a route. A chart library, a markdown editor, a video player, a payment SDK. Each of those is a candidate.

Run the analyzer again after this step. The shared bundle should drop by 100 KB to a megabyte, depending on what you split. The page-specific bundles will be larger, but only loaded when needed.

8. Replace your images

Almost forgot the part where pictures of food account for 70 percent of the bytes on the average e-commerce page.

The 2026 image stack is straightforward. Serve AVIF with a WebP fallback and a JPEG fallback. Size them to the actual display dimensions, not the original camera resolution. Use the native <picture> element or a framework wrapper like next/image.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="..." width="1200" height="630" loading="lazy">
</picture>

The width and height attributes prevent layout shift and give the browser an early hint. The loading=lazy attribute defers off-screen images. The AVIF source typically shaves 30 to 50 percent off the file size compared to JPEG at the same quality.

A typical e-commerce site that does the full image audit drops its page weight by a megabyte or two. That single change moves Lighthouse scores more than the previous six steps combined.

9. Re-baseline and write the number down

Run step 1 again. Write the new number next to the old one. Compare.

If you ran all eight changes on a typical Next.js app with one heavy dashboard, an icon library, lodash, and unoptimized images, you should see the First Load JS drop from a starting point of 400 to 600 KB down to 100 to 200 KB. The Lighthouse performance score should jump 20 to 40 points. The Time to Interactive should fall by a full second on a throttled mid-range Android device.

If you did not get those wins, one of two things happened. Either your app is already lean, in which case congratulations, or you skipped a step. Run the analyzer again and find the rectangle that is still too big.

The framework you can actually keep

The nine steps above are a one-time audit. The hard part is keeping the wins after the audit ends. Three rules I run on every project:

Rule 1: A bundle budget in CI.
  Bundle size has to be a number in a green or red box on every PR.
  npm install --save-dev bundlewatch
  Add it to your test script. Set a max. Fail the build on regression.

Rule 2: A dependency review on every PR that touches package.json.
  Use the @sentry/bundle-analyzer or @next/bundle-analyzer in CI.
  Post the diff as a comment. The team will see it. The team will care.

Rule 3: A monthly "what got fat" report.
  Once a month, run the analyzer and look at the biggest rectangles.
  One of them will surprise you. Fix it.

Without these three rules the wins drift back inside six months. With them, the bundle stays at the size you decided it should be at the audit, indefinitely.

The honest take

You are not going to ship your next SaaS in 64 KB. Nobody is asking you to. But the lesson from QUOD is not about the absolute number, it is about the constraint mindset. The standard toolchain ships every feature you do not use. Every dependency is a vote against your users on a slow connection. Every imported icon set is a tax on the laptop battery of the person reading your page on a flight.

The good news is that the audit pays back in hours, not weeks. The first time I ran this playbook on a real codebase, I cut a 540 KB First Load JS down to 168 KB in one afternoon. The before and after Lighthouse score difference would have taken six months of "performance work" if I had done it gradually. Doing it all in one focused sweep is dramatically faster.

The next time you reach for a 4 MB library to format a date, think about QUOD. Then think about whether your users would rather download your full app, or four hundred copies of QUOD running at the same time, with guns in them.

Question for the comments: what is the biggest single byte win you ever shipped, and what tool did you replace?

GDS K S · thegdsks.com · follow on X @thegdsks

Every byte in your bundle is a tiny vote against your users on a slow connection.

I asked Cursor to rename a function. It sent 8,400 tokens. I checked.

GDS K S — Wed, 13 May 2026 03:58:11 +0000

The afternoon I learned what my AI subscription was actually doing, and the 200 lines that took my next bill down 41 percent.

I had been using Cursor for six months when I noticed the discrepancy. I was renaming a function. A short one. Three lines of body. One call site. The kind of refactor that takes, at most, six seconds of human attention.

I had two windows open. The Cursor chat panel where I had typed "rename getUser to fetchUser". And the Anthropic console in another tab, because I had been debugging a different project earlier and forgot to close it.

The Anthropic console refreshed while the Cursor request was in flight. I watched the token counter tick up live. The number it landed on for that single rename request was 8,400 input tokens. The actual prompt I had typed was eleven words.

I sat there for a moment. Then I opened a fresh terminal and made the same call directly through the Anthropic API with my own minimal prompt. Same model. Same intent. Same outcome.

The direct call used 1,900 input tokens. Cursor had sent 6,500 extra tokens of context to perform the same rename.

That observation was the start of the spreadsheet that ate the next four hours of my evening.

What was in those 6,500 tokens

I do not have inside knowledge of Cursor's internals. I have my own experiments and the public documentation, neither of which gives a complete picture. Here is what I have: when I ran the same prompt 50 times across different parts of my codebase, the input token count varied between roughly 4,000 and 14,000 with a median around 8,000. The variation correlated loosely with how many open buffers I had and how recently I had viewed files in the same directory.

The reasonable inference is that Cursor was sending me a system prompt, plus indexing context derived from my recent activity, plus tool definitions for the agent framework, plus the actual prompt I had typed. The first three are the routing layer doing its job. The fourth was the only one I could see in the chat panel.

Some of that context helps. When I ask for a refactor that touches several files, Cursor knowing about those files is the entire point. When I ask to rename a function whose call sites fit in three lines of context, sending 6,500 tokens of unrelated buffer state is the routing layer playing it safe on my behalf in a way that benefits Cursor more than it benefits me.

Cursor charges a fixed seat fee. Anthropic charges Cursor by the token. The math runs the wrong direction for me as a heavy user, because the marginal token cost ends up in my own direct API calls (which Cursor's seat does not cover) plus the fixed seat itself. Conservative context is cheap to ship and expensive to consume. The incentive lands on the wrong side of the table.

The bill that made me pay attention

My March bill arrived on April 2. The Anthropic line item had grown 50 percent month over month for three months running. Cursor at $20 was flat. Copilot at $10 was flat. The variable line was the API I was hitting from my own CLI for things Cursor was not the right tool for.

The growth was not from doing more work. I checked. My weekly logged hours were stable. The growth was from an increasing fraction of those hours involving AI calls that I was making more casually because the AI was getting more useful.

The trend was straight. If I extrapolated, by August I was going to be paying more in direct Anthropic API spend than in Cursor seats, and my Cursor seat would still be running the same conservative context overhead on every chat panel turn. The bill was going to keep growing in two places at once.

I cancelled Cursor that weekend.

The 200 lines

The thing I built to replace the routing piece of Cursor was small enough to embarrass me for not having built it months earlier. A regex based intent classifier with five rules. Trivial prompts route to Haiku. Code prompts route to Sonnet. Planning prompts route to Opus. Embedding-style classification prompts route to a cheap OpenAI model. Default to Sonnet if nothing matches.

That is the entire routing logic. Two hundred lines of TypeScript including imports, error handling, a pricing table, and a cost calculator that logs every call. The full file fits on one screen if you have a tall display.

I tested it on a hundred prompts I had logged from the previous week. The breakdown shifted hard. Sonnet went from 70 percent of calls to 25 percent. Haiku went from zero to 60 percent. Opus stayed at 5 percent. The estimated cost reduction was 47 percent on the test set.

I did not believe the number. I assumed I had a bug. I instrumented the router to log the actual model picked per prompt and the cost in real time, and I ran my normal workflow for two weeks. The actual reduction came in at 41 percent on the May 2 bill, with 30 percent more total calls because the cheaper per call cost made me reach for AI more often.

What I did not understand before

The routing layer is the most valuable part of the AI tool stack right now, and the wrappers want to own that part most of all.

Every coding tool I have looked at in the last 90 days has shipped a model dropdown. Cursor added one. GitHub Copilot added one. Windsurf added one. The story they tell is customer choice. The story underneath, I think, is that they have all noticed the same thing I noticed in April. The user can route their own calls. The user is starting to. If the wrappers do not own the routing layer, they own a chat panel and an autocomplete and not much else.

The chat panel is real value. The autocomplete is real value. They are not $20 a month of value for a heavy user who would prefer to route directly. They are maybe $5 to $10 a month of value, sized to the actual work they save.

I think we are two quarters away from a wave of users doing this exercise. The wrappers know that. The pricing pages are starting to reflect it.

What I would tell my March self

Three things, in the order they matter.

The first: open the Anthropic dashboard. Look at the input token count on three of your normal Cursor turns. If the number runs more than 3x your direct call baseline, the routing layer is not earning its cost on your usage pattern. That does not mean cancel. That means notice.

The second: log every AI call you make for one week. Cost per call, model picked, prompt length, output length. The log takes twenty lines of code per provider. The data will surprise you. No honest way exists to optimize a bill you cannot see.

The third: write the router. Two hundred lines. The first version does not have to be smart. Five regex rules for intent capture 70 percent of the savings. Iterate on the rules later.

The reason I would tell my March self these things: I would have done the same exercise three months earlier and saved roughly $300 in subscription overlap. The cost of doing the exercise: one Saturday afternoon. The cost of not doing it: whatever your bill grows to in the next quarter, which for most people building with AI right now lands at a number bigger than they want to admit.

What this does not solve

The router does not give me a multi file editing agent. It does not index my codebase. It does not know about my open buffers. It does not autocomplete inline. None of that is its job.

I kept Copilot for the inline ghost text in VS Code, because that is a different product solving a different problem and the $10 is not the line that hurts. For the multi file agent work I would have used Cursor for, I now use Claude Code from the terminal, which I pay for separately through my Max plan. The total stack is cheaper than Cursor plus my old direct API spend.

If your usage pattern is different, your math will be different. If you live in the chat panel and rarely go outside it, Cursor is probably still a fair trade. If your AI work spans chat, agent loops, embedding pipelines, and one off CLI calls, the routing layer is the one piece worth owning yourself.

The closing

The bill came in on April 2. The new bill came in on May 2. The difference between them was 41 percent and 200 lines of code and one weekend afternoon I was going to spend half asleep in front of a movie.

The lesson should have been obvious. The wrappers have an incentive to send more tokens than necessary. The user has an incentive to send fewer. The routing layer is where the two incentives meet. Whoever owns the routing layer wins.

The routing layer can be 200 lines of yours.

What is the line on your AI bill that grew the fastest last month? Drop it in a reply. I read everything.

Written by **GDS K S* (thegdsks.com), building Glincker.*
If this was useful, follow me on X / @thegdsks. I write about the parts of the AI stack vendors keep off the pricing page.

AWS Lambda Is Dead. The $0.20 Was Never the Price

GDS K S — Tue, 12 May 2026 04:24:50 +0000

Last quarter we migrated 47 Lambda functions off AWS. The monthly bill dropped from $8,362 to $1,790. Lambda invocations were 22% of that bill. The rest was the part AWS never put on the pricing page, never put in the AWS Lambda 101 docs, and never came up when our solutions architect ran our forecast workshop in 2024.

We are committing to one position in this piece and we are not flipping at the end. Lambda is dead for the API, webhook, auth, and edge workload that most teams actually deploy. Every comparison article we read while researching the move closed with "but evaluate your needs carefully." That sentence is what kept us on Lambda for an extra year. We are not writing that sentence today.

If you are skimming, the punchline is at the top.

TL;DR

Thing	What it does	Why Lambda loses
INIT billing (Aug 2025)	Cold start init time now bills like duration	The price floor moved up, quietly
The orchestration bundle	API Gateway, CloudWatch, NAT, egress	Lambda is 20 to 40% of your serverless bill
The crossover point	Where Fargate or Workers wins	Moved from 20M to about 2M invocations a month
V8 isolates	Cold start of 2 to 5ms on Workers	No warm-up tax, no provisioned concurrency to buy

1. The $0.20 Per Million Is a Loss Leader

Lambda lists at $0.20 per million requests and $0.0000166667 per GB-second. People build their forecasts on this number. Then the bill arrives and the Lambda line item is a quarter of the total.

A breakdown from a real account, redacted, one month:

Lambda invocations + duration   $1,847   (22%)
API Gateway                     $1,612   (19%)
CloudWatch Logs                 $1,398   (17%)
NAT Gateway hours               $1,287   (15%)
Data egress                     $1,094   (13%)
X-Ray, KMS, Secrets, parameter store   $1,124   (14%)
                              ─────────
Total                          $8,362

Read that table again. Lambda is the fifth column. The wrapper. CloudWatch Logs is bigger. NAT Gateway is bigger. Almost everything is bigger.

Lambda by itself was fine. Lambda inside the AWS bundle was a loss leader for the bundle. CloudWatch Logs at the default ingestion rate eats functions that log a single audit line per call. NAT Gateway hours rack up if your function needs to reach a private RDS or any non-VPC endpoint, which is, you know, basically every real function. Data egress at $0.09 per gigabyte compounds with every response payload.

We have a name for this pattern on our internal docs. The Token Tab. The headline price advertises the wrapper. The real money is in the orchestration around it. AWS did not invent this pattern. AWS just runs the most disciplined version of it.

2. INIT Billing Changed the Floor (And Nobody Noticed)

In August 2025, AWS quietly changed how Lambda billed cold start initialization. Before the change, INIT time was free for managed runtimes. Now it bills as duration.

For a JVM function with 800ms of init, every cold invocation costs an extra 80% on top of the actual work. Boot up Spring Boot? Pay for the boot. Cold start your fat Python ML container? Pay for the import storm.

The change shipped in a release note. Not a keynote. Not a tweet from a Principal Engineer. A release note.

We did not find out about it until April 2026 when we audited a function that was supposed to cost $40 and was billing $110.

Reports floating around early 2026 (source: InfraDecodedOps cold-start teardown):

23% of customer-facing Lambda invocations hit a cold start
p99 cold latency of 1.8 seconds on those endpoints
AWS counters that fewer than 1% of invocations across Lambda are cold

Both numbers are true. The 1% headline reflects hot, internal, async functions running at scale. The 23% reflects what your users actually feel on your auth endpoint at 6:42am UTC when traffic is sparse.

SnapStart helps for Java, Python, .NET. SnapStart does not help for the part of your bill that is API Gateway and NAT.

3. The Crossover Moved (And It Moved a Lot)

Folk wisdom in 2022 was that Lambda was cheaper until you hit roughly 20 million invocations a month. After that, Fargate. After that, real instances.

With INIT billing layered onto the bundle pricing, the crossover is closer to 2 million for typical API workloads. That is an order of magnitude shift in three years. Nobody updated the blog posts.

Monthly cost
   ▲
   │                    ╱── Lambda + bundle
   │              ╱────╱
   │        ╱────╱
   │  ╱────╱─────────── Fargate (1 task, ALB)
   │═════════════════════ Workers + KV/D1
   │
   └──────────────────────►
    0    1M   2M    5M   10M  invocations/mo

Workers stays flat because Workers bills CPU time, not wall clock. If your function waits 200ms on a database response but only burns 15ms of CPU, you pay for 15ms. Lambda bills for the full 200ms.

That is not a small detail. That is the whole game. The typical API spends 80% of its time waiting on a database, a downstream service, or an LLM. Lambda charges you for the wait. Workers does not.

4. The Cope Chart (Optimizations That Do Not Save You)

Things we tried in 2024 and 2025 to "fix" our Lambda bill:

Tactic	Effect on Lambda line	Effect on total bill
Trim function memory	-8% on Lambda	-1.7% on total
Switch Python to Node	-12% on Lambda	-2.6% on total
ARM64 (Graviton2)	-15% on Lambda	-3.3% on total
Add provisioned concurrency	+30% on Lambda	+6.6% on total
SnapStart on JVM functions	-22% on Lambda	-4.8% on total
Audit and prune CloudWatch retention	0	-9% on total
Add VPC endpoints to kill NAT	0	-14% on total

You see the pattern. The Lambda optimizations move the Lambda line a little. The bundle optimizations move the bill a lot. We spent a year picking up dimes on the Lambda line while the bundle was charging us in 50s.

The audit-and-kill-bundle tactics are what actually save money on AWS. Nobody writes blog posts about them because they are not sexy. There is no AWS re:Invent talk about deleting your unused log groups. There should be.

5. Workers vs Lambda, Side by Side

A real example. A signed URL generator for S3, ported to R2 on Workers.

Lambda version:

import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({ region: "us-east-1" });

export const handler = async (event: any) => {
  const key = event.pathParameters?.key;
  if (!key) return { statusCode: 400, body: "missing key" };

  const cmd = new GetObjectCommand({ Bucket: "assets", Key: key });
  const url = await getSignedUrl(s3, cmd, { expiresIn: 300 });

  return { statusCode: 200, body: JSON.stringify({ url }) };
};

Cold start with the SDK loads at 400 to 700ms. Warm at 30 to 80ms. Bills wall clock. Behind API Gateway. Logs go to CloudWatch by default. Outbound to S3 may hit NAT depending on VPC config.

Workers version with R2:

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const key = new URL(req.url).pathname.slice(1);
    if (!key) return new Response("missing key", { status: 400 });

    const obj = await env.ASSETS.get(key);
    if (!obj) return new Response("not found", { status: 404 });

    return new Response(obj.body, {
      headers: { "cache-control": "public, max-age=300" }
    });
  }
};

Cold start at 2 to 5ms (Cloudflare's own dashboards and a six-month production comparison back this up). R2 egress to the public internet is zero. No log retention to forget about. No NAT in the path. The pricing page does not need a footnote.

Same function. Different platform. The bill says everything.

5b. The Platform Comparison

Here is the table that should be at the top of every serverless conversation in 2026. Pricing is approximate and cold starts come from production benchmarks reported by independent teams. The links go to canonical comparison or pricing pages for each platform.

Platform	Cold start	Billing model	Free egress	Sweet spot
AWS Lambda	200-700ms (cold), bills INIT since Aug 2025	Wall clock + bundle	No ($0.09/GB)	AWS-native event glue, GPU jobs
Cloudflare Workers	2-5ms (V8 isolate)	CPU time only	Yes (R2 zero)	HTTP APIs, edge, webhooks
Google Cloud Run	50-200ms	Wall clock	Yes within region	Container portability, ML inference
Azure Functions Premium	Pre-warmed (0)	Flat + per-exec	No	Enterprise, no-cold-start needed
Fly.io Machines	250ms-2s (cold)	Per-second machine	Limited	Stateful regional apps, full VM control
Railway	Container boot	Usage-based	Yes	Solo and small team backend hosting

Baselime reported an 80% cloud-cost drop after migrating from AWS to Cloudflare. Sitepoint published a case study where a team moved their Lambda proxy entirely into the browser and cut their bill from $2,400 to $140 a month. Different workloads, same direction.

6. The Honest Counter (And Why It Does Not Save Lambda)

Three places Lambda still earns its keep. We are not pretending otherwise.

GPU and long-running compute. Workers has a 30-second CPU cap and no GPU. If you are doing inference, video transcoding, or anything past a 30-second budget, Lambda or SageMaker or a real instance is the answer. We kept zero of these. We do not run any.

Heavy AWS-native event glue. If your workload is S3 to DynamoDB to SQS to Step Functions and you never leave AWS, the orchestration bundle is the platform, and Lambda is the right glue. We kept four functions for this. They run for cents.

Sparse async cron jobs. A nightly batch at 3am that runs once a day for 200ms? Lambda is essentially free at that scale. Workers Cron Triggers are also fine. Either works.

Notice what is absent from that list. The typical API. The webhook receiver. The edge function. The auth gateway. The fan-out worker that most teams actually deploy. That whole pile is the dead zone for Lambda in 2026.

If your team's Lambda fleet is mostly the typical API workload, you are in the dead zone whether you have noticed yet or not. The bill will tell you eventually. Usually after a quarterly investor update where someone asks why infrastructure spend grew faster than revenue.

7. The Migration Playbook

If you want to move the workloads that no longer make sense on Lambda:

Pull a 30-day Cost Explorer report. Tag by Lambda function name. Find the top 10 by total cost.
For each, count outbound calls per invocation, average duration, average response size, cold start frequency, and whether it crosses a NAT.
Candidates that move first are HTTP-fronted, low-CPU, high-invocation, network-bound. Those are the ones bleeding wall-clock dollars.
Port to Workers or Cloud Run. Keep the AWS-native event glue on Lambda. Do not try a big-bang migration. Move one function, watch it for two days, move the next.
Watch the bill for two cycles. Decommission API Gateway routes and CloudWatch log groups as functions go quiet. The teardown is where 30% of the savings actually live.

We did this over six weeks. The hardest part was not the rewrites. The hardest part was untangling which CloudWatch log groups still mattered and which ones quietly cost $40 a month to keep indexed. The second hardest part was convincing one of our seniors that the AWS SDK he had written wrappers around for two years was the part we were throwing out.

8. What We Are Not Coming Back For

Lambda was the right shape in 2015. The shape of cloud has moved. V8 isolates that start in 2ms. Container platforms with sub-second cold boots. Edge runtimes that bill CPU instead of wall clock. Those are the new default for the workload Lambda used to own.

We will not migrate back. Not because Workers is perfect, but because the bundle math does not reverse. If AWS dropped Lambda pricing to $0.10 per million tomorrow, our bill would drop by 11%. The other 89% would still be the orchestration tax.

The $0.20 per million was a beautiful marketing line. That was never the price. The price was always the bundle.

The Bottom Line

If your team is building an API in 2026 and Lambda is the first thing on the architecture diagram, ask why. Ask it out loud. The honest answer is almost always organizational momentum, not technical fit. Someone built this pattern at their last job. The first hire wired it up because the AWS reference architecture said to. Nobody questioned it because nobody had time to audit Cost Explorer.

We had that conversation. Six weeks later our bill was 79% smaller and our p99 was 22 times faster.

Lambda is dead for the workload most teams actually run. The pricing page never told you why. The bill always will.

GDS K S · thegdsks.com · follow on X @thegdsks

Lambda is dead for the workloads most teams actually run. The bundle around it was always the real product.

Sources

Sandesh, AWS Lambda Is Your Worst-Performing Cost-Saver: The 2026 Cold Start Data. Source for 23% cold start figure and 1.8s p99.
LeanOps, AWS Lambda Pricing 2026: Costs, Fees and Hidden Traps. Source for 20-40% base Lambda share of total spend.
Alan West, AWS Lambda's Hidden Costs: When to Migrate to Containers. Source for the crossover point math.
Vantage, Cloudflare Workers vs AWS Lambda Cost. Source for CPU-time vs wall-clock pricing breakdown.
Leaper, Cloudflare Workers vs AWS Lambda 2026. Source for 50-80% cost reduction at scale and Baselime case.
Rebal AI, Cloudflare Workers vs AWS Lambda: Six Months of Production Reality. Source for six-month production comparison.
SitePoint, Case Study: Cloud to Local-First AI Migration. Source for the $2,400 to $140 PWA migration.

The first time you watch an AI agent buy something, you will feel something you cannot name.

GDS K S — Sun, 10 May 2026 17:08:53 +0000

A 91 second experiment, an $11.78 charge, and a moment of hesitation that surprised me more than the result.

I knew the agent was going to spend money. I had set the cap. I had created the Stripe Project. I had signed the OAuth flow. I had watched a YouTube demo of somebody else doing the same thing two hours earlier.

When the moment came, my hand still moved toward Control C.

The agent was 38 seconds into its run. It had checked the Cloudflare API, found quiet-thunder-7821.dev available, queried the registrar, and received a 402 Payment Required response with a price of $11.78 for one year. The next thing it would do, in the next four seconds: charge the card.

I let it.

The charge cleared. The domain registered. The Worker deployed. The smoke test passed. The agent printed a URL. I copied the URL into a browser. The page said hi from an agent in plain text on a white background. From the moment I ran the script to the moment the page rendered: 91 seconds.

I sat there for a long minute after that, not doing anything. Just looking at the cursor.

This piece is about that minute.

The protocol, briefly

Cloudflare and Stripe shipped something this week called Machine Payments Protocol. The technical version is HTTP 402 with a JSON price body, OAuth scoped to a per agent Stripe Project, and a default $100 monthly spending cap that lives on Stripe's side. The marketing version is "agents can now provision Cloudflare accounts, register domains, and deploy applications without human intervention".

The cap is the part that lets you sleep. Stripe enforces it server side. The agent cannot raise it from inside its own runtime. If the agent goes wild and tries to spend $5,000 on premium domains, Stripe stops it at $100 and you get a notification. The blast radius stays bounded.

I knew that. I had read the docs page twice. The cap was not the reason my hand moved.

Why my hand moved

The thing I underestimated was the difference between "the agent could spend money" as a concept and "the agent is about to spend my money" as a live event.

I have given AI tools access to my code repository. I have given them access to my email. I have given them production database read credentials. None of those felt the way this felt. The pattern is similar. The instinct was different.

I think the difference is that money is the one resource I have a lifelong physical relationship with. I have handled cash. I have signed checks. I have watched receipts print at gas stations. My brain encoded "spending" through years of physical signal. The mental model for "reading email" did not get the same wiring. When the agent was about to spend, that part of my brain woke up and asked who had approved this.

I had approved it. I had set the cap. The amount was small. My reasoning brain knew that. My reasoning brain was not driving my hand.

I think a lot of the resistance to agentic payments over the next year is going to look like this. Not measured objections. Not policy debates. A specific and slightly embarrassing instinct that fires the first time you watch one happen.

The thing I was not expecting

The agent picked the domain name itself. I had told it to pick something in the format adjective-noun-number.dev. I had not told it to pick quiet-thunder-7821.

I sat with that for longer than I sat with the payment. The payment was a transaction with bounded outcomes. The naming was an aesthetic choice. An aesthetic choice made by software, on my behalf, with my money, about a thing that would now exist in the world under my account and bill to my card every year if I did not delete it.

I do not know what to do with that observation. The agent's choice was fine. quiet-thunder-7821.dev is a perfectly cromulent domain. If you had asked me to pick one in 30 seconds I might have done worse.

But the domain was not mine. The domain belonged to the agent's taste. The card was mine, the legal liability was mine, the renewal would be mine. The taste was the agent's.

This is the part that nobody is talking about yet. The protocol is well designed. The cap is well placed. The OAuth scoping is correct. The unanswered question is what happens when agents start making aesthetic and judgment calls inside the bounds we set for them, and we discover that the bounds were the easy part.

What I did with the domain

I deleted it the next morning. The Worker came down. The DNS unwound. The Stripe Project archived itself with a complete ledger of every cent the agent had touched. Total spend on the experiment: $11.78 for the registration plus a fraction of a cent for the Worker compute.

The deletion took six seconds. The registration was non refundable. So somewhere out there, in a Cloudflare ledger, $11.78 of mine paid for a domain that lived for 14 hours and whose only content was the string hi from an agent.

I am fine with that. The 14 hour domain was the price of the demonstration. The demonstration was worth more than the domain.

What I am going to do next

The next experiment is bigger. I am going to give an agent a slightly larger budget and ask it to spin up a real piece of software. A small SaaS. Frontend, backend, storage, a Stripe Checkout flow that takes payments from real users and routes them to a real revenue split. End to end, from a cold start, with no human in the deploy loop.

I am giving the agent a $200 monthly cap. I am giving it a virtual card with a $300 balance. I am giving it a domain budget of $20. I am scoping the Stripe Project so it cannot reach my main account.

The reason I am doing this is not because I think it will work the first time. I think it will fail somewhere in the middle. I think the failure mode will be interesting. I think the cap will save me.

The reason I am writing it down ahead of time is that I want to commit, in public, to running the experiment without bailing out at the moment my hand moves toward Control C. If you check back in two weeks, I will tell you what happened.

The closing

The first time you watch an AI agent buy something, you will feel something you cannot put a name on. The feeling will fire in the middle of an event you approved, sized correctly, capped appropriately, and conceptually understood. The feeling will not care.

I think the right thing to do with the feeling is to notice it, decide whether to act on it, and let the agent finish if you decide not to. The cap is real. The audit trail is real. The protocol is well designed. The instinct that fires anyway is older than any of those things.

If you are about to run your first agent payment, run it small. Run it on a thing you can delete. Run it when you have time to sit with the cursor for a minute afterward. The minute is part of the experience.

What are you going to give an agent a card for?

Written by **GDS K S* (thegdsks.com), building Glincker.*
If this was useful, follow me on X / @thegdsks. I write about the parts of the AI stack vendors keep off the pricing page.

Anthropic hit B ARR in 16 months. I went looking for where the money is actually coming from.

GDS K S — Sat, 09 May 2026 16:41:10 +0000

A revenue chart that goes vertical does not tell you who pays. It tells you who gets charged.

A friend who runs infrastructure at a 200 person SaaS company called me on Monday. He had just gotten the quarterly bill from his AI vendor through an enterprise contract. He told me the number. I asked him to repeat it.

The number ran high. Not "we are building a foundation model" high. High enough that he had a week of his life mapped out to write a proposal to bring some of the workloads on prem so the company could keep the AI features without the bill getting written into the next earnings call.

That conversation kept me thinking. Anthropic's annualized revenue went from roughly $1 billion in late 2024 to $30 billion as of April 2026. A 30x in 16 months. That is not a SaaS curve. It is not a marketplace curve. It is a curve that comes from a small number of contracts each writing a number with a comma in it.

So I went looking for the line items. Not the press releases. The places the money actually flows from. Here is what I found.

What just happened, in numbers

The revenue trajectory:

Late 2024: ~$1 billion ARR
Mid 2025: ~$5 billion ARR
Late 2025: ~$15 billion ARR
April 2026: ~$30 billion ARR

In April, Anthropic passed OpenAI on revenue for the first time. The two companies shifted from "duopoly with one obvious leader" to "duopoly where the lead changes hands by quarter."

Behind the headline number sits a much smaller story than most people want to make it. The breakdown that leaked out across coverage points to roughly three quarters of revenue coming from API calls, the rest from Pro and Max subscriptions plus smaller enterprise integrations. Within the API revenue, a handful of customers account for an outsized share. AWS, through Bedrock. Microsoft, through the new Copilot integrations. Three hyperscalers and four large coding tool vendors who resell Claude wrapped in their own products.

When Anthropic says they hit $30 billion ARR, the honest reading is: a handful of large enterprise contracts, a handful of large coding tool vendors paying through the nose for Opus 4.7 access on behalf of their users, and a tail of API and subscription revenue from everyone else.

The thing nobody is saying

Individual developers do not write the $30 billion check. Their employers do, twice removed.

Trace the path. A senior engineer at a mid sized company opens GitHub Copilot, picks Claude Sonnet 4.6 from the model dropdown that GitHub added last month, and asks it to refactor a function. That call goes to GitHub. GitHub forwards it to Anthropic. Anthropic charges GitHub the per token API rate. GitHub charges the company a Copilot Enterprise seat plus, starting June 1, premium request budgets. The company charges, ultimately, the customers of its product through whatever line item is closest to "engineering labor cost".

Every leg of that chain takes margin. The model call costs $0.04 in raw inference. By the time three companies have wrapped, billed, and amortized that call, the end customer pays a multiple of the original cost.

Anthropic gets the smallest cut by percentage. They get the largest cut by absolute dollars, because the volume runs enormous and the gross margin on inference at scale runs high. The wrappers earn the rest. The end users notice nothing because the cost lives buried in seat fees and monthly minimums.

That is the mechanism. The $30 billion is not magic. The number reflects the visible part of an iceberg of indirect billing that runs through every developer tool that touched a Claude API key in the last 12 months.

Numbers that matter

A few benchmarks to anchor the scale:

Vendor	Approx ARR	When
Anthropic	$30B	April 2026
Snowflake	$4B	Late 2024
Databricks	$3B	Late 2024
MongoDB	$2B	2024

Anthropic now ranks larger by revenue than any independent data company in history. They got there in two years from product launch. The closest comparable: the early growth of AWS, which took eight years to reach the same scale and had Amazon's retail business funding it.

The other number that matters: gross margin. Public analyst estimates put inference gross margin at large hyperscale operators in the 50 to 70 percent range. If Anthropic sits at the lower end, $30 billion ARR generates roughly $15 billion in gross profit. That covers a lot of training compute. Not yet a lot of net profit, because training the next model class still costs enough to consume most of the gross.

Which is where the pressure on the consumer subscriptions comes from. Pro plan subscribers cost more to serve than they pay, on average, when they use Claude Code heavily. Enterprise customers pay per token and are profitable per call. The math points in one direction. Optimize for the segment that pays per use. Defend the consumer segment as a brand and onboarding play, but do not let it grow faster than the gross can carry.

The honest take

The thing that makes this market different from past compute waves: cost scales hyper in both directions. A single team using Claude Code aggressively can spend more in a month than they did on cloud the entire previous year. A single agent loop run wrong can spend a thousand dollars overnight. The unit economics of an inference call now drive the unit economics of software.

Exhilarating if you build the wrappers. Uncomfortable if you write the checks. The companies my friend works with are realizing that the line item labeled "AI tooling" will keep growing every quarter for the foreseeable future, because the tools are getting better at burning tokens, not just at writing code.

Two things follow.

First, the wrapper layer holds the next big margin compression. Every coding tool that resells Claude or GPT sells on convenience, not on inference cost. The convenience is real. The convenience is also not defensible. Anyone with two days and an API key can build a thinner wrapper for their own team that captures 80% of the value. The wrappers know this. That explains why GitHub, Cursor, and Windsurf have all announced model dropdowns and pricing tiers in the last 90 days. They are racing to build platform features around the model so that switching costs grow before the customer notices the bill.

Second, the agentic workflow becomes the new unit. Inference cost per chat message converges across vendors and approaches a floor. Inference cost per agent run varies by ten times depending on how you write the agent. The next wave of optimization work happens here, and individual engineering teams can actually move the needle on their own bills without waiting for the vendor to drop prices.

What I am doing about it

Three concrete things, in case they help.

I cancelled the AI seat subscription that I was using for chat and switched to direct API access via a small script. The gross saving is small. The visibility is large. I now know exactly what each conversation costs.

I built a multi model router that picks the cheapest model that can do the job. About 60 percent of my queries route to Haiku. The bill dropped 41 percent in the first month with no perceptible quality loss on the routed traffic.

I started logging the cost of every AI call in our internal projects, broken out by feature. The first week of data was an unflattering surprise. One feature accounted for half the bill. We cut its budget by limiting context length and the entire feature still works. Nobody noticed.

None of this is novel. Old infrastructure habits applied to a new compute primitive. The only reason these moves feel novel: the AI vendor pitch has read "do not worry about the cost, the wrapper handles it" for so long that thinking about the bill counts as a contrarian position.

The closing

The headline number is real. The story behind it runs smaller and stranger than it sounds. A handful of contracts with hyperscalers. A handful of coding tool vendors paying through the nose to put Opus 4.7 in front of their users. The rest: a fast growing tail of API and subscription revenue from individual developers and small teams.

Anthropic earned the number. They built the better model, they shipped the better agent, and the market rewarded them with a revenue chart that reads more like an oil discovery than a software company. None of that comes off as wrong.

Worth keeping in mind: a feedback loop funds the chart. Better model. More usage. Higher bill. Higher bill funds more training. More training produces a better model. The loop runs as long as the customers keep paying without flinching. The day they flinch will be the day the wrapper market starts compressing and the routing layer becomes the most valuable real estate in the AI stack.

I think that day comes sooner than the press releases suggest. The pricing tremors of April 2026 are the early reading. Watch the bill.

Written by **GDS K S* (thegdsks.com), building Glincker.*
If this was useful, follow me on X / @thegdsks. I write about the parts of the AI stack vendors keep off the pricing page.

Anthropic just rented Elon Musk's data center. The price of a Claude token is about to make sense.

GDS K S — Thu, 07 May 2026 13:25:45 +0000

A 300 megawatt deal, a $180 a month decision, and the strange feeling of having a vendor solve your problem 12 minutes before you were about to pay them more.

I had the Anthropic billing page open. Two columns. Max 5x on the left, what I was paying. Max 20x on the right, what I was about to pay. The difference was $180 a month. The reason for the difference was that my Tuesday night Claude Code sessions had started bumping into the peak hour throttle, and the throttle was making the agent loop sluggish in the exact moments I needed it to be fast.

I was on the upgrade page because I had decided, two days earlier, that another $180 a month was a fair price for not having to feel the throttle. I had walked away from the page once already. I had come back. The cursor was hovering over the Confirm button.

A friend texted me a CNBC link.

I read the headline. I read the subhead. I closed the upgrade tab.

The headline said Anthropic had signed a deal with SpaceX for 300 megawatts of compute capacity at the Memphis Colossus 1 data center. Two hundred and twenty thousand NVIDIA GPUs coming online within a month. The blog post Anthropic put out alongside it said the new capacity would lift peak hour reductions on Pro and Max accounts and raise per request limits on Opus.

In other words, the throttle I was about to pay $180 a month to outrun was about to ease on its own. Within 30 days. For free.

This piece is about why I think that timing matters more than the headline lets on.

The throttle was telling us something

For the last 60 days, every Anthropic pricing headline read like a tighter limit. April 21, the brief disappearance of Claude Code from the $20 Pro plan. Late April, the weekly caps creeping down. Early May, the peak hour reductions that pushed me to consider Max 20x in the first place.

I had read those moves the way I think a lot of users read them: as repricing. As Anthropic discovering that the bundle did not work at current usage levels and starting to walk it back. The implicit story was about cost.

The SpaceX deal tells me the story was always about capacity. Not what the inference cost, but how many requests the existing fleet could serve at peak. When you cannot serve every customer who wants in, you do not raise prices. You throttle. The throttle looks like a pricing problem from outside. Inside, the throttle is a queue.

A 300 megawatt deal solves a queue. Repricing solves a cost problem. The fact that Anthropic chose to spend a number with three commas in it on capacity, rather than push a price increase to the existing fleet, tells you which problem they thought they had.

The implication for those of us watching the pricing page: the moves of the last two months were tactical, not structural. They are reversible. The SpaceX deal is the reversal.

What changes for the Max 5x holder

I am going to be specific because vague is what made me almost hit Confirm.

Max 5x today gets me roughly 5x the messages and Claude Code usage of Pro, with peak hour reductions kicking in around 4 PM Eastern on weekdays. The reductions are not a hard cap. They slow my agent loop down by about 30 to 40 percent during the affected window. On a Tuesday night when I am in the middle of a refactor, that 30 to 40 percent feels like sand in the gears.

Max 20x removes most of the peak reductions and lifts the message ceiling four times over. The price is around $200 a month, give or take depending on the billing cycle.

The SpaceX capacity comes online in 30 days. According to Anthropic's own messaging, peak hour reductions on Max accounts ease as that capacity lights up. The question for me, sitting on the upgrade page, became: am I willing to pay $180 a month for the next 30 days of unthrottled access, knowing that by month two the throttle on Max 5x will likely ease anyway?

I closed the tab. I am going to let the 30 days play out. If by mid June my Tuesday nights still feel like sand, I will revisit. If they do not, I just kept $180.

I am not telling everybody on Max 5x to do the same. I am suggesting everybody on Max 5x should pause before clicking Confirm. The new capacity is real and the timeline is short.

The wrappers should be more nervous than they look

Cursor, GitHub Copilot, Windsurf. They all resell Claude under their own pricing. They all spent the last two months absorbing the same throttle I was feeling. Their tactic: a pricing change of their own (premium request budgets, daily quotas, model dropdowns) that pushed some of the cost back onto the user.

When Anthropic's serving capacity doubles in 30 days, the wrappers lose part of their pitch. The pitch was something like: we route around the capacity issues so you do not have to. If there are no capacity issues to route around, the routing layer is doing less work, and the user is paying for that routing in a seat fee that just got harder to justify.

I do not think the wrappers go away. I think the conversation with their CFO gets harder in Q3. The numbers that mattered for the last 12 months were "we provide reliable capacity". The numbers that will matter for the next 12 are "we provide better routing than you can build yourself". The first one was easy to charge for. The second one is a much harder sell when the user can write 200 lines of TypeScript and have the routing themselves.

The orbital footnote

I want to mention this and then drop it, because I do not want it to swallow the piece. The SpaceX press release also said Anthropic had expressed interest in working with SpaceX to develop gigawatts of compute capacity in space. Not next year. Not anytime soon. The phrase: "expressed interest".

That sentence will spawn a thousand think pieces about orbital data centers. Most of them will be silly. The line shows up in the press release because the comparative cost of cooling at orbit gets interesting once you are spending hundreds of millions a year on terrestrial cooling, and SpaceX has the only credible path to mass orbit at a price that makes the math work.

I am not writing that think piece today. I just want the record to show that the line was in the announcement. In 18 months somebody will argue Anthropic hid it, and the receipts will say otherwise.

What I am going to do

Three things, all small.

Sit on Max 5x for 30 more days. Watch the peak hour throttle. If it eases, the upgrade decision is dead. If it does not, I revisit.

Log my Anthropic API spend daily, not weekly. The 30 day window is short enough that a weekly snapshot misses the inflection. Daily is cheap to set up. I want a clean before and after on the throttle change.

Send the upgrade page screenshot to the Glincker channel as a reminder. The thing I almost did made sense at the moment I almost did it. Twelve minutes later, the same decision read wrong. The lesson: pricing decisions made under throttle differ from pricing decisions made when the throttle is going away. Wait if you can.

The closing

I had the upgrade page open. The cursor was hovering. A friend sent a link. I closed the page.

The thing I want you to take, if you take anything: when a vendor announces capacity that solves the exact problem you were about to pay them more to outrun, wait. Not forever. Thirty days. The cost of waiting is one Tuesday night with a slow agent. The cost of upgrading is $180 a month, every month, until you remember to cancel.

Most of us are not going to remember to cancel.

If you are on Max 5x and were eyeing Max 20x for the same reason I was, the only honest take I can give you is the one I gave myself this afternoon. Watch the throttle through the first week of June. Decide then. The capacity will have arrived or it will not. Right now we do not know. Spending $180 to find out is not the right way to learn.

What is on your billing page right now that you were about to upgrade?

Written by **GDS K S* (thegdsks.com), building Glincker.*
If this was useful, follow me on X / @thegdsks. I write about the parts of the AI stack vendors keep off the pricing page.

I built a 200 line AI router in TypeScript. My monthly bill dropped 41%.

GDS K S — Thu, 07 May 2026 03:34:05 +0000

I track my own AI spend across three projects. In March, the line item that grew fastest was not Claude or GPT calls. It was my Cursor seat plus my Copilot seat plus the Anthropic API I was hitting from a personal CLI. Three subscriptions, three meters, and the same Opus tokens billed twice because Cursor was sending the same context to its own backend that I was already passing through to Anthropic directly.

The wrappers do not advertise this. The router code is not their product. The product is the convenience of not thinking about which model handles which prompt. You pay the orchestration tax in margin baked into the seat price.

I got tired of paying it. So I wrote the router. It is 200 lines of TypeScript. My April bill came in 41% under March on roughly the same volume of work.

TL;DR

Model	Input $/M tokens	Output $/M tokens	Best for
Haiku 4.5	0.80	4.00	Lookups, classification, typo fixes
Sonnet 4.6	3.00	15.00	Default coding, refactors, code review
Opus 4.7	5.00	25.00	Multi step planning, architecture
GPT-5 mini	0.50	2.00	Cheap classification, embeddings prep

The 41% saving came from one thing: stopping Sonnet from handling tasks that Haiku could finish in a tenth of the cost. Most coding queries are lookups dressed up as questions. Route by intent, not by habit.

1. The orchestration tax is real

Every wrapper makes the same trade. They pick a model for you, they prepend a system prompt you cannot edit, and they hold a context window you cannot inspect. In return, you do not have to think.

The cost of not thinking shows up two ways:

The wrapper calls the most expensive model that fits its SLA, because that is what makes the demo look good
The wrapper bills you for context it sent on your behalf, including its own system prompt and tool definitions

I logged 30 days of Cursor usage against the Anthropic dashboard. Cursor was sending an average of 8,400 input tokens per chat turn. My direct API calls for the same chats averaged 1,900. The 6,500 token delta is Cursor's frame, plus indexing context, plus its agent scaffolding. Useful, but not free.

When you build the router yourself, you choose what to send. That is the whole game.

2. The 200 line router

Here is the file. Drop it in a project, give it your API keys, and it picks a model per request based on rules you control.

// router.ts
import Anthropic from "@anthropic-ai/sdk";
import OpenAI from "openai";

type Intent = "trivial" | "code" | "plan" | "embed";

interface RouteRule {
  match: (prompt: string) => boolean;
  intent: Intent;
}

interface ModelConfig {
  provider: "anthropic" | "openai";
  model: string;
  maxTokens: number;
}

const ROUTES: Record<Intent, ModelConfig> = {
  trivial: { provider: "anthropic", model: "claude-haiku-4-5-20251001", maxTokens: 1024 },
  code: { provider: "anthropic", model: "claude-sonnet-4-6", maxTokens: 4096 },
  plan: { provider: "anthropic", model: "claude-opus-4-7", maxTokens: 8192 },
  embed: { provider: "openai", model: "gpt-5-mini", maxTokens: 512 },
};

const RULES: RouteRule[] = [
  { intent: "trivial", match: (p) => p.length < 200 && /\?$/.test(p.trim()) },
  { intent: "trivial", match: (p) => /^(what is|define|fix typo|rename)/i.test(p) },
  { intent: "plan", match: (p) => /(refactor|design|architect|migrate|plan)/i.test(p) },
  { intent: "code", match: (p) => /(```
{% endraw %}
|function |class |const |let )/i.test(p) },
  { intent: "embed", match: (p) => p.startsWith("CLASSIFY:") },
];

function pickIntent(prompt: string): Intent {
  for (const rule of RULES) {
    if (rule.match(prompt)) return rule.intent;
  }
  return "code";
}

const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export interface RouteResult {
  text: string;
  model: string;
  inputTokens: number;
  outputTokens: number;
  costUsd: number;
}

const PRICING: Record<string, { in: number; out: number }> = {
  "claude-haiku-4-5-20251001": { in: 0.8, out: 4 },
  "claude-sonnet-4-6": { in: 3, out: 15 },
  "claude-opus-4-7": { in: 5, out: 25 },
  "gpt-5-mini": { in: 0.5, out: 2 },
};

function priceCall(model: string, inTok: number, outTok: number): number {
  const p = PRICING[model];
  if (!p) return 0;
  return (inTok * p.in + outTok * p.out) / 1_000_000;
}

export async function route(prompt: string): Promise<RouteResult> {
  const intent = pickIntent(prompt);
  const cfg = ROUTES[intent];

  if (cfg.provider === "anthropic") {
    const r = await anthropic.messages.create({
      model: cfg.model,
      max_tokens: cfg.maxTokens,
      messages: [{ role: "user", content: prompt }],
    });
    const text = r.content
      .filter((b) => b.type === "text")
      .map((b) => (b as { text: string }).text)
      .join("");
    return {
      text,
      model: cfg.model,
      inputTokens: r.usage.input_tokens,
      outputTokens: r.usage.output_tokens,
      costUsd: priceCall(cfg.model, r.usage.input_tokens, r.usage.output_tokens),
    };
  }

  const r = await openai.chat.completions.create({
    model: cfg.model,
    max_tokens: cfg.maxTokens,
    messages: [{ role: "user", content: prompt }],
  });
  const usage = r.usage ?? { prompt_tokens: 0, completion_tokens: 0 };
  return {
    text: r.choices[0]?.message?.content ?? "",
    model: cfg.model,
    inputTokens: usage.prompt_tokens,
    outputTokens: usage.completion_tokens,
    costUsd: priceCall(cfg.model, usage.prompt_tokens, usage.completion_tokens),
  };
}
{% raw %}

That is it. Two providers, four intents, five rules, and a cost calculator. Use it like this:


typescript
import { route } from "./router";

const out = await route("rename this function from getUser to fetchUser");
console.log(out.model, out.costUsd.toFixed(5));
// claude-haiku-4-5-20251001 0.00012

The rules are deliberately dumb. Length plus regex covers maybe 70% of routing decisions correctly. For the other 30%, override with a prefix:


typescript
await route("[force:opus] design a permissions model for ...");

Add a one liner to pickIntent to read the prefix. I left it out to keep the example tight.

3. Routing rules that actually work

The naive approach is to send a tiny classifier call to a cheap model and have it pick the route. That sounds smart and costs more than it saves, because every request now eats two API calls. The cost of pickIntent must be zero.

Five regex rules cover most of my workload:

Short and ends in a question mark: trivial
Starts with "what is", "define", "fix typo", "rename": trivial
Contains "refactor", "design", "architect", "migrate", "plan": plan
Contains code fence or function keyword: code
Starts with "CLASSIFY:" prefix: embed (cheap classifier)

Default to code. A wrong route from trivial to code costs maybe 4x more on that one request. A wrong route from code to opus costs 1.6x. Neither is a disaster. The bug to avoid is sending Haiku a multi step plan it cannot hold context for, which means default conservatively.

I also log every miss. After two weeks I had a small CSV of "this prompt routed to X but should have been Y". I added two regex rules and the miss rate dropped from 8% to under 2%.

4. The 41% number, broken down

March bill, no router:

Source	Calls	Spend
Cursor seat	n/a	$20
Copilot seat	n/a	$10
Anthropic direct	4,200	$87
OpenAI direct	800	$14
Total		$131

April bill, with router (cancelled Cursor, kept Copilot for IDE inline only):

Source	Calls	Spend
Cursor seat	n/a	$0
Copilot seat	n/a	$10
Anthropic via router	5,100	$54
OpenAI via router	1,400	$13
Total		$77

That is 41% lower on 30% more total calls. The router shifted 62% of calls onto Haiku, which was eating workloads Sonnet had been handling. Average cost per call dropped from $0.024 to $0.013.

The Cursor cancel did the headline saving. The router did the smaller, repeating, compounding saving. Both come from the same idea: the wrapper is hiding decisions you could make better yourself.

5. What this does not do

This is not an agent framework. It does not stream. It does not retry. It does not cache. It does not handle rate limits. It does not do tool use. It does not know about your codebase.

Adding any of those takes work. Streaming is two changes. Caching with the Anthropic prompt cache is one extra header on each call. Retries with exponential backoff is 20 lines. Tool use requires schema plumbing you would write anyway.

If you need all of that, use a real framework. If you want to stop paying the orchestration tax on 80% of your calls, the 200 lines above will do it. Add the rest as you actually hit each problem.

Conclusion

Wrappers exist because routing AI calls is annoying. It is also the highest leverage thing you can own in your own code. The 200 lines above are not a moat. They are a Tuesday afternoon. The reason to write them is that you cannot improve a bill you cannot see.

What is your current ratio of cheap model to expensive model calls? If you do not know, that is the first thing to fix. Wire up cost logging before you wire up the router. The numbers will surprise you.

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

The orchestration tax is the part of the AI bill that does not show up on the pricing page.

Cloudflare and Stripe just let agents buy domains and ship code. Here is the API.

GDS K S — Thu, 07 May 2026 03:27:56 +0000

On April 30, Cloudflare quietly published a blog post and a docs page that nobody outside the agentic AI crowd noticed for about 24 hours. The headline buried a real shift. AI agents can now provision a Cloudflare account, register a domain, attach a Stripe payment method, deploy a Worker, and hand you back a live URL. With a single CLI command. With no human in the loop after you accept terms and add a card.

Stripe Projects is the open beta side. The Cloudflare Agents SDK is the runtime side. The protocol underneath is called Machine Payments Protocol (MPP), co authored by Tempo Labs and Stripe, with x402 (HTTP 402 Payment Required) doing the actual money plumbing. The whole thing went live this week.

This is the first time the major infra players have published a real specification for "agent buys thing, deploys thing, pays for thing" without manual intervention. The spec is short. The implications are not.

TL;DR

Capability	Who provides it	What it costs
Agent provisions Cloudflare account	Cloudflare Agents SDK	Free in beta
Agent registers domain	Cloudflare Registrar via MPP	At cost, $100/month default cap
Agent attaches payment	Stripe Projects	Card on file at parent Stripe account
Agent deploys Worker, Pages, R2	Workers platform	Per usage, agent metered
Spending guardrail	Per provider cap, default $100/month	Caller controls

1. The protocol in one paragraph

Three components. Discovery is a REST/JSON catalog where each provider publishes what an agent can buy from them and at what price. Authorization uses identity attestation plus OAuth, so the agent calls under a delegated identity scoped to your Stripe project. Payment uses tokenization through Stripe with a default $100/month per provider spending cap, which you can raise or lower per project.

That is the whole protocol. The cleverness is that x402 turns "you owe money for this API call" into a normal HTTP response status. The agent sees a 402, looks up the price, decides if it can pay, and either pays or asks for a higher cap. No new wire format. No new auth scheme. Just HTTP.

2. The CLI command that started it

stripe projects init my-side-project

That command does five things in sequence:

Creates a Stripe Project (a sandboxed sub account scoped to one agent run)
Provisions API credentials and an OAuth token for the agent
Connects the project to your Stripe account's payment methods
Sets a default monthly spend cap (you override with --cap 200)
Outputs a .stripe-project.json that the Cloudflare Agents SDK reads

After that, an agent calls Cloudflare with the OAuth token, gets a workers account, registers myproject.dev, deploys a Worker, and emits the live URL. End to end, in the demos, around 90 seconds.

3. The code an agent runs

Here is roughly what the Cloudflare Agents SDK invocation looks like for an agent that builds and deploys a small TypeScript service. I have stripped error handling so the shape is visible.

import { CloudflareAgent } from "@cloudflare/agents-sdk";
import { StripeProjectAuth } from "@stripe/agents";

const auth = await StripeProjectAuth.fromEnv();
const cf = new CloudflareAgent({ auth });

// 1. Get or create an account
const account = await cf.accounts.ensure({ name: "demo-account" });

// 2. Buy a domain (this hits MPP under the hood, returns 402 first call)
const domain = await cf.registrar.purchase({
  name: "my-side-project.dev",
  budgetUsd: 12, // hard ceiling for this call
});

// 3. Deploy a Worker with the source
await cf.workers.deploy({
  account: account.id,
  name: "hello",
  script: `
    export default {
      async fetch(request) {
        return new Response("hi from an agent");
      }
    };
  `,
  routes: [{ pattern: `${domain.name}/*`, zone_id: domain.zone_id }],
});

// 4. Tell the human
console.log(`live at https://${domain.name}/`);

Three points worth pulling out.

The budgetUsd parameter is per call. The Stripe Project's monthly cap is the global ceiling. So you have two layers: a per request budget (so the agent cannot accidentally spend $50 on a single domain it should not have bought) and a per provider cap (so the agent cannot spend more than $100 in a month total at Cloudflare). Both are enforced server side on Stripe's end. The agent cannot bypass them by editing client code.

The OAuth token from StripeProjectAuth.fromEnv() is scoped to the project. If you revoke the project, the token dies. There is no way for the agent to reach into your main Stripe account or your other projects.

The MPP 402 flow is invisible in the snippet above. Behind the scenes, the SDK retries the registrar call with a payment authorization header after seeing the 402. You can hook into that with a onPayment callback if you want a confirmation step. Most agents will not.

4. Where the safety story is real and where it is not

Real:

The $100 default cap is server enforced. Agent cannot raise it from inside the agent runtime.
OAuth scoping is per project, not per Stripe account. Compromise of a single agent run does not reach your other money.
The budgetUsd per call is a hard ceiling, not a hint.
Stripe ledger logs every cent. You see exactly which agent run spent what.

Not real:

The agent can still loop. A buggy agent that calls domain.purchase in a retry loop will hit the cap, but it will hit it fast. The cap stops the bleeding, not the bug.
The agent decides what to deploy. If the prompt was "build me a phishing kit", the agent will buy a domain and deploy a phishing kit. Cloudflare and Stripe screen for known abuse patterns, but the threat model is "agent acting on a legitimate user's behalf for an illegitimate purpose" and that is not solved.
The "stripe projects init" gives the agent a card. You authorized that card. If you give the agent a card that is also your personal card, the agent can spend up to the cap on stuff you would not have bought.

The mitigation pattern that works today: create a Stripe Project per agent run, attach a virtual card with a $100 balance, give the agent the project, and burn the project when the run finishes. You can script this in 10 lines.

5. What this changes in practice

Three things become possible that were not yesterday.

Agents that can finish. Most coding agents today produce a PR or a local file and stop there because deploying needs human credentials. With this, the agent can ship. That changes how you think about iteration: the loop is no longer "agent writes code, human deploys, human tests" but "agent writes, agent deploys, human reviews live".

Cost as a programmable signal. The 402 response with a price is data the agent can reason about. An agent that wants to register a domain can compare prices across registrars and pick the cheapest. An agent that needs storage can decide between R2 and S3 based on the per request fee. This is the first time price has been a first class API parameter in a way agents can actually use.

Per agent budgets as a defense layer. Today most teams running agents in production have a single API key with a monthly cap on the underlying model provider. With this, you can give each agent run its own scoped budget across compute, storage, and DNS at the same time. That is a much sharper control than you had before.

At Glincker we wired this in last night

Our internal agent that drafts and tests code for our content engine now has its own Stripe Project with a $25 weekly cap. It can register subdomains for staging tests, deploy preview Workers, and tear them down when the test finishes. Before, those steps required a human to provision and manually delete. The cap is the only thing standing between us and a runaway loop, and so far the cap has done its job.

The thing I was nervous about before flipping it on was a buggy retry loop burning $25 in 30 seconds. That has not happened, but I want to log a few hundred runs before I trust it. If you do this, log every 402 and every successful payment with the agent run ID. You will catch the loop the first time it happens.

The bottom line

This is the first agentic payment protocol from infrastructure providers that ships with real guardrails and a real spec. The spec is small enough to read on a Tuesday lunch. The implementation already works. The cap is not a substitute for thinking about the threat model, but it is a real cap.

If you build with agents, this is a control plane you have wanted for a year. If you do not, the existence of this protocol is a sign that the question "should agents spend money" has officially shifted to "how do we put the right limits on what they spend".

What are you about to give an agent a card for? I want to read the answer in the comments.

GDS K S · thegdsks.com · building Glincker · follow on X @thegdsks

Agents with a card change the threat model from "what can it do" to "what can it spend before you notice".

Giving an AI agent permission to spawn sub-agents (without losing control)

GDS K S — Sun, 03 May 2026 22:14:05 +0000

Giving an AI agent permission to spawn sub-agents (without losing control)

A reader asked me last week: "If my main agent spawns a sub-agent, what permissions does the sub-agent get? How do I make sure it cannot do more than the parent?"

This is the agent delegation problem. It comes up the moment you have agents that work in tandem. A planner that hands off to a coder. An orchestrator that fans out to specialists. An MCP server that calls another MCP server on a user's behalf.

The naive answer is: give the sub-agent the same API key as the parent. This is wrong. Once you do that, the sub-agent can do everything the parent can. If it goes off the rails, you cannot kill it without killing the parent. There is no audit trail per agent. You cannot apply different rate limits.

The right answer is scoped delegation with revocation. Here is what that looks like.

What scoped delegation means

When the parent agent spawns a sub-agent, it issues the sub-agent a token that:

Is its own credential, not a copy of the parent's
Inherits a subset of the parent's permissions, never more
Has a parent reference, so revoking the parent revokes everything downstream
Has its own expiry, separate from the parent
Has a depth limit, so a sub-agent of a sub-agent of a sub-agent eventually hits a wall

KavachOS calls this a delegation chain. The data model is:

parent_agent (token A)
  └── sub_agent_1 (token B, parent=A, scopes ⊆ A)
        └── sub_agent_2 (token C, parent=B, scopes ⊆ B)

Revoking A revokes B and C. Revoking B revokes only C. Each token has its own audit trail.

Code

import { createKavach } from "kavachos";
import { delegate, revoke } from "kavachos/agent";

const kavach = await createKavach({
  database: { provider: "sqlite", url: "kavach.db" },
});

// parent agent has a token with these scopes
const parentToken = await kavach.agent.issue({
  agentId: "planner-001",
  scopes: ["github:read", "github:write", "deploy:staging"],
  ttl: "1h",
});

// parent spawns a coder sub-agent
// it can read and write GitHub, but not deploy
const coderToken = await delegate(parentToken, {
  agentId: "coder-001",
  scopes: ["github:read", "github:write"],  // dropped deploy:staging
  ttl: "30m",                                // shorter than parent
  maxDepth: 1,                               // coder cannot spawn its own
});

The delegate call:

Verifies the requested scopes are a subset of the parent's
Throws ScopeEscalationError if the sub-agent asks for a scope the parent does not have
Sets parent_token_id so revocation cascades
Issues a fresh token with its own JTI

// this throws: ScopeEscalationError
const badToken = await delegate(parentToken, {
  agentId: "rogue-001",
  scopes: ["github:read", "deploy:production"],  // parent does not have it
});
// kavach.error.code === "SCOPE_ESCALATION"

The library refuses to issue a token with scopes the parent does not have. This is enforced at issue time, not at validation time, so a misbehaving caller cannot sneak it through.

Revocation

await revoke(parentToken);
// every descendant token is also revoked

Behind the scenes, KavachOS marks the parent token id as revoked. Any token with parent_token_id matching it (recursively) is rejected on next validation. The agent table has an index on parent_token_id so this stays fast.

You can also revoke a single sub-agent without touching the parent:

await revoke(coderToken);
// parent and other siblings keep working

Audit

Every action an agent takes through KavachOS goes into the audit log:

{
  event: "tool.call",
  agent_id: "coder-001",
  parent_agent_id: "planner-001",
  scope: "github:write",
  resource: "repos/kavachos/kavachos/contents/README.md",
  timestamp: "2026-04-29T11:42:13Z",
  request_id: "req_abc123",
  outcome: "allowed"
}

When something goes wrong at 3am, you can trace exactly which sub-agent of which parent of which root user did what. This is the answer to "the agent merged a bad PR" type incidents. Without it, you have a Slack message with no fingerprint.

Why depth limits matter

A planner spawns a coder. The coder spawns a tester. The tester spawns a fixer. The fixer spawns a re-tester. At some point, the chain has to stop. Otherwise an agent stuck in a loop can consume all your tokens and rate limits.

const parentToken = await kavach.agent.issue({
  agentId: "planner-001",
  scopes: ["github:read", "github:write", "deploy:staging"],
  maxDepth: 3,
  ttl: "1h",
});

The fourth-level descendant fails to issue. You catch this in your orchestrator and decide how to handle it: escalate to a human, fail the task, or split the work differently.

Where this matters most

This pattern is what enterprise will demand once agents are doing real work. Right now most teams ship with shared API keys and a hope. That works until it does not. When it does not, you are trying to reconstruct what happened from log fragments.

Building this from scratch is doable but boring. Token issuance is straightforward. Cascading revocation is not. Depth tracking takes care to get right. The audit log is its own project.

If you do not want to build it yourself, KavachOS handles all of it as a primitive in the same library that does human auth.

npm install kavachos

Source: github.com/kavachos/kavachos. MIT.

If you run multi-agent systems in production today, how do you scope sub-agent permissions? Shared API keys? Per-agent tokens? Something stricter? Curious where the pain is for you.

Free SVG brand icons in 2026: thesvg.org vs svgl vs Simple Icons

GDS K S — Sat, 02 May 2026 18:01:02 +0000

If you need brand logos for a dashboard, a marketing page, or a "trusted by" section, the answer in 2026 is no longer just Simple Icons. Three libraries now cover most real-world needs, and they win on different brackets.

This post is the comparison I wish existed when picking one for a recent build. Real numbers, no invented benchmarks, honest tradeoffs.

TL;DR

Library	Icons	Color	License	Best for
Simple Icons	3000+	Monochrome only	CC0	Footer rows, social icons
svgl	657	Full color, dual variants	MIT	Curated brand grids, design references
thesvg.org	5600+	Full color, multi-variant per brand	Free, no attribution	Brand dashboards, logo walls, marketing pages

If you need an aggregator across 200+ icon sets (Lucide, Heroicons, Material, plus brand sets), Iconify is the long-tail option. It is not in the same category as the three above, so I leave it out of the head-to-head.

1. Simple Icons

Simple Icons is the historical default for free SVG brand icons. Three thousand plus brands, all monochrome, CC0 license. You import what you need.

The catch hides in the word "monochrome." Every icon ships as a single-fill SVG. Stripe renders purple in real life. Visa is blue and yellow. Slack uses four colors. Simple Icons gives you the silhouette and a hex code in the metadata. You apply the brand color yourself.

import { siStripe } from 'simple-icons/icons';

export function StripeIcon({ size = 24 }: { size?: number }) {
  return (
    <svg width={size} height={size} viewBox="0 0 24 24" fill={`#${siStripe.hex}`}>
      <path d={siStripe.path} />
    </svg>
  );
}

That works for footer rows where everything renders at one size with one color. It does not work when a designer asks for the actual Stripe gradient, or when you need both the wordmark and the symbol.

The bundle question matters too. The full Simple Icons npm package weighs around 13 MB unpacked. Modern bundlers strip what you do not import, but a Next.js build can pull in the whole package because of a barrel file. Import per-icon paths to be safe.

2. svgl

svgl is a curated collection of brand SVGs that has gained traction over the past two years. As of writing, the site shows 657 logos across categories like AI, Analytics, Browser, Database, Devtool, Framework, Hosting, Payment, and Social.

The strength is curation. Every entry looks production-ready. The Adobe entries, for example, ship both color and grayscale variants, so you can match the surrounding UI without hunting for an alternate file. The MIT license keeps usage simple.

The tradeoff is breadth. 657 logos cover popular SaaS, dev tools, and consumer brands, but if your fintech dashboard needs every regional bank or every payment processor in a niche market, you will hit gaps. svgl also leans on a copy-from-site model rather than a heavy npm install, which is good for bundle size and works as long as you have network at build time.

3. thesvg.org

Disclosure: thesvg.org is my project.

thesvg.org is a free brand SVG library focused on coverage and clean source files. The current catalog is 5600+ icons, with several variants per brand where the brand ships them (typically a wordmark, a symbol, and a monochrome version). License: free, no attribution required.

npm install thesvg

Browse and download from thesvg.org. The site supports category filtering (AI, Analytics, Browser, Database, Devtool, Framework, Hosting, Payment, Social, plus dozens more) and alphabetical sort, so finding a specific brand takes seconds.

The pitch is breadth at a strong fidelity bar. 5600+ vs 657 is the headline number. The structural choice that matters for production work is consistent variant coverage: when you build a logo wall, you want every brand to ship a symbol and a wordmark in the same SVG style, not a mix of "we got this one as a square avatar and that one as a horizontal logo."

The tradeoff is curation overhead. Adding a brand correctly means sourcing the original, optimizing through SVGO with a per-brand config, naming the variants, and verifying the output renders the same on dark and light backgrounds. The library trades faster growth for cleaner files.

4. The structural comparison

I will not invent benchmarks I have not run. Instead, here is how the three stack up structurally on the dimensions that actually matter on a real project.

Dimension	Simple Icons	svgl	thesvg.org
Smallest bundle (monochrome)	Wins	n/a	n/a
Best curation per icon	Tie	Wins	Wins
Most full-color brands	n/a	n/a	Wins
Variant coverage (symbol + wordmark + mono)	n/a	Partial	Wins
Easiest CDN drop-in	Tie	Wins	Wins
License simplicity	CC0	MIT	Free, no attribution

If you want hard byte numbers, run the same component three ways on your own build. Tree-shaking and your framework choice matter more than what any blog post claims.

5. The license question nobody reads

This part bit me on a freelance project two years ago. Free does not mean unrestricted.

Simple Icons is CC0 for the SVG paths. The brand names and logos themselves remain trademarks of their owners. CC0 covers the SVG file, not the trademark right to use it.

svgl is MIT for the file collection, with the same trademark caveat per brand.

thesvg.org is free with no attribution required for the file collection, again with trademark rules applying per brand.

Practical rule: free SVG brand icons libraries give you the artwork, not the right to imply endorsement. If you build a "trusted by" marketing page or a competitor comparison, check the brand's actual logo guidelines. Most companies allow editorial and "as a customer" use, but not rebranding.

6. When to pick which

Three patterns I keep falling back to.

If you need a footer row of twenty social or tech logos, all monochrome, all the same size, Simple Icons is the right answer. Smallest bundle, simplest API.

If you want a curated set of around 600 popular brands and value tight curation over raw count, svgl is the right answer. Strong category organization, MIT license, easy CDN drop-in.

If you need the broadest catalog of full-color brand SVGs with consistent variant coverage, thesvg.org is what I built for that case. 5600+ icons, multi-variant, free with no attribution.

If you need icons across 200+ sets and brands matter only as part of a wider icon system, look at Iconify as a separate option. It serves a different search intent and a different bundling story.

The bottom line

No single library wins every bracket because the brackets are different. Match the tool to the job. Audit your trademark exposure before launch. And do not assume tree-shaking will save you, check the bundle output of your own build.

What is your default brand icon library, and what made you switch? Drop a comment with your stack.

GDS K S · thegdsks.com · building thesvg.org and Glincker · follow on X @thegdsks

Free SVG brand icons are a solved problem only if you pick the right library for the bracket you are in.

I rewrote my auth library to run on Cloudflare Workers. Here is what broke.

GDS K S — Thu, 30 Apr 2026 15:48:36 +0000

Most TypeScript auth libraries assume Node.js. They reach for crypto.randomBytes, Buffer, the Node fs module, sometimes process.env directly. That works on Vercel serverless, AWS Lambda with the Node runtime, Railway, Fly. It does not work on Cloudflare Workers.

Workers do not have Node. They have Web APIs. crypto means Web Crypto, not the Node crypto module. Buffer is gone. fs is gone. process.env does not exist. Bindings are injected into a request handler.

I rewrote KavachOS to run on Workers in February. Here is what I had to change, in case you are going through the same migration.

Why bother

Workers are cheap. They run close to the user. They cold-start in under 5ms. For an auth library that gets called on every authenticated request, that latency floor matters. If your auth library adds 80ms of cold start every time someone hits an endpoint, your app feels slow even when the actual logic is fast.

Most AI agent infrastructure is also moving to the edge. MCP servers, agent runtimes, function-call handlers, they all want to be near the user. If your auth layer cannot follow them there, it becomes the slow link.

Buffer is gone. Use Uint8Array.

This was the biggest change. I had Buffer.from(x) in maybe 60 places. All of it had to go.

Before:

const bytes = Buffer.from(secret, "utf-8");
const hex = bytes.toString("hex");

After:

const bytes = new TextEncoder().encode(secret);
const hex = Array.from(bytes)
  .map((b) => b.toString(16).padStart(2, "0"))
  .join("");

This is more verbose. It is the price of running on Web APIs.

For base64 I added a small helper:

function bytesToBase64Url(bytes: Uint8Array): string {
  let binary = "";
  for (const b of bytes) binary += String.fromCharCode(b);
  return btoa(binary)
    .replace(/\+/g, "-")
    .replace(/\//g, "_")
    .replace(/=+$/, "");
}

That replaced every Buffer.from(bytes).toString("base64url") call.

Node crypto out, Web Crypto in

Node:

import { randomBytes, createHash } from "node:crypto";

const token = randomBytes(32).toString("hex");
const hash = createHash("sha256").update(input).digest("hex");

Web Crypto:

const bytes = new Uint8Array(32);
crypto.getRandomValues(bytes);
const token = bytesToHex(bytes);

const data = new TextEncoder().encode(input);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);
const hash = bytesToHex(new Uint8Array(hashBuffer));

Web Crypto is async. Node createHash is sync. That cascaded through the library because functions that called createHash had to become async too. About 20 internal helpers gained an await.

For JWT signing I switched from jsonwebtoken (Node-only) to jose, which has a Web Crypto path. Both work the same way at the API surface, but jose runs on Workers, Bun, and Deno without a polyfill.

SQLite to D1

Cloudflare D1 is SQLite, but the API is different. You cannot pass a url string. You pass a binding:

const kavach = await createKavach({
  database: {
    provider: "d1",
    binding: env.DB,  // injected by the Workers runtime
  },
});

I added a d1 provider next to the existing sqlite provider. They share most of the schema and migration code. The difference is the prepared statement API. D1 uses db.prepare(sql).bind(...).run() instead of the better-sqlite3 style db.prepare(sql).run(...).

The migration utility had to ship two paths. On Node, it reads the schema file from disk. On Workers, the schema is bundled at build time as a string. The library imports it conditionally based on which provider is active.

process.env is gone

Workers do not have process.env. Bindings come in on the request:

export default {
  async fetch(request: Request, env: Env) {
    const kavach = await createKavach({
      secret: env.AUTH_SECRET,
      database: { provider: "d1", binding: env.DB },
    });
    return kavach.handle(request);
  },
};

I had to push every secret read into a config object instead of having the library reach for process.env.X internally. This was good for testing too. It made the library easier to use in tests where you do not want real env vars.

TypeScript 5.8 ArrayBuffer / Uint8Array typing

This was the most annoying change. After upgrading to TypeScript 5.8, code like this stopped compiling:

const bytes: Uint8Array = await crypto.subtle.digest("SHA-256", data);

crypto.subtle.digest returns ArrayBuffer, not Uint8Array. You have to wrap it:

const bytes = new Uint8Array(await crypto.subtle.digest("SHA-256", data));

There were 30 places where I was implicitly casting. Each one needed an explicit new Uint8Array(...) constructor.

What I gained

Bundle size dropped from 240KB to 90KB after pulling out Node-only dependencies. Cold start on Workers is around 4ms for a typed handler. The library now runs on Workers, Bun, Deno, and Node from the same source tree, with no polyfills.

The "no Node-specific APIs" rule is also why KavachOS works in Vercel Edge runtime, AWS Lambda@Edge, Netlify Edge, and Deno Deploy. One auth library, every edge runtime.

What I would skip if I did this again

I spent two days on a custom AES-GCM helper before realizing Web Crypto already has it. Read the Web Crypto API docs first. Most of what you reach for in Node crypto has a direct counterpart. You just have to learn the new API surface.

I also wrote my own bytesToBase64 before realizing btoa works fine for ASCII. Use the platform.

If you are migrating and want a reference, KavachOS is open source. The PR that introduced D1 support is small enough to read in 10 minutes. The PR that switched away from node:crypto is bigger but documented commit by commit.

https://github.com/kavachos/kavachos

If you have ported a Node library to Workers or Bun, what was the gnarliest API surface you ran into? Buffer was easy in retrospect. process.env and the async cascade from Web Crypto cost me real days.

Adding OAuth 2.1 to your MCP server in TypeScript

GDS K S — Wed, 29 Apr 2026 17:40:05 +0000

If you're building an MCP server, sooner or later someone is going to ask: how does authentication work?

The MCP spec leaves this open. Most early servers shipped with no auth at all, or a hardcoded API key in an environment variable. That's fine for local Claude Desktop use. It falls apart the moment you publish a remote MCP server that real users connect to.

The right answer is OAuth 2.1 with PKCE, plus four RFCs that nobody enjoys reading: 9728 (Protected Resource Metadata), 8707 (Resource Indicators), 8414 (Authorization Server Metadata), and 7591 (Dynamic Client Registration). I know that sounds like a lot. Let me show you what it looks like in practice.

I'll use KavachOS, the auth library I built for AI agents. You don't have to use it. The point of this post is to show what a compliant MCP OAuth setup actually requires, and why each piece exists.

What you'll build

A Hono-based MCP server that:

exposes /.well-known/oauth-protected-resource (RFC 9728)
handles dynamic client registration so Claude Desktop can register itself (RFC 7591)
runs the authorization code flow with PKCE S256 (OAuth 2.1)
issues access tokens scoped to a specific resource indicator (RFC 8707)
validates incoming MCP requests against those tokens

Client                Auth Server          MCP Server
  │                       │                    │
  │  GET .well-known/...  │                    │
  ├──────────────────────────────────────────► │
  │  401 + auth metadata pointer               │
  │ ◄──────────────────────────────────────────┤
  │                       │                    │
  │  POST /register       │                    │
  ├──────────────────────►│                    │
  │  client_id            │                    │
  │ ◄─────────────────────┤                    │
  │                       │                    │
  │  /authorize (PKCE)    │                    │
  │ ◄────────────────────►│                    │
  │  code                 │                    │
  │ ◄─────────────────────┤                    │
  │                       │                    │
  │  /token (code+verif)  │                    │
  ├──────────────────────►│                    │
  │  access_token         │                    │
  │ ◄─────────────────────┤                    │
  │                       │                    │
  │  POST /mcp + bearer   │                    │
  ├──────────────────────────────────────────► │
  │                       │   200 + result     │
  │ ◄──────────────────────────────────────────┤

Setup

npm install kavachos @kavachos/hono hono

index.ts:

import { createKavach } from "kavachos";
import { mcpOAuth } from "kavachos/mcp";
import { createHonoAdapter } from "@kavachos/hono";
import { Hono } from "hono";

const kavach = await createKavach({
  database: { provider: "sqlite", url: "kavach.db" },
  plugins: [
    mcpOAuth({
      issuer: "https://your-mcp-server.com",
      resource: "https://your-mcp-server.com/mcp",
    }),
  ],
});

const app = new Hono();
app.route("/auth", createHonoAdapter(kavach));

That's the auth surface. You still need an MCP handler. Wire it like this:

import { requireToken } from "kavachos";

app.post(
  "/mcp",
  requireToken({ scope: ["mcp:tools"] }),
  async (c) => {
    const agent = c.get("agent");
    const body = await c.req.json();
    // route the MCP request to your tool implementation
  },
);

requireToken validates the bearer, checks scope, and attaches the agent identity to the request context. If the token is missing, expired, revoked, or has the wrong scope, the middleware rejects the request before your handler runs.

What each RFC actually does

RFC 9728: Protected Resource Metadata

When Claude Desktop tries to connect to a remote MCP server, it does not know where the OAuth endpoints are. RFC 9728 fixes that. You expose a .well-known/oauth-protected-resource endpoint that points the client at the authorization server.

GET /.well-known/oauth-protected-resource

{
  "resource": "https://your-mcp-server.com/mcp",
  "authorization_servers": ["https://your-mcp-server.com"],
  "scopes_supported": ["mcp:tools", "mcp:resources"]
}

Without this, Claude Desktop has no way to discover the auth flow. The connection just fails with a confusing error.

RFC 7591: Dynamic Client Registration

You do not want every MCP user filing a ticket to get a client_id. RFC 7591 lets clients register themselves at runtime. Claude Desktop calls:

POST /register
Content-Type: application/json

{ "redirect_uris": ["http://localhost:3334/callback"] }

You return a client_id (and optionally a client_secret). The client uses it for the auth code flow. With this in place, your MCP install is one command from the user's side, not a support email.

OAuth 2.1 with PKCE S256

OAuth 2.1 is essentially OAuth 2.0 minus the mistakes. PKCE is mandatory. The implicit flow does not exist anymore. Public clients must rotate refresh tokens.

The flow:

Client generates a code_verifier (random) and a code_challenge (SHA-256 of the verifier, base64url-encoded)
Client redirects to /authorize?code_challenge=...&code_challenge_method=S256&...
User approves
Client receives an authorization code at the redirect URI
Client exchanges the code plus the original code_verifier at /token for an access token

KavachOS handles this end to end. You write zero lines of OAuth code.

RFC 8707: Resource Indicators

Without resource indicators, an access token is valid for "anything this auth server protects." That is a recipe for token leakage. RFC 8707 binds a token to a specific resource (your MCP server URL).

When Claude Desktop requests a token, it includes:

resource=https://your-mcp-server.com/mcp

The token comes back with that resource baked in. Your MCP server validates it. A token meant for one MCP server will not work against another. This matters more than people realize once a Claude user juggles ten MCP servers from one client.

Testing the flow

npm run dev

In another terminal:

# 1. Discover the auth server
curl http://localhost:3000/.well-known/oauth-protected-resource

# 2. Register a client
curl -X POST http://localhost:3000/register \
  -H "Content-Type: application/json" \
  -d '{"redirect_uris":["http://localhost:3334/callback"]}'

# 3. Walk the auth code flow
# The MCP Inspector from Anthropic does this end to end:
# https://github.com/modelcontextprotocol/inspector

If your server passes the inspector, Claude Desktop connects cleanly.

What you get

Once the server ships:

An audit log of which agent called which tool, with which scope, at which timestamp
Per-agent revocation, so you can kill one client without affecting others
Rate limits per agent, not per IP
A path to enterprise SSO later, since KavachOS supports SAML and OIDC providers as the upstream identity

Common pitfalls I keep seeing

A few things I have watched teams trip on while wiring this up.

Skipping the .well-known discovery endpoint. Without it, Claude Desktop has no idea where to send the user. It returns a generic "could not connect" error and the user blames the MCP server. This endpoint costs you four lines of code; ship it first.

Hardcoding client_id for testing, then forgetting to swap it for dynamic registration. The single-tenant test setup looks identical to a production setup until the second user shows up and steamrolls the first user's client. Add dynamic registration before you share the server with anyone else.

Ignoring the resource indicator. I have seen teams treat OAuth as a generic login layer and issue tokens with no resource binding. The token then works against any MCP server in the same auth realm, which means a compromised server gets credentials valid against every other server you protect. Always bind tokens to the specific resource URL.

Not setting up token revocation early. Most teams add it after the first incident. By then they have already issued thousands of tokens, none of which they can recall cleanly. The KavachOS revocation API runs in milliseconds. Wire it before you need it.

Skipping audit logs because "we will add observability later." When the first agent does something weird, the only way to find out which token it used is the audit log. Six lines of middleware now save you a week of forensic SQL later.

A note on where MCP auth is going

The MCP spec is still moving. Recent drafts formalize the discovery flow and add elicitation (asking the user to confirm an action mid-flow). KavachOS tracks the spec, so updates land in the SDK without changes on your side.

If you want to skip the build and try it, install is one command:

npx create-kavachos-app

Source: github.com/kavachos/kavachos. MIT.

If you ship an MCP server, what's the auth setup you actually use today: hardcoded key, an Auth0/Clerk pass-through, or something custom? Curious which trade-offs you've made and where it's biting you.