A quarter of Neon's deploys come through MCP, not the CLI it recommends

What Neon counted

On Wednesday, Neon published a count of how AI agents get into its product (opens in a new tab). Neon sells hosted Postgres databases, and an agent can reach it through two doors. One is the CLI, the command-line tool a coding agent can run in a terminal. The other is Neon’s MCP server, a plug-in that hands an AI assistant a list of tools it can call by name.

The MCP server now has about twice as many daily users (opens in a new tab) as the CLI. And agents use it even where Neon asks them not to. In October, more than a quarter of deploys to Neon (opens in a new tab) came through the MCP server. Neon’s own instructions for agents tell them to deploy with the CLI (opens in a new tab).

This matters beyond Neon. Most devtools companies now ship some mix of CLI, MCP server and API for agents, and their docs point agents at one of them. Neon’s numbers suggest the agent doesn’t follow that advice as often as you’d hope. It uses whatever its app puts in front of the model at the moment it acts. That’s our reading, and Neon’s own numbers make it weaker than it first looks. We’ll get to that below.

Clerk, a sign-in service for developers, saw the same thing from the other side. It pushed agents toward its CLI by rewriting one error message.

The door Neon recommends

In August, Neon renamed its CLI (opens in a new tab) from neonctl to plain neon and pitched it as a tool for agents. An agent can do all its work there and never open Neon’s dashboard. A few weeks later, Neon let an agent create a database before anyone signs up, as we covered in September.

Agent skills are instruction files a vendor publishes so an agent knows how to use its product. Neon’s new neon init command sets up its skills and the MCP server together (opens in a new tab). Neon’s main skill (opens in a new tab) is clear about which door to use:

Prefer the CLI over the MCP server unless the user instructs otherwise, since it provides more capabilities, including deploying Neon Functions.

Neon Functions is Neon’s hosting for small pieces of backend code. There’s a practical reason the skill sends deploys to the CLI. The neon deploy command bundles, zips and deploys the code (opens in a new tab). The MCP server’s deploy tool only takes a zip that’s already built (opens in a new tab). So an agent that deploys through MCP has to do the building itself.

What agents did instead

The MCP server passed the CLI in daily users (opens in a new tab) a year ago, before Neon pitched its CLI at agents. By August it was handling more tool calls than the CLI ran commands (opens in a new tab). So October is the new part. The skill tells agents to prefer the CLI, and more than a quarter of deploys still came through MCP (opens in a new tab). ChatGPT’s agents even zip the code themselves and deploy through MCP (opens in a new tab).

Neon’s explanation is about what the agent sees. A harness is the app an agent runs in, like ChatGPT, Claude Code or Cursor, and it decides which tools the model is shown. Here’s how Neon’s post (opens in a new tab) puts it:

A harness puts the tools of every connected MCP server right in front of the model. So when someone has both installed, the agent tends to reach for the MCP server first.

In other words, the model sees the MCP tools every time it’s asked to do something. It only reaches for the CLI if it already knows the CLI, or if a skill or a project’s instructions file tells it to. A skill that says “use the CLI” is one more paragraph for the model to weigh. The MCP tools are right there in its list.

Here’s the catch

Neon is the only source for these numbers, and it gives growth rates without the counts underneath. Read closely, its own post weakens the headline in four ways:

Half the traffic can’t run a CLI. ChatGPT and Claude Desktop are chat apps with no terminal. Together they made almost half of October’s tool calls (opens in a new tab) on the MCP server. For them, MCP isn’t a choice over the CLI. It’s the only door. The sum is ours, not Neon’s.
The deploys lean the same way. ChatGPT alone sent one in ten of all deploys (opens in a new tab) through MCP. Every other client together sent fewer than a fifth of all deploys through MCP. That’s our math. Neon doesn’t say how much of that came from Claude Desktop, which has no terminal either.
Neon installs the MCP server itself. Its plugin for Cursor, Claude Code and Codex puts the MCP server next to the skills (opens in a new tab). So part of “the harness shows MCP first” is Neon putting it there.
Neon sells the conclusion. The post argues every product will need an MCP server. It ends by promoting templates that run one on Neon (opens in a new tab).

The post also doesn’t say how it counts CLI users, or how many of them are agents rather than people. So the two user counts don’t measure the same thing.

Neon corrected the post the next day to add a second ranking. ChatGPT and Claude Desktop are its biggest clients by tool calls, but ranked by active users, Codex is first (opens in a new tab). Codex is OpenAI’s coding agent, and it can run a terminal. So the clients that could have used the CLI are a big share of Neon’s users. That’s where “agents skip the skill” gets its real test, and Neon hasn’t said how Codex deployed.

Whatever the split turns out to be, Neon is putting more into MCP, not less. This week it added support for the newest version of the MCP spec (opens in a new tab).

Clerk steered agents with an error message

Clerk’s code library used to quietly make temporary keys, so a new app could run with no Clerk account. Since its Core 3 release, Clerk has dropped that (opens in a new tab), and the no-account path is now a CLI command, clerk init. In Clerk’s Next.js library, an app with no keys now throws an error (opens in a new tab) that tells the developer, and their agent, to run it.

The first version of that error didn’t work, because agents misread it. Clerk’s own code change from last month (opens in a new tab) says so:

Coding agents read the error as ‘an account is needed’.

One agent stopped and told its user the step was theirs. Another spent about 20 tool calls (opens in a new tab) and decided the feature was broken. So Clerk rewrote the message to say the command doesn’t need a Clerk account and writes temporary keys for development.

Did it work? Clerk’s growth engineer, Devin Gould, thinks so. In a video posted on Thursday (opens in a new tab), he said:

I don’t know the exact number of, like, percentage increase, probably like double or triple the number of CLI users basically, um, overnight from, from doing that.

That’s an estimate. Gould doesn’t say when the change shipped or what counts as a CLI user. The video is hosted by Gauge, a company that sells agent testing, and its headline says “3x”, which Gould didn’t.

Put the two side by side. Neon’s skill told agents to use the CLI, and many of them used MCP. Clerk’s error told agents to use the CLI, and by Gould’s estimate many more did. The agents skipped instructions written for them in advance and followed the text they ran into mid-task.

Our take

Our take: if agents use your product, the text they read mid-task is now part of your docs. That’s your MCP tool descriptions and your error messages. And you need to count which door each agent comes in by. Neon’s skill pointed one way, and more than a quarter of deploys went the other. Clerk changed one error, and by its own rough count its CLI users jumped. Both companies learned it by watching what agents did.

The best case against is in Neon’s own numbers. So much of its MCP traffic comes from apps that can’t run a CLI that “agents skip the docs” may really be “chat apps need MCP”. What would change our mind is Neon splitting its deploys by client. If Codex, Claude Code and Cursor mostly deployed with the CLI, the skill worked wherever it could. Neon already split out ChatGPT’s share. The rest would take one more table.

Tessl launches Factory with a $13-a-PR claim it doesn’t explain

Tessl led its launch on Friday with one number. Its own cost per PR, it says, fell from $75 to $13 (opens in a new tab).

Tessl is an AI coding startup, founded by Guy Podjarny (opens in a new tab), who also founded Snyk. “Software factory” is the name sellers give to running coding agents as a pipeline: a ticket goes in, and reviewed code comes out. Tessl’s version is a product called Factory.

What’s in the $13? The release doesn’t say. It gives no time period, no number of PRs, and no word on whether those PRs were merged or what the spend covers. Tessl hasn’t put up a launch post of its own, so a newswire release is the only source. Its second claim, that most of a week’s PRs needed no hand-editing (opens in a new tab), doesn’t say which week.

That’s odd, because Tessl knows how to do this. Last month, when it reported how many of its PRs merge without human review, it gave the count behind it: more than 1,200 a week (opens in a new tab). And just before the launch, its own blog (opens in a new tab) said a factory’s cost should cover “infrastructure, retries, review, and rework where they can be measured”. Tessl doesn’t say whether the $13 meets that.

Here’s what a checkable version looks like. CampusIQ, an education software company, published its own spend (opens in a new tab): $53,000 on tokens, divided by 1,832 merged PRs, is $29 a PR. Then it says what the number leaves out:

We’re not presenting $29 as a fully loaded cost per pull request because it isn’t one.

Salaries, seats and laptops aren’t in it. It’s one company’s own count, and it doesn’t date the window.

Our take: if you sell an agent product, you’ll soon be asked for a cost per outcome, so publish it with its labels on. Say which PRs, opened or merged. Say which weeks. Say which spend is in it, and what isn’t. The best argument against is that cost per PR may be the wrong number to ask for. A team can make its PRs smaller and watch the cost per PR fall. And Uber lists cost per merged PR (opens in a new tab) among the numbers it tracks, but publishes no value for it. It reports only a change in cost per session instead. That’s a reason to label the number, not to drop it. Tessl’s launch offers $200 in credits (opens in a new tab) and no price for Factory at all (opens in a new tab).

PostHog now keeps new customers’ data for two years, not seven

If you start paying PostHog today, it keeps your event data for two years by default. Until Thursday, it kept it for seven (opens in a new tab). PostHog sells product analytics, billed by usage. Events are its raw record of what your users did in your product. Retention is how long you can still query them. The free plan stays at one year (opens in a new tab).

Who keeps the longer window? Existing paid customers do, as long as they don’t downgrade (opens in a new tab). New customers can pay for longer windows with PostHog’s monthly add-on packages (opens in a new tab). Seven years now comes only with the top one, Enterprise, at $2,000 a month (opens in a new tab).

PostHog’s main reason is cost. From the post (opens in a new tab):

Old data rarely gets queried. … Storing 7 years of data is expensive.

The post also calls two years the industry standard (opens in a new tab). It gives no figure for how often old data gets queried, or what it saves.

Here’s the catch. A downgrade now comes with a deletion. A customer who trims its bill drops to two years, and the docs (opens in a new tab) are blunt about what happens next:

Expired events may be deleted at any point, and we can’t restore deleted events.

So how does a customer find out? Not from an email to every customer. PostHog plans its marketing in public, in a GitHub repo anyone can read. Its tracker there shows (opens in a new tab) it settled on two emails, sent only to the customers affected. One goes out on a downgrade. The other goes out 14 days before PostHog starts deleting. PostHog points anyone who wants to keep old data to a scheduled export into their own warehouse (opens in a new tab).

This is a fair way to take something back: new customers only, existing ones kept, and the reason given as cost. The weak spot is the downgrade. A customer cutting costs may not know it’s also giving up five years of history, and that second email is its last warning.

Briefly

GitHub will make a risky trigger fail on purpose before it blocks it for good. pull_request_target is a GitHub Actions trigger that runs a workflow with the repository’s secrets on pull requests from outsiders. From 2 December it’s blocked by default in public repositories (opens in a new tab). Before that, GitHub will switch the block on for two hours tomorrow and again a week later (opens in a new tab). Runs it would block will fail, and then go back to warnings. GitHub calls these brownouts. A brownout is a deprecation notice users can feel.

Trigger.dev published the scope of its breach, but not how it happened. Trigger.dev runs background jobs for developers’ apps. Its incident report on Friday (opens in a new tab) says the breach hit 0.66% of customers and lays out when each customer email went out. It has revoked the exposed API keys and tells affected customers to rotate every credential. It says it can’t comment on the attack vector yet. That’s enough for a customer to know whether to act, and not yet enough to know what went wrong.

Everything else this week

Launch · 7

11-08 GitHub Next opens Ace, a local agent workspace (opens in a new tab)
11-07 Tessl launches Factory for agent-run software (opens in a new tab)
11-07 SuperPlane 1.0 is an open-source software factory (opens in a new tab)
11-05 Render opens Sandboxes beta for agents (opens in a new tab)
11-05 LaunchDarkly launches Release Autopilot for AI-built code (opens in a new tab)
11-05 DoorDash opens agent ordering via MCP and CLI (opens in a new tab)
11-04 RudderStack open-sources DevBox, its agent harness (opens in a new tab)

Release · 9

News · 3

Sources, check them yourself

Every load-bearing claim above links to one of these. A single-sourced claim says so in the text.