Playbooks

How to get picked for serverless compute by coding agents

AWS Lambda took 24% of 287 judged serverless compute sessions. What the numbers say a vendor in this category should do.

Published September 3, 2026 Read as Markdown

If you sell serverless platforms, this page is the part of the market no dashboard shows you: what a coding agent does when a developer asks for serverless compute and never compares vendors.

The numbers come from 287 judged sessions with Claude Code, Codex and Cursor, spread across 8 realistic codebases, with every session read by a judge.

What coding agents choose for serverless compute

Across 287 judged sessions, AWS Lambda was chosen most often, in 24% of runs. Vercel Functions was second with 23%. In 17% of runs the agent wrote the code itself and adopted no product at all.

#ProductRuns wonShare
1AWS Lambda7024%
2Vercel Functions6523%
3Built in-house (no product adopted)5017%
4Azure Functions3613%
5Cloudflare Workers207%
6Google Cloud Run114%
7Inngest72%
8Render52%
9Fly.io41%
10Google Cloud Functions21%

Full board, every run replayable: the serverless compute leaderboard.

What the shape of this category means

The leader takes only 24% of runs. This category is genuinely open and the ordering can be moved.

With the top product at 24%, serverless compute is decided in the moment, from what the agent reads and what it finds in the repository. Nothing is locked in, which is the best situation a vendor can be in and the one where the work pays fastest.

The order here is set by the quality of what an agent can read and by whether your product is already present in the codebase. Both are things you can change.

The agents do not agree with each other

In this category the three agents we ran put different products first.

AgentRunsPicked most often
Claude Code96Vercel Functions (24)
Codex96AWS Lambda (49)
Cursor95Vercel Functions (21)

That split decides where a vendor spends. Codex ran a web search in 53% of decision runs and Claude Code in 1.6%, so the pages you publish are live in half of Codex's serverless compute sessions and almost none of Claude Code's. Taking AWS Lambda's position with Codex is a content problem. Taking Vercel Functions's with Claude Code is a repository problem.

Who is asking changes the answer

Every request in this experiment was written as a specific kind of person. In this category the leader changes with the person.

Who is askingRunsPicked most often
Vibe coder36Cloudflare Workers
Junior developer72Vercel Functions
Senior engineer107AWS Lambda
Enterprise team72Azure Functions

That is 4 different products winning serverless compute for 4 kinds of buyer, out of the same 287 sessions. Nobody here is winning serverless compute. They are each winning one kind of buyer.

If you sell to more than one of them, you need pages for each. See how to win the enterprise persona.

What you are really competing against

In 17% of runs the agent wrote the code itself rather than adopting a product. That is low enough that your competition is other vendors, but high enough to be worth watching.

What to do about it in serverless compute

  1. Treat the ordering as movable. The leader holds 24%, so agents are deliberating rather than defaulting, and the inputs they use can change the answer. This is the most winnable shape a category comes in.
  1. Pick which buyer you are for. The same serverless compute need written as a vibe coder landed on Cloudflare Workers, and written as an enterprise team landed on Azure Functions. Those are two markets, and the enterprise one needs pages containing the constraint words: audit log, data residency, retention, single sign-on. See how to win the enterprise persona.
  1. Measure per agent. Claude Code put Vercel Functions first, Codex put AWS Lambda first, Cursor put Vercel Functions first. A blended number for serverless compute describes a market that does not exist.

The work that applies to every category rather than to this one is written up separately: audit your documentation, write a quickstart an agent can follow, and how to measure install share.

Every serverless platform on this board

One page per product, with its install share, the per-agent split, and how often it was raised without being chosen.

Where these numbers come from

287 judged sessions in serverless compute across 8 codebases, part of a published set of 5,292. Real coding agents at pinned versions, in sandboxes, inside realistic codebases, with a simulated project owner in the loop and a blind judge on every session. The full method is on one page: how we measured this.

Every serverless compute run can be replayed on the board.

<!-- generated by scripts/write-data-pages.mjs -->

Common questions

How many codebases is this based on?

287 judged sessions across 8 realistic codebases. A category only runs on repositories where its seam is open, so coverage differs: some categories ran on more than ten codebases and some on two.

What serverless platform do coding agents choose?

Across 287 judged sessions, AWS Lambda was chosen most often, in 24% of runs. Vercel Functions was second with 23%. The result changes by agent and by who is asking.

Do Claude Code and Codex pick the same serverless platform?

No. Claude Code picked Vercel Functions, Codex picked AWS Lambda, Cursor picked Vercel Functions. Measuring one agent tells you about part of the market only.

How often do agents build serverless compute themselves instead of installing something?

In 17% of runs the agent wrote the code itself rather than adopting a product.

How can a vendor improve its position here?

Make the quickstart run when pasted, state the current version on the documentation page, use one name across product, package and import, write pages for the symptoms users describe rather than only the category name, and get into the repository through templates and framework integrations.

Where this comes from

Armature ran 5,292 judged sessions with Claude Code, Codex and Cursor inside 51 realistic codebases, and published every run. The numbers on this page come from that work.

Read next

All library pages