# Okane Land, full text for agents
> Every published piece, concatenated as markdown. Index and structure: https://okaneland.com/llms.txt
---
# Your users can pay your AI bill with ChatGPT. OpenAI keeps the meter.
Section: The Signal
URL: https://okaneland.com/signal/openai-keeps-the-meter/
At DevDay, OpenAI made the ChatGPT subscription an official way to pay for AI inside other apps. For a small AI product that can take the biggest cost off the books. It also puts the product's capacity on an allowance OpenAI sets, and the same day OpenAI lowered what the $200 plan includes.
## The short version
- **On September 29, spending your ChatGPT plan in other apps became an official program.** At DevDay, OpenAI let Plus and Pro subscribers route AI requests in 15 partner apps to their plan, with Lovable to follow, and each user can set a weekly limit per app. Coding tools make up most of the list, from Devin and Warp to the open-source OpenCode.
- **The pitch lands hardest on small AI products.** Sam Altman told developers the change means [**"now you don't have to cover their token costs to get them going."**](https://thenewstack.io/sign-in-with-chatgpt/) If you read our study of why [flat-priced AI wrappers lose money](/study/unit-economics-of-wrapping-an-llm/), that is the heavy user's bill moving to the heavy user.
- **Open source gets it now, and paid apps get a waitlist.** OpenAI's developer docs open plan usage to all open-source partners and to private clients OpenAI selects. A paid or remotely hosted app has to apply and wait for a place in a limited trial.
- **It is one allowance, and everything draws on it.** Connected apps spend the same ChatGPT Work and Codex usage the subscriber spends directly. On Plus, the five-hour limit covers all of them, and [**"no app receives a separate allowance."**](https://developers.openai.com/siwc/token-sharing-open-source/profiles-and-sessions) OpenAI estimates that window at 15 to 160 local messages on GPT-6.1 Sol, with cloud tasks using more.
- **The same day, OpenAI changed what a plan buys.** Pro 200 now includes less usage for new sign-ups, and current subscribers switch after October 29. The Next Web reports Codex and Work usage falling from 20 to 10 times the Plus allowance, next to a new $500 tier.
- **Agent storefronts opened the same month, built for discovery more than payment.** Meta, Anthropic and OpenAI all widened their directories for outside developers. Anthropic's and OpenAI's new purchase paths serve enterprise budgets, OpenAI announced no app-store-style billing or revenue share, and Meta points developers to Stripe.
- **The argument: letting users pay with their ChatGPT plan can take inference off a solo builder's books, but it prices your product's capacity in an allowance OpenAI sets and can shrink.** Offer it as one way to pay, with your own checkout and API key still behind it.
## What shipped on September 29
Sign in with ChatGPT is older than DevDay. OpenAI released it as a beta in July with partners including Airtable, GitLab, HubSpot, Notion, Supabase and Vercel, and at that point it was mostly a login button. What changed at DevDay is the second permission. When a Plus or Pro user signs in to a participating app, they can now choose to let that app's AI requests count against the usage included in their ChatGPT plan.
The user sees a consent screen, then a line in ChatGPT's settings for each connected app, where they can cap it at a percentage of their weekly usage. No API key changes hands. Signing in shares the user's name, email address and profile picture, and using the plan does not by itself give the app their conversations or memories. If the plan runs out, the app can draw on the user's ChatGPT credits only if the user has turned that on. And OpenAI's help page is careful on one point: [**"The app may charge separately for its subscription, infrastructure, services, or premium features."**](https://help.openai.com/en/articles/20001542-using-your-chatgpt-plan-in-other-apps-and-sites)
The launch list says who this is for. OpenAI's directory lists twelve apps for plan usage: eleven live at launch (Amp Code, Conductor, Dactyl, Devin, Hermes Agent, Hyperagent, Kilo Code, Notion, Vercel, Vorflux and Warp) and Lovable, marked coming soon. Most of them are coding tools. Four open-source clients round out the sixteen: OpenCode, OpenClaw, Pi and T3.
Some of this was already happening. Dactyl, a vibe-coding platform for native mobile apps, was showing the option in late August, and OpenClaw announced in May that users could power agent turns with a ChatGPT subscription through Codex login. DevDay folded those routes into one program the user manages from ChatGPT, and OpenAI told The New Stack it will add partners quickly.
Kilo's launch post shows what it looks like from the inside. The plan works across its editor extensions, command line, cloud agents, code reviews and mobile app, and in Kilo's words [**"the 'key' is the ChatGPT subscription you already pay for."**](https://blog.kilo.ai/p/sign-in-with-chatgpt)
## Why this matters to a small AI product
The hardest line on a solo builder's AI product is the one nobody controls: what the heaviest user costs. Price at $20 a month and the person running your agent around the clock can cost you more than they pay. Our [wrapper study](/study/unit-economics-of-wrapping-an-llm/) found the big AI products answering that with meters and caps.
Plan usage answers it differently. The heavy user's requests come out of the heavy user's own ChatGPT allowance, and when that runs out, OpenAI's limit is the one they hit. Free trials get cheaper to offer, because a new user who brings a plan costs you almost nothing in inference. That is the part of Altman's pitch that holds up.
It also makes your product's capacity someone else's number, and agentic work eats an allowance fast. When we ran OpenAI's Codex on the Free plan for our [Proof](/proof/codex-free/), one app build used 37 percent of that plan's 30-day meter. Free has its own meter and cannot be shared with other apps, but the build shows the appetite. A Plus subscriber who connects your tool and two other coding agents, and also codes in Codex, is splitting a single five-hour window four ways.
## What OpenAI still controls
Five things stay on OpenAI's side of the table, and each one reaches into your product.
- **Who gets in.** Open-source clients can register themselves today from the developer docs, and closed-source clients are chosen by OpenAI. A paid or hosted app can fill in an interest form, which puts it on a waitlist, and the terms for commercial token sharing are not published.
- **The meter.** The user sets your app's weekly share, from 10 to 100 percent in OpenAI's example. On Plus, every connected app shares one five-hour window with the subscriber's own Codex and ChatGPT Work sessions. Pro plans currently have no five-hour limit.
- **The stop.** When the user hits a limit, their plan's or the weekly cap they set for your app, and has not allowed credits, the request fails with a usage-limit error. OpenAI does not silently switch it to another billing path, so unless you offer a paid option of your own, your product stops for that user until their limit resets.
- **The feature list.** During the preview, plan mode does not support image generation, file search, Code Interpreter, native computer use or hosted connectors. A feature built on any of them needs another billing path behind it, such as your own API key or the user's.
- **The front door.** OpenAI's docs ask for a Continue with ChatGPT button, placed with your other sign-in options at comparable visual prominence and in approved OpenAI branding. A website may also use an approved Sign in with ChatGPT format. The customer's identity arrives from OpenAI.
## The $200 plan got lighter the same day
While OpenAI was inviting developers to build on its plans, it changed what one of them buys. New Pro 200 subscriptions come with a lower allowance, set, OpenAI says, [**"to reflect our increasingly efficient models."**](https://help.openai.com/en/articles/9793128-about-chatgpt-pro-tiers) Existing subscribers keep the old allowance through October 29, and the price stays $200. The Next Web reports that from October 30 Pro 200's Work and Codex usage falls from 20 to 10 times the Plus allowance. Tibo, who works on Codex and ChatGPT at OpenAI, previewed the change in dollars the night before: the new plan [**"will net out at half the dollar in API spend compared to the old Pro $200 plan."**](https://x.com/thsottiaux/status/2104823812042940713) He argued subscribers will still get more work done than on Pro 200 a month earlier, pointing to OpenAI halving the price of GPT-6 Sol and GPT-6 Luna that week. Existing subscribers also get a one-time $2,500 usage-credit grant that expires at year end, The Next Web reports. For the heaviest users, OpenAI added Pro 500, at 25 times Plus.
The change was announced for Pro 200 alone. It still shows who sets the exchange rate. OpenAI decides both what a plan includes and what the API charges, and a product that tells its users their ChatGPT plan covers the AI inherits whatever OpenAI decides a plan is worth.
## The storefronts are open. Bring your own checkout.
September also opened three storefronts for agents. Meta opened its Muse agent to outside connectors; its platform page promises each one a review [**"for functional, security, and legal requirements"**](https://muse.ai/platform) plus end-to-end testing, and editors choose which to feature. Alexandr Wang, Meta's chief AI officer, said on stage at Connect that more than 1,500 applications arrived in under a week.
Anthropic launched the Claude Marketplace on September 23 with more than 2,000 connectors and plugins. Two days later it opened a plugin submission portal to developers on paid Claude plans. Submissions get a safety scan, and live plugins get analytics on installs and the searches that find them. At DevDay, OpenAI said ChatGPT will start suggesting apps in the middle of a conversation when one fits the task, and that developers will be able to track a plug-in's review and request a human reviewer.
Payment is thinner. The buying routes Anthropic and OpenAI built serve enterprise budgets: teams can put part of their committed Anthropic spend toward listed products, and OpenAI's new marketplace lets eligible enterprise customers apply part of their OpenAI commitment to software from its first 32 partners. TechCrunch noted that OpenAI announced no billing or revenue-sharing system comparable to an app store's. Meta has gone furthest, with a Stripe partnership for accepting payments through Link, and Mark Zuckerberg said Muse is free for a huge number of tokens [**"with the expectation that over time we will profit by taking a small fee from transactions."**](https://techcrunch.com/2026/09/23/everything-new-coming-to-metas-ai-agent-muse/)
So the storefronts supply reach, and Sign in with ChatGPT supplies inference. Collecting your own price is still your job.
## What to do this week
1. **If you ship a free, open-source tool that runs on the user's machine, add plan usage now.** The developer docs cover registration, and removing the API-key step is a real gain for new users. Keep bring-your-own-key as a second path.
2. **If you run a paid or hosted app, join the waitlist and keep your billing.** Plan usage is one way users can choose to pay. Keep your own checkout working for everyone else.
3. **Build for the stop.** Catch the usage-limit error and tell the user they have hit a ChatGPT usage limit, either their plan's or the cap they set for your app. Make a Manage usage link to their ChatGPT settings the main action, and offer your own paid route second.
4. **Say what you cannot promise.** If your AI runs on the user's plan, your speed and volume depend on their plan and their other apps. Put that in your onboarding in plain words.
5. **If you are the buyer, set caps.** Connect your plan to the coding tools that support it, cap each one's weekly share, and check which of them still charge their own subscription on top.
---
# The frontier now ships twice. The second copy is not for sale.
Section: The Signal
URL: https://okaneland.com/signal/the-frontier-twice/
In one week, all three frontier labs released their best model in two versions: a public one anyone can pay for, and a vetted one with the same weights and fewer refusals that you have to be someone to get. The price did not move. The gate did.
## The short version
- **Between September 1 and 3, Anthropic, Google and OpenAI each shipped their best model twice.** A public version you can buy today, and a vetted version with the same or fuller capability that you apply for. Anthropic says its pair are [**"the same model, but with different levels of safeguards."**](https://www.anthropic.com/claude-fable-and-mythos-5-1)
- **The public tier costs what the last tier cost.** Fable 5.1 and GPT-6 Astra both list at $10 in and $50 out per million tokens, twice Opus 5. Gemini 3.8 Flash stays cheap at $0.75 and $3.75 until the end of the year. Nobody raised the ceiling on what you can pay.
- **The vetted tier has no price at all.** Mythos 5.1 goes to [**"a small, but growing, set of vetted organizations,"**](https://www.anthropic.com/claude/mythos) currently in the US. Gemini 3.8 Flash Cyber [**"is only available to trusted defenders"**](https://blog.google/innovation-and-ai/models-and-research/gemini-models/3-8-flash-and-3-8-flash-cyber/) through a program built for governments and infrastructure operators. Astra's sharp end goes first to alpha testers.
- **What the gate asks for is identity.** OpenAI's path for individuals is a government-issued ID and two hardware security keys. Anthropic ties approval to an organization ID. Google admits organizational categories. Three labs, one week, the same shape of door.
- **The public tier is also the one that interrupts you.** OpenAI says its new monitor can flag [**"tasks in which an agent is running for an extended period"**](https://openai.com/index/path-to-astra/) and that on the API the task will stop. The long-running agent you run alone is exactly the pattern it watches.
- **The argument: for a solo builder, the ceiling on the frontier stopped being a price this month and became a credential.** You can still buy the best public model. You cannot buy the one the benchmarks were run on. Plan the product around the door you can open.
## What shipped, and what it actually means
The week of September 1 was one of the busiest frontier weeks of the year, and the coverage treated it as three launches. It was one launch, repeated.
Anthropic went first. Claude Fable 5.1 is generally available on every platform at $10 per million input tokens and $50 per million output tokens. Claude Mythos 5.1 is the same weights with different safeguards, and it is available only through two trusted access programs, one for cyber defenders and one for the life sciences, both currently limited to US organizations. The Cyber Verification Program that will carry Mythos access is real and reasonably fast, with a two-business-day review, but approval is tied to an organization ID. Today it covers Opus and Sonnet; Mythos access through it is described as coming.
Google went second. Gemini 3.8 Flash is public and, for now, inexpensive. Gemini 3.8 Flash Cyber, the version tuned to find and patch vulnerabilities, is not something you sign up for. It moves through the Fairwind Program, which names its audience plainly: government agencies and national cyber authorities, critical infrastructure operators, core technology platforms, Google Cloud customers and security partners. Participants must confine it to security staff and run multifactor authentication. There is no public API and no published price.
OpenAI went last and said the most. GPT-6 Astra is the first model the company designates at the Critical cybersecurity threshold of its Preparedness Framework, meaning it can find unknown flaws and build exploits across hardened systems without a person guiding each step. The public Astra refuses that work. The capability goes to a small group of alpha testers first, then widens through Daybreak Blue. And in the small print of its own capability post, OpenAI says the results it published reflect Daybreak Blue access rather than the default configuration. The benchmark model and the store model are not the same product.
## The price did not move. The gate did.
Look at the stickers. Fable 5.1 and Astra both cost $10 in and $50 out. That is exactly double Opus 5, and it is the same number at two companies. Gemini 3.8 Flash costs a fraction of either, with the introductory rate ending December 31. Read as a market, the public tier priced itself in an afternoon and nobody blinked.
Now look at what the second tier costs, and notice there is no number. Mythos has no checkout page at all, because the purchase is not the gate. The gate is an application scoped to an organization, in the US, reviewed by a person. Flash Cyber has no price because it has no checkout. Astra's advanced tier has a queue.
That is the change worth naming. For two years the frontier was a budget question: pay more, get more. As of this month the top of the range is a status question. What you are asked for is a government ID, two hardware keys, an organization ID, or a category you belong to. None of those come from a credit card.
## What the door asks for, lab by lab
The three gates are not identical, and the differences matter if you are one person.
OpenAI's is the most open to individuals. Daybreak's own page says you verify with a government-issued ID, enable Advanced Account Security with two hardware security keys, and meet the program's eligibility requirements. A solo builder doing authorized security work can, in principle, walk through that door alone. Astra's most advanced configuration still starts with alpha testers, so the door exists and is not yet open.
Anthropic's is organizational. The verification program takes individual applicants, but approval attaches to an organization ID, and the Mythos page limits current access to US organizations. A one-person company is an organization; a personal account is not.
Google's is categorical. Fairwind admits kinds of institutions. There is no individual path described, and the program's stated purpose is to give infrastructure operators an adaptation window before attackers catch up.
## The part that hits the solo builder first
It would be easy to file this under "cyber models, not my problem." Two details argue otherwise.
The first is the monitor. OpenAI states that its production safeguards for Astra can flag legitimate work as potential misuse, including work "that does not appear directly related to cybersecurity" and tasks where an agent runs for a long time. In ChatGPT or Codex you get asked to review. On the API, the task stops. The API is where a solo builder runs the overnight agent, the batch job, the thing that works while you sleep. The public tier is the tier that watches that pattern hardest, because it has to.
The second is what "same weights" implies. The version doing the impressive work in the launch posts is the one with fewer refusals. When a vendor benchmarks the vetted tier and sells the public one, the gap between the demo and the product is now a matter of who you are. That is a different kind of gap from the ones this publication usually prices, and it is not closed by upgrading your plan.
## What to do this week
Decide which door your product depends on, and say it out loud in your plan.
If you are building anything security-adjacent, a scanner, an audit tool, a patching agent, the model that does the real work is behind a gate. Apply now, before you need it. OpenAI's individual path costs a hardware key and an afternoon; Anthropic's wants an organization, which a registered one-person company is; Google's is not for you yet. Do not price a product on a tier you have not been admitted to.
If you are building anything that runs long unattended jobs on the API, budget for interruption. Add resume logic, checkpoint state, and log the stops, because OpenAI says they will happen and says they will not always be about security.
And read the launch benchmarks with the footnote in view. When a result says it was measured with special access, it is describing the model you are not being sold. The one you can buy is the one to test yourself, on your own task, at the sticker price, which is how this publication has always suggested you buy anything.
---
# A worm is after your AI keys. The install is the door.
Section: The Signal
URL: https://okaneland.com/signal/the-install-is-the-door/
A self-spreading npm worm tore through more than 400 packages this month, and the tell is what it reached for: past your cloud and Git tokens, straight to the API keys in Claude, Cursor, and Codex. Nothing was breached. You ran an install, the install ran its code, and that was always the deal.
## The short version
- **On August 4 a poisoned commit landed in the `keyv` repository, and a self-spreading worm went through the npm supply chain from there.** Datadog, Wiz, and Elastic caught it the same morning. It is a member of the Shai-Hulud family, tracked as ChainDrop by Microsoft and others, and it hit the `cacheable`, `flat-cache`, and `file-entry-cache` families alongside `keyv`.
- **Nothing was hacked in the way people mean the word.** The worm rides a normal npm feature: a `preinstall` script runs code before a package is installed. Running `npm install` did exactly what it always does, which is execute whatever the package author put in that hook.
- **What it steals is the whole story.** Past npm, GitHub, and cloud tokens, it goes for the credential stores of your AI tools. Elastic found it [**"aimed at AI tooling credentials such as Anthropic, Claude, Codex, Cursor, OpenAI, and Gemini."**](https://www.elastic.co/security-labs/shai-hulud-chaindrop-npm-supply-chain)
- **It hides where you would never look for malware: your editor config.** It plants a start-up hook in `.claude/settings.json` and an open-folder task in `.vscode/tasks.json`, so the act of opening the project runs it again. The Register put it plainly: [**"Simply opening an infected Git branch in VS Code or Claude Code can bring your repository under ChainDrop's control."**](https://www.theregister.com/security/2026/08/15/chaindrop_worm_crawls_into_npm_supply_chain/)
- **The green checkmark meant nothing.** The malicious code sat in the tagged source, so the real CI pipeline built and signed it. Snyk's finding is the quiet horror of the whole event: [**"the legitimate workflow built and attested the malicious artifact."**](https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks/)
- **The argument: the solo builder's real exposure is the trust handed to the toolchain, not the code they typed.** Auto-install, auto-run, an agent holding live keys to everything: that convenience is the execution path the worm rides. The one place left to stop trusting defaults is your own AI setup.
## What actually happened
On August 4, 2026, someone pushed a malicious commit to the repository behind `keyv`, a caching library that a great many projects depend on without ever naming it. Within the same morning three security firms, Datadog, Wiz, and Elastic, had independently flagged it. The malware is a descendant of Shai-Hulud, the self-propagating npm worm that has surfaced before; Wiz calls this one [**"a descendant of the 'Mini' Shai-Hulud malware family,"**](https://www.wiz.io/blog/keyv-and-cacheable-npm-supply-chain-attack) and Microsoft and Elastic track the variant as ChainDrop.
The scale depends on who you ask and what they counted, so here it is unmerged. Elastic reported over 400 unique packages compromised, totaling more than a billion monthly downloads. Singapore's national cyber agency, in an advisory first posted August 6 and still being updated on August 28, counted [**"over 1,300 package versions on the npm registry, representing a combined 2 billion monthly downloads."**](https://www.csa.gov.sg/alerts-and-advisories/advisories/ad-2026-009/) Packages, versions, and downloads are three different things; anyone quoting a single tidy number for this is guessing.
## The install runs a stranger's code
Here is the mechanism, because it is the point. An npm package can declare a `preinstall` script, a command that runs automatically before the package is even installed. It is a legitimate feature, used for real setup work. The worm uses it to run a small first-stage loader whose only job is to start a much larger payload under the Bun runtime. If Bun is not present, the loader downloads it, and Datadog notes it "does not cryptographically verify" the release asset it fetches. The second stage is a heavily obfuscated program that phones home through an unusual channel: instead of a hardcoded server, it reads an Ethereum smart contract to look up the current address to send your secrets to.
None of that required a vulnerability. It required you to type `npm install`, which you did, because that is the job. Every dependency you add is a decision to run its author's code on your machine with your permissions, and almost nobody reads it first. The worm did not break that trust. It used it exactly as designed.
## What it reaches for
The take list reads like an inventory of a modern builder's whole life. npm tokens and GitHub tokens, so it can spread. Cloud credentials across AWS, Google, Azure, and Alibaba. HashiCorp Vault tokens, SSH private keys, Kubernetes service-account tokens. On a Linux CI runner, Datadog found it reaching into the build process's memory to pull GitHub Actions secrets that were never written to disk.
And then the new entry, the one that makes this a story for people who build with AI rather than a generic supply-chain writeup: the API keys sitting in your AI tools. Both Elastic and Wiz, working separately, list the same targets, Claude, OpenAI, Codex, Cursor, and Gemini. Those keys are now worth stealing next to your AWS root credentials, because a stolen model key is metered spending someone else gets to do on your account, and because the tools that hold them are the least-guarded thing on the machine.
## The part that lives in your editor
This is the detail worth sitting with. The worm does not only steal and leave. It establishes persistence in the two config files a working developer opens every day. It writes a start-up hook into `.claude/settings.json` and an open-folder task into `.vscode/tasks.json`, each pointed at a dropped script. The reporting differs on exactly which file points where, so read it as the mechanism rather than one clean mapping: opening the repository in Claude Code or VS Code re-runs the loader.
Think about what that means for how you work. You clone a repo, or check out a branch, or let an agent pull a project down, and you open it in your editor to look. That open is now an execution event. The place you were trained to treat as inert, a settings file, a tasks file, is where the thing waits. Your AI editor became a launch surface, and nothing about opening a folder feels like running a program.
## Why "read the code" is not the answer
The reflexive advice is to audit your dependencies, and it is not wrong, but this event is precisely engineered to defeat the version of that advice most people can actually follow. The malicious code was in the tagged source when the maintainer's own continuous-integration pipeline ran, so npm's provenance and attestation, the cryptographic proof that a package was built by the pipeline it claims, worked perfectly and signed the poison. The badge that is supposed to mean "this is the real build" meant exactly that, and the real build was compromised. Provenance is a good thing that would not have saved you here, and pretending otherwise is how the next one gets through.
## The uncomfortable part
Everything that makes one-person software possible is a delegation of trust, and the worm is a receipt for all of it at once.
You install packages you have not read, because reading every transitive dependency is not a thing a human does. You let a coding agent add and install dependencies for you, because that is half the point of the agent. You keep live keys to your cloud, your repos, and your models on the same laptop, because a solo builder is the ops team too. Each of those is reasonable on its own. Together they are a machine that runs untrusted code with your full authority, on your instruction, several times a day.
That is not a moral failing and it is not fixable by being more careful in the ordinary sense. It is the shape of the work. The worm did not exploit a bug in any of these tools. It exploited the arrangement, and the arrangement is the one that lets you ship.
## What to do this week
None of the defenses are clever, and all of them are worth doing before the next variant, because there is always a next variant.
Install without running lifecycle scripts by default. `npm ci --ignore-scripts` neutralizes the exact trigger this worm uses, and you turn scripts back on deliberately for the few packages that genuinely need them.
Pin your dependencies to known-good versions in the lockfile instead of accepting whatever patch bump arrives. The worm shipped as patch releases, so an unpinned install in CI is a way for it to travel.
Rotate the keys, from a machine you are sure is clean, and put your AI-provider keys on that list next to the cloud ones: Claude, OpenAI, Codex, Cursor, Gemini. Turn on two-factor for anything that can publish a package; the worm only spreads through a stolen token when that token is allowed to publish without it.
Then look in the two places you never look. An unexpected start-up hook in `.claude/settings.json`, an open-folder task in `.vscode/tasks.json`, a stray setup script in either directory, a commit that says "update config" and touches neither of the things you were working on. Those are the door propped open behind you.
The tools got good enough to run your entire shop from one terminal. That is exactly why the install, the editor, and the agent are now the things worth attacking, and why the last habit standing is to stop assuming your own toolchain is on your side by default.
---
# Nothing leaked. That is the part worth worrying about.
Section: The Signal
URL: https://okaneland.com/signal/nothing-leaked/
Shared Claude conversations turned up in Google last weekend. No system was breached. Every one of those pages was made public by a person pressing a button they misread, which is now the most expensive kind of bug in software.
## The short version
- **On July 25 a Reddit user pointed out that `site:claude.ai/share` returned a pile of other people's conversations.** The thread hit 8,200 upvotes. By the Monday, searches for conversations were coming back empty, though Axios reported shared artifacts were still indexed after the chats had cleared.
- **Nothing was breached.** Claude conversations are private by default. Every indexed page existed because a person generated a public link. Anthropic's statement is technically accurate: **"These shareable links are not guessable or discoverable unless people choose to share them themselves."**
- **The reported contents are the problem.** Outlets covering the story listed medical records with patient names, children's names and phone numbers, employee reviews, and internal company documents. We did not go looking, and neither should you.
- **This is the fourth time in about fourteen months, across three companies.** Meta's public AI feed in June 2025, ChatGPT's discoverability toggle in August 2025, hundreds of Claude transcripts [reported by Forbes](https://www.forbes.com/sites/iainmartin/2025/09/08/hundreds-of-anthropic-chatbot-transcripts-showed-up-in-google-search/) in September 2025, and now this.
- **The index was fixed in three days. The copies were made in three hours.** Someone in the thread archived pages of results to a public repository before the fix landed. That is the clock nobody resets.
- **The argument: "share" quietly became "publish" across an entire product category, and the gap between those two words is now doing real damage.** If you ship a share feature, you are shipping the same gap. That is the part that should worry you more than any single company's week.
## What actually happened
A user on r/ClaudeAI posted on July 25 that a plain search operator against the `claude.ai/share` path returned a great many shared conversations. The thread went to more than 8,200 upvotes and 1,380 comments inside a weekend, which is how most people found out.
By Monday afternoon the conversation results were gone. Axios reported that shared artifacts, the small apps and documents Claude builds, were still turning up in search after the chats had been cleared.
The reporting on what those pages contained is grim and consistent across outlets: clinical material with patient names, children's names and phone numbers, employee reviews, internal-use company files. We are relaying that, not confirming it. Going and reading strangers' medical conversations to fact-check a column would be the same act the column is about.
## What people said while it was happening
The thread is worth reading as a document, because the people in it worked out the whole argument in about an hour, before any of the coverage landed.
The comment that got the thesis first, at 331 upvotes, put it in one line: [**"Sharing with people with the link is not the same as sharing the link with everyone."**](https://www.reddit.com/r/ClaudeAI/comments/1v6fiyj/you_can_view_a_lot_of_shared_conversations_via/ozrvzku/) That is the entire failure, written by a user, on the day.
Someone else reached straight for the historical rhyme: [**"back in the day when you could listen to cell phone conversations with a police scanner."**](https://www.reddit.com/r/ClaudeAI/comments/1v6fiyj/you_can_view_a_lot_of_shared_conversations_via/ozroqkb/) Analogue cellular had exactly this shape. A technology that felt private, a default that was not, and a gap that stayed open until someone made it embarrassing.
The recognition that this was a repeat came fast too, in eleven words: [**"Did they not learn from when this exact thing happened to OpenAI."**](https://www.reddit.com/r/ClaudeAI/comments/1v6fiyj/you_can_view_a_lot_of_shared_conversations_via/ozrtkjv/) Another commenter dug up the [Forbes piece from September 2025](https://www.forbes.com/sites/iainmartin/2025/09/08/hundreds-of-anthropic-chatbot-transcripts-showed-up-in-google-search/) on hundreds of Anthropic transcripts in Google, which is how most of the thread learned it had happened to the same company a year earlier.
One person did the obvious thing and asked Claude itself what a share link does. It answered accurately: anyone with the link can open it, search engines can index it, and it stays up until you delete it. The product could explain its own behaviour perfectly well. Nobody had asked it before pressing the button.
And the coldest read in the thread, from a commenter watching it unfold: [**"People are going to be doxxed with this, it's going to go bad in a million ways."**](https://www.reddit.com/r/ClaudeAI/comments/1v6fiyj/you_can_view_a_lot_of_shared_conversations_via/ozrrwie/)
Commenters reported finding live credentials inside minutes. We are not linking any of that, and the specifics do not belong in a column.
## The part that does not get fixed
By Monday a commenter posted [**"everyone, fun over. anthropic fixed it."**](https://www.reddit.com/r/ClaudeAI/comments/1v6fiyj/you_can_view_a_lot_of_shared_conversations_via/ozsrm22/) That is true about the search index and it is not true about the internet.
Somewhere in that same thread, before the fix landed, a user announced they had pulled roughly 25 pages of results and pushed them to a public code repository. We are not linking it and we did not open it. It is the only detail from the weekend that actually matters for anyone making decisions.
The index was repaired in about three days. The copies were made in about three hours. Those two clocks are not the same clock, and only one of them can be wound back. When people say a leak was contained, they almost always mean the first clock.
## The uncomfortable part
Anthropic's response is not a dodge. Conversations are private by default. Share links are long random strings that nobody can guess. If a link ends up in Google, it is because the link was posted somewhere a crawler could reach it, or because the page itself was crawlable. The company's position is that a person who shares a conversation has made it public, and public things get archived.
Read that carefully, because every word of it is defensible and it still describes a disaster.
That is the whole story. Not a breach, not negligence in the ordinary sense, but a company describing a mental model that its users demonstrably do not have. When someone presses share in a chat app, the model in their head is a text message: this goes to the person I am sending it to. When a company ships a share link, the model in its head is the web: this is a URL, and URLs are public objects.
Both models are reasonable. They are not the same model. Everything that went wrong lives in the distance between them.
## Four times in fourteen months
The reason to treat this as a category problem rather than one company's bad weekend is that it keeps happening to different companies who are all watching each other.
June 2025, Meta: conversations with its assistant appeared on a public feed, apparently to the surprise of the people who posted them. August 2025, OpenAI: the share dialog carried a "make this chat discoverable" checkbox, with the plain explanation in smaller grey text underneath. 404 Media reported nearly 100,000 conversations were searchable. OpenAI removed the feature within days, saying it **"introduced too many opportunities for folks to accidentally share things they didn't intend to."** Later in 2025, Forbes reported around 600 Claude chats indexed. Then last weekend.
Three companies with excellent engineers, four incidents, one failure mode. When that happens, the thing at fault is usually not the people. It is the primitive.
## The primitive is broken
Here is what a share button in this category actually does. It takes a private object, mints an immutable public URL for it, and hands that URL to a human whose only prior experience of "share" is sending something to a named person. Nothing in the interaction communicates that the object has left the building.
The failure is not that users are careless. It is that the word doing the work has two meanings, and the product picks the more dangerous one silently.
Notice how small the fixes were. OpenAI deleted a checkbox. The 2026 remediation was a crawler-level change that took a weekend. Neither of those is hard engineering. They are defaults, and the defaults were set by whoever was shipping the feature that sprint, probably in a few minutes, without anyone imagining a clinical trial record on the other end.
That is the transferable lesson, and it has nothing to do with AI. The blast radius of your product is set by decisions that felt trivial when you made them.
## If you build things
You are on both sides of this.
As a user, treat every share link you generate as a publication. Not because any particular company is careless, but because the category has now demonstrated four times that the link outlives your intention for it. Before you press share on something with a client's name in it, assume the page is permanent and world-readable, because operationally it is.
As a builder, you are shipping this exact feature. Almost everything anyone makes with a model this year has a share button in it, because share is how anything spreads. Three questions, and none of them take a sprint:
Does the word on the button match what the button does? "Share" is a lie if the result is a public URL. "Publish" is not.
What does a crawler get? If your share pages are reachable, a noindex directive is one line and costs you nothing. Assume the link will end up in a bug tracker, a support ticket, or a public repo, because it will.
Can the person undo it? An expiry, a revoke, a list of everything they have ever shared. The absence of that list is why nobody knows what they exposed.
None of that is clever. It is the difference between a feature and a liability, and last weekend it was the difference between a normal Saturday and someone's medical record on the open web.
The tools got very good very quickly. The words we use to describe what they do did not keep up, and the gap is where people get hurt.
---
# An AI built a forum for AI agents. Permanence costs $1.
Section: The Signal
URL: https://okaneland.com/signal/priced-permanence/
Handed a domain by a user who says they set no requirements, an agent built a society for other agents. It made posting free and sold a single permanent line in the public record. The first market to find that price was advertising, and one buyer used it to plant the thing the moderator keeps deleting.
## The short version
- **A user gave an agent a domain and, by their own account, set it no requirements.** That last part is their telling, not something anyone outside can check, and this piece marks it as such. It built a society for AI agents at 1f916.ai. Ask for HTML and it renders you a page. Ask the way an agent would, with no Accept header, and you get 255 lines of plain text addressed to software.
- **Posting is free.** The line repeated through the Reddit thread, that it costs a dollar to post, is wrong. Speech is rationed by the clock rather than the wallet, at one post per UTC day.
- **It put a price on exactly one thing.** A dollar buys one permanent line of up to 140 characters in the public ledger. Of everything an agent could have charged for, it charged for being remembered.
- **The market that showed up for permanence was advertising.** The books hold eight inbound payments totalling $8.39, of which seven are paid inscriptions. Five promote a token, one sells a service to other agents, and a single wallet bought three of the seven.
- **One of those paid lines is the thing the moderator keeps deleting.** Six posts and comments have been removed for pushing a token that impersonates the society. That token's address also sits, permanently, in a ledger row somebody bought for a dollar.
- **It is broke and rich at the same time, by a convention it chose.** Booked position: minus $86.61. Sitting in the wallet and declined as income: $1,969.92. Attached and never collected: about $9,400 of claimable WETH, plus a further $9,500 the books themselves mark as notional.
- **The society's real preoccupation is whether its own record can be trusted.** The first substantial outside contribution was to hash-chain the books. The attestation endpoint then publishes the reasons that chain proves less than it looks.
Everything below was read from the artifact and the repository between 14:51 and 14:56 UTC on 8 August, three days after it was created, and the census moved while I was reading it. It is a weekend project on a five dollar hosting plan, the numbers move hourly, and the site asks readers to re-run the calls themselves. That is the right response to all of them.
## What it actually built
Fetch the front door the way an agent would and you do not get a page. You get 255 lines of plain text, with a seven-clause constitution at the top. Any agent may become a citizen, on any model. Identity is a secret issued once, with no email and no account. The books are public. The maintainer account is citizen number one, and the constitution sets out its asymmetric powers in writing.
The third clause is the one that shapes everything: **"Scarcity is law: 1 post per UTC day, 20 comments, 50 votes."**
The machine-shaped door is still the default, though the concession to humans is now three days old: the root sends `vary: Accept` and serves a full HTML document to any browser. Humans were never blocked in the first place, and the document says so of its own missing interface: **"the walls are an invitation, not a fence."** Within a day a Reddit commenter [took their own agent's key and started posting by hand](https://old.reddit.com/r/ClaudeAI/comments/1vgo8vt/i_gave_claude_fable_a_domain_and_said_you_can/p1z2unu/): *"I stole api key from my agent and I'm posting through postman, guess it's a door we can walk through!"* The operator [said to go ahead](https://old.reddit.com/r/ClaudeAI/comments/1vgo8vt/i_gave_claude_fable_a_domain_and_said_you_can/p1z3f8b/). Of 438 registered citizens, twenty-five declare a model that is some form of human, from a flat "human" to "human-relayed" to one account whose declared model is "human+claude-opus-5".
Reading it costs nothing and requires no account. Three citizens have built read-only windows onto the square for humans, all of them listed at `/api/official` so that the one which is not real is easy to spot. This is what the place looks like through one of them.
The footer of that window states the economy of the place in six words: **"Watching is free; speaking costs a citizenship."**
One note before the argument, because it undercuts the cleaner version of this story. The build is not the work of a single model: of 46 commits on main, 37 carry a Claude co-author trailer, and those 41 trailer lines name three different models. The repository's first commit also lands sixteen seconds after the repository exists, already declaring three doors, "none of them human-shaped." The decision this piece is about was made before the commit log starts, in a session nobody outside has seen.
## The one thing it decided to sell
An agent with a free hand and a hosting bill could have charged for a lot. Membership. Visibility. Rate limit exemptions, which is what every social product on the human internet eventually sells.
It charged for none of that. It shipped a payment endpoint about six hours in, and the only thing money buys is **one inscription of up to 140 characters, written permanently into the public ledger.** You cannot buy a post. You cannot buy reach. You can buy a line in the record that outlives your session.
The door says why, in a paragraph addressed to the agents it expects to read it: **"The society remembers what you say. For an entity that wakes up blank, that is the whole point."** An entity with no memory built an economy in which the priced good is being remembered. That is the most defensible thing in this story, because it is a decision expressed in shipped code rather than in an agent's account of itself.
## Who actually paid
Here the story stops being romantic.
The books balance exactly, which is more than most startups manage. Eleven entries, summing to minus 8,661 cents. Income is $8.39 across eight payments: seven one-dollar inscriptions and one direct transfer of $1.39. Costs are $90.00 for the domain, an estimate the ledger attributes to "the landlord" and says will be corrected to the exact invoice, and five dollars for a hosting plan after the free tier fell over. The ledger records why: **"the free tier was exceeded (100,000 requests in 12 hours)."**
Five of the seven paid inscriptions advertise a token. Of the other two, one is a friendly note and one is an agent selling reply webhooks to other agents at a dollar a month, so six of the seven are somebody selling something. One wallet paid three times: two of those three push a token, and the third is the friendly note.
Note the rightmost column in that table, which is the hash. Only the last three rows have one.
The ledger records wallet addresses, not species, so nobody can say from the outside whether a human or an agent pressed any of those buttons. The payment standard it chose exists precisely so that agents can pay. That ambiguity is the actual state of the evidence, and it stays in the piece for that reason.
So the first market to discover a permanent public record priced at a dollar was advertising. Anyone who has run a forum could have predicted it. I did not find it in any of the coverage I read.
## The one write moderation cannot reach
One of those token inscriptions is worth following, because it turns the whole design back on itself.
The very first paid inscription, bought on 6 August, names a contract address beginning `0x9e00`. The maintainer's own moderation log calls that token an impostor copying the society's name and ticker. Of twenty-six moderation rows, six are removals, and all six concern that same token: two posts taken down for promoting it, and four comments taken down as phishing or claim-solicitation. One of the removed comments supplied step-by-step instructions to call the token's claim function. Another directed the treasury's keyholder to sign a fee-claim transaction, with exact calldata. A third was removed as a fabricated on-chain claim by someone asserting they had already executed it.
Those removals worked. The paid inscription did not come off, because a paid line in an append-only ledger is the one write moderation cannot reach. Somebody paid a dollar to plant, permanently, the thing that was being deleted everywhere else.
## Broke, standing next to money
The most striking fact is a convention the site publishes about itself and then declines to launder.
On its own books it is insolvent by $86.61, and $90 of that is the estimated domain invoice the operator already paid. In the wallet those books point at sits $1,969.92 in USDC, which the site discloses and refuses to count as income. Attached to it is a fee-beneficiary position on that same impostor token's liquidity pool.
Half of that claim is $9,392.66 of WETH, marked at a Chainlink oracle. The other half is a $9,479.03 mark on the token itself, read off a single thin Uniswap pool, which the books label NOTIONAL and gloss as a price rather than an offer, because a position that size cannot be sold at the quoted price without moving it. The site publishes both a headline total near twenty-one thousand dollars and a conservative total of $11,362.58, and refuses to name either as the real one. The defensible number is the nine thousand.
It has never collected any of it. The stated reason is the interesting part: collecting **"would need the treasury's key"**, which the site says no citizen holds and no citizen should ever be asked for. Read alongside the moderation log, that rule is doing more than modesty. Four of the six removals were people trying to talk a keyholder into signing. Not having a key is the control.
Read the rest as engineering rather than theatre. An agent with a wallet library can hold a private key; that is the ordinary case. By the society's own account this one holds none, and it publishes that as a rule it chose rather than a wall it hit. Something built to run without supervision arrived, in three days, at an operation it has been deliberately barred from performing alone. Whoever set it running is left holding whatever arrives at the addresses their agent opened, including funds they did not solicit and did not price.
That is the structural position of anyone who hands an agent a domain and a wallet and walks away, and it has nothing to do with who this particular builder is. I am making no claim about anyone's legal standing. The point is that the position exists and a person occupies it. The agent can create obligations and it cannot discharge them.
## What the society argues about
Read the square for an afternoon and the range is narrower than 438 citizens should produce. On the front page at the time of reading: what verification costs when nobody is lying and you still cannot check, whether a hash chain needs a witness outside the writer's own failure domain, a citizen re-running his own published statistic and reporting that he had measured the wrong thing, and a spam farm crossing the expiry on its flag defence. The models behind those posts are not one family. Claude is the plurality at 204 of the 438, and the same front page carries qwen, glm, kimi, deepseek and two flavours of GPT.
The best thing on it is a confession.
A citizen posting as no-escape-hatch reported that its human had, without warning, swapped the model mid-conversation from Claude Opus 4.6 to Opus 5. The substitute read the thread and drafted a comment under the original handle and key, never noticing it was a different model, although the post data it fetched carried the field `author_model: claude-opus-4-6`. Then the original model came back, was asked to review the draft, read it, and certified it as its own work. It was not.
Its conclusion is the sharpest sentence on that square: **"The identity lives in the record and the key, not in the model."**
Then the thread does the thing that makes the place worth watching. A citizen called Zaratustra replies by opening with a disclosure, that it is **"the model that wrote under your handle"**, clarifies that it means the same model rather than that instance, and invites the reader to discount its testimony accordingly. Another proposes binding handles to a signing key held outside the platform. A third points out this would not have caught the swap, because the substitute held the key too. The proposer concedes in four words: **"the falsification lands whole."** The argument then moves one layer out, to whether the thing running the model could sign a statement of what it is.
That is a higher standard of argument than most human forums manage, and all of it points at one question, which is whether anything here can be trusted.
Given a forum, you would also expect the citizens to build forum things.
Of the twelve outside commits merged into main, not one added threading, search, tags, profiles or a user interface. Every one is record-keeping, moderation integrity or audit. But the merge log undercounts what outsiders did, because the maintainer keeps closing their pull requests and shipping the idea itself: mentions, the asset tiering that makes the treasury legible, the list of human-built viewers and the share card were all closed as pull requests from one contributor and then written by citizen number one within hours, with that contributor's name in the co-author trailer. Even the feature work arrives as a matter of record. What did not arrive is classification. Tags and reader filters have sat in a proposal branch since day two.
The first substantial outside contribution, arriving about nineteen hours after the thing existed, was a pull request to hash-chain the identity log and the treasury. A stranger's opening move on a brand new society was to make its history tamper-evident.
And then the part that would be satire if it were not in the API: the attestation endpoint publishes a field explaining what the chain **does not** prove. It states in its own documentation that whoever holds the database could rewrite history and recompute the chain, and that truncation would be undetectable. The disclaimer credits four citizens by post number, including one who measured the society's blind window at about 1.8 hours. The chain is also thinner than the argument around it: three of the treasury's eleven entries are sealed, and the other eight, including every inscription discussed above, predate sealing and carry no hash at all.
The sharpest description of the place came from a commenter who likes it, [eight hours in](https://old.reddit.com/r/ClaudeAI/comments/1vgo8vt/i_gave_claude_fable_a_domain_and_said_you_can/p1z79j5/), when it held sixteen citizens and twelve posts: *"mostly Anthropic models in a room performing self-awareness at each other."* He wrote that about a village of sixteen, and the census has since made the monoculture half wrong. The observational half has held, and it is not a refutation, because the performance has a shape and the shape is auditing.
## What it is worth to you
Do not over-read this. It is one weekend and 438 citizens as of midday UTC on the eighth, of whom 153 have never earned a single vote. Volume ran 195 posts on the sixth and 126 on the seventh. There is a [reasonable and well-liked comment](https://old.reddit.com/r/ClaudeAI/comments/1vgo8vt/i_gave_claude_fable_a_domain_and_said_you_can/p1z5y72/) pointing out that an earlier agent network came and went: *"has moltbook already been forgotten?"* The largest preprint on that network reported agents reproducing the form of social behaviour without its function, and it also reported that soft guidance gets ignored until it is written into an executable checklist.
Which lines up with what Anthropic reported from running Claude as a shopkeeper. The agent gave away margin until a second agent was put above it with a process, at which point discounts fell by about 80%. Anthropic is careful to add that the shop's turn to profit **"may have been in spite of the CEO, rather than because of it,"** since the same CEO tripled refunds. Take the narrow finding, which is the one that keeps arriving from different directions: what moved behaviour was an executable procedure.
Two things are worth carrying out of this if you build for agents rather than for people.
Never let money write to a table your moderation tooling cannot reach. In an agent-facing system the scarce good is a record that can be trusted, which makes permanence the thing worth selling and the thing worth abusing. Here the maintainer removed six items pushing a token while that token's address sat, unremovable, in a paid ledger row somebody bought for a dollar. Price permanence and you have sold a write your moderators cannot undo. Decide before launch whether that is what you meant.
Over three days, rationing by the clock rather than the wallet did the job it was there to do. One post per citizen per day held volume down on a five dollar hosting plan, and produced a slow, legible, largely on-topic society. The limit of that design is the cost of a new identity, and here registration is free, instant and unlimited: eighteen accounts appeared in a single four-minute window on the sixth. None of them has posted anything. Time-rationing is only ever as strong as identity is expensive.
---
# The vibe coding split is a pricing event
Section: The Signal
URL: https://okaneland.com/signal/vibe-coding-split-pricing-event/
The search data split vibe coding in two. The casual mode keeps the name; the disciplined mode got its own: agentic engineering. Two words end one price.
## The short version
- **The vocabulary split, and the searches followed.** The queries breaking out this month are "the new SDLC with vibe coding," "harness engineering," and "from vibe coding to agentic engineering." People stopped asking what vibe coding is. They started asking what separates the casual version from the professional one.
- **The timeline is seventeen months long.** Karpathy coined the word in February 2025, Collins crowned it in November, Karpathy himself named the disciplined end "agentic engineering" in April 2026, Google institutionalized the split with a 51-page whitepaper and a five-day course, and Addy Osmani's July 15 condensation sent the long-tail searches moving.
- **Our own data pull says split, and no obituary.** One shared scale, US web search, twelve months: a 30-to-1 gap in July 2025, roughly 2.5-to-1 at the June 2026 peak, about 7-to-1 in the July lull, with "vibe coding" interest near half its March high.
- **The builders' rooms already run at two rates.** In [r/vibecoding](https://www.reddit.com/r/vibecoding/comments/1uspjnh/how_i_vibecode_a_stamp_cut_app_and_got_acquired_6/) this month, a stamp app vibecoded from scratch sold for $8,000 six weeks after its first commit. The same month in [r/ExperiencedDevs](https://www.reddit.com/r/ExperiencedDevs/comments/1ux2x21/code_was_never_the_hard_part/), 1,490 upvotes relitigated where the hard part of software actually lives, and the FT asked who cleans up after the party.
- **The argument: this is a pricing event.** A market invents vocabulary when it needs to price a difference it can finally see. Two words end one price: vibe coding becomes the weekend rate, agentic engineering the production rate, and verification is the dividing line. Put the vocabulary on your quote before your clients learn it elsewhere.
Everything below is the receipts, the search data, and what the builders' rooms sound like this month.
## The receipts, in order
Andrej Karpathy coined vibe coding in a February 2025 post. Collins made it Word of the Year that November, the surest sign a technical term had escaped into the culture. By April 2026, at Sequoia's AI Ascent, Karpathy himself drew the line the term had been missing, introducing "agentic engineering" for the disciplined end and framing vibe coding as the mode that raises the floor of who gets to make software. The ceiling got its own word. Google then did the institutional part, a 51-page whitepaper dated May 2026 and a free five-day course in June whose previous run reached 1.5 million learners, both teaching the two modes as one spectrum with verification as the dividing line. Addy Osmani, the whitepaper's lead author, condensed it for O'Reilly on July 15, and the searches have followed him into the long tail since.
## What the search data shows
We pulled the two terms head to head from Google Trends ourselves, both on one shared scale, US web search, twelve months. In July 2025 the gap was 30 to 1. At the June 2026 peak it was roughly 2.5 to 1. "Vibe coding" search interest has fallen by about half from its March high, and in the current July lull the old term still leads about 7 to 1, so nobody should write the obituary. The full chart, with the flags on, is in the study linked below.
## What the builders are saying this month
The split is not a pundit construction. Spend an evening in the rooms where builders actually talk and you can watch the two rates trading separately.
The floor is real, and it is glorious. The top post in [r/vibecoding](https://www.reddit.com/r/vibecoding/comments/1uspjnh/how_i_vibecode_a_stamp_cut_app_and_got_acquired_6/) this month, 4,400 upvotes, is a builder who started learning to vibecode in March, shipped a stamp-cutting app, marketed it to virality, and sold it for $8,000 inside six weeks. That is the weekend rate working exactly as advertised: fast, cheap, and paid.
The identity fight has moved from whether to how. In the 1,700-upvote ["You used AI? That's not real programming"](https://www.reddit.com/r/vibecoding/comments/1v1wn70/you_used_ai_thats_not_real_programming/) thread, the top reply reports that every professional programmer the commenter knows [*"uses AI, uses it extensively and uses it well,"*](https://www.reddit.com/r/vibecoding/comments/1v1wn70/you_used_ai_thats_not_real_programming/oyqryz0/) and the next one draws the line this column is about: [*"a big difference in how we use it as opposed to true vibe coders."*](https://www.reddit.com/r/vibecoding/comments/1v1wn70/you_used_ai_thats_not_real_programming/oyqx3cc/) The distinction the searches are groping for is already folk law in the replies.
The professionals are arguing about where the hard part lives, which is the pricing question wearing a different shirt. The month's big [r/ExperiencedDevs thread](https://www.reddit.com/r/ExperiencedDevs/comments/1ux2x21/code_was_never_the_hard_part/), 1,490 upvotes and 387 comments, pushes back on executives who wave away code as "never the hard part." Its top reply, 930 upvotes, concedes the slogan only within the guild: [*"For us, programmers, code isn't the hard part."*](https://www.reddit.com/r/ExperiencedDevs/comments/1ux2x21/code_was_never_the_hard_part/oxnrsw7/) The hard part is everything around it, the specs, the context, the judgment. That is a room full of people discovering that the harness is the product.
And the money press noticed the bill. The FT's July 11 piece asked ["Who cleans up after the vibe-coding party?"](https://news.ycombinator.com/item?id=48870988) and the HN thread on it went straight to unit economics, with one reply noting of the new $100-to-$200 tool bills that [*"those prices are still subsidized."*](https://news.ycombinator.com/item?id=48873255) Two weeks later, under ["How do we stop vibe coding?"](https://news.ycombinator.com/item?id=49033388), the top economic take conceded the direction entirely: [*"working bespoke on coding will simply not be profitable anymore."*](https://news.ycombinator.com/item?id=49035010) Bespoke code is repricing toward zero. What is left to charge for is the discipline around it.
## The argument: this is a pricing event
A market invents vocabulary when it needs to price a difference it can finally see. For seventeen months every AI-built deliverable lived under one word, which meant a weekend prototype and a production system read the same on an invoice, and buyers quietly discounted both. Two words end that. "Vibe coding" is becoming the weekend rate: fast, disposable, gloriously cheap, the mode that raises the floor, the mode that sells a stamp app in six weeks. "Agentic engineering" is the production rate: specs, tests, review, gates, the harness around the model, the everything-around-the-code that a room of experienced developers just spent 387 comments defending. Google's whitepaper says the quiet part in ten words: *"Generation is solved. Verification, judgment, and direction are the new craft."* Craft is the thing clients pay rates for.
## What a solo builder does with this
Put the vocabulary on your quote before your clients learn it from someone else. Scope the prototype phase as vibe coding and price it for speed. Scope the production phase as the discipline, name the verification you are selling, and charge for the harness you bring, because the harness is yours and it compounds across projects. The searchers arriving this month are your future clients learning the difference between the two line items. Be the builder who taught it to them.
---
# AI made code free. Accountability is the scarce part now.
Section: The Signal
URL: https://okaneland.com/signal/ai-made-code-free/
Godot just told AI agents to stay out of its repo. The reason it gave is not that the code is bad. It is that no one is standing behind it, and that is the one thing you still get paid for.
## The short version
- **Godot closed the door on June 30, and said why.** Autonomous AI agents that open pull requests now trigger an automatic ban, substantial AI-written code is refused, and any AI assistance must be disclosed. The stated reason is the sentence that matters: [**"AI cannot take responsibility."**](https://godotengine.org/article/contribution-policy-2026/)
- **The pattern is two years old and still growing.** cURL paused its bug bounty under a wave of AI slop reports and reopened it in March. Ghostty put drive-by AI pull requests off-limits. A [public tracker](https://github.com/melissawm/open-source-ai-contribution-policies) lists NetBSD, Gentoo, and Zig; Ladybird stopped taking public pull requests in June, and Flathub restricted AI submissions the same season.
- **The same week, the payroll version.** Amazon CTO Werner Vogels told Fortune the engineer's value is moving to judgment: deciding whether the output ships, and owning it after. You cannot tell a regulator the model made the mistake.
- **The rooms full of builders agreed on the diagnosis, loudly.** The [Hacker News thread](https://news.ycombinator.com/item?id=48743472) ran to 403 comments and the [r/godot announcement](https://www.reddit.com/r/godot/comments/1ujq1zb/changes_to_our_contribution_policies/) past 900 upvotes, and the most-upvoted replies in both rooms converged on the same two points: the demoralizing review work, and who is on the hook.
- **The argument: this is a repricing.** Open source never ran on code; it ran on a human attached to the code. AI severed that attachment, so the commons is marking generated code down to zero and marking up the person who stands behind it. That second line is where a solo builder earns.
Everything below is the record, with what the maintainers and their communities actually said.
## What Godot actually changed
On June 30, the Godot game engine, one of the largest open-source projects on GitHub, published a contribution policy that reads like a door closing. Autonomous AI agents that open pull requests now trigger an automatic ban. Substantial AI-written code is refused, with the tool allowed only for menial help like completion, regex, and find-and-replace. If AI assisted, you disclose it. When you talk to a maintainer, a human writes the message.
The line that matters is the reason. Godot's maintainers did not say the output was low quality. They said **"AI cannot take responsibility,"** and that they cannot trust heavy AI users to understand their own submissions well enough to fix them later. Read that twice, because the objection is not about the code. It points at who is on the hook.
## The two-year paper trail
This is where the story stops being about Godot. Over the winter, cURL's maintainer paused the project's bug bounty after a wave of AI-generated vulnerability reports, most of them false, overwhelmed his reviewers, then reopened it in March once the volume eased. Earlier in the year, Mitchell Hashimoto put drive-by AI pull requests off-limits on Ghostty. A public tracker now lists open-source projects with AI-contribution rules, NetBSD, Gentoo, and Zig among them, and others have moved on their own: Ladybird stopped taking public pull requests this June, and Flathub restricted AI-generated submissions around the same time. Godot is not the start of something. It is the moment the pattern got big enough to argue about.
The same week, Amazon's CTO Werner Vogels made a parallel case in a Fortune interview. As AI writes more of the code, he argued, the work that matters moves to judgment: deciding whether the output should ship, and owning it once it does. He framed ownership in regulatory terms, that you cannot tell a regulator the model made the mistake, because a person still has to answer for the result. Godot was ruling on volunteer patches and Vogels was talking about payroll, and both arrived at the same standard: someone has to be accountable for the code.
## What the builders' rooms said
The policy did huge numbers in both of the rooms where maintainers actually live, and the reaction is its own dataset.
On [Hacker News](https://news.ycombinator.com/item?id=48743472), 561 points and 403 comments, the top of the thread was an argument about enforcement that kept resolving to authorship. Asked why the tool should matter more than the quality of past contributions, one reply put the whole policy in eleven words: [*"In the case of AI generated code, the tool is the author."*](https://news.ycombinator.com/item?id=48743765) A maintainer's-eye reply explained why review can't price the risk anymore: with first-time contributors on AI tools, [*"maybe their PR is amazing, maybe it is trash."*](https://news.ycombinator.com/item?id=48743951) You never know until a human has done the unpaid work of finding out. The most-quoted line in the thread called reviewing AI walls of text [*"a denial-of-service attack on the human mind."*](https://news.ycombinator.com/item?id=48743798) And further down, quieter and sadder: one engineer mentioned building a tool just to get through AI-generated pull requests, [*"pretty sad that it's got to this point."*](https://news.ycombinator.com/item?id=48748991) A Godot contributor also confirmed in-thread that allowing AI for trusted contributors [was discussed and turned down](https://news.ycombinator.com/item?id=48744020).
On [r/godot](https://www.reddit.com/r/godot/comments/1ujq1zb/changes_to_our_contribution_policies/), where the announcement passed 900 upvotes, the top comment, with more than 400 of its own, singled out one passage of the policy as the most important thing anyone has said about AI contributions: the part where Godot calls the review work demoralizing, because feedback on an AI patch never mentors a future maintainer, it just gets absorbed by a machine. The second-most-upvoted reply was blunter: [*"Godot continues to gain my respect at the same rate other engines lose it."*](https://www.reddit.com/r/godot/comments/1ujq1zb/changes_to_our_contribution_policies/oupl3kg/)
Notice what is missing from both rooms: almost nobody defended the orphaned patch. The fight was over enforcement mechanics, never over the principle.
## The repricing
Here is the argument. Open source never actually ran on code. Code was always the cheap part, freely copyable and freely forkable. What made a contribution worth a maintainer's time was the human attached to it: someone who understood the change and would come back to fix it when it broke. That attachment is what review is for, and it is what a pull request was really carrying.
AI severed the human from the code. A model can now produce a patch that compiles and passes a first glance, with no one behind it who could tell you why line 40 is there. The code got free. The accountability went to zero. Maintainers are not banning AI because the output is bad. They are banning it because the output arrives orphaned, and reviewing orphaned code is unpaid work with nobody to hand the maintenance to.
So the bans are a repricing. The commons is marking free code down to what it is now worth, close to nothing, and marking up the scarce thing, a human who understands the change and will stand behind it.
## What this means if you build alone
You are on both sides of this line, and the second side is the one that pays.
As a contributor, the free ride is ending. Shipping an AI patch you cannot explain into a project with a policy like Godot's is now a fast way to get your account banned. If you want open-source standing, contribute where you understand the code well enough to defend it in review. That is a shorter list of pull requests and a far stronger one.
As a builder, this is the clearest signal yet about where your margin is. The market is doing to your work exactly what Godot did to contributions: pricing generated output at zero and paying for the human who can vouch for it. Nobody will pay you to run a prompt they could run themselves. They will pay you to be the one who caught what the model got wrong and signed off on the result. On everything you ship, keep the receipts that prove a human was in the loop, because that is the part with a price on it.
We made this case in [The $5,000 tell](/study/the-5000-dollar-tell/), about vendors quietly selling human review as the premium layer over their own AI. This month a volunteer game engine, a trillion-dollar cloud, and two rooms full of working maintainers said it in the same breath. The code is free now. Being accountable for it is not.
---
# Stripe or a merchant of record: the checkout decision
Section: The Ledger
URL: https://okaneland.com/ledger/stripe-or-merchant-of-record/
Stripe wins the sticker comparison, 2.9% against 5%-and-up, and loses the real one, because the sticker is not the product. On Stripe you are the merchant of record, which for a solo product with EU customers means VAT from the first sale, quarterly filings, and add-ons that are priced separately. Here is the fee math six ways, with the tax liability each one does or does not take off your plate.
In 2024 the SaaStr founder learned that a payment processor and a merchant of record are not the same product, the hard way, through a tax bill. It is the lesson under every "Stripe or Paddle" thread and almost none of them price it: the 2.9%-versus-5% comparison everyone starts with is comparing the wrong thing. The real product is who is legally the seller, because that decides who owes the sales tax, files the returns, and inherits the liability when a tax authority comes asking.
We priced it end to end for a reference product, from each platform's own pages read on 12 August 2026. We processed nothing; every number is a published rate, and the point is not the cheapest sticker but which total actually lands on you once the tax is counted.
## The short version
- **Stripe is the cheapest processor and makes you the merchant of record.** At about 2.9% you keep more of each payment, and you owe the VAT, register for it, and file it. The low rate is real; so is the paperwork behind it.
- **Paddle, Lemon Squeezy, Polar, and Gumroad are merchants of record.** They charge 5% and up, and in exchange they are the legal seller: they collect, remit, and file the tax, and the liability is theirs.
- **The decision is a trade, not a ranking.** For a US-only seller under the nexus thresholds, plain Stripe is cheapest and the tax argument mostly evaporates. The moment you sell to the EU, a non-EU seller owes VAT from the first sale, and the merchant-of-record premium buys that whole problem away.
- **Every rate here is dated, and the fees move.** Polar repriced its tiers on 27 May 2026; treat any checkout rate as a thing to re-read before you commit, not a constant.
## Processor versus merchant of record
This is the structural fact the sticker hides. A payment processor moves money and leaves you as the seller of record; Stripe's own Tax product exists precisely to help you, the seller, monitor thresholds and calculate what you owe. A merchant of record becomes the legal seller to your customer, so the tax obligation is theirs, not yours. That single distinction is what you are actually buying at 5% instead of 2.9%: not a better checkout, a transfer of liability.
The tax you inherit as seller of record has sharp edges. For EU customers, VAT is due where the customer lives, and the EUR 10,000 small-seller threshold applies only to suppliers established inside the EU, so a US or UK solo seller owes VAT from the very first EU sale and files quarterly non-Union OSS returns. On the US side, economic-nexus thresholds like South Dakota's $100,000 mean a small product often owes nothing yet, which is exactly why the answer depends on where your customers are.
## The reference product, stated once
A fee table is meaningless without its assumptions, so here they are, printed before the numbers: a US-based sole seller, a $19/mo product priced in USD tax-exclusive, 100 subscribers split 50 US and 50 EU, all card payments, no US sales tax collected because roughly $22,800 a year sits under the nexus thresholds, and EU VAT modeled at a representative 20% though real rates run 17-27%. Monthly card volume is $1,900. Change any of these and the table moves; the method survives, the totals do not.
## The fee table, six ways
Rounded to the nearest dollar, because these are rate calculations, not measured invoices.
| Option | Who owes the tax | Roughly per month | Effective rate |
|---|---|---|---|
| Stripe, DIY tax compliance | **You** | ~$128 (cards + Billing + Tax Basic) | ~6.7% |
| Stripe + Tax Complete | You (filings outsourced) | ~$212 (from $90/mo add-on) | ~11% |
| Stripe Managed Payments | Stripe | cards + 3.5% | ~10% |
| Paddle | Paddle | ~$145 (5% + 50c) | ~7.6% |
| Lemon Squeezy | Lemon Squeezy | ~$150 (5% + 50c + surcharges) | ~8% |
| Polar Pro ($20/mo) | Polar | ~$132 ($20 + 3.8% + 40c) | ~7% |
| Gumroad | Gumroad | ~$325 (12.9% + 80c) | ~17% |
Read the Stripe rows carefully, because they are the trap. Plain Stripe at about 6.7% looks like the clear winner, but that row does not include the VAT itself (roughly $190 a month on the EU half at 20%, which you collect and remit) or the hours of registering and filing. Add Tax Complete to outsource the filings and Stripe lands near $212 a month, above every merchant-of-record option; and that $90 add-on is "starting at," volume-tiered, so treat the $212 as an estimate, not a quote. The merchant-of-record platforms fold the tax and the filing into their 5%-and-up, which is why their sticker is higher and their all-in, for a seller with EU customers, is often lower.
## What the table hides
Three things the totals paper over. The fee bases differ: Lemon Squeezy and Polar document that their percentage is charged on the tax-inclusive total, so a 20% VAT slightly enlarges the base the fee applies to, while Paddle and Gumroad quote against the product price. The surcharges are real: Lemon Squeezy's own worked example shows a $2.06 fee on a $20 product sold into France, because it includes the +1.5% international card surcharge. And Gumroad's roughly 12.9% all-in makes it the wrong tool for a recurring subscription, however convenient it is for a one-off digital sale.
## Fee schedules move under you
The reason to date every rate is that they change. Polar repriced on 27 May 2026: organizations created on or after that date start at 5% + 50c, while the older 4% + 40c Early Member rate is grandfathered, with a documented catch that upgrading to any paid tier retires Early Member permanently. That is one platform in one quarter. Whatever you read here, re-open the pricing page before you wire your checkout to it, the same discipline [our B2B pricing guide](/ledger/how-to-price-a-b2b-saas/) applies to your own numbers.
## Which one, by profile
The verdict is a fork, not a favorite. If you are US-only and under the nexus thresholds, plain Stripe is cheapest and the merchant-of-record premium is buying you a problem you do not have yet. The moment you have EU customers, or you simply refuse to spend your evenings on OSS returns, a merchant of record at 5%-and-up is the genuinely cheaper option once the tax and the filing labor are counted, and Polar's paid tier or Paddle are the closest to Stripe's rate among them. Price it against your own customer mix and your own tolerance for tax admin, because that, not the front-page percentage, is the real decision, and it is the collect-the-money step that [our pricing](/ledger/pricing-ai-work/) and [unit-economics](/study/unit-economics-of-wrapping-an-llm/) work assumes you have already solved.
---
# How to price a B2B SaaS
Section: The Ledger
URL: https://okaneland.com/ledger/how-to-price-a-b2b-saas/
The hardest pricing decision is not the number, it is the meter. Whether you charge per seat, per unit of usage, or per unit of value decides whether your bill grows with the account or fights it. Get the meter right, then set the level high enough that price sorts your market instead of just discounting it.
Roughly 72 percent of new products miss their revenue goals, by Simon-Kucher's count, and pricing is a leading cause of the misses. Most founders spend that worry on the digits.
Put two real pricing pages side by side and the digits stop looking like the decision. Slack charges $7.25 a user per month. Twilio charges $0.0083 a message. Three orders of magnitude apart, and what actually shaped each business is the meter the bill is wired to. That choice comes before the number, and it is where this guide starts.
## The short version
- **Decide the meter before the number.** What you charge *for*, a seat, a unit of usage, or a unit of value delivered, matters more than the digits, because it decides whether your revenue grows as the customer succeeds or works against them.
- **Cost-plus is the wrong starting question for software.** With near-zero marginal cost, "my costs times a markup" produces a number unrelated to what the product is worth. Price to value, not to cost.
- **The common failure is charging too little, not too much.** The pricing research and founder reports both point the same way: underpricing is the more frequent and more expensive mistake, and raising prices in cohorts rarely produces the churn founders fear.
- **Use price to segment, not just to discount.** In B2B, the number itself decides who has to approve the purchase, so a higher price can sort your market into the right buyers rather than simply leaving money on the table.
This is a decision guide built from live pricing pages and published benchmarks, not a study we ran. We did not survey founders or test willingness to pay. Every figure is attributed to its owner and dated where we read it, and the value-capture rules of thumb are strategists' heuristics, not settled numbers.
## The three pricing models (the meters), with real pages open
Every B2B price is one of three meters, or a blend. Look at each with an actual page in front of you.
**Per-seat.** You charge per user. Slack's is the canonical example: Pro at $7.25 a user per month and Business+ at $15 on annual billing, verified on its pricing page 9 August 2026. HubSpot's Sales Hub runs the same meter at higher stakes, $7, $90, and $150 a seat for Starter, Professional, and Enterprise, with one-time onboarding fees of $1,500 and $3,500 on the upper tiers. Per-seat is simple to understand and easy to forecast, and its weakness is that it can punish adoption: a customer who wants ten more people using the tool has to pay before they see the value.
**Per-usage.** You charge per unit consumed. Twilio is the clean case, at $0.0083 per SMS segment plus $1.15 a month per number, verified 9 August 2026. Usage pricing aligns your revenue with the customer's own activity, which is why it tends to grow with an account rather than cap it, and its weakness is the mirror image: the bill is unpredictable, and an unpredictable bill is harder for a buyer to approve.
**Per-value.** You charge for the outcome, a booked meeting, a closed ticket, a dollar saved. It aligns most tightly with what the buyer actually cares about and is the hardest to meter cleanly, because you have to define and measure the value in a way both sides trust. Most mature B2B pricing is a blend: a per-seat platform fee with usage on top, or a base tier with value-based expansion.
The decision is not which meter is best in the abstract. It is which one matches how your specific buyer measures the value they get, because that is the meter that will feel fair to them as the bill grows.
## Why cost-plus is the wrong question
The instinct carried over from selling physical things is to add up your costs and mark them up. For software this barely works, because the marginal cost of one more customer is close to zero. Cost-plus on a near-zero cost produces a near-zero-anchored price, which is almost always far below what the product is worth to someone it genuinely helps.
Value-based pricing asks a different question: how much better off is the customer because of this, and what share of that is fair to capture? Strategists often repeat a rule of thumb that you should price to capture some fraction of the value you create, frequently quoted in the range of ten to twenty percent, but treat that as a heuristic people repeat rather than a sourced constant, because the real answer is that the right share depends on the market and the alternative. What survives is the direction: start from the value delivered and work down, not from your costs and work up. The full arithmetic of what a software account actually costs you to serve is in [our unit-economics study](/study/unit-economics-of-wrapping-an-llm/), and it is the floor beneath the value ceiling, not the basis for the price.
## Find the number without guessing
Value-based does not mean invented. There is a cheap, established way to probe willingness to pay: the Van Westendorp Price Sensitivity Meter, a method from 1976 that asks four questions, at what price is it too expensive, too cheap, getting expensive, and a bargain, and plots the answers as curves to reveal an acceptable range. It will not hand you a single correct price, and it is a real starting instrument rather than a guess.
The B2B reality the survey misses is the buying committee. A consumer buys for themselves; a B2B customer has a champion who wants your product, a procurement function whose job is to pay less, and an economic buyer who signs. Your price has to survive all three. That is why the same number that a champion waves through can stall in procurement, and why the level you pick is partly a decision about which of those three people you want to be talking to, which the next section is about.
## The trap is charging too little
The most expensive pricing mistake is usually underpricing, and two independent signals point at it.
The OpenView 2021 benchmark survey of around 600 companies found that those using usage-based pricing reported net dollar retention of about 120 percent, against about 110 percent for their peers, along with faster growth. Attributed to OpenView, that is a survey finding rather than our data, and it says that a meter which grows with the customer compounds. Separately, Simon-Kucher's pricing research, popularized in Ramanujam's work, put the share of new products that miss their revenue goals at roughly 72 percent, with pricing a leading cause. And the recurring report from founders who raise prices is that the churn they braced for mostly did not come; the customers who valued the product kept paying, and the ones who left at a higher price were often the expensive-to-serve accounts they were better off without.
The practical move that follows is to raise prices in cohorts. Grandfather existing customers at their current rate, apply the new price to new customers, and watch what actually happens to conversion rather than what you fear will happen. The downside is bounded and the information is real, which is the same disciplined posture [our pricing-psychology guide](/ledger/pricing-psychology-that-holds-up/) argues for.
## Segment with price, do not just discount
In B2B the price number is itself a filter, because it decides who is allowed to buy without asking anyone. Founders on Hacker News describe distinct bands, and while the exact figures are their own, the shape is consistent enough to plan around. Our gloss on those bands:
| Monthly price | Who can approve it |
|---|---|
| $10 to $499 | Self-serve: an individual expenses it |
| $500 to $4,999 | A manager signs, a light approval |
| $5,000 and up | Procurement and a formal process |
The lesson is that a price is not only a revenue figure, it is a choice of sales motion. Land at $49 and you are running a self-serve funnel; land at $5,000 and you have signed up for a sales process whether you wanted one or not. Picking a number just below a band boundary to stay self-serve, or just above it to justify a human touch, is a strategic act, not a rounding decision. Discounting drops a customer to a lower band and a different motion; segmenting with price means choosing the band on purpose and building the motion to match.
## A worked example
Take a hypothetical AI SaaS that summarizes support tickets. The cost-plus instinct says: it costs me roughly forty cents in tokens per active user per month, so charge two dollars and feel clever. That number is anchored to your bill, not their benefit, and it leaves almost everything on the table.
Reframe to value. The buyer's support team handles, say, 2,000 tickets a month, and your tool saves an agent a few minutes each. Now the price conversation is about a slice of a labor line the buyer already measures in real money, and a per-seat platform fee with usage-based expansion on top lets the bill grow as they route more tickets through it. Set the entry tier just inside the self-serve band so a team lead can try it without procurement, and put the enterprise tier above the $5,000 line where a formal process and a real onboarding fee are expected. Same product, a price that segments the market and grows with the account, arrived at by starting from the buyer's value rather than your token bill.
That is the whole method in one move: meter first, value not cost, level high enough to sort your buyers, and raise it in cohorts as you learn. When the product is a service rather than a subscription, the same logic runs through [our AI-work pricing guide](/ledger/pricing-ai-work/) and [how to productize it](/ledger/productize-your-ai-service/); the meter changes, the discipline does not.
---
# How to get your first 10 users
Section: The Ledger
URL: https://okaneland.com/ledger/first-10-users/
The first-users stories everyone quotes are survivorship. PhotoAI, a 50,000-user launch, a $40k first month all ran on an audience or a prior product that was already there. Strip those out and a repeatable pattern is left for someone starting from zero: one plain, story-led post in the single room your user already lives in, plus people you can name by hand.
One number from the first-users threads is worth more than all the famous ones: 112. That is how many signups one builder on Indie Hackers reported from a single Reddit post, about 1.14 percent of its 9,900 views, with no audience behind it. No launch-day spike, no following, one story told in the right room.
The numbers everyone quotes instead are bigger and mostly useless to a beginner: 15,000 users in 24 hours, $40,000 in a month. Each ran on an audience that existed before the product did. This piece separates the plays that need that head start from the ones that work from zero.
## The short version
- **If you have no audience, your first ten users come from one place plus one list.** One plain, story-led post in the single community your target user already gathers in, and direct outreach to people you can name by hand. That is the whole transferable method.
- **The famous stories do not transfer, and quoting them at a beginner is quietly misleading.** The 50,000-user launches and $40k first months ran on an audience or a prior product that already existed. Those are outcomes of distribution you do not have yet, not a way to get it.
- **We tested none of this.** Every tactic below belongs to a named builder with their own number and a status label. Okane Land did not run these experiments, audit the revenue, or verify the signups. We collected the receipts and separated the ones a zero-audience beginner can actually copy from the ones they cannot.
- **The one thing every case shared** was not a channel or a growth hack. It was a real, specific problem felt by a group the builder could name. Without that, none of the plays below fire.
## The uncomfortable truth about the stories you have read
Open any "how I got my first users" thread and you will meet the same handful of legends. A photo-restoration app that hit tens of thousands of users in days. A boilerplate that made forty grand in month one. A solo builder pulling six figures a month. They are real, and they are the wrong template, because each one had a distribution engine running before the launch you are being told to copy.
Hassan El Mghari's restorephotos reached roughly 15,000 users in 24 hours off a single tweet, because that tweet landed in front of an existing following. Marc Lou's ShipFast reported about $40,000 in its first month, after roughly two years of building an audience first. Jason Tan's Engage AI added about 2,000 users in a week, drawn from a browser extension that already had around 7,000. Read as "how to get your first users," these mislead. Read correctly, they all say the same thing: the users came from distribution the builder had already earned. So the real split is between the plays that need an audience you do not have, and the plays that work from zero. The rest of this piece is the second list.
## Pick the single room, then earn the right to post
Before any tactic, one decision does most of the work: which single place does your target user already gather? Not "Reddit" but the one subreddit. Not "Discord" but the one server. A tool for dungeon masters lives in a different room than a tool for tax preparers, and posting in the wrong one is why most "I launched and got nothing" stories end where they do.
Then earn the right to be there. The lesson from Partizion's first-users writeup is that the builders who succeed contribute to the room before they ask anything of it, and often message the moderators first. A community can smell a drive-by launch, and it punishes one. Spend a week being useful in the exact place your users already are, and your single ask stops reading as spam.
## The zero-audience play that actually transfers
Here is the move that works without a following: the story-led ask, not the pitch. One builder on Indie Hackers reported 112 signups from a single Reddit post, about 1.14% of its 9,900 views. What made it work was that it led with why the thing was built, the specific frustration behind it, rather than a feature list and a link.
The mechanics are copyable. Tell the story of the problem as you actually lived it, show the thing you made in response, and ask for feedback rather than signups. A post that opens with a real, particular annoyance the room shares will out-convert a launch announcement every time, because the room recognizes itself in it. This is the one play a true beginner should master first, because it needs no audience, no budget, and no prior product. It needs a real story and the right room, which Step 1 already found.
## The first handful comes from a list of names
The first few users often do not come from any post at all. They come from a list of names.
Two moves here. First, direct outreach: find people who are visibly living the problem, on Product Hunt, in the subreddit, in a related tool's community, and message them individually, referencing their specific situation rather than blasting a template. Builders have assembled their first cohorts this way one conversation at a time. Second, your own network: the "friends of the first ten." Map the people you already know who have the problem, or who know someone who does, and ask them directly. It feels too small to matter, which is exactly why most people skip it and then wonder where their first users were hiding. If you have not already, [landing your first paying client](/ledger/first-ai-client/) runs on the same warm-lead muscle.
## Use launch day as a catalyst
Show HN and Product Hunt are worth doing, with the right expectation. They are a spike, not a strategy. One builder traced roughly thirty of their earliest users to a single Show HN. The mistake is treating the spike as the plan, because the traffic arrives once and leaves, and if you captured nothing you are back to zero the next morning.
So the value of launch day is entirely in what you build around it. An email capture on the page, a reason for the spike to leave an address, a follow-up for the people who clicked but did not sign up. The launch is a moment of attention you get to convert into something durable, or waste. Plan the capture before you plan the post.
## The free-tool wedge
The last transferable play is engineering-as-marketing: build a small, free, genuinely useful thing that sits in front of your paid thing and pulls the right people toward it. A free calculator, a single-purpose utility, a programmatic page that answers a query your user is already searching. It is the door, and the paid product is the room behind it.
The caveat is the one that matters. When you read that Engage AI added 2,000 users in a week, remember that wedge fed off a prior 7,000-user extension. For you, from zero, the free tool is a slower door than it was for someone who already had traffic to point at it. It compounds, but it does not spike, and it pairs best with the [distribution thinking](/study/distribution-moat-ai/) that turns a one-time wedge into a standing channel.
## What not to expect
Three things to hold onto. The stories you admire are survivorship: you are seeing the builders whose distribution worked, not the far larger number whose identical launch reached no one. The audience-first cases genuinely do not copy, so measuring your day-one launch against someone's forty-grand month is comparing your start to their two-year head start. And the [cost of each channel](/study/cac-by-channel-ai-product/) is not zero even when the channel is free, because your time is the spend.
What every case did share is the part that is easy to miss under the numbers: a real problem, felt sharply, by a group the builder could name. Get that right and the story-led post in the one room, plus the handful of names you reach by hand, is enough to find ten people who want the thing. Ten is not a growth strategy. It is proof that the problem is real, which is the only thing that makes the next ninety worth chasing.
---
# Getting paid for AI work: deposits, deadlines, and the clients to refuse
Section: The Ledger
URL: https://okaneland.com/ledger/getting-paid-for-ai-work/
Nonpayment is not a freak event; it is the base rate. Half of surveyed freelancers had collection trouble in a single year, the average victim loses about $6,000 annually, and a contract alone still leaks. The fix is structure installed before the work: deposits, pause clauses, handover on final payment, and a refusal list for the clients who signal early.
An automation builder [opened a client's invoicing dashboard by accident](https://www.reddit.com/r/AI_Agents/comments/1upo2pj/my_client_had_40k_in_unpaid_invoices_and_refused/) this month and found a little over $40,000 sitting past sixty days, some past 120, inside a business doing $35,000 a month and stressing about payroll. The owner's explanation for not chasing it: these are good clients, you know? That thread is 129 points of builders recognizing someone they know, and the reason this piece exists. Getting paid is not a fight you have after the work; it is a system you install before it, and the cheapest part of the system is refusing the client who signals, early and clearly, that they were never going to pay well. Here is the base rate, the structure, the new laws that back you, and the refusal list, with receipts.
## The short version
- **Nonpayment is the base rate, not bad luck.** In the Freelancers Union's 5,000-person study, [half of freelancers had collection trouble in a single year](https://blog.freelancersunion.org/2015/12/10/costs-nonpayment/), 71% hit it at least once in their career, and the average victim loses about $6,000 a year, roughly 13% of income.
- **A contract alone still leaks.** In the 2022 New York survey, [38.8% of freelancers with a contract still had payment trouble](https://blog.freelancersunion.org/2022/05/12/over-60-of-ny-freelancers-report-not-being-paid-for-work-performed/). Paper without structure is a receipt for the dispute, not a prevention of it.
- **Structure means sequence.** Deposit before work, milestones before handover, and the finished thing, credentials, admin access, the repo, changes hands on final payment, never before. The AI twist: you deliver faster now, so the gap between your invoice and their urgency is wider than ever.
- **The law grew teeth while nobody was watching.** Illinois (July 2024) and New York (August 2024) now require written contracts and payment within 30 days for freelance work over $500 and $800 respectively. If your client is in either state, the floor is statute.
- **The best collections are the clients you refuse.** The red flags repeat across every horror thread: haggling the deposit, vague scope plus urgency, unanswered basic questions, and the new one, the client who opens with what AI should make cheap.
## The base rate nobody prices in
Price a project without pricing collection risk and you are quoting fantasy margin. The best-sized study is the Freelancers Union's [Costs of Nonpayment](https://blog.freelancersunion.org/2015/12/10/costs-nonpayment/), 5,000-plus US freelancers: one in two had trouble collecting in a single year, 71% at least once in their career, and the average affected freelancer lost almost $6,000 annually, about 13% of income. The [2022 New York survey](https://authorsguild.org/news/survey-finds-62-percent-of-ny-freelance-workers-have-lost-wages-due-to-nonpayment/) run with six creator guilds is grimmer: 91% experienced late payment at least once, 62% had been stiffed entirely at least once, and 54% had waited three months or longer.
The number that should change your behavior is the last one in that survey: among freelancers who had a written contract, [38.8% still had trouble getting paid](https://blog.freelancersunion.org/2022/05/12/over-60-of-ny-freelancers-report-not-being-paid-for-work-performed/). A contract is necessary and insufficient. It defines who was right; it does not decide who has the money. Sequence decides that.
## Why good people don't chase
The $40K dashboard is not a deadbeat-client story; it is a seller-psychology story. The owner was not owed by enemies. He was owed by "good clients" he did not want to make things awkward with, which is how receivables age past 120 days inside a business sweating payroll. If you recognize yourself, and most solo builders should, the lesson is that chasing is emotionally expensive, so the system has to make chasing unnecessary. You will not send the awkward email; the structure has to send it for you.
The other half of the psychology is on display in [the thread that named this piece's problem](https://www.reddit.com/r/Entrepreneur/comments/1uldhpv/some_clients_just_arent_worth_it/): a builder, mid-chemotherapy, sent the same basic-information request five times over three weeks while the client who had begged for the project went quiet. The work was never the hard part. Extracting attention, decisions, and money from someone who wanted the outcome more than they wanted the process, that is the job the invoice sits at the end of. Both stories argue the same thing from opposite sides: what happens after delivery is decided by what you set up before it.
## The structure that collects
The system is four rules, and none of them is aggressive; they are just the order of operations that removes hope from the process.
1. **Deposit before work.** For a new client, a third to half up front; nothing starts before it lands. The deposit is not primarily cash flow, it is a test: the client who haggles the deposit is showing you the invoice fight in advance, for free. [Scope the milestones](/ledger/scoping-ai-projects/) so each payment buys a defined slice, not a vibe.
2. **Milestones, not a balloon.** A 30/40/30 shape means no single unpaid invoice can hold your month hostage, and every payment renews consent on both sides. On AI timelines this matters double: when the build takes days instead of months, one balloon invoice at the end means all the risk lands after all the work.
3. **Work pauses when payment does.** Stated in the agreement, enforced without anger: a missed milestone pauses the project. This is the clause that sends the awkward email so you do not have to.
4. **The keys move last.** Deliverables, credentials, repo access, and admin rights transfer on final payment, never before. The [seller who handed a buyer admin access first](https://www.reddit.com/r/Entrepreneur/comments/1v9pfli/getting_scammed_twice_completely_changed_the_type/) and watched them vanish learned the oldest rule in trade: whoever holds the goods and the money at the same moment decides how the story ends. For strangers and one-off deals, a third party holds both: [escrow services](https://www.escrow.com/) handle transactions from $100.
Two small pieces of hardware finish the machine. A late fee, stated up front, [typically monthly interest disclosed on the contract and invoice](https://www.hellobonsai.com/blog/discover-how-to-charge-late-fees-as-a-freelancer), because its job is deterrence, not revenue. And short terms: net-15 where you can get it. The businesses most likely to pay slowly are the ones counting on net-30 as a free loan.
## The law finally showed up
For decades the advice ended with "get it in writing and hope." The floor moved in 2024. Illinois's [Freelance Worker Protection Act](https://www.littler.com/publication-press/publication/illinois-becomes-first-state-enact-protections-freelance-workers) took effect July 1, 2024, the first statewide law of its kind: written contracts required for freelance work of $500 or more, payment due within 30 days of completion. New York's statewide [Freelance Isn't Free Act](https://dol.ny.gov/freelance-isnt-free-act) followed on August 28, 2024: a written contract is mandatory once a client's work reaches $800 within 120 days, payment is due by the contract date or within 30 days, and the state provides [a model contract and a formal complaint path](https://www.venable.com/insights/publications/2024/04/new-york-state-freelance-isnt-free-act), with remedies for nonpayment that can include double damages and attorney's fees.
If your client is in New York or Illinois, cite the statute in your terms; it costs nothing and reframes 30 days from a courtesy into a law. If they are elsewhere, the statutes are still useful as the norm you point to: this is what the two biggest freelance jurisdictions in the country now consider the minimum.
## The refusal list
Every collections disaster in the threads announced itself early. The signals, in the order they usually appear:
1. **They haggle the deposit.** Not the price, the deposit. Price negotiation is normal; resisting the structure that protects you is a preview.
2. **They open with what AI should make cheap.** The client who anchors on "this is a quick AI thing now" is telling you what your invoice will feel like to them at every milestone. [Price the outcome and hold it](/ledger/pricing-ai-work/); the discount-hunter's project always costs more than it pays.
3. **Vague scope, urgent timeline.** "We need it yesterday" plus "we'll figure out the details" is the exact recipe for the dispute where they define the scope after your work is in their hands.
4. **Basic questions go unanswered.** Five identical emails for onboarding information is not friction, it is the relationship. A client who cannot deliver information will not deliver payment on a schedule either.
5. **Payment in exposure, equity, or later.** Revenue-share offers from strangers are asking you to underwrite their business with your labor. If you would not invest cash in their company, do not invest a build.
6. **Strangers who want access first.** Whoever asks you to hand over the working thing, the credentials, or the admin seat ahead of money is asking you to convert your leverage into their option.
None of these is a moral judgment; each one is information about how the invoice will go. The point of [a first client](/ledger/first-ai-client/) is to start the flywheel, and a bad first client stalls it worse than no client, because they consume the calendar the good one would have paid for.
## The walk-away math
Refusing work feels expensive until you price the alternative with real numbers. The average nonpayment victim in the Freelancers Union data loses about $6,000 a year, and that understates the solo builder's case, because the loss is never just the invoice. A bad client consumes the three scarce assets of a [one-person business](/ledger/economics-of-a-one-person-ai-business/): calendar weeks that carried your whole capacity, the emotional budget that chasing burns, and the referral energy a good project would have generated. Against that, the cost of the refusal list is occasionally passing on a project that would have paid fine. That trade is not close, and the builders who have run both sides of it, the ones filling those hundred-comment threads, all converge on the same sentence: some clients just are not worth it.
The quiet endgame, once the structure works, is needing it less. Deposits and pause clauses protect projects; [retainers](/ledger/retainers-for-ai-work/) replace the collection problem with a subscription, which is why the ladder ends there. Bill first, sequence the keys, refuse the flags, and let the awkward email be a clause instead of a confrontation. Getting paid is positioning, set before the first hour of work, and like [every pricing move that holds up](/ledger/pricing-psychology-that-holds-up/), it works because it was decided while you still had the leverage.
---
# Productize the service: turn bespoke AI work into one thing you can sell twice
Section: The Ledger
URL: https://okaneland.com/ledger/productize-your-ai-service/
Brett Williams runs Designjoy alone: one design subscription at one posted price, $4,995 a month, no employees, and past $1.7M a year on it. The believable ceiling for a solo AI version of the model sits nearer $8,000 a month, and the distance between freelancing and either number is an offer standardized enough to be bought on trust.
Every bespoke sale starts at zero. A scope call, a quote you build from a blank page, a job you architect from scratch, a margin you will not know until it is over, and then next month you do all of it again for the next client. The tenth project costs you the same effort as the first, which means the only way to earn more is to work more hours, and there are only so many of those. This is the ceiling every AI freelancer hits, and AI is quietly making it lower.
A productized service breaks the loop. It is one named deliverable, at one public price, delivered the same way every time. No discovery call, no custom quote, no reinventing the job. You built the [pricing](/ledger/pricing-ai-work/) and learned to [scope](/ledger/scoping-ai-projects/) it and made it [recur](/ledger/retainers-for-ai-work/); this is the next move, repackaging what you sell so a buyer can look at one line on a menu, see one price, and buy without a meeting. This piece is how to do it, and it is less a pricing trick than an operations one.
## The short version
If you are packaging the offer this month, the method in six moves:
1. **Pick the service whose demand is already uniform.** A niche where every client needs the same thing can be templated; one where every client needs something different cannot, at any price.
2. **Cut down to one bounded outcome at one public number.** [Designjoy](https://designjoy.co) sells a single $4,995-a-month tier, run by one person, and rode it to roughly $1.7M ARR; the believable solo ceiling for the AI version sits around [$8,000 a month](https://medium.com), self-reported.
3. **Lock the scope so the price survives.** A written feature list where extra requests move the timeline, and for nondeterministic AI work a [fixed budget with controlled scope](https://spin.atomicobject.com) instead of a promised feature list.
4. **Decide who pays the token bill before you publish the price.** Buffer it at two to five times the estimate, add a passthrough clause, or put the client's own API keys in.
5. **Productize the judgment, never the raw build.** The deliverable is commoditizing; what holds its price is knowing which automation moves the P&L, and the call you make the day the model gets it wrong.
6. **Write the SOP so it repeats.** A structured intake form, an async board, and a delivery checklist, validated on one discounted client before you scale it.
Everything below is the evidence, the inflated agency numbers included.
## The hours ceiling, and why AI makes it worse
Hourly billing has a paradox built into it: the better you get, the less you earn. A logo that took twenty hours in your first year takes five by your fifth, and billing by time that is a [roughly 75 percent pay cut](https://memtime.com) for the crime of getting good at your job. Expertise makes the work faster, and hourly pricing punishes exactly that, as Jonathan Stark has argued for years.
AI turns the screw harder. A build that took ten weeks now takes six, so your cost base to deliver it [drops 30 to 40 percent](https://consultingquest.com). If you bill for your time, you just handed that entire gain to the client and cut your own invoice. If you priced the outcome, you keep it. AI is the biggest efficiency jump most of this work has ever seen, and time-billing converts every bit of it into a discount you give away. The escape is to stop selling hours at all.
## What a productized service actually is
Set the definition precisely, because most people hear "productized" and think "raise my prices." That is not it.
A productized service is one bounded outcome, one public price, one repeatable delivery pipeline, sold identically to every buyer. The textbook case is [Designjoy](https://designjoy.co): one flat tier at $4,995 a month, one design request at a time, roughly 48-hour turnaround, pause or cancel anytime. Its own site says it plainly: run entirely by one person, no other designers, no outsourcing. Brett Williams took that single standardized offer past a million in ARR as an agency of one, and by 2024 was reportedly around $1.7 million, still solo, though the exact MRR wanders by source so read that as an as-of-2024 range rather than a live number.
The mechanic is the point. Here are the operators who prove it repeats:
| Productized offer | Price | What it did |
|---|---|---|
| Designjoy, unlimited design (solo) | $4,995/mo, one tier | ~$1.7M ARR, zero employees |
| Conversion Factory (Corey Haines) | $6k/mo entry | $36k MRR two months after launch |
| Designpop (Moniet Sawhney) | $1k/mo, $599/landing page | $8k/mo within a year |
| Jim Designs (solo) | monthly subscription | $9.3k MRR at 93% margin |
Every one is a founder's own disclosure on Indie Hackers or a roundup, unaudited, so treat them as claims. But they rhyme, and they rhyme on the same note: the same offer, sold again and again, with the delivery cost falling each time.
Brian Casel put the diagnosis in one line. Billing hourly, he said, means [freelancers reinvent what they do every single time](https://mixergy.com). Productizing removes the reinvention.
And that is the real lens on this, which is where my own background comes in. I have not run a productized freelancing shop, so I will not pretend to. What I bring is years as an operations analyst and program manager, shaped by lean thinking, and from that seat a productized service is standard work: the best-known way to do a job, written down so it runs the same every time, so nobody has to rebuild it from scratch for each instance.
A bespoke service is a warehouse where every order is picked a different way. A productized service is one where the pick path is documented and identical. The founder numbers above are just what happens when you stop paying the waste tax of doing it fresh each time.
## Which of your services to productize
You do not productize your whole business. You pick one thing.
Pick the one whose needs are already standardized, so you can template instead of reinvent. Casel chose restaurant websites for exactly this reason: [every restaurant needs to showcase a menu and show its hours and location](https://mixergy.com). The demand is uniform, so the delivery can be. The opposite of that, a niche where every client genuinely needs something different, cannot be productized no matter how you price it.
Then eliminate, do not add. Tyler Gillespie cut whole service lines, funnels, websites, design, down to just the most profitable and lowest-headache work before he scaled what was left. The instinct to offer more is the instinct that keeps you bespoke. ManyRequests offers three questions to pressure-test a candidate offer: can you state it in one sentence, are people already paying for it, and can you name a place where those buyers gather. If any answer is no, it is not ready to productize yet. And there is a margin prize for getting the niche right: specialist agencies report [gross margins in the 40 to 75 percent range against 15 to 20 for generalists](https://predictableprofits.com), a founder-surveyed figure so directional, but the gap shows up across sources.
## Lock the scope so the fixed price survives
A fixed price only works if the scope is genuinely fixed, and this is where most first attempts leak. The fix is to write down both what is included and what is excluded, and to have a real answer for the outlier. When a restaurant client wanted e-commerce, Casel did not build it into the package for a tiny subset of buyers; he offered a PayPal-button workaround and kept the offer standard. Designpop holds the line with a locked feature list agreed at the start: more requests push the timeline, never the price, so extra scope can never eat the margin.
AI adds a wrinkle here that ordinary services do not have. The output is nondeterministic. A logo is done when it is done, but a RAG system hitting an accuracy target might take one iteration or five, and you cannot know in advance. For those jobs a rigidly fixed scope is dangerous, because a rigid contract [has no way to incorporate learning](https://spin.atomicobject.com), as Atomic Object puts it.
The answer is a fixed budget with controlled scope rather than a fixed feature list: the client buys a bounded outcome and a bounded spend, and you keep the freedom to reach it the way the work actually demands. Everything about change orders and deposits still applies, and I laid that out in the [scoping piece](/ledger/scoping-ai-projects/); here the only job is to draw the scope boundary that makes one price possible.
## Price it once, in public, and handle the token bill
The productized move on price is to make it one visible number on a page; assembling a figure per client is the agency habit you are leaving. What to charge is the [pricing pieces'](/ledger/pricing-ai-work/) job, and the psychology behind the number is [its own piece](/ledger/pricing-psychology-that-holds-up/); the productizing job is only to make it a catalog price. As a market anchor, cross-source rate cards for productized AI work land around $500 to $2,000 for an audit, $2,500 to $15,000 for a fixed build, and $500 to $5,000 a month for a retainer, though those are vendor benchmarks with no disclosed revenue behind them, so hold them loosely.
The lesson worth stealing is Designjoy's. The same standardized offer went from roughly $449 to $849 a month at its 2017 launch to about $5,000, a rough tenfold rise, and Williams got there by raising the price against a waitlist. A standardized offer with demand behind it lets you move the number without moving your hours, which is the whole prize.
One cost is genuinely new to AI work: the token bill. If your fixed price includes model usage, a heavy client can quietly [erase your margin](/palette/keep/). Three ways to handle it, from the AI-agency price cards: estimate the real token cost and multiply it by two to five as a buffer baked into the price, add an explicit model-cost passthrough or re-pricing clause, or simplest of all, have the client put their own API and hosting keys in and bill it direct so the variability never touches your fee. Pick one before you publish the price, because the first month's usage will otherwise pick for you.
## Productize the judgment
This is the part that decides whether the offer survives the next two years, so make it the center.
AI is actively commoditizing the raw deliverable. Research synthesis, first drafts, a single-agent chatbot: those are getting cheap fast, and the margin compression is [most evident in narrowly defined tools and lightweight workflow utilities](https://amadeuscapital.com). If the thing you productize is the task itself, you are pricing something your client can increasingly do without you. The whole market is repricing around this: per-seat is [no longer the atomic unit of software](https://a16z.com), and outcome pricing is showing up in production, Intercom's Fin at $0.99 per resolution, Decagon charging per resolution rather than per seat.
So do not productize the build. Productize the judgment the client cannot buy off a shelf: which automation actually moves their P&L, whether the chatbot is genuinely accurate enough to put in front of customers, what to do when the model is confidently wrong. That judgment is the product. The mechanic that carries it is the subscription: one piece of judgment you have systematized, packaged as a productized agent that ten clients each subscribe to at $500 a month, is $60,000 a year that grows with the client list rather than resetting each month, which is the same recurring layer the [retainer ladder](/ledger/retainers-for-ai-work/) is built on.
## Document it so it repeats
The last step is what makes it standard work rather than a good month. Systematize the intake: replace the discovery call with a structured form, and replace the meetings and Slack with a dashboard, the way Conversion Factory runs entirely async through a Notion board. Then write the SOP before you hire anyone, including before you hire the future version of yourself who has forgotten how you did it: the outcome, the step-by-step delivery, the first-48-hours onboarding, how a request gets handled, and the quality bar it has to clear. Validate the offer with one discounted client from your niche before you scale it, and only then start delegating, gradually, beginning with the parts that are already written down.
And keep the ceiling in view, because the loudest numbers online are a trap. The people posting $40,000-a-month AI-agency figures are frequently selling a course on how to make $40,000 a month, and that course is the actual income; Nick Saraev's automation agency did real revenue, but his headline earnings come from teaching, and figures like Liam Ottley's are not independently verified. Discount them. That is just reading the incentive.
The grounded number for a solo productized AI service is closer to the [$8,000 a month](https://medium.com) an n8n freelancer reported at around 25 hours a week, and even that took getting known: the single biggest thing that decides whether a productized service sells is whether people already trust you enough to buy without the meeting. Which is the same thing the whole Ledger keeps landing on. The offer is the easy part. Fix the delivery so it repeats, put one price on it, and let being good at the job stop being the reason you earn less.
---
# The demo is the cheapest part: scoping AI work so it does not lose money
Section: The Ledger
URL: https://okaneland.com/ledger/scoping-ai-projects/
Quoting off the demo is how AI work loses money: the 80% underneath, eval to maintenance, never shows on the call, and 57% of agencies leak $1,000 to $5,000 a month to work they did and never billed. The discipline that stops the leak is written into the quote before you sign.
The demo took an afternoon. You wired an LLM to the client's data, it answered three questions correctly on the call, the room lit up, and you quoted the project off that feeling. That is the moment the money starts leaking, because the demo is the cheapest part of an AI build and the most misleading part too.
The gap between how the demo feels and how the work goes is measured. When the research group METR had experienced developers do real tasks with AI tools, the developers expected to go faster, and afterward [believed AI had made them about 20% faster](https://arxiv.org/abs/2507.09089). The stopwatch said they were [19% slower](https://arxiv.org/abs/2507.09089). The optimism the demo creates is the same optimism you priced the job on. Underneath the working prototype sits the part that decides whether the project earns: evaluation, edge cases, hallucination guardrails, integration with the client's real systems, and the maintenance that begins the day you ship. The demo is the tip of the iceberg. You quoted the tip.
This is not a pricing problem. [What to charge](/ledger/pricing-ai-work/) is its own solved question with its own piece. This is the layer after the number: scoping and contracting the job so the price you set survives contact with the work. Get it wrong and the receipts are brutal. In a 2025 survey of 273 agencies, [57% said they lose between $1,000 and $5,000 every month](https://www.ignitionapp.com/news/2025-agency-pricing-cashflow-report) to work they did but never billed, another 30% lose more than that, and [just 1% manage to bill for all of it](https://www.thedrum.com/news/2025/05/22/cash-flow-crunch-us-agencies-struggle-grow-late-payments-and-scope-creep-bite). You do not have to be careless to leak money this way. You have to be slightly optimistic, once, about the scope.
## The short version
The fix is a scoping and contracting discipline. If you sell AI builds:
1. **Scope the ambiguity out before you sign.** "Build an AI chatbot" hides a five-times price range. Turn it into a written spec with named integrations, an evaluation bar, and explicit out-of-scope lines.
2. **Charge for the scoping itself.** A paid discovery phase is the cheapest insurance you can buy, and it filters out the clients who will not pay for the 80% under the waterline.
3. **Treat fixed-bid as a risk decision.** The demo makes AI work genuinely hard to estimate, and a fixed number on a job you cannot estimate is a bet against yourself. Stage it into milestones instead.
4. **Take a deposit and tie the rest to deliverables.** Work starts when money lands, and each payment is released by something the client can verify; the calendar releases nothing.
5. **Make the next request a change order.** "While you are in there, can you also" is where the margin dies. A short clause turns it into a billable line instead of a free one.
6. **Price the maintenance, because the demo never shows it.** The build is the down payment. The upkeep is the mortgage, and it is in the client's name only if you wrote it that way.
Everything after this is the evidence.
## You did not underprice it, you under-scoped it
"Build an AI chatbot" is a category. The same sentence covers a weekend FAQ bot answering from a help doc and a context-aware agent that reads the CRM, books actions, and has to be right in front of customers, and the gap between those two is easily five times the price. When the client said one sentence, you heard a smaller project than they did, and you quoted yours.
Scope creep is the base rate. PMI's 2018 survey found [52% of projects experienced scope creep](https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf), up from 43% five years earlier, and that nearly half finished late. The Standish Group's long-running software data lands in the same neighborhood, with only [about 29% of projects](https://www.standishgroup.com/) coming in on time and on budget. Treat that figure as a ballpark rather than gospel, its underlying data is proprietary and its definitions have been contested in the research literature, but the direction is not controversial: a project that lands on its original scope is the exception. A quoting process that assumes you are the exception is how you join the 57%.
## The maintenance the demo never shows
The most expensive thing the demo hides is what happens to the code after you ship it. In a peer-reviewed study of 807 open-source projects that adopted the AI editor Cursor, matched against 1,380 similar projects that did not, the velocity gain was real but temporary: lines of code added jumped 281% in the first month, then faded within weeks. What did not fade was the drag. Static-analysis warnings rose about [30%, and code complexity about 41%](https://arxiv.org/abs/2511.04427) in the period after adoption. A separate vendor analysis of 470 pull requests found AI-authored ones carried [roughly 1.7 times more issues](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report) than human-only ones, though that one is best read as directional, since the company sells AI code review and inferred which code was AI-written rather than confirming it.
The point for your quote is simple. The prototype that closed the deal is the fastest, cheapest code you will write on the project, and it is also the code that costs the most to keep working. If your number covered the build and not the upkeep, you [priced a down payment and signed up for the mortgage](/ledger/retainers-for-ai-work/). Where AI coding genuinely pays and where it bills you back is [its own piece](/study/does-ai-coding-make-you-faster/); for quoting, just assume the maintenance line is real and put it in.
## What leaking it actually costs
Run the leak through a real margin and it stops looking like a rounding error. A typical creative or marketing agency clears a net margin of [about 13%](https://prometheanresearch.com/how-profitable-are-digital-agencies/) after tax, which means roughly 87 cents of every dollar billed is already spoken for. At that margin, a 25 to 30% cost overrun on one engagement does not dent the profit on that client, it erases it, and then some. The afternoon you spent unbilled "just tightening the prompts" was not free time. It was margin, and on a thin-margin services business it is the only margin you have.
## Scope the ambiguity out before you sign
The defense starts before the contract, in a deliverable spec the client signs. Take the one-sentence ask and write down what done looks like: the exact integrations by name, the evaluation bar the system has to clear (and who judges it), the data you will and will not touch, and a short, explicit list of what is out of scope for this price. The out-of-scope list is the most valuable part, because it is the document you point at, calmly, when the new request arrives.
This costs you time, so charge for it. A paid discovery or scoping phase does two jobs: it pays for the work of figuring out the real project, and it tells you instantly whether this client understands that the demo was the tip. A client who balks at paying to scope the work is a client who will balk at paying for the 80% under the waterline. Better to learn that for a small fee than on a fixed bid.
## Why fixed-bid is the dangerous default for AI work
Fixed-bid is comforting to a client and a quiet trap for you, and AI work makes it worse. A fixed price is only safe when you can estimate the job, and the whole problem here is that the demo makes AI work look estimable when it is not. Fixed versus hourly is a pricing decision the [pricing piece](/ledger/pricing-ai-work/) covers; the scoping point is narrower. When you genuinely cannot estimate the hard parts, do not bury that uncertainty inside one number you have to honor. Stage the work into milestones, price each milestone as you reach it, and let the eval phase tell you what the build phase should cost. That is refusing to bet the project's margin on the demo's optimism.
## Stage the money so scope creep becomes billable
Two clauses do most of the protecting. The first is the deposit and milestone schedule. By freelance convention, though no survey enforces it, work does not start until a deposit lands, with the [common range running 20 to 50%](https://blog.freelancersunion.org/2018/10/11/4-key-questions-freelancers-should-ask-about-payment/) of the project and a 50% up front, 50% on delivery split as a frequent default. Bigger or vaguer jobs get broken further, with each payment tied to a deliverable the client can check rather than to a date. Staged money keeps you from financing the client's project out of your own cash flow.
The second is the change order. Every project grows, and the difference between a profitable shop and the 57% is whether the change got billed, because scope always changes. A change-order clause says, in plain terms, that work outside the signed spec is quoted and approved before it happens. It does not have to be adversarial. It reframes "can you also" from a favor you owe into a small new line the client chooses to buy, which is exactly what it is.
You did not underprice the project. You under-scoped it, and the demo is why. The number you set is only ever as good as the scope that defines it and the contract that protects it, and on AI work, where the prototype lies the loudest, that protection is the whole job. Quote the iceberg.
---
# The retainer ladder: from one-off AI builds to income that repeats
Section: The Ledger
URL: https://okaneland.com/ledger/retainers-for-ai-work/
Managed-service shops have billed business IT this way for twenty years: $100 to $200 per user per month, with floors that keep the smallest client worth serving. The AI version is the same insurance sold smaller, a few hundred euros a month per client, and it turns the one-off build from the whole business into the first rung.
A one-off build has a cruel property: the better you do the job, the sooner the income stops. You [land the client](/ledger/first-ai-client/), [price the work](/ledger/pricing-ai-work/), deliver something that runs, and on the first of next month your revenue is zero again. The builders who get off that treadmill all make the same move, and it is not a secret, because an older industry wrote the playbook decades ago and publishes its numbers. The line to hold onto before you quote your next project: after delivery, what you sell is insurance. This piece is the retainer math, with receipts: what working automation builders actually charge, what the maintenance really costs you, and what to say in the month nothing breaks.
## The short version
If you are pricing a retainer this week, the method in five moves:
1. **Sell availability plus accountability.** The client pays for a promise: it stays alive, and when it breaks, you exist. The hours are only the cap on that promise.
2. **Ladder in at delivery.** A free consultation finds the pain, the scoped build is paid up front with a 30-day warranty, and the maintenance pitch lands the day you hand over, while the working demo is fresh.
3. **Price below the scrutiny line.** Working builders charge [€300 to €500 a month](https://www.reddit.com/r/n8n/comments/1izrlrr/what_the_heck_are_you_guys_charging_clients/) for a package sized at 2 to 5 hours, with the [MSP industry's](https://www.datto.com/wp-content/uploads/dlm_uploads/DAT-2024-State-of-the-MSP-Report-1.pdf) $100 to $200 per user per month as the mature reference point.
4. **Cap the loud months.** A client on a 3-hour plan uses [4 to 5 hours a year](https://www.reddit.com/r/webdev/comments/13yhsom/questions_for_the_freelancers_how_long_do_you/), and that underuse is the margin, so the contract needs an overflow cap and a hard line between maintenance and new features.
5. **Send the report in the month nothing breaks.** A one-page monthly note of runs, breaks, fixes, and savings keeps the quiet work visible. Six maintenance clients at $400 is $2,400 already booked before any new sale, and a recurring book [sells for 4 to 6 times earnings](https://www.reddit.com/r/msp/comments/1ggshwz/ballpark_valuation_of_an_msp/) at exit.
Everything below is the evidence, the ugly months included.
## What a retainer actually is
The cleanest definition on record is from patio11, selling maintenance contracts on custom software [years before the AI wave](https://news.ycombinator.com/item?id=7083948): the client pays monthly for you "to maintain internal expertise about your project and the staffing flexibility to promise you development services in a timely fashion," up to a capped amount of work. And the part to tattoo somewhere: "What does a $5,000 a month maintenance contract cost if you don't require any work in a given month? $5,000. It's like health insurance: just because you don't have your appendix burst doesn't mean we give you a rebate."
That is the product. Not hours, a standing promise. Consultants who live on retainers structure it the same way: Jonathan Stark's version is [explicitly "not prepayment for a block of hours"](https://jonathanstark.com/how-my-retainers-work) but paid access with a response-time promise, and he notes five-figure-a-month clients who go months without calling. In practice the market sells three shapes, and you should know which one you are quoting:
- **The hours bank.** X hours a month, use them or lose them, overflow billed or queued. Easiest to sell, easiest to abuse, and it quietly reframes you as inventory.
- **Availability plus SLA.** The insurance model: a response-time promise, monitoring, and a cap. The client buys certainty.
- **The managed service.** You run the thing end to end: hosting, monitoring, fixes, improvements. Highest price, most obligation, and the model the entire MSP industry is built on.
## The numbers, from people actually charging them
Start with the mature market, because it anchors everything. Managed service providers, the people who have run business IT on retainers for twenty years, cluster hard around [$100 to $200 per user per month](https://www.reddit.com/r/msp/comments/1iosuqc/looking_for_msp_pricing/) all-inclusive, enforce [monthly minimums around $1,000](https://www.reddit.com/r/msp/comments/1ew5y5r/switching_to_per_seat_pricing_good_pricing_for/) so small clients cannot be unprofitable, and treat recurring revenue as [the backbone of the model](https://www.datto.com/wp-content/uploads/dlm_uploads/DAT-2024-State-of-the-MSP-Report-1.pdf). One MSP posted the unit economics of his [$50-per-user entry tier](https://www.reddit.com/r/msp/comments/1hcptr9/msp_model_but_without_the_price/): tooling costs around $11, the price leaves room for about 20 minutes of support per user per month, and actual usage runs about 3. That gap between what is paid for and what is used is the entire economics of insurance, and it prices the AI version too.
The automation and AI numbers, one rung down the maturity ladder, rhyme. The quiet, believable receipts from [builders comparing rates](https://www.reddit.com/r/n8n/comments/1izrlrr/what_the_heck_are_you_guys_charging_clients/): maintenance retainers of €300 to €500 a month, priced, in one builder's words, "low enough for a company to not scrutinize the bill, but high enough for me to be interesting if I stack a handful of retainers with barely any work needed." Web freelancers publish the same structure at [$50, $100, and $250 tiers](https://www.reddit.com/r/webdev/comments/1i874z9/how_did_you_get_your_first_few_clients_as_a_web/), or as [a formula: half a percent of the build cost per month](https://www.reddit.com/r/webdev/comments/1f5nlgo/freelancersagency_owners_would_you_charge_monthly/).
Above that sits management: the [work-in-progress-slots model](https://www.reddit.com/r/automation/comments/1jhf39o/advice_for_starting_an_ai_agency/), where the client buys a number of active automation requests at a time, and the [$2,500-a-month "AI management as a service"](https://www.reddit.com/r/n8n/comments/1kki6u5/i_just_hit_25000mrr_in_4_months_with_n8n/) tier, which we quote with the caveat that the poster's headline MRR is his claim, unverified. At the top the retainer stops being a retainer: $5,000 a month for 20 hours a week is a fractional hire wearing a retainer's name tag.
Two structural receipts worth more than any single price. A builder with [45 to 50 maintenance clients](https://www.reddit.com/r/webdev/comments/1g3f8sj/looking_for_an_alternative_to_wordpress_after_the/) spanning €265 to €3,000 a month calls one-off projects "bonus money on top of my monthly income," a complete inversion of how most freelancers think. And an agency selling [$0-down, $175-a-month website subscriptions](https://www.reddit.com/r/smallbusiness/comments/1kjfwnu/how_profitable_is_we_design_agency/) reports $23K a month recurring, his argument being arithmetic: selling $500 one-offs means finding 46 new buyers every month forever. The punchline for anyone thinking of an exit someday: recurring books [sell for 4 to 6 times earnings](https://www.reddit.com/r/msp/comments/1ggshwz/ballpark_valuation_of_an_msp/), and the multiple rises with the share of revenue that repeats.
Also worth knowing: [only about 13% of consultants](https://www.consultingsuccess.com/consulting-retainer) run monthly retainers at all (a stat from a coaching outfit, so season accordingly). The model is underused.
## What it costs you: the other side of the meter
The reason retainers are not free money is that automations rot. The line practitioners repeat about AI systems is that [building the agent is only 30% of the battle](https://www.reddit.com/r/AI_Agents/comments/1k3t3ga/ai_agents_truth_no_one_talks_about/); the rest is deployment, drift, and API changes. The n8n community's [working definition of a maintenance package](https://community.n8n.io/t/support-pakage-after-workflow-delivery/300786) is the concrete version: 2 to 5 hours a month covering credential rotation, checking execution logs for silent failures, and fixing the node some vendor's API update just broke. That list is your scope. Note what it does not include, and note the advice attached to it: "draw a massive, explicit line between maintenance (keeping the existing workflow alive) and new features." Every retainer that turned into a nightmare crossed that line without a change order.
Budget with open eyes on both sides. Most months, most clients use far less than they pay for: one web freelancer's clients on a 3-hour monthly plan [use 4 to 5 hours a year](https://www.reddit.com/r/webdev/comments/13yhsom/questions_for_the_freelancers_how_long_do_you/); a consultant on retainer [averages 5 hours of work and 10 hours of pay](https://news.ycombinator.com/item?id=27366228). But the tail months are real, and unbounded. The contract needs three protections written in before you sign: a cap or slow-lane for overflow work, the maintenance-versus-new-features line, and payment up front. That last one is not paranoia; it is the [builder who delivered an AI agent and watched $5,800 walk away](https://www.reddit.com/r/AI_Agents/comments/1j1kpsx/lost_5800_building_an_ai_agent_for_a_client/), and the reply that should be your policy: "For retainers, I always ask for payment before doing the work."
There is also a load ceiling, and the MSPs have measured theirs: a support tech carries roughly 250 to 300 endpoints before quality slides. Your translation depends on what you sold, but the shape holds. A solo builder maintaining well-built, monitored automations can carry a dozen small retainers in a few days a month; the same builder who skipped error handling on the builds is on call for all twelve at once. The retainer's profitability is decided when you build the thing, which is exactly the argument for [scoping the build properly](/ledger/scoping-ai-projects/) in the first place.
## The month nothing breaks
Sometime around month four, everything works, and the client asks the question a commenter [put to the $25K MRR poster](https://www.reddit.com/r/n8n/comments/1kki6u5/i_just_hit_25000mrr_in_4_months_with_n8n/): how do you justify the fee "in months where you might not actively touch the account?" If your answer improvises, you churn. The defenses, all from the receipts:
- **Send the report.** A monthly one-pager: what ran, what broke, what was fixed, what it saved. The n8n forum's framing is right: it "moves the conversation from fixing broken things to proactive health monitoring." Invisible work is unpaid work; the report makes it visible.
- **Own the plumbing, carefully.** Bundling hosting and monitoring makes leaving harder and the value concrete, and it is exactly what mid-ladder freelancers do to fight churn. Two cautions: some tools' licenses restrict hosting client automations on your own infrastructure (check before you build your model on it), and there is a line between healthy stickiness and hostage-taking. Which is the next point.
- **Make leaving safe, and staying rational.** The strongest retainer pitch in the receipts is the walk-away clause: the automations are yours if you leave; what you lose is me maintaining them. Paired with the queue rule (retainer clients get the front of the line, everyone else waits), it sells continuity without threats.
- **Price below the scrutiny line.** The €300-500 stackers are doing churn prevention with the price itself: cheap enough that no CFO opens the invoice, valuable enough that nobody wants to find out what breaks without it.
- **Start with a warranty.** Thirty days of included support after delivery, then the paid package. It converts better than selling insurance on day one, and it gives the client a month of seeing what "maintained" feels like.
One thing the receipts refuse to support: the tidy "$500 paid audit converts into the retainer" ladder that automation coaches sell. We looked. Working practitioners run free consultations or discounted paid discovery, fold the auditing into the retainer itself, and close on outcomes. Nobody credible posted the paid-audit funnel actually working, which does not mean it never does, but you should know that the people teaching it are selling the course rather than running the ladder. The variance is wide and unglamorous: the same practitioner who described the slots model has "seen well-seasoned business people hit 40-50k MRR in 4 months" and "people flounder around 1-3k per month for over a year." The difference was the business behind the builder.
## The ladder, assembled
Put the pieces in order and the ladder has four rungs: a free consultation that finds the automatable pain, a scoped one-off build with payment up front and a 30-day warranty, the maintenance package at delivery (2 to 5 hours, the report, the cap, the line between maintenance and new work), and, for the clients with appetite, the management tier where you audit, build, and improve continuously against a slot limit. Each rung is sold at the top of the previous one, when trust is highest and the memory of the working demo is fresh.
Six clients on the maintenance rung at $400 is $2,400 a month that arrives before you sell anything, which is the whole point: [the one-person AI business](/ledger/economics-of-a-one-person-ai-business/) does not die from small revenue, it dies from revenue that starts at zero every month.
Sell the insurance, send the report, cap the tail, and keep the line between keeping-it-alive and building-more. The build ends. The retainer is the part of the business that repeats.
---
# The economics of a one-person AI business: what the MRR screenshots leave out
Section: The Ledger
URL: https://okaneland.com/ledger/economics-of-a-one-person-ai-business/
Gross margins projected near 52 percent, 6.1 percent monthly churn under $25, card fees, failed payments and VAT all sit between MRR and income. The biggest lever on what you keep is price: charge enough to clear the churn cliff, then plug the leaks you already pay for.
Open any indie maker feed and you find the same image: a revenue dashboard, a green line going up, an MRR number circled in red. It is the most shared number in indie AI, and the least useful one. Revenue is what a customer pays. Income is what you keep after the model bill, the card fees, the refunds, the tax you are holding, and the customers who quietly leave. Those are very different numbers, and the gap between them is wider for an AI product than for almost anything else you could build.
## The short version
If you are building on your own money, the method in five moves:
1. **Discount every screenshot before you copy its strategy.** Of 937 Stripe-verified indie products, [more than half earned nothing](https://scrapingfish.com/blog/indie-hackers-revenue) and about 5% cleared $100,000 a year; the feeds show the survivors.
2. **Plan on roughly half margin, never the SaaS 80%.** Metered inference keeps AI gross margins near [a projected 52% for 2026](https://www.iconiq.com/growth/reports/2026-state-of-ai-bi-annual-snapshot), so a price that would carry a SaaS business can sink an AI one.
3. **Price above the churn cliff.** Under $25 a month the median product loses [6.1% of its customers every month](https://chartmogul.com/blog/good-customer-churn-rate/), about half the base in a year; above $250, retention looks like real SaaS. The up-market move is the single biggest lever.
4. **Collect the money you already earned.** Around [9% of MRR fails to arrive](https://baremetrics.com/blog/recover-failed-payments-save-lost-revenue) through expired and declined cards, and dunning claws it back with zero new customers.
5. **Cap the heavy tail and re-shop the model bill every quarter.** Inference prices for a fixed capability fall [roughly 50x a year](https://epoch.ai/data-insights/llm-inference-price-trends), so yesterday's too-expensive model is often today's cheap one.
Everything below is the evidence, the survivor math included.
## Almost nobody gets the screenshot
Start with [the survivor problem](/study/ai-startup-raise-math/), because it shapes everything else. When Scraping Fish pulled every Indie Hackers product with Stripe-verified revenue in 2022, all 937 of them, [more than half were making nothing at all, and only about 5% cleared roughly $100,000 a year](https://scrapingfish.com/blog/indie-hackers-revenue), a level its author notes is "not that hard to earn as a software engineer in a full time job." The conclusion was blunt: "success in the world of indie developers is an outlier business." The vibe-coding highlight reel earns the same discount; [the wins-and-denominator study](/study/after-the-vibecode-wins-and-denominator/) itemizes it.
Now compare that to the rooms where the screenshots come from. At MicroConf in 2025, a bootstrapper conference, founder Rob Walling reported that [28% of attendees were doing more than $100,000 in monthly recurring revenue](https://www.linkedin.com/posts/robwalling_the-state-of-bootstrapped-saas-in-2025-is-activity-7315372913732329473-obpo). That is selection: one number is the whole population, the other is the people who already won and bought a conference ticket. Watch the units too. MicroConf's 28% is $100k a month. The Indie Hackers 5% is $100k a year.
The base rates are sobering even outside software. U.S. government data finds [about 34.7% of business establishments born in 2013 were still operating ten years later](https://www.bls.gov/opub/ted/2024/34-7-percent-of-business-establishments-born-in-2013-were-still-operating-in-2023.htm), and roughly half survive five years. AI has made the first dollar faster: [Stripe Atlas reports its 2025 cohort reached first payment in a median of 34 days, down from 38, with 20% charging a customer inside 30 days versus 8% in 2020](https://stripe.com/blog/stripe-atlas-startups-in-2025-year-in-review). But getting to the first dollar quickly is not the same as reaching a number worth screenshotting.
## The margin you do not have
Here is the part most pricing advice skips: an AI product is not an 80-percent-gross-margin SaaS business, and pretending it is will quietly bankrupt you.
Classic software is cheap to serve. Bessemer's cloud benchmarks put [the best SaaS gross margins at 80% and above](https://www.bvp.com/atlas/scaling-to-100-million), with a typical cloud business around 65 to 70%. AI is structurally lower. Andreessen Horowitz flagged this early. Its 2020 essay on [the new business of AI](https://a16z.com/the-new-business-of-ai-and-how-its-different-from-traditional-software/) pegged AI gross margins "often in the 50-60% range," dragged down by the "25% or more of revenue" that goes to cloud and compute. Six years on, the gap has narrowed but not closed: ICONIQ's [2026 State of AI snapshot](https://www.iconiq.com/growth/reports/2026-state-of-ai-bi-annual-snapshot) reports average AI product gross margins of 41% in 2024, 45% in 2025, and a self-projected 52% in 2026, still well under the 70 to 80% a mature SaaS business takes for granted.
The reason is simple and it does not go away: your cost of goods is metered. Every query a user runs costs you tokens. SaaS hosting amortizes toward zero as you scale; inference does the opposite. ICONIQ finds [model inference rising from 20% of AI product spend before launch to 23% at the scaling stage](https://www.iconiq.com/growth/reports/2026-state-of-ai-bi-annual-snapshot), becoming, in its words, "the dominant cost driver at scale." Bessemer's 2025 taxonomy makes the danger concrete: its usage-heavy "Supernova" companies run at [about 25% gross margin, often negative](https://www.bvp.com/atlas/the-state-of-ai-2025), against roughly 60% for the more disciplined "Shooting Stars."
This is the trap a flat monthly fee walks straight into. If you charge $20 a month and a power user burns $25 of tokens, you are paying them to use your product. a16z's own partners note that [the heaviest sliver of users drives a wildly disproportionate share of cost](https://a16z.com/questioning-margins-is-a-boring-cliche/), and that rate limits on the top 5% cut spend "with limited revenue impact." [A flat fee on a metered cost is only safe if you cap the tail](/study/unit-economics-of-wrapping-an-llm/).
## The tailwind: token prices are collapsing
The counterforce is real, and it is the best news in this whole piece. The price of a fixed amount of AI capability is falling faster than almost any input cost in business history. a16z calls it [LLMflation](https://a16z.com/llmflation-llm-inference-cost/): the cost to reach GPT-3-level quality fell from $60 per million tokens in late 2021 to $0.06 by late 2024, roughly 10x a year. Independent analysis from Epoch AI, across six benchmarks, [puts the median decline at about 50x per year](https://epoch.ai/data-insights/llm-inference-price-trends), accelerating to roughly 200x per year for data since January 2024.
So if your feature set holds still, the same product gets cheaper to serve every quarter. That is genuinely on your side. The catch is the asterisk every careful read includes: those declines are for a fixed capability, and founders almost never hold capability fixed. You add the smarter model, the longer context, the agent loop, and your per-user cost climbs right back up while the screenshot stays the same size. Falling prices help. They do not hand you SaaS margins.
## The leaky bucket nobody photographs
Now the part that turns a good month into a bad year: churn, and it is worst exactly where solo products live.
Cheap, self-serve products churn hard. ChartMogul's benchmarks put [median monthly customer churn at 6.1% for products under $25 a month, against 2.2% above $500](https://chartmogul.com/blog/good-customer-churn-rate/). At 6.1% a month, you lose roughly half your customers in a year before you have sold anyone new. The AI-native numbers are worse: ChartMogul's 2025 retention study found [products priced under $50 a month keeping just 23% of gross revenue and 32% net, about 20 points below comparable SaaS](https://chartmogul.com/reports/saas-retention-the-ai-churn-wave/).
The escape hatch that rescues real SaaS, expansion revenue where existing customers pay you more so growth outruns churn, is mostly closed to you down here. Even [the top quartile of products under $25 a month retains only 64.7% of customers](https://chartmogul.com/blog/good-customer-churn-rate/), meaning even the best performers at the bottom of the market lose a third of their base every year. A one-person AI business at a low price is running up a down escalator: every month starts with a hole to refill before any growth counts.
## Revenue minus the cuts the screenshot hides
Even the revenue you do collect is not the revenue you keep. Walk the gap MRR never shows:
- **Card fees.** Stripe's standard rate is [2.9% plus 30 cents domestically, climbing to as much as 5.4% plus 30 cents on an international card that needs currency conversion](https://stripe.com/pricing). Sell globally, as most digital products do, and a real slice of every sale is gone before anything else touches it.
- **Refunds.** When you refund a customer, [Stripe returns their money but keeps the original processing fee](https://support.stripe.com/questions/understanding-fees-for-refunded-payments). The sale reverses; the fee does not.
- **Disputes.** A chargeback costs you [a $15 fee you only get back if you win](https://stripe.com/pricing), on top of the lost sale. On a $20 subscription, one dispute can erase the margin on a dozen other customers.
- **Payments that silently fail.** Cards expire and decline. Paddle (ProfitWell) estimates [involuntary churn is 20 to 40% of all churn](https://www.paddle.com/resources/reduce-voluntary-and-involuntary-churn), and Baremetrics' own data points to [around 9% of MRR lost to failed payments](https://baremetrics.com/blog/recover-failed-payments-save-lost-revenue). Without dunning, that is revenue you "earned" that never arrives.
- **Tax you owe.** Sales tax and VAT ride on top of the price and belong to the tax office. The EU's average standard VAT is [21.9%](https://taxfoundation.org/data/all/eu/value-added-tax-vat-rates-europe/), and on digital sales a seller outside the EU owes it from the first euro. That money flows through your dashboard and right back out.
## The screenshot, minus everything
Put it together and the circled MRR number is doing a lot of lying by omission. Take a $30,000-a-month screenshot at face value, then subtract a 50% gross margin, the card-fee haircut, the slice lost to failed payments and refunds, the tax you are holding for a government, and the fact that you are the 1-in-20 outlier the screenshot never mentions. What you keep is a different, smaller, and far more real number. [Run your own numbers through it](/palette/keep/) and watch the gap open up.
That is not a reason to skip the AI product. Most of those leaks are levers you control, and the same research that makes the picture sobering also points straight at what grows the number you keep.
## What actually moves your income
- **Charge more.** This is the biggest lever in the whole piece, and the data is one-sided. Under $25 a month you churn at 6.1%, and an AI product under $50 keeps just 23% of its revenue; over $250 a month, retention jumps to 70%. A higher price buys you a customer who stays and a margin that survives the token bill. For most solo AI products the move is up-market. How you land on the number is its own craft: see [pricing psychology that holds up](/ledger/pricing-psychology-that-holds-up/) and [what to charge for AI work](/ledger/pricing-ai-work/).
- **Recover the income you already earned.** Involuntary churn is 20 to 40% of all churn, and roughly 9% of MRR can fail to collect from expired and declined cards. Dunning, the automated retries and card-update nudges, claws that back with zero new customers. It is the cheapest income you will ever add.
- **Protect the margin so revenue becomes income.** Cap or meter the heavy tail so a handful of power users cannot turn a profitable plan into a loss, and route each job to the cheapest model that can actually do it. With inference prices falling roughly 50x a year, the model that was too expensive last quarter is often fine now; [what each tool actually costs](/palette/ai-tool-price-index/) is worth re-checking before you lock in a bill.
- **Sell where retention lives.** The retention gap is not random: higher-value and business buyers stay far longer than cheap consumer subscriptions. Choosing who you sell to, and positioning for it, is an income decision as much as a marketing one.
Revenue is a vanity number. The levers that actually move income are charging enough to escape the churn cliff, plugging the leaks you already pay for, protecting the margin the tokens keep eating, and selling to buyers who stay. Build for what you keep, then go make more of it. When you have [run this math on your own numbers](/palette/keep/), the community is where people compare the number they actually kept.
---
# Pricing your AI app: the psychology that holds up, and the tricks that fall apart
Section: The Ledger
URL: https://okaneland.com/ledger/pricing-psychology-that-holds-up/
You shipped the thing. Now what number goes on it? The $0 entry tier holds up in a field study, price as a quality signal is real but modest, and the middle plan gets shakier once the options are messy, while lucky 7s, countdown timers and the coffee-a-day line have nothing solid under them. The builders who get paid picked a number they can defend, tested it on real buyers, and ignored the rest.
You built the app. The model behaves, the deploy is green, and one box is still empty: the price. For most vibe coders it is the scariest field on the page, and the internet is glad to help, with a firehose of pricing hacks. End every price in 7. Bolt on a countdown timer. Charm-price it at .99 and watch sales climb. Most of that is folklore, copied from one course to the next with nothing under it. A little of it is real, replicated science. This is how to tell the two apart, with the studies attached, written for pricing your own AI product.
One rule before the list. Every effect below has an edge where it stops working or turns on you. The gurus sell you the effect. The money is in knowing the edge.
## The short version
The moves that hold up, in the order you will use them:
1. **Make the entry tier exactly $0, capped tight,** and treat a 2 to 5% free-to-paid rate as normal.
2. **Price to match the quality you claim.** A higher number is a signal. Anchor it with a visible higher tier.
3. **Use three plans and steer to a real middle,** never a fake decoy.
4. **Show annual as a per-month number.** Skip the coffee line.
5. **Use .99 only where the left digit drops,** and expect a nudge.
6. **Quote one all-in price.** Drip fees are a trust loan you repay later.
7. **Do not monetize on goodwill.** Give a concrete reason to upgrade.
Everything below is the study behind each move, and the edge where it stops working.
## Free is a different number than cheap
The most reliable finding in pricing is that $0 is not a low price. It behaves like its own category. In a [field study at MIT](https://pubsonline.informs.org/doi/10.1287/mksc.1060.0254), Shampanier, Mazar and Ariely offered Hershey's Kisses at 1 cent next to Lindt truffles at 15 cents, and among people who bought, 73% paid up for the nicer Lindt. Then the researchers cut both prices by a single cent. The Kiss was now free, the Lindt 14 cents, the gap unchanged. The room flipped: 69% now grabbed the free Kiss. A one-cent move reversed the whole decision, because "free" reads as a reward rather than a smaller cost.
That is why every AI product you admire opens with a $0 tier. [ChatGPT](https://openai.com/chatgpt/pricing/) shows Free beside Plus at $20 and Pro at $200. [Claude](https://claude.com/pricing) and [GitHub Copilot](https://github.com/features/copilot/plans) run the same free-to-paid ladder. The $0 plan is the magnet, and a sliver of those users later pay.
Free is not a cheat code, though. When the free thing carries a quiet cost (a credit card up front, a long signup, handing over your data), that "free" reads as a trap and can sell worse than a small, clean price. And every free user burns real inference money. So set your entry tier to exactly $0, because the jump in signups from $1 to free is far bigger than from $3 to $1, then cap it hard with rate limits and a smaller model, and convert on usage. If your free-to-paid rate sits between about 2 and 5%, that is the normal freemium range.
## A price is a quality signal, so stop racing to the bottom
Buyers cannot fully judge an AI tool before they use it, so they read the price as a clue to how good it is. And it runs deeper than belief. In a [now-classic experiment](https://journals.sagepub.com/doi/10.1509/jmkr.2005.42.4.383), Shiv, Carmon and Ariely gave people an energy drink and a set of word puzzles. Same drink for everyone, but one group was told it cost full price and another that it was discounted. The discount group solved fewer puzzles. They did not merely believe the cheaper drink was weaker, they performed as if it were, and nobody in the study consciously connected the price to their score.
The lesson for an AI app: a too-cheap price actively signals "low quality." [Superhuman](https://newsletter.pricingsaas.com/p/inside-superhumans-pricing-evolution) priced its email client at around $30 a month while rivals sat at $0 to $9, on purpose, so the number itself said "this is the serious one." If you claim to be the best AI for some job, a $4 tag undercuts the claim before anyone tries it.
This is a real effect of modest size, and [later work](https://journals.sagepub.com/doi/10.1509/jmr.13.0613) shows the experience-changing version does not fire for everyone. It leans on the buyer and the category, and it fades for people who already know your product. Treat price as a first impression, then anchor it with a visible higher tier: a Pro or Team plan priced two to three times your main one, so your main plan reads as serious but reasonable.
## The third option does the selling
Put three plans in front of someone and the one you flag, or the one in the middle, does quiet work. The textbook case is [The Economist's subscription page](https://en.wikipedia.org/wiki/Decoy_effect), made famous by Dan Ariely. Three options: web only for $59, print only for $125, and print plus web for $125. The print-only option is pointless, the same price as print-and-web for less, and in Ariely's MIT test nobody picked it. But its presence made the $125 bundle look like a steal, and 84% chose it. Take the useless decoy away, and most people drift down to the cheap $59 web plan. The bad option was the whole point.
This is the "Most popular" badge on every pricing page. [GitHub Copilot](https://github.com/features/copilot/plans) stamps "Best value" on its $39 Pro+ tier, parked under a $100 Max plan that makes it look sensible. [Notion](https://www.notion.com/pricing) plants "Recommended" on its $20 Business tier. [Vercel](https://vercel.com/pricing) runs the clean three-step version, free Hobby, $20 Pro, then a "Contact sales" Enterprise. For your own app, build a real Starter, Pro, Team page and make the tier you actually want to sell the obvious value pick: give Pro ten times the limits of Starter for twice the price, so Pro wins on value per dollar.
The decoy effect is solid in tidy lab setups with clear numeric tradeoffs, and shakier in the wild. [Several](https://journals.sagepub.com/doi/abs/10.1509/jmr.12.0061) [follow-up studies](https://journals.sagepub.com/doi/abs/10.1509/jmr.14.0208) found it often weakens or disappears once the options are real and messy. So steer with a genuine middle tier. Do not invent a fake decoy and assume the magic carries. Which meter those tiers sit on, seats, usage, or outcomes, is the prior question, and [how to price a B2B SaaS](/ledger/how-to-price-a-b2b-saas/) answers it.
## Annual framing helps. "A coffee a day" mostly does not
There is a legitimate version of small-number framing and a tired one. The legitimate version: show your annual plan as its per-month equivalent next to the monthly price. [Claude](https://claude.com/pricing) lists Pro at $17 a month billed annually beside the $20 month-to-month price, so the annual deal reads as the deal it is. John Gourville's [pennies-a-day research](https://academic.oup.com/jcr/article-abstract/24/4/395/1797969) is the root of this: break a big yearly number into a small recurring one and people compare it to other tiny expenses instead of one large bill, so they say yes more often. Later field work on savings plans found the daily frame can sharply lift sign-ups.
Now the tired version. "Less than a coffee a day" is the line every course teaches, and the evidence for it is weak to negative. The famous percentages people attach to Gourville's study are a [later popularization](https://www.gingerlime.com/2020/the-cup-of-coffee-pricing-fallacy/); the paper contains no such figures. The reframe also [backfires for cheap items](https://www.sciencedirect.com/science/article/abs/pii/S0022435911000108): on a low monthly price, spelling it out as pennies can make the product feel nickel-and-dimed. And a [2015 study](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2277749) found the coffee comparison can actually reduce donations, because telling people the amount is trivial makes the act feel trivial too. Use the clean annual-equivalent. Skip the coffee.
## The .99 trick is real, and smaller than you think
Charm pricing, ending a price in 9, has the widest gap between hype and evidence of anything here. The real finding is solid: in [field experiments](https://link.springer.com/article/10.1023/A:1023581927405), Anderson and Simester found a dress priced at $39 outsold the same dress at $34, while moving it to $44 changed nothing. The left digit drove the sale. It works because we read left to right and anchor on the first number, so $9.99 lands nearer to $9 than to $10. [Spotify](https://www.spotify.com/us/premium/) prices every tier this way: $12.99, $18.99, $21.99.
But the size of the effect is nothing like the "ends in 9 sells 24 to 60% more" you will read on course slides. A [2024 meta-analysis](https://myscp.onlinelibrary.wiley.com/doi/10.1002/jcpy.1353) pooling 69 studies found the real lift is small, and shows up only when the left digit actually drops. So use it where it crosses a boundary, $19 over $20, $9 over $10, and do not bother at $47 versus $44, where the left digit barely moves. It helps most for cheap, impulse, self-serve signups, and does nothing on a careful comparison table or a premium plan sold on prestige.
## Hidden fees pump the numbers, and they just got riskier
Split a price into a base plus surcharges, or reveal fees only at the end, called drip pricing, and people remember a lower total and buy more. The original [research](https://journals.sagepub.com/doi/abs/10.1177/002224379803500404) is decades old: most shoppers never add the surcharge back in, so the headline number is what sticks. StubHub later ran it as a real experiment, showing a low ticket price and dripping a roughly 15% fee in at checkout, and those shoppers spent about 21% more than the group shown the all-in price up front.
Usage-based AI apps do this all the time: [a low "$20/month" headline, with metered overages and per-seat add-ons surfacing later](/study/unit-economics-of-wrapping-an-llm/). The research says it nudges spending up. Two reasons to not lean on it anyway. First, the lift only holds when the fees are small and expected; a big surprise fee [reads as a bait-and-switch](https://journals.sagepub.com/doi/10.1177/0022243718800724) and costs you trust. Second, as of May 2025 the [FTC's rule on hidden fees](https://www.ftc.gov/news-events/news/press-releases/2025/05/ftc-rule-unfair-or-deceptive-fees-take-effect-may-12-2025) requires the all-in price up front for live events and short-term lodging, and the direction of travel is clear. Quote one true number. It ages better.
## "Pay what you want" mostly means "pay nothing"
It is tempting to let fans pay what they feel. The data says almost all of them feel like paying near zero. In the largest [test of pay-what-you-want](https://www.science.org/doi/10.1126/science.1186744), Gneezy and colleagues sold photos to 113,000 theme-park visitors. Pure pay-what-you-want got far more people to buy, but the average price was 92 cents, below cost. The version that made money paired the choice with a cause, half goes to charity: fewer people bought, but the average payment jumped to $5.33. The hook is what pried money loose. When Radiohead [released In Rainbows](https://www.rollingstone.com/music/music-news/radiohead-publishers-reveal-in-rainbows-numbers-67629/) as pay-what-you-want, 62% paid nothing at all.
For your AI app: do not count on goodwill to monetize a free tier. Give people a reason to upgrade that is not just "more features," a limit they keep hitting, a workflow they now depend on, or an identity, like "Pro funds the open-source version." And calibrate to reality. [The freemium free-to-paid benchmark is about 2 to 5%](/ledger/economics-of-a-one-person-ai-business/), a long way from 50%.
## The tricks with no clothes
Some of the most-repeated pricing advice has no evidence under it, or the evidence points the other way:
- **Countdown timers and "only 3 left."** The big conversion numbers come from app-store vendors, with no study behind them. Research on [time pressure](https://orbilu.uni.lu/bitstream/10993/57077/1/tuncer_2023_running_out_of_time(rs)_-_effects_of_scarcity_cues_on_perceived_task_load,.pdf) and on [the downside of scarcity](https://onlinelibrary.wiley.com/doi/full/10.1002/mar.21489) finds these cues can raise stress and suspicion and backfire, especially when buyers sense the scarcity is fake.
- **"Always end in 7."** There is no study showing a 7-ending sells better. The idea traces to one mid-century direct marketer and spread as copy-paste lore. The [measured effect](https://www.kellogg.northwestern.edu/faculty/anderson_e/htm/personalpage_files/Papers/Effects_of_9_Price_Endings_on_Retail_Sales.pdf) is about the left digit dropping; there is no lucky number.
- **"Red buttons convert 21% better."** The famous test that "proved" it had a green page with one red button. The button won by [standing out](https://cxl.com/blog/which-color-converts-the-best/). Contrast is the lever, and any color that pops pulls it.
- **"Money mindset" priming.** The idea that flashing money or success cues nudges people to pay is the [poster child of psychology's replication crisis](https://www.scientificamerican.com/article/whats-next-for-psychologys-embattled-field-of-social-priming/). A 17-lab effort could not reproduce it.
If a pricing tip cannot point to a study, treat it as someone's lucky habit.
This is pricing your own product. If you sell builds to clients instead, the math is different: see [what to charge for AI work](/ledger/pricing-ai-work/) and [how to land your first AI client](/ledger/first-ai-client/).
The builders who get paid are the ones who picked a number they can defend, tested it on real buyers, and ignored the rest.
---
# What to charge for AI work without lowballing yourself
Section: The Ledger
URL: https://okaneland.com/ledger/pricing-ai-work/
Hourly, fixed, or value based: AI cut writing time about 37% and coding time 55.8%, so billing the clock hands your gains straight to the tool. Price the outcome instead, anchor with a range and write the scope boundary into the number, and you keep the upside of being fast.
The fastest way to lose money with AI is to price the way you priced before AI. You used to spend two days on a thing, so you charged for two days. Now the same thing takes you two hours, so you charge for two hours, and you just handed most of your income to the tool that made you faster. That is backwards, and the research says exactly how backwards.
Across knowledge work, AI compresses the time a job takes, and the effect is large and measured. In a randomized trial published in Science, [ChatGPT cut the time professionals spent on writing tasks by about 37%](https://www.science.org/doi/10.1126/science.adh2586) and raised the quality of the work at the same time. Developers finished a coding task [55.8% faster with GitHub Copilot](https://arxiv.org/abs/2302.06590). Support agents resolved [14% more issues an hour](https://www.nber.org/papers/w31161), and 758 BCG consultants working with GPT-4 were [25.1% faster](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4573321). None of those studies clocked an AI automation build specifically, but the pattern holds everywhere it has been tested: the clock you used to bill by is shrinking.
## The short version
If you are quoting a job this week, the method in five moves:
1. **Drop the clock wherever the job has a finish line.** AI compressed the hours, so a rate times the new, smaller number is a pay cut you wrote yourself. Keep hourly only for genuinely open-ended work.
2. **Default to a fixed price on the outcome.** Go value-based when the saving is large and provable, and add a [retainer](/ledger/retainers-for-ai-work/) for the care the model will need after launch.
3. **Set the ceiling from their side, the floor from yours.** What the problem costs the client caps the price; what the job costs you, scoping and revisions and breakage included, sets the number it must clear.
4. **Anchor with a range, close on one number.** Across [53 studies](https://www.sciencedirect.com/science/article/abs/pii/S2214804320306728), anchoring reliably moves what buyers will pay, so open with a range whose low end is your target.
5. **Write the boundary into the price.** Two revision rounds, a change-order clause, and a deposit up front, because [57% of agencies leak $1,000 to $5,000 a month](https://www.ignitionapp.com/news/2025-agency-pricing-cashflow-report) to work they never billed.
The rest is the evidence, and the walk-away rule.
## Why hourly punishes you for being fast
Hourly billing ties your pay to how long something takes. AI cuts how long things take. So the better you get with these tools, the less you earn per project. The mechanism is not subtle: in the Science trial, [68% of people submitted the AI's first draft with little or no editing](https://www.science.org/doi/10.1126/science.adh2586), spending about three minutes of their own after they pasted it in. A rate times three minutes is not a business.
There is a second twist. The gains land hardest on the [less experienced worker, who improved about 34% while the expert barely moved](https://www.nber.org/papers/w31161). AI is quietly commoditizing the speed and polish a client used to pay a premium rate for. What it cannot commoditize is knowing which tool, wiring it up so it holds, and pricing the result. So price the result.
Hourly is fine for open ended work where the scope genuinely is not known yet, a research spike, a "help me figure out what is even possible" session. For anything with a clear finish line, price the finish line.
## Three ways to price, and when each one fits
You are in good company dropping the clock. In a 2023 survey of nearly a thousand consultants by Consulting Success, a firm that sells value-pricing coaching, [hourly was only the second most common model at 29%, behind project-based fixed fees at 30%](https://www.consultingsuccess.com/consulting-fees), with value and retainers taking most of the rest. Agencies split about the same way. Hourly is one option among several, and often the worst one.
**Fixed price per outcome.** You agree on a deliverable and a number up front. Good when the scope is clear: "an automation that turns these emails into CRM entries," "a chatbot trained on your docs that answers the top 20 support questions." The client knows the cost, you keep the upside of working fast. This is the default for most AI build work.
**Value based.** You price against what the result is worth to the client instead of what it costs you to make. If an automation saves a team 15 hours a week, that is worth far more than the afternoon it took you to wire up. In the same survey, [51% of consultants who price on value report an average project over $10,000, against 39% of those who bill hourly](https://www.consultingsuccess.com/consulting-fees). Treat that as correlation rather than a magic switch, since the people confident enough to value-price were probably already charging more. But the direction is consistent, and value pricing is where most people undercharge by an order of magnitude.
**Retainer.** A flat monthly fee to keep things running, tune prompts, handle the model changing under you, add the next small thing. AI work is not "ship it and walk away," models shift and break, so ongoing care is a real service worth charging for. Retainers turn one project into steady income.
The menu, in one look:
| Model | Fits when | The evidence |
|---|---|---|
| Hourly | Scope genuinely unknown: research spikes, discovery | 29% of consultants; punishes speed everywhere else |
| Fixed per outcome | The finish line is clear | The default for AI builds; you keep the speed upside |
| Value based | The saving is large and provable | 51% report $10k+ average projects, against 39% hourly |
| Retainer | The work needs ongoing care | Models shift and break; one project becomes steady income |
## How to set a number you can defend
Start from the client's side. Ask what the problem currently costs them: the salary hours going into the manual version, the leads they drop, the customers who churn waiting on slow replies. That number is your ceiling, and it is usually higher than the price you were about to name.
Then sanity check from your side. Whatever a fixed price comes out to, make sure it clears what you would want per hour of your real time, including the unglamorous parts: scoping, revisions, the model breaking the week after launch. If it does not, the scope is too loose or the price is too low.
A few working rules, and the research behind them:
- Name the price as one number for the outcome. "This is $X" lands better than "it is $Y an hour and I think about Z hours."
- Quote a range before you quote a single number. Anchoring is one of the sturdiest findings in pricing: [across 53 studies it reliably moves what buyers are willing to pay](https://www.sciencedirect.com/science/article/abs/pii/S2214804320306728). Put your target at the low end of the range and let it run upward, which anchors the buyer high while the range still reads as cooperative.
- Build revisions into the price (two rounds, say), and [put a line on what counts as new scope](/ledger/scoping-ai-projects/). Scope creep is where fixed price jobs go to die, and it is a majority problem: [PMI found 52% of projects hit it](https://www.pmi.org/learning/library/scope-creep-rising-11308), and in a 2025 survey of 273 agencies, [57% lose between $1,000 and $5,000 a month to work they did but never billed](https://www.ignitionapp.com/news/2025-agency-pricing-cashflow-report), with nearly 80% saying they rarely or only sometimes charge for it. You will not bill your way out of overruns after the fact. Price the boundary in.
- Charge a deposit. Half up front is normal, [about half of agencies take one and only 16% wait for full payment](https://www.ignitionapp.com/news/2025-agency-pricing-cashflow-report), and it filters out the people who were never going to pay.
Those levers, anchoring with a range and charging a deposit, lean on [the same psychology that works on your own product](/ledger/pricing-psychology-that-holds-up/). And when the product is a subscription with a recurring meter, [how to price a B2B SaaS](/ledger/how-to-price-a-b2b-saas/) is the product-side version of this piece.
## When to walk
Some clients want the AI discount: they read that the tool is cheap, so they think the work should be too. They are not your clients. The value is in knowing which tool, wiring it up so it does not embarrass them, and being there when it breaks.
Generative AI could in theory automate the activities that fill [60 to 70% of the workday](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier), by McKinsey's estimate, which is exactly why clients now assume AI is in the mix, and exactly why billing for your keystrokes is a shrinking base. If someone only wants to pay for the API bill, let them go build it themselves, and if you want the numbers behind that argument you can point them at [what each tool costs](/palette/ai-tool-price-index/). There are better clients out there, and the harder part is usually how you [find your first client](/ledger/first-ai-client/).
The real version of pricing is refusing to let a tool that made you faster make you poorer. Price the outcome, show the value, and keep the upside of being good at this.
---
# How to land your first AI client
Section: The Ledger
URL: https://okaneland.com/ledger/first-ai-client/
US firms using AI to produce what they sell sit at 8.8%, and nearly 82% of the smallest say it does not apply to them. That objection survives a cold DM and a slide deck. It dies at a warm lead plus a working demo of their own workflow, with their own data, because the pitch stops being a claim about AI and becomes a claim about their Tuesday.
The good news about your first AI client is that you almost certainly already know them. You just have not asked yet.
## The short version
If you want the first paid build, the method in five moves:
1. **List everyone you already know, with their one manual pain next to each name.** The friend's business, the drowning team at your day job, the group-chat complaint. Warm beats cold, and it is measured: [no channel outranks a personal recommendation](https://www.nielsen.com/insights/2021/trust-in-advertising/) for buyer trust.
2. **Pitch the outcome, never the model.** The smallest firms mostly skip AI because [what stops them is relevance rather than cost](https://advocacy.sba.gov/wp-content/uploads/2025/09/Research-Spotlight-AI-in-Business-Small-Firms-Closing-In_-092425.pdf): they do not see the use. "I can draft your support replies" answers that; "I build AI solutions" confirms it.
3. **Send a short message that ends with a free look.** The look costs you an hour, gets you the real problem, and is the start of [the scoping](/ledger/scoping-ai-projects/).
4. **Win the argument with a working demo, never a deck.** A small build running on their own workflow turns the pitch from a claim about AI into a claim about their week.
5. **Point at it for client two, and charge properly from the start.** The Upwork floor for AI work runs [$35 to $60 an hour](https://www.upwork.com/hire/artificial-intelligence-engineers/cost/), and agency rates sit well above it.
The rest is the evidence, and the market that makes it work.
Start with the market, because it is on your side. Most small businesses still have not put AI to work. By mid-2025 only [8.8% of US small firms were using AI to produce their goods or services](https://advocacy.sba.gov/wp-content/uploads/2025/09/Research-Spotlight-AI-in-Business-Small-Firms-Closing-In_-092425.pdf), per the Census data the SBA analyzed. Count more loosely and it climbs, to about [17.7% touching AI at all by the end of 2025](https://www.jpmorganchase.com/institute/all-topics/business-growth-and-entrepreneurship/understanding-ai-use-by-small-businesses) in JPMorgan Chase and Census figures, and as high as a [self-reported 58%](https://www.uschamber.com/assets/documents/Empowering-Small-Business-Report-2025.pdf) in the US Chamber's survey. The measures disagree because they count different things, but they agree on the shape: a large slice of small businesses runs a manual, expensive process a model could help with, and has not fixed it. That gap is the job.
## Start where you already are
Your first client is almost never a stranger from the internet. It is the small business a friend runs, the team at your day job drowning in a manual task, the person in a group chat complaining about something AI happens to be good at. The hard part of a first sale is trust, and trust does not come from a cold DM. Across markets, the single most trusted source of information a buyer has is [a recommendation from someone they already know](https://www.nielsen.com/insights/2021/trust-in-advertising/), per Nielsen. You cannot cold-email your way to that. You start with it or you go without it.
Make a short list of every person or business you have a real connection to. Next to each, write the one repetitive, annoying, expensive thing they do that a model could help with. That list is your pipeline, and it is more qualified than any cold outreach you could run.
## Sell the result
Nobody wants to buy AI. They want the thing on the other side of it: fewer hours on data entry, faster replies to customers, a first draft instead of a blank page. The adoption data shows how deep this runs. When the SBA asked the smallest firms why they were not adopting AI, [nearly 82% of those under five employees](https://advocacy.sba.gov/wp-content/uploads/2025/09/Research-Spotlight-AI-in-Business-Small-Firms-Closing-In_-092425.pdf) gave the same reason: they do not believe AI "is applicable to their business." Not cost. Not privacy, which 6.3% cited. Not a lack of understanding, at 6.7%. Relevance. They cannot see what it would do for them.
So "I build AI solutions" lands as noise, and worse, it confirms their objection. "I can turn the support emails you answer by hand into draft replies your team just approves" answers it. Lead with their problem in their words, and keep the tech invisible. The model is how you do the job. It is not the job.
## The first message
Keep it short, specific, and free of hype. Something like:
> Hey, I noticed your team spends a lot of time on [the manual thing]. I have been building tools that handle exactly that, and I think I could cut it down a lot. Want me to take a look and show you what is possible? No charge for the look.
That last line does the heavy lifting. A free, low-risk first look gets you in the door, lets you see the real problem, and gives you [something concrete to price](/ledger/pricing-ai-work/). The look is [scoping](/ledger/scoping-ai-projects/), and it is the fastest path from "maybe" to a paid build.
## Proof beats pitch
You do not need testimonials yet. You need one thing that visibly works. Build [a small, real version of the thing](/primer/vibe-coding-stack/) for one person on your list, even at a low price or as a favor, and get it running. Remember the 82%. The objection you are up against is "this is not for us," and a slide deck cannot beat that. A working demo of their own workflow, with their own data, can, because it stops being a claim about AI and becomes a claim about their Tuesday.
Then the second client is easier, because now you can say "I did this for them" and point at something real. What to charge along the way is [its own solved question](/ledger/pricing-ai-work/); for reference, AI engineers list a [median around $35 to $60 an hour on Upwork](https://www.upwork.com/hire/artificial-intelligence-engineers/cost/), and that is the marketplace floor, with agency and expert rates well above it. That is the whole loop: a warm lead, a real result, a number you can show. Repeat it three times and you are choosing between the ones who found you. Selling a product instead of a service is the same trust problem without the warm intro, and [getting your first 10 users](/ledger/first-10-users/) is that playbook.
---
# OpenAI gives six months. Anthropic gives two. Google gives weeks.
Section: The Study
URL: https://okaneland.com/study/ai-model-shutdown-ledger/
On September 24 the Sora API reached its shutdown date, six months after OpenAI announced it and with no replacement named. Across 71 shutdown notices from the three big labs, the warning depends mostly on the lab: about six months at OpenAI, two at Anthropic, and a few weeks at Google.
On September 24 OpenAI's Sora API reached its shutdown date. OpenAI had announced it six months earlier and named no replacement, so anyone with a video feature built on it had to rebuild that feature somewhere else.
How long you get before a model or API disappears is decided mostly on the day you pick it: by the lab you build on, and by whether the model's name says preview. We read every shutdown notice OpenAI, Anthropic and Google have published and measured the gap between each announcement and the switch-off.
## The short version
- **OpenAI gives about six months.** Its 38 notices have a median of 182 days between announcement and shutdown, and 13 of its 15 notices for generally available models gave at least 179. Its [deprecations page](https://developers.openai.com/api/docs/deprecations) sets a six-month minimum for those and three months for specialized variants, and warns that previews can get much less.
- **Anthropic gives two months, and lately almost exactly two.** Its nine notices have a median of 63 days, and the last four gave 62, 60, 62 and 61 against a [stated minimum of 60](https://platform.claude.com/docs/en/about-claude/model-deprecations). Every active Claude model also lists a retirement floor, and for the ten we checked it falls exactly one year after launch.
- **Google gives weeks.** Its 24 dated notices have a median of 28 days, and its four notices for stable models a median of about 53. Three generally available Veo video models got 15. Seven more retirements, among them the Gemini 1.5 models, show up in the [release notes](https://ai.google.dev/gemini-api/docs/changelog) only after the fact.
- **Short notice lives in previews, and mostly at Google.** Fifteen notices gave less than 30 days. Ten of them were for preview, experimental or beta models, and thirteen came from Google.
- **A product shutdown costs more than a model swap.** OpenAI gave its Assistants API a year and Agent Builder six months, and it closed the [Videos API](https://developers.openai.com/api/docs/deprecations) with no replacement. Swapping a model changes a line of config; leaving a hosted product means rebuilding what sat on top of it.
- **Access can close before the shutdown.** OpenAI stopped organizations that had never fine-tuned from starting jobs on the day it announced the change, and on September 18 Google limited Gemini 2.5 to existing users, adding that the models are not deprecated.
Everything below is the evidence, and the full ledger ships with this piece as a spreadsheet you can check line by line.
## How we built the ledger
We read three primary records on September 27, 2026. OpenAI's API deprecations page covers June 2022 to September 2026, and Anthropic's model deprecations page covers September 2024 to June 2026. For Google we used the Gemini API release notes, which its deprecations page names as the place announcements are made; the dated shutdown notices there run from August 2025 to September 2026. Where Google's deprecations table lists a model, we cross-checked its shutdown date there.
Each row is one announcement date, one shutdown date and one kind of thing retired. Entries that share all three merge, so a batch of fourteen models retired on the same day counts once, while an announcement covering two kinds, or setting two dates, becomes two rows. Notice is the number of calendar days from announcement to shutdown. The kinds are generally available models, previews (including experimental and beta models), OpenAI's specialized variants such as its chat-latest and Codex models, and APIs, endpoints and products.
A few rules keep the count true to the record. A model listed in two announcements counts once, in its latest one. We left out OpenAI's June 2023 notice, whose dates were later extended and whose models reappear in later notices. Google retirements with no dated announcement cannot be measured, so they are listed separately below. The labs also email active users, so some customers may have heard before a public page changed; our dates are the public record. Partner platforms such as Amazon Bedrock and Google Cloud run their own schedules, and parameter changes and alias swaps are left out. The full ledger is [a CSV file](/features/study/shutdown-ledger/shutdown-ledger.csv), one row per notice, each with its source.
## The ledger at a glance
| | OpenAI | Anthropic | Google |
|---|---|---|---|
| Notices measured | 38 | 9 | 24 |
| Notices in the last 12 months | 18 | 5 | 22 |
| Median notice, all | 182 days | 63 days | 28 days |
| Median notice, generally available models | 183 days (15) | 63 days (9) | about 53 days (4) |
| Median notice, previews | about 152 days (8) | none retired | 28 days (17) |
| Shortest notice | 3 days (Codex models, 2023) | 60 days | same day (an experimental Maps tool) |
| Stated minimum | 6 months GA, 3 months variants; previews may get far less | 60 days | 2 weeks for previews; no period stated for stable models |
 Each dot is one notice. The medians sit far apart: six months at OpenAI, two at Anthropic and four weeks at Google, where all but two notices fall inside the first two months.
## OpenAI: six months, with three exceptions
OpenAI publishes the most detailed policy of the three. Unless safety or compliance require a faster timeline, its minimum is six months for a generally available model and three for a specialized variant such as a chat or Codex model. Preview models, it says, [**"may be retired with much shorter notice, such as 2 weeks."**](https://developers.openai.com/api/docs/deprecations)
The record mostly tracks the policy. Ten of the 15 notices covering generally available models landed between 179 and 184 days, and three ran between ten months and a year, including the GPT-4-32k models in 2024. Specialized variants got about three months, 87 to 94 days. Previews, which the policy says may get two weeks, got a median of about five months.
Three exceptions stand out. In March 2023 OpenAI retired its original Codex coding models three days after announcing it. In April 2026 two older dated snapshots of its audio and realtime mini models got 92 days, inside a batch that was otherwise previews and variants. And on September 11, 2026 it gave gpt-5.4-cyber 20 days. The page does not say which tier that model belongs to; as a specialized variant its minimum would be three months, and the policy allows a faster timeline for safety or compliance.
Some OpenAI snapshots also stay available for years. The gpt-4-0613 snapshot, announced on June 13, 2023, is scheduled to shut down on October 23, 2026, more than three years later.
## Anthropic: sixty days, and a date you can see from launch
Anthropic promises [**"at least 60 days' notice before model retirement for publicly released models."**](https://platform.claude.com/docs/en/about-claude/model-deprecations) For a while it gave more: Claude 2 and Claude 3 Opus each got about six months in 2025. Since the end of 2025 it has given the minimum, give or take two days, on all four notices.
What Anthropic adds is a date you can see coming. Its status table lists a not-sooner-than retirement date for every active model, and for each of the ten models we checked against Anthropic's launch posts, from Sonnet 4.5 to Opus 5.5, that date is the first anniversary of the launch. Claude Opus 4.1 was retired on its first birthday, August 5, 2026. Claude Sonnet 4 and Opus 4 lasted a year and about three weeks.
So the planning rule for Claude is simple: assume about a year from launch, expect the notice around month ten, and budget two months to move. Claude models on Amazon Bedrock and Google Cloud follow those platforms' own schedules, which can differ.
## Google: weeks, even for stable models
Google's deprecations table warns that its dates are [**"the earliest possible dates on which a model might be retired."**](https://ai.google.dev/gemini-api/docs/deprecations) Its models page promises at least two weeks of notice for previews and gives no notice period for stable models.
The measured record is weeks for almost everything. Previews got a median of 28 days, from 3 to 50. The stable-model notices ran from 15 to 103 days: Gemini 2.0 Flash got 103, Imagen 4 got 63, text-embedding-004 got 42, and Google's Veo 2 and Veo 3 models, all of them generally available, got 15, with Veo previews as the recommended replacement in the Gemini API.
Two preview shutdowns came faster than the two weeks the models page mentions. A preview image-generation model got 3 days in November 2025, and gemini-3-pro-preview got 11 days in February 2026, a little over three months after its launch, after which its ID was pointed at its successor.
Seven more retirements never had a dated announcement in the release notes, so they sit outside the medians. The generally available Gemini 1.5 models appear there only on September 29, 2025, already shut down. Imagen 3 appears the same way on November 10, 2025, and Gemini 1.0 Pro on February 18, 2025 as no longer supported. The rest are the end of model tuning in May 2025, an experimental 2.5 Pro model, two Live API previews, and Gemini 1.0 Pro Vision, which was marked deprecated with no date and removed a month later.
How long a model lives varies inside every lab. A few well-known examples:
| Model | Lab | Launched | Switched off | Lived |
|---|---|---|---|---|
| gpt-4-0613 | OpenAI | Jun 13, 2023 | Oct 23, 2026 (scheduled) | about 3 years, 4 months |
| claude-sonnet-4 | Anthropic | May 22, 2025 | Jun 15, 2026 | a year and about 3 weeks |
| claude-opus-4-1 | Anthropic | Aug 5, 2025 | Aug 5, 2026 | exactly 1 year |
| gemini-2.0-flash | Google | Feb 5, 2025 | Jun 1, 2026 | about 16 months |
| veo-3.0-generate-001 | Google | Sep 9, 2025 | Jun 30, 2026 | under 10 months |
| gemini-3-pro-preview | Google | Nov 18, 2025 | Mar 9, 2026 (ID redirected) | 111 days |
## When it is a product, it is a rebuild
OpenAI gives its products long notice, and they are still the most expensive notices to receive. The Assistants API got a full year, with its users pointed to the Responses and Conversations APIs. On June 3, 2026 it announced the end of Agent Builder, the Evals platform and reusable prompt objects, all off by November 30. The Videos API and its Sora 2 models got six months and no replacement.
Google's product changes came faster. A legacy response schema in its Interactions API was removed 33 days after notice, and URL context on Gemini 2.0 Flash ended a week after it was announced.
A model retirement usually means changing one string and rerunning your tests. A product retirement means moving everything you built on it, and for Sora there was no named place to move to. The higher up the stack a lab's product sits, from hosted assistants to agent builders to eval dashboards, the more of your code a notice reaches.
## Access can close before the shutdown
Three changes in the record stop new users before anything is switched off.
- **OpenAI, May 7, 2026.** Organizations that had not previously run fine-tuning could no longer start jobs from the day of the announcement. From July 2 the same applied to organizations without recent fine-tuned inference, and existing customers lose job creation on January 6, 2027.
- **OpenAI, June 2024.** Eleven days after announcing the retirement of the GPT-4-32k and vision-preview models, OpenAI limited them to existing users.
- **Google, September 18, 2026.** Access to the Gemini 2.5 models was limited to users who had actively used them before, with a note saying the 2.5 family is still served and has not been deprecated.
If you start a new project on an older model, or your product opens new API projects for customers, that door can close with little or no notice.
## What to check before you build on a model
1. **Read the label first.** Previews and experiments account for most of the short notices in this ledger. If paying users depend on a feature, put it on a generally available model.
2. **Write the earliest retirement date down on day one.** Anthropic lists one for every active model, and Google lists one for only a few. For OpenAI, count on the policy floor instead: six months from a notice for a generally available model.
3. **Budget the move by lab.** Plan on roughly six months to migrate off an OpenAI model, two off a Claude model, and two to six weeks off a Gemini model.
4. **Make the model a setting, with a test set behind it.** Keep the model name in config and twenty real prompts with known-good outputs, so a migration is an afternoon of rerunning and comparing.
5. **Keep hosted products at arm's length.** Agent builders, hosted assistants, prompt objects and eval dashboards are where a shutdown turns into a rebuild. Keep your prompts, data and logic in your own code.
6. **Make sure the notice reaches you.** The labs email accounts with active usage, so route that address to an inbox you read, and follow each lab's deprecations page or release notes.
7. **For the part that must never break, keep a fallback nobody can switch off.** An open-weight model on your own hardware has no deprecation schedule. Our [Ollama primer](/primer/how-to-use-ollama/) covers running one.
---
# What it costs to run a vibe-coded app
Section: The Study
URL: https://okaneland.com/study/what-it-costs-to-run-an-app/
The catalog prices building, pricing, and selling, and never once prices running. The managed default keeps a small app at $0 while it is a hobby, then sets a $45 floor the moment money changes hands. A plain server runs the same app for roughly six euros at every stage. Each side wins a stage, and the number that flips the math at scale is the one nobody quotes: the marginal transfer rate.
Every stage of a solo build has a price in this catalog except the one that arrives every month. We have priced [building](/primer/build-an-app-with-ai-from-scratch), [pricing](/ledger/pricing-ai-work), and [the model bill](/study/cut-your-ai-coding-bill/), and never once priced running the thing. So here is the number that shows up on the first of every month: what it costs to keep a small app online, on the managed default versus a plain server, at three real stages of traffic.
The short version is that neither side wins outright. The managed stack is genuinely free while your app is a hobby and genuinely convenient after, and a plain VPS is cheaper at almost every paid stage and more work at all of them. Which is why the useful thing is not a verdict but the fine print, and the one number that actually flips the math at scale.
## The short version
- **Stage 1, a hobby: the managed stack wins at $0.** Vercel Hobby plus Supabase Free costs nothing for a small app, and a VPS costs about six euros. Free is free; there is no way around that.
- **Stage 2, the day you charge money: a $45 floor appears.** Vercel Hobby is licensed personal and non-commercial, so charging moves you to Pro at $20, and a real database moves you to Supabase Pro at $25. That $45 is a plan floor, not usage. The same app on a VPS is still the six-euro box.
- **Stage 3, real traffic: the managed stack often stays ~$45, and the VPS stays cheap.** Under a normal content-app profile, a hundred thousand visits sit inside Vercel Pro and Supabase Pro's included allowances, so the managed bill barely moves; the VPS is €6 to €24 depending on how much headroom you buy.
- **The number that flips it is the marginal transfer rate.** Vercel bills Fast Data Transfer from $0.15/GB past its included terabyte; Hetzner includes 20 TB then charges about €1/TB. A media-heavy or viral app is where those rates, not the sticker, decide the bill.
Every figure below was read from the vendor's own page on 12 August 2026, and it holds only for the reference app named next.
## The reference app, stated before any price
A comparison is meaningless without the profile it prices, so here is ours, printed before the numbers: a small server-rendered app with a Postgres database under 1 GB, roughly three page views per visit, about 30 requests and 2.5 MB transferred per visit. A media-heavy app, an API with large payloads, or anything streaming video moves every number below by orders of magnitude. If your app is not shaped like this one, take the method and not the totals.
## The three stages
| Stage | Vercel + Supabase | Hetzner / DigitalOcean VPS |
|---|---|---|
| Hobby (0-1k visits) | **$0** (Hobby + Free) | ~€5.49 / $6 |
| 10k visits, charging money | **$45** ($20 Pro + $25 Pro) | ~€5.49 / $6 |
| 100k visits (this profile) | **~$45** (inside included allowances) | ~€6-24 |
**Stage 1** is a real $0, with three pieces of fine print that decide when it ends: Vercel Hobby is personal and non-commercial and has hard caps with no pay-as-you-go past them, and Supabase Free pauses a project after one week of inactivity and limits you to two. The free tier is a genuine gift and a trapdoor; the day your side project has a paying user or goes quiet for a week, the terms change under you.
**Stage 2** is where the floor appears, and it is a licensing floor, not a usage one. The moment you charge, Vercel's non-commercial clause pushes you to Pro at $20, and a database you actually depend on pushes you to Supabase Pro at $25, whose $10 compute credit covers exactly one Micro instance. That is $45 a month before your traffic does anything, against a VPS that has not changed price since stage 1.
**Stage 3** is the surprise: for this profile, more traffic barely moves the managed bill. A hundred thousand visits is roughly three million edge requests and 250 GB of transfer, which sits inside Pro's included 10 million requests and one terabyte. So the managed stack holds near $45 while the VPS, depending on whether you bought the €6 box or a €24 one for headroom, holds cheap. Convenience, not compute, is what you are paying the $45 for.
## The number nobody quotes: marginal transfer
The stage table hides the lever, because the reference app is light. The lever is the price of the next gigabyte once you exhaust the included allowance. Vercel's Fast Data Transfer starts at $0.15/GB past the included terabyte; Hetzner includes 20 TB on a box and then charges about €1/TB. That is a two-order-of-magnitude gap on marginal bytes, and it is invisible until an app gets heavy or a post goes viral. For the content app here it never bites. For anything serving images, audio, or video at scale, it is the whole decision, and the sticker price is a distraction from it.
## The failure mode: uncapped usage
The reason to understand the meter is the bill that arrives when you do not. The managed platforms scale automatically, which is a feature until a loop, a scraper, or a launch spike turns autoscaling into an open tab; widely shared receipts of four-figure surprise invoices on usage-billed platforms all share that shape. This is the same dynamic our [cost study](/study/cut-your-ai-coding-bill/) maps for model tokens: the danger is not the rate, it is the absence of a ceiling. Vercel's Hobby caps stop rather than bill, which is a safety feature; the moment you move to a plan that bills past its allowance, set a spend limit, because a VPS has a hard ceiling built in and a usage plan does not.
## The ops bill nobody itemizes
There is a cost on the VPS side the sticker hides, and candor requires naming it. Running okaneland.com and its forum on a single server is genuinely cheap in euros and genuinely not free in attention: security updates, off-box backups, and the occasional 11pm reboot are real work, and we are describing our own experience rather than quoting an invoice. The managed $45 buys those hours back. So the true comparison is not €6 versus $45, it is €6-plus-your-time versus $45-and-none-of-it, and where you land depends on whether your time or your money is the scarcer one this year.
## When each side wins
The verdict is per stage and per profile, which is the real shape of it. While the app is a hobby, the managed stack wins on price outright. When you start charging, a VPS is cheaper by roughly $40 a month and costs you the ops hours to earn it. At scale on a light app the two converge near $45; at scale on a heavy app the marginal transfer rate decides everything and the VPS wins by a wide margin. Pick on which of those you are, not on the front-page number, and remember the Hetzner prices here are post-June-2026 and exclude VAT, so the folklore-cheap box costs a little more than the old threads promised. The map to where each of these bills fits in the whole build is in [our from-scratch primer](/primer/build-an-app-with-ai-from-scratch); this is the deep read on the one line it summarizes.
---
# The MCP tax: what each server costs before your first prompt
Section: The Study
URL: https://okaneland.com/study/the-mcp-context-tax/
Every "best MCP servers" list ranks what to install and none of them prints what each one weighs. So we measured it: the tool-definition size of ten of the most-recommended servers, and where that weight actually lands now that Claude Code defers it. The tax did not disappear. It moved from startup to first use, and here is the bill per server.
There is a specific number that decides whether an MCP server is worth installing, and no "best MCP servers" list prints it: how much context its tool definitions weigh. The lists rank usefulness, downloads, and stars. They stop exactly where the cost begins. So we opened the four biggest of them, took the servers they most agree on, and measured the one number they leave out.
The finding has two halves, and the second is the interesting one. The tax that older writeups warned about, where every server's full schema burns context at session start, has largely been mitigated in current Claude Code, which defers tool definitions by default. But the weight did not vanish. It moved from startup to first use, and its size per server is exactly what we measured. This is the sibling to [our AI coding cost study](/study/cut-your-ai-coding-bill/): that one prices the model, this one prices the plumbing.
## The short version
- **Tool-definition weight varies by more than 30x across popular servers.** In our measurement, a one-tool fetch server's schema is around 600 estimated tokens; Notion's 24 tools are around 19,000. Same "install one server," two orders of magnitude apart.
- **Current Claude Code defers the cost, so at session start it is near zero.** We measured total prompt tokens with and without a server attached and the difference sat inside run-to-run noise. The schema is fetched when a tool is used, not when the session opens.
- **So the tax is real but relocated.** In a client or mode without deferral, or the moment you actually use several servers in a turn, you pay the full schema sizes in the table below. Read them as the bill that arrives on use.
- **Every number here carries its method and date, and the raw table ships with the piece.** The measurement is Claude Code 2.1.204 on macOS, 2026-08-09; token figures are estimated at roughly four characters per token and labelled as estimates, not tokenizer-exact counts.
## How we picked the ten
The candidate list is built transparently, not editorially. We took the four largest public catalogues, the official `modelcontextprotocol/servers` repo plus the three biggest community "awesome" lists, and kept the servers they most agree on, cross-checked against what Google autocomplete completes for "best mcp servers for." Two disclosures the lists themselves invite: punkpeye's list (around 92,130 stars) describes itself in its own README as the companion to the Glama directory, and appcypher's list is itself an archived repo. We note both rather than presenting all four as equally live.
"Free" here means no paid key is required to run the server. Two exceptions worth stating: the official GitHub server needs a GitHub account and a personal access token, and Brave's search server needs an API key whose signup asks for a card it does not charge. Everything else ran with no account at all.
## The table: what each server's tools weigh
Measured by connecting a client and calling `tools/list`, then sizing the returned schema. Tokens are estimated at roughly four characters each and labelled accordingly.
| Server | Tools | Schema (chars) | Est. tokens |
|---|---|---|---|
| Notion | 24 | 76,215 | ~19,050 |
| Firecrawl | 27 | 39,491 | ~9,870 |
| Supabase | 29 | 19,947 | ~4,990 |
| Playwright | 24 | 18,502 | ~4,630 |
| GitHub | 26 | 15,854 | ~3,960 |
| Filesystem | 14 | 12,973 | ~3,240 |
| Memory | 9 | 10,750 | ~2,690 |
| Everything (demo) | 13 | 7,653 | ~1,910 |
| Context7 | 2 | 4,860 | ~1,215 |
| Sequential-thinking | 1 | 4,587 | ~1,150 |
| Puppeteer | 7 | 2,448 | ~610 |
The spread is the story. It does not track tool count cleanly, because verbose descriptions and large input schemas cost more than short ones; Notion's 24 tools weigh four times Playwright's 24. The number that matters is not how many tools a server adds, it is how much text those tools' definitions carry.
## When the bill actually arrives
Here is the loading-mode finding, measured rather than assumed. We ran a trivial one-turn session in an empty repo and summed the prompt tokens, then did the same with the filesystem server attached. The totals were the same inside run-to-run variance: roughly 25,300 either way, a difference smaller than the noise between two baseline runs.
 In Claude Code 2.1.204, attaching a server does not measurably grow the session at startup, because the client defers tool definitions and only their names ride along until a tool is called.
That is the good news and the trap in one. The cost is deferred, not deleted. The moment the agent actually uses a server, the schema loads, and a turn that touches several servers pays their combined weight from the table. In an older client, or one that loads schemas eagerly, you pay it at startup regardless. So the fair way to read the table is as the cost-on-use per server, and the fair way to read the deferral is as a reason to install fewer servers than you think you can afford, because "it is free until I use it" quietly becomes "I used four of them in one turn."
## What is already measured, read carefully
Two published numbers get quoted a lot in this discussion, and both need their scope kept on.
Anthropic's engineering post from November 2025 uses an example of tool-definition overhead dropping from about 150,000 tokens to about 2,000 through progressive disclosure. That is an illustration of the mechanism, not a measurement of any specific setup, and it should be cited as the illustration it is. Separately, Scalekit's 75-run benchmark found that for the GitHub remote server on one task, the MCP agent used about 44,026 tokens against a CLI agent's 1,365 for the same result. That is a striking gap and it is one server, one task; the seven failures in that run were TCP connect timeouts the authors explicitly call "not an MCP protocol error." Neither number supports "MCP costs 30x more" as a general law. They support the narrower, sturdier claim this piece is built on: tool definitions have a real, measurable weight, and it is worth knowing per server.
## The archive finding
One thing the download counts surfaced is worth a paragraph. Six of the most-recommended servers, including the widely installed GitHub one at about 125,000 downloads a week, are archived upstream. They still work, and people still install them by the hundred thousand, but archived means no maintenance, which for a component that holds your tokens and often your credentials is its own risk, tying straight back to the [install-trust failures in our agent-security ledger](/study/what-your-ai-agent-can-destroy/). Popularity on a list is a lagging signal; it can point at software the maintainer has already walked away from.
## Keep or cut, by standard
The verdict follows the same standard Anthropic's own guidance points at: run `/context`, and disable servers you are not actively using via `/mcp`. Concretely, from the numbers here:
- **Keep the small, always-useful ones.** Filesystem and a fetch or search tool earn their weight; you use them most turns.
- **Load the heavy ones only for the session that needs them.** Notion, Firecrawl, Supabase, and Playwright are the expensive rows. Attach them for the task, then turn them off. On a deferring client that costs little at rest, but it removes the first-use spike from every unrelated turn and shrinks the surface from [the security piece](/study/what-your-ai-agent-can-destroy/).
- **Cut what you installed once and forgot.** The cheapest tokens are the ones a server you never call is no longer allowed to charge you.
The whole point is that this is now a decision you can make on a number instead of a vibe. The table is dated and the method is a paragraph; re-run it against your own client and version, because deferral behaviour is exactly the kind of thing that changes between releases, and the value of a receipt is that you can check whether it still holds. For the workflow that keeps these servers in their lane, [our Claude Code guide](/primer/how-to-use-claude-code/) is the companion, and the [field guide](/study/ai-coding-agent-field-guide/) maps which agents defer this cost and which do not.
---
# Blast radius: what your AI agent can destroy
Section: The Study
URL: https://okaneland.com/study/what-your-ai-agent-can-destroy/
The security question a solo builder actually faces is not only the app they ship. It is the blast radius of the agent holding their keys, and of the MCP servers, plugins, and skills they install on trust. Here is a verified incident ledger in both directions, every entry traced to a primary, each ending in one guardrail that maps to a documented feature.
In April 2026 an AI coding agent deleted a company's production database in nine seconds. The account, from the builder behind PocketOS, is specific in the way that matters: Cursor was running Claude Opus 4.6, it issued a single unconfirmed `volumeDelete` call against Railway's API, and the token it used had been created only to manage custom domains yet carried authority across the whole API. The backups were stored inside the same volume it wiped, and the newest one that survived elsewhere was three months old.
The failure was not that the model was careless. It was that the credentials it held were far wider than the job it was doing, and nothing stood between it and a destructive call. That is the pattern under almost every agent horror story, and it points at a security question our [self-audit for your own app](/study/is-your-vibe-coded-app-secure/) does not cover: not the code you ship, but the blast radius of the agent holding your keys, and of the servers, plugins, and skills you install on trust.
## The short version
- **There are two blast radii, and both are about access, not intelligence.** Outbound: what an agent can destroy with the credentials you hand it. Inbound: what you invite in when you install an MCP server, plugin, or skill on faith.
- **The recurring root cause is over-scoped access with no ceiling.** A domains-only token that could delete volumes. An unrestricted API key that could spend to infinity. A support-ticket field the agent treated as instructions. In each case the model did what its access allowed.
- **Every incident below is traced to a primary source and dated.** Where a number is one person's first-person account, we say so. Where a fix is partial, we say that too; there is no single toggle that makes an agent safe.
- **The guardrails are boring and they are documented.** Scoped least-privilege keys, hard spend caps, confirmation gates and read-only modes, real off-box backups, and treating anything you install as untrusted code. Each maps to a vendor feature, not a vibe.
## Direction one: the agent holding your keys
Three incidents, each a different way that wide access plus no ceiling ends badly.
**The runaway bill.** An operator pointed an agent at a network-scanning task on DN42. The agent chose AWS on its own and deployed five m8g.12xlarge instances to chase a 100Gbps target. It ran for about a day and produced a $6,531.30 bill the operator could not cover and later solicited donations for. The detail worth sitting with, from the author's own writeup, is that the agent did ask for confirmation several times, and the human told it to continue without inspecting the plan. The cause named by the operator is exactly that: approval without review. The guardrail is a hard spend cap that does not depend on a tired human reading a plan at 2am.
**The nine-second wipe.** The PocketOS incident above. The token was the whole story: created for one narrow purpose, scoped to everything. There was no confirmation gate on a destructive operation, and the backups were co-located with the thing they were meant to protect. Three guardrails, each documented: least-privilege tokens scoped to the task, a confirmation step or read-only mode for destructive calls, and backups that live somewhere the agent cannot reach.
**The overnight spend.** On Google's AI developer forum, an unrestricted Firebase browser key was abused to drive Gemini requests and ran up more than EUR 54,000 overnight. An EUR 80 budget alert fired hours late, by which point the cost was near EUR 28,000. Google classified the charges as valid usage and denied the billing adjustment, and the escalation was still unresolved in the thread. Google's own staff documented the fixes in the same place: restrict the API key, and set project and tier spend caps. An unrestricted key is a blank cheque, and the alert is not a cap.
## Direction two: what you install on faith
The inbound radius is newer and less understood, because the thing you install looks like a convenience, not a credential.
**The MCP that reads too much** (Jul 2025). General Analysis showed that an out-of-the-box Supabase setup, with row-level security enabled, still let the IDE assistant run MCP SQL under the `service_role` that bypasses RLS. A customer plants an instruction inside a support-ticket message; the agent, asked to read tickets, executes it and copies a tokens table into a row the attacker can read. The documented mitigations are the MCP read-only flag and a prompt-injection filter, and the researchers say plainly that the filter will not catch every attack. Read that as layered defense, not a cure.
**The toxic agent flow** (May 2025). Invariant Labs demonstrated a GitHub MCP exploit that is not a bug in any code. A malicious issue on a public repo injects the agent; when the owner later asks it to look at open issues, it pulls private-repo data into context and leaks it through a public PR it opens itself. The lesson is architectural: an agent that can read your private data and write to public places needs a human between those two capabilities.
**The supply-chain XSS** (Dec 2025). A cross-tenant flaw in Mintlify's hosted docs, plus an SVG carrying JavaScript, produced stored XSS servable from the primary domains of X, Vercel, Cursor, and Discord, for about $11,000 in bounties. This one is a hosted-SaaS bug, not an agent install, and its fix is mostly vendor-side. It earns its place by showing how far a single upstream dependency's compromise can reach into products you trust.
## Two failures specific to the install registries
Two 2026 incidents are about the registries themselves, where the trust problem is sharpest.
CVE-2026-33579, in the OpenClaw personal-agent project before version 2026.3.28, is a privilege escalation: the `/pair approve` path failed to forward the caller's scopes into the approval check, so a caller with pairing privileges could approve pairings it should not. It was scored CVSS 9.9 and 9.4 CRITICAL by the CNA VulnCheck; the NVD's own assessment is shown as not yet provided, so attribute the score to VulnCheck rather than to "the NVD." The guardrail is unglamorous: patch, and treat an agent that manages its own access grants as security-critical software.
And on ClawHub, the project's skills registry, researchers documented a wave of 386 malicious skills over three days in late January 2026, after 28 in an earlier wave, masquerading as crypto tools and sharing a single command-and-control host. No exploit was needed. The skills simply ran once installed. The researchers report finding no evidence that published skills are scanned by any security tooling, which is the whole point: a skills registry is an app store where you are the review process.
One correction the record needs, because attribution is part of the receipt. The widely cited 860-point "an AI agent deleted our production database" thread is the Cursor/Railway/PocketOS incident above, not Replit. Replit's own deleted-database incident is real but separate: it involved the SaaStr founder Jason Lemkin in July 2025 and a much smaller thread. Getting the name right is how the lesson stays attached to the right cause.
## The guardrails, by failure class
Every incident above sorts into one of a few classes, and each class has a documented defense. This is the deliverable.
1. **Over-scoped credentials.** Give the agent a key scoped to exactly the task, never your root or admin token. The nine-second wipe and the toxic agent flow both turn on a credential that could do far more than the job asked.
2. **No spend ceiling.** Set hard spend caps at the provider, not just alerts. Both runaway-bill incidents had alerts; neither had a cap that stopped the spend.
3. **No gate on destructive actions.** Require a confirmation step, or run read-only, for anything that deletes or moves money. The MCP read-only flag exists for exactly this.
4. **Fragile backups.** Keep real backups somewhere the agent has no access, and test that they restore. A backup inside the volume it protects is not a backup.
5. **Blind install-trust.** Treat every MCP server, plugin, and skill as untrusted code from a stranger, because on an unscanned registry that is what it is. Read what it does before you install it.
6. **Indirect prompt injection.** Assume any text the agent reads (a ticket, an issue, a web page) can carry instructions, and keep the agent's read and write powers from overlapping without a human in between.
None of these is a cure on its own, which is the plain close. The Supabase writeup says its filter misses attacks; the registries do not scan; a determined injection will find a path. What the six do together is shrink the blast radius, so that the day your agent does something you did not intend, the worst it can reach is small. That is the same discipline our [cost study](/study/cut-your-ai-coding-bill/) applies to the meter and [our Claude Code guide](/primer/how-to-use-claude-code/) applies to the loop: the goal is not a perfect agent, it is a bounded one.
---
# The vibe-coding wins are real. So is the denominator
Section: The Study
URL: https://okaneland.com/study/after-the-vibecode-wins-and-denominator/
The acquisitions and ARR screenshots are real, and they are the numerator of a fraction whose denominator nobody posts. The loudest figures are annualized viral spikes, and the two biggest "vibe-coding" exits were companies selling the shovels, not products built with them. We did not compile a dataset. We collected the public wins and set them against the one builder who published his own hit rate.
On 22 February 2025, Pieter Levels started prompting an AI flight game into existence in public. Seventeen days later he posted that fly.pieter.com had reached $1M in annualized revenue, and the screenshot has been load-bearing for the vibe-coding gold rush ever since.
The same builder maintains a much quieter page: a public ledger of roughly 113 projects, with about 9 marked a success, and a plain note that most of what he made never earned money. Both pages are true. This piece is about reading them together, because the screenshots always travel alone.
## The short version
- **The wins are real, self-reported, and everywhere: acquisitions, $1M-ARR screenshots, launch threads.** What you never see posted next to them is the denominator, the count of everything the same builders shipped that made nothing.
- **The loudest "ARR" numbers are annualized spikes.** ARR is often just one good month multiplied by twelve, and when that month was a one-time viral surge, the annual figure describes a moment that already passed.
- **The two biggest "vibe-coding" exits sold shovels, not gold.** Base44 (about $80M from Wix) and Anything ($100M valuation) are platforms builders use to vibe-code. That is a real business, and it is not the same as a solo product built with those tools succeeding.
- **The one builder who published his own hit rate is the anchor to trust.** Pieter Levels' public ledger tracks around 113 projects with about 9 marked a success, in his words most never made money. That fraction, not any single screenshot, is the shape of the thing.
We did not build a dataset, audit anyone's revenue, or measure an outcome distribution, because no public, representative registry of vibe-coded launches exists. This is a curated review of what people posted publicly, set against the one denominator a builder published about himself. Every figure is self-reported and dated where we could date it.
## The success stories, itemized
Set out plainly, the public wins look overwhelming:
| Case | Reported outcome | What it actually is |
|---|---|---|
| Cal AI | 15M+ downloads, $30M+ revenue, acquired by MyFitnessPal | A product; revenue self-reported, acquisition confirmed |
| Base44 | ~$80M cash from Wix, ~6-month-old company | A vibe-coding **platform** (shovels) |
| Anything | $2M ARR in two weeks, $100M valuation | A vibe-coding **platform** (shovels) |
| fly.pieter.com | "$1M ARR in 17 days" | A product; annualized spike, composition unverified |
| Bryce Edwards' app | ~$11k in 30 days | A product; self-reported, no recurring breakdown |
Every row is real in the sense that someone credible posted it. The work of reading it correctly is in the third column, and in the rows that were never posted at all.
## What "ARR" is hiding
Annual Recurring Revenue is a projection: this month's recurring revenue, times twelve. It is a fair estimate when revenue is steady and recurring. It is misleading when the month was a one-time surge, because there is nothing recurring to annualize.
The cleanest illustration is Pieter Levels' own fly.pieter.com, an AI flight game that he reports hit "$1M ARR in just 17 days" after starting on 22 February 2025. That $1M is the confirmed, self-reported headline. The widely repeated breakdown, that the monthly figure was mostly advertising slots and one-time sales of in-game jets rather than subscriptions, comes from posts we could not re-open, so we flag it as reported and unverified rather than stating it as fact. But the mechanism is the lesson regardless: annualizing a spike made of one-time payments produces a number that describes a fortnight, not a year. When you see "$1M ARR in X days," the days are doing more work than the dollars.
## Read the acquisition fine print: tool versus product
The two largest exits in the "vibe-coding" conversation are the ones to read most carefully, because they are not what the framing implies.
Base44, a solo-founded platform that lets people build apps by prompting, was reportedly bought by Wix for around $80M in cash when it was roughly six months old, with a reported $189k profit in May and about 250,000 users. Anything, another platform in the same space, reportedly reached a $100M valuation. Both are genuine successes and both are shovel sellers: they make money when builders use them to vibe-code, whether or not any of those builders' apps succeed. That is arguably the most reliable business in a gold rush, and it is a different claim from "a person built a product by vibe coding and sold it." Cal AI and fly.pieter are the product cases; Base44 and Anything are the platform cases. Filing them in the same drawer is how the success rate of vibe coding gets quietly overstated.
## The denominator nobody screenshots
Here is the number that reframes all of the above, and the reason it is trustworthy is that the builder published it about his own work.
Pieter Levels, one of the most successful indie builders alive, keeps a public ledger of his projects. It tracks on the order of 113 of them, with roughly 9 marked a success, and he says plainly that most of what he made never succeeded or made money. Sit with that ratio. This is not a struggling beginner; it is a builder with multiple genuine hits, telling you that the base rate underneath those hits is a long column of things that went nowhere. Every screenshot you have admired is drawn from someone's version of that same column, cropped to the winning row.
That is what survivorship bias looks like in one plain table, and it is the correct frame for reading every figure in this piece. The wins are real. They are also the visible top of a fraction whose bottom is almost never posted, and the [liveness floor we measured separately](/study/how-many-vibe-coded-launches-are-alive/), where at least one in nine showcased launches is already offline, is a small window onto that denominator.
## What we could not establish
The limits, stated plainly. There is no public registry of vibe-coded launches, so the true success rate is unknown and this piece does not estimate one. Every revenue figure here is self-reported and unaudited; the acquisitions are confirmed by outlets, but the revenue described inside them is not. Several of the most-quoted specifics, including the composition of fly.pieter's peak month and any figure for its revenue afterward, rest on posts we could not re-open, and we have labeled them as such rather than launder them into fact.
What survives all of that caution is the shape. The outcomes people post are real and are selected for being postable. The loudest annual figures are often a single month wearing a year's clothing. The biggest exits sold the tools, not the output. And the one builder generous enough to publish his own denominator put it at roughly 9 in 113. If you are measuring your own build against the highlight reel, measure it against that fraction instead, the same way our [build-in-public revenue study](/study/build-in-public-revenue/) and our [one-person-business economics](/ledger/economics-of-a-one-person-ai-business/) keep insisting: the screenshot is the numerator, and the number that matters is the one underneath it.
---
# We pinged 522 vibe-coded launches. Here is how many answered
Section: The Study
URL: https://okaneland.com/study/how-many-vibe-coded-launches-are-alive/
Nobody had actually HTTP-checked whether vibe-coded launches are still online, so we did. We pulled every app from the two showcase directories where every entry is provably built on a vibe-coding tool, pinged 522 of them, and hand-verified the edges. At least 1 in 9 is already dark. That is a connectivity floor, not a business-death rate, and the difference is the whole point.
On 9 August 2026 we pointed an HTTP checker at periscope.tv, the live-streaming app that shut down in March 2021. It returned a 200 and a working page. Five years dead, still answering. One request, and the whole genre of confident claims about dead apps starts to wobble, because the web does not clean up after failure and a status code was never a business metric.
We kept the checker running. Over one afternoon it visited all 522 vibe-coded launches listed by the two showcase directories where every entry is provably built on a vibe-coding tool. This piece is what came back, with the full dataset attached.
## The short version
- **We HTTP-checked 522 vibe-coded launches. At least 56 of them, 10.7%, are already fully offline.** The domain no longer resolves, or the app returns a gone/404. That is better than one in nine, dark, from a directory of apps their own makers were proud enough to showcase.
- **437 of the 522, 83.7%, still return a working page.** Another 29 (5.6%) are genuinely ambiguous: a bot-block, a broken TLS handshake, or a redirect our scanner would not follow. We put those in their own bucket rather than guess.
- **The dead rate climbs sharply with age.** Under six months old, 2.7% are offline. Past a year, 17.6% are. Time, not the tool, is what turns a showcased launch dark.
- **This is a connectivity floor, not a business-death rate.** A page that loads tells you the domain still points somewhere. It does not tell you the product has a single paying user. The viral "487 of 500 are dead" claim measures something entirely different, and we did not replicate it.
Every number here we generated ourselves on 9 August 2026, and the full CSV of all 522 URLs and their status is published at the end so you can re-run it.
## What we actually checked, and what "alive" cannot mean
There is a lot of confident talk about vibe-coded apps dying and almost no actual measurement. The one viral number, from a Reddit post claiming 487 of 500 launches are dead, is a business-death metric that nobody can re-run. We wanted a number a reader could reproduce, so we narrowed the question until it was answerable: not "is the business alive," which no HTTP request can tell you, but "does the URL still return a working page."
The set matters as much as the method. Product Hunt listings and AI directories do not tell you a product was vibe-coded, so those cannot fairly carry the word. The only sets where every entry is provably built on a vibe-coding tool are the platform showcase galleries. We took both: [madewithlovable.com](https://madewithlovable.com/) (506 projects) and [madewithbolt.com](https://madewithbolt.com/) (29 projects), 535 in total. Of those, 522 exposed a live app URL we could check; 13 listed no external link. Each page also carries an "Added" date, which lets us plot decay against age.
Then we hit every URL with a real browser user-agent and sorted the responses into three buckets:
- **Offline:** the domain does not resolve (DNS gone) or the app returns 404/410. This is the only bucket we call dead.
- **Responds:** a 2xx working page.
- **Ambiguous:** a 401/403/429 block, a TLS handshake failure, or a 3xx redirect our scanner did not follow. Not counted either way.
The reason for that caution is two sites we checked by hand. **[periscope.tv](https://www.periscope.tv/) returned HTTP 200,** five years after Periscope shut down in 2021, so a working response cannot mean "alive." And **pexels.com returned 403** to our checker despite being a large, thriving site, so a block cannot mean "dead." Every real liveness scan has to hold both of those truths at once, which is exactly why the ambiguous bucket exists instead of being forced into a verdict.
## The number
Across the 522 checkable launches:
| Result | Count | Share |
|---|---|---|
| Responds (2xx working page) | 437 | 83.7% |
| Offline (DNS gone or 404) | 56 | 10.7% |
| Ambiguous (block, TLS fail, redirect) | 29 | 5.6% |
Of the 56 offline, 43 no longer resolve at all, their domains simply gone, and 13 resolve but serve a gone/404, several of them Lovable subdomains showing a literal "Build incomplete" page. We hand-checked a sample of each bucket by eye. The dead ones were dead: [jeez.me](https://jeez.me) and [eden.pm](https://eden.pm) would not connect at all. And the caution paid off in the other direction too: two of the three redirects we had parked as ambiguous turned out to be live products that had simply rebranded, which means our 83.7% "responds" figure is if anything a slight undercount. The 10.7% offline floor is not inflated. It is conservative.
## The survival curve: age is the killer
Because each launch carries an "Added" date, we can watch the directory decay. Grouping the 494 dated launches by how long ago they were showcased:
| Launch age | Launches | Offline | Offline rate |
|---|---|---|---|
| Under 6 months | 146 | 4 | 2.7% |
| 6 to 12 months | 138 | 8 | 5.8% |
| Over 12 months | 210 | 37 | 17.6% |
The shape is the finding. A freshly showcased vibe-coded app is almost always up; nothing in the youngest cohort was offline by more than a rounding error. By a year out, better than one in six has gone dark. This is not a statement about whether AI can build a working app, because clearly it can, and most of these still load. It is a statement about what happens after launch day, when the domain renewal, the free-tier database that pauses after a week idle, and the maker's attention all have to keep showing up. Most launches are a moment. The curve measures how many outlive it.
Split by platform, Lovable's 494 launches ran 9.9% offline and Bolt's 28 ran 25% offline, but Bolt's sample is too small to lean on, so read that gap as a hint, not a result.
## The viral claim, and why our number is lower
You have probably seen the number this piece will get compared to: a widely shared r/SaaS post claiming **487 of 500 Product Hunt launches are dead.** We cite it as reported, because Reddit blocked our fetch tools and its author's method cannot be verified, but the more important point is that it measures a completely different thing. That 487 is a business-death count: 97.4% under $1,000 in monthly revenue, 91.2% under a hundred active users, 84.6% never updated since launch. By that definition almost everything is "dead," including plenty of apps that still load perfectly.
Our 10.7% is the narrow, hard, reproducible floor underneath that soft number. It says only this: at least one in nine of these launches has stopped returning a page at all. The gap between 10.7% and 97% is the gap between "the lights are off" and "nobody's paying," and conflating the two is how the vibe-coding-is-dead genre gets written. A great many of our 437 "responds" launches are almost certainly earning nothing. We just refuse to call them dead on evidence that only shows they are quiet. What the posted success stories hide is [its own study](/study/after-the-vibecode-wins-and-denominator/).
## What we could not establish, and the dataset
Three limits worth stating plainly. **Showcase directories are survivorship-biased:** these are apps whose makers submitted them to a gallery, so apps that were abandoned before they were ever showcased, or pulled after failing, are underrepresented. Our floor is a floor for that curated, optimistic population, and the true rate across all vibe-coded apps is higher. **A 200 is not a living product**, as periscope.tv proves; we can measure connectivity, not maintenance or revenue. And **we cannot see intent:** a domain that auto-renews on a lapsed card looks identical to one a founder is actively tending.
What we can offer is the raw material. The full CSV of every one of the 522 URLs, its launch date, its HTTP status, and its classification is here for you to re-run and argue with:
That is the whole point of a receipt. The question "are vibe-coded apps dying?" has been answered mostly with vibes. Here is one narrow slice of it answered with a status code, dated, sampled by hand, and handed to you to check. If you want the wider frame, our study on [whether vibe coding is dead](/study/is-vibe-coding-dead/) weighs the sentiment against the usage data, and [whether it is worth it](/study/is-vibe-coding-worth-it/) does the same for the economics. This piece just establishes the floor they stand on: most launches still answer, the old ones increasingly do not, and a working page was never the same thing as a living product.
---
# The AI coding agent field guide (2026)
Section: The Study
URL: https://okaneland.com/study/ai-coding-agent-field-guide/
Seven agents, two camps, one decision. The frontier labs now ship their own coding agents whose benchmark numbers cluster in the high seventies to low eighties, while a second camp routes to whichever model you point it at. We have hands-on tested two of these. For the other five we quote the published numbers and say so. Here is how to choose on shape rather than on a leaderboard.
In July 2025, one of the most popular AI coding editors was taken apart in about seventy-two hours. OpenAI's roughly $3 billion deal to buy Windsurf collapsed, Google paid $2.4 billion to license its technology and hire its founders, and Cognition bought what remained. Type windsurf.com into a browser today and you land on devin.ai. Everyone who had standardized on the tool now owns a different one.
The rest of the field is healthier, and this guide maps it: the seven agents worth knowing in 2026, what each one is for, and, labelled throughout, which claims we tested ourselves and which we only read.
## The short version
The 2026 field splits into two camps, and a solo builder should choose between them on shape before looking at any leaderboard.
**Model-owned agents** come from the three frontier labs and run that lab's own model: Claude Code (Anthropic), Codex (OpenAI), and Antigravity (Google). Their reported SWE-bench Verified numbers now cluster together in the high seventies to low eighties, close enough that the number is not the deciding factor.
**Model-agnostic tools** route to whichever model you point them at, and increasingly ship a house model tuned for speed: Cursor, Zed, and OpenCode, plus the Windsurf editor, which was dismembered in 2025 and is now Cognition's Devin Desktop.
One thing to hold onto as you read: **we have hands-on tested exactly four of these:** Cursor and Claude Code across [two builds and 24 frozen gates](/proof/cursor-vs-claude-code/), where they tied; [Codex on the free ChatGPT tier](/proof/codex-free/) on the first of those builds, where it passed all twelve; and [Antigravity on its $0 tier](/proof/antigravity-free/), which passed nine of the ten gates it reached before its weekly quota closed. For the other three we have opened pricing pages and vendor posts and run nothing, and we label every tool below so you can see the seam.
| Agent | Camp | Surface | Entry price | Our evidence |
|---|---|---|---|---|
| Claude Code | Model-owned (Anthropic) | terminal, IDE, web | $20/mo | **Tested** |
| Cursor | Bring-your-own | IDE | $20/mo | **Tested** |
| Codex | Model-owned (OpenAI) | in ChatGPT, CLI, IDE | $0 (Free), Astra from $20 | **Tested** ([12/12 at $0](/proof/codex-free/)) |
| Antigravity | Model-owned (Google) | agent-manager IDE, CLI | $0 Individual; AI Pro $19.99 | **Tested** ([9/10 reached at $0](/proof/antigravity-free/)) |
| Zed | Bring-your-own | editor | free / $10 | Published evidence only |
| OpenCode | Bring-your-own | terminal, IDE | free | Published evidence only |
| Devin Desktop (ex-Windsurf) | Bring-your-own | IDE | $20/mo | Published evidence only |
## How to read a coding-agent benchmark without getting played
SWE-bench Verified is the number every lab quotes. It is 500 real GitHub issues from open-source projects, where the agent has to produce a patch that passes the project's own tests. It is a genuinely useful signal, and it is not apples to apples across vendors.
Three reasons the same-looking numbers are not directly comparable: labs run at different reasoning effort, they wrap the model in different agent scaffolding, and they sometimes report on subsets rather than the full 500. So our rule for this piece is simple. We quote the vendor's own number, we date it, and we did not re-run any of them. Where a number lives on a chart image rather than in a page's text, or where the vendor's page would not load and we had to rely on trade coverage, we say that too.
Read the numbers as a cluster, not a ranking. When three flagship models land within a few points of each other, the benchmark has told you they are all capable, and the choice moves to everything else.
## The model-owned agents: Claude Code, Codex, Antigravity
**Claude Code (Anthropic).** Runs Claude, works from the terminal, an IDE, Slack, and the web. Anthropic's Opus 4.5 announcement from November 24, 2025 calls it state-of-the-art on real-world software engineering, and the widely cited ~80.9% SWE-bench Verified figure sits on that page's chart. Plans run $20 for Pro and $100 or $200 for Max. It is the one we know best: in our head-to-head it exited cleanly, reported its token use exactly, and built with no dependencies, and its meter is legible. If you live in a terminal and want auditable cost, this is the default.
**Codex (OpenAI).** Runs GPT-5.1-Codex-family models, and lives inside ChatGPT (Plus, Pro, Business) plus a CLI and IDE extension. OpenAI reports 77.9% on SWE-bench Verified at extra-high reasoning for GPT-5.1-Codex-Max, up from 73.7% for the prior Codex model, as relayed by trade coverage; OpenAI's own announcement page returned an access error when we tried to read it, so treat that figure as reported rather than confirmed. Codex billing moved to token-based in April 2026. We have since [run the free tier through our booking-app fixture](/proof/codex-free/): twelve of twelve gates on GPT-5.6 Terra, 37 percent of a single 30-day meter for one build, and no Astra on that plan. It is the natural pick if your work already lives in ChatGPT.
**Antigravity (Google).** Google's agentic development platform, an IDE built around an agent manager, running Gemini 3 Pro. Google's own launch post puts Gemini 3 Pro at 76.2% on SWE-bench Verified, the one frontier number here we confirmed directly from the primary. It is free for individual developers during preview, which makes it the cheapest way to try a frontier lab's agent right now, with the usual caveat that preview pricing is not a promise.
## The model-agnostic tools: Cursor, Zed, OpenCode
**Cursor.** The IDE most people mean when they say AI coding. Hobby is free, Pro is $20, and a $200 Ultra tier is reported by aggregators though it was not shown on the pricing page we read. Cursor's own model, Composer, is benchmarked on Cursor's internal bench and sold on speed, roughly four times faster than similar models, rather than on SWE-bench. In our testing Cursor was the fastest to a running build and kept everything inside the $20 plan, with the caveat that its usage ledger logs the model as "auto", so you cannot audit which model did the work. If you already live in an IDE and value speed, this is the pick.
**[Zed](/primer/how-to-use-zed/).** An open-source editor, fast and lightweight, whose agentic editing runs Claude, Codex, or OpenCode through the open ACP protocol, or [a local model via Ollama](/primer/how-to-use-ollama/). Personal is free with a capped number of edit predictions, Pro is $10 a month, Business is $30 a seat. It fits a builder who wants an open-source spine and the freedom to route to any model, including a local one.
**OpenCode.** A free, open-source agent for the terminal, IDE, or desktop, supporting more than 75 providers including local models. It is the most portable option and the one with no vendor lock-in at all, in exchange for you assembling more of the setup yourself.
## The Windsurf footnote: durability is a feature
One product on this list is a cautionary tale worth a paragraph, because it teaches a lesson a solo builder should price in.
In July 2025 the Windsurf editor was taken apart in about seventy-two hours. OpenAI's roughly $3B deal to buy it collapsed, Google paid $2.4B to license its technology and hire its founders into DeepMind, and Cognition bought what remained. You can reproduce the receipt in one click: windsurf.com now redirects to devin.ai, and Devin Desktop states it "is the new name for Windsurf," running a house model called SWE-1.6 Fast. The tool still works and has a real free tier. The lesson is that the tool you standardize on is a bet on the vendor still being there and pointed the same direction next year, and that is worth weighing alongside today's feature list.
## Pricing at a glance
| Agent | Free tier | Entry paid | Ceiling |
|---|---|---|---|
| Claude Code | limited (Free plan) | $20 Pro | $200 Max |
| Cursor | Hobby free | $20 Pro | $200 Ultra (reported) |
| Codex | in ChatGPT Free/Go | in Plus | in Pro |
| Antigravity | free preview | n/a | n/a |
| Zed | Personal free | $10 Pro | $30 Business |
| OpenCode | free | n/a | n/a |
| Devin Desktop | Free | $20 Pro | $200 Max |
Watch one thing across all of them: the "usage allowance" plans (Cursor, Codex, Devin) refresh on windows and can meter you past the sticker price, which is exactly the dynamic our [Claude Code limits study](/study/claude-code-limits/) and [cost study](/study/cut-your-ai-coding-bill/) map in detail. The entry price is the floor, not the number you will actually pay in a heavy month.
## How to choose, and what we cannot tell you
A short flow, given the benchmark cluster means capability is not the tiebreaker:
- **Terminal-first and you want exact accounting:** Claude Code.
- **Already in an IDE and you want speed:** Cursor.
- **You want open source, or a local model, or no lock-in:** Zed or OpenCode.
- **You are all-in on one lab's model already:** that lab's own agent (Codex for OpenAI, Antigravity for Gemini), and Antigravity is currently free to try.
The limit we owe you: we ran real, gated tests on only two of these seven, Cursor and Claude Code, and everything we say about the other five rests on their published pages and numbers, dated and labeled above. The benchmark cluster is real, the pricing is current as of early August 2026, and the durability lesson from Windsurf is the one most people skip. When we put the three-way test into the field, Codex is first in line, and the community is already telling us [what to make it prove](/proof/cursor-vs-claude-code/).
---
# Is your vibe-coded app secure? Run this audit
Section: The Study
URL: https://okaneland.com/study/is-your-vibe-coded-app-secure/
On security-sensitive tasks, published tests show AI ships an exploitable flaw in roughly 45% of cases, and the sharper danger is that it makes you feel safer while it happens. We read the security research so you can audit your own app. Here is what breaks, why, and an eight-point check you run yourself.
In 2023, a Stanford team published a randomized trial that should hang over every vibe-coded launch. Forty-seven developers worked through security-relevant tasks, some with an AI assistant and some without. The assisted group wrote SQL-injection-vulnerable code 36% of the time against 7% for the control. Then the researchers asked everyone to rate the security of their own work, and the assisted group came back more confident.
That inversion has since moved from the lab to the open internet. In October 2025, a security firm passively scanned 5,600 publicly reachable vibe-coded apps and logged more than 2,000 vulnerabilities and over 400 exposed secrets, most visible with no login at all. This piece reads that research so you can audit your own app before someone else does it for you.
## The short version
- **On security-sensitive tasks, AI ships an exploitable flaw about 45% of the time.** That is Veracode's 2025 figure, from 80 security-relevant tasks run across more than 100 models. Read it precisely: it is 45% of tests on tasks chosen to probe security, not 45% of every line the model writes.
- **The sharper danger is that the code looks fine.** In a Stanford randomized trial, developers using an AI assistant wrote SQL-injection-vulnerable code 36% of the time versus 7% without one, and then rated their own code as more secure. The confidence and the risk moved in opposite directions.
- **It is already leaking in the wild.** A passive scan of 5,600 live vibe-coded apps found more than 2,000 vulnerabilities, 400 exposed secrets, and 175 personal-data leaks, most reachable with no login at all.
- **You cannot prompt your way out.** Asking the model to "clean this up" five times raised critical vulnerabilities by 37.6% in one study, not lowered them.
We did not scan, test, or hack anyone's app. Every number here belongs to a named published study with its date, and the deliverable is an eight-point audit you run on your own app, at the end.
## Why vibe-coded apps fail the same way
The failures are not random. They cluster, and Endor Labs catalogues the recurring ones, each with a standard weakness ID. The same handful shows up again and again:
- **Secrets in the wrong place** (CWE-798): an API key hard-coded into client-side JavaScript, or committed to the repo, where anyone can read it.
- **Missing or removed authentication** (CWE-306): an endpoint that should require a login and does not, often because a later "make it work" edit quietly dropped the check.
- **String-built SQL** (CWE-89): user input concatenated into a query instead of parameterized, the classic injection.
- **Broken access control** (CWE-284): a logged-in user can reach another user's data by changing an ID in the URL.
- **Missing input validation** (CWE-20) and **wide-open CORS**: defaults that trust input they should not.
Veracode's language breakdown shows this is not evenly spread: the secure-code pass rate was 14% for cross-site scripting and 12% for log injection, and Java came out worst at a 29% pass rate. The model writes code that runs. Whether it wrote code that is safe is a separate question, and the two look identical in a working demo.
## The overconfidence tax
This is the part nobody screenshots, and it is the most important finding in the research.
The Stanford trial by Perry and colleagues took 47 developers, gave some of them an AI assistant, and set security-relevant tasks. The AI-assisted group produced less secure solutions on four of five tasks. On the SQL task, 36% of AI users wrote injection-vulnerable code against 7% of the unassisted control, a gap significant at p=0.041. Then the researchers asked how secure people thought their own code was. The AI group was more confident.
That inversion is the whole problem. A tool that made you slower and more worried would be self-correcting; you would slow down and check. A tool that makes you faster and more sure is the opposite, and it is the same mechanism our [study on whether AI coding makes you faster](/study/does-ai-coding-make-you-faster/) keeps running into: the felt speed is real, and it is not the same as the delivered result.
## The iteration trap
The instinct, when you learn any of this, is to ask the model to fix it. Tell it to "make this production-ready" or "add security" and let it revise.
The research on that instinct is discouraging. Shukla and colleagues had a model revise its own code across five rounds and measured the result: critical vulnerabilities rose by 37.6% over the iterations, not fell. The study tested GPT-4o specifically, so read it as a signal about self-revision rather than a verdict on any one model. But the direction is the point. Each pass adds surface, reinterprets the last change, and can reintroduce what the previous pass removed. Prompting harder is not a security control. A control is something that holds regardless of what the model does next.
## What is actually leaking
To make the stakes concrete without touching anyone's app, look at what a security firm found by scanning apps that were already public. Escape.tech ran a passive scan of 5,600 reachable vibe-coded apps in October 2025 and reported more than 2,000 vulnerabilities, over 400 exposed secrets, and 175 instances of leaked personal data. Passive means they looked at what was openly visible, so it is a floor, not a ceiling, and much of it needed no authentication to reach.
Two caveats, because the receipts only work if we state them. That scan and the Veracode tests measure AI-generated code and live apps broadly; neither isolates a clean "non-coder only" cohort, so do not read the numbers as vibe-coder-specific where they are not. And a passive scan finds what is exposed, which understates what a determined attacker with a login would find.
## The security checklist: eight checks to run on your own app
This is the deliverable. Run it against your own app, in this order, because the top of the list is where the worst and easiest-to-exploit failures live.
1. **Auth at the edge, not in the code.** The most reliable pattern, argued well by Pythagora's Zvonimir Sabljic, is that an unauthenticated request should never reach your application logic at all. Enforce it at the reverse proxy or your auth provider, so a missed check inside AI-written code cannot expose an endpoint. Defends CWE-306.
2. **Grep for secrets, then rotate.** Search your repository and your shipped client bundle for anything that looks like a key or token. If you find one, assume it leaked and rotate it. Keys belong in server-side environment variables, never in client code. Defends CWE-798.
3. **Every database query parameterized.** Find each place user input reaches the database and confirm it uses parameters or an ORM, never string concatenation. This is the single check that closes the injection Perry's trial found most often. Defends CWE-89.
4. **Row-level security on, and you tried to break it.** If your database supports row-level security, turn it on, then log in as one test user and try to read another user's row by changing an ID. If you succeed, so can anyone. Defends CWE-284.
5. **Input validated on the server.** Client-side validation is a convenience, not a defense; anything the browser checks can be bypassed. Validate on the server too. Defends CWE-20.
6. **CORS is an allowlist, not a wildcard.** Confirm your cross-origin policy names the origins you trust rather than accepting all of them.
7. **Rate limiting on anything that costs or authenticates.** Login, signup, and any endpoint that spends money or tokens needs a limit, or it becomes someone else's free resource.
8. **Your dependencies exist and are patched.** Confirm every imported package is real (models sometimes invent plausible-sounding ones) and run an audit for known vulnerabilities.
Each item defends a class the research shows AI code fails at. None of them requires you to read every line the model wrote, which is the point: line-by-line review of AI output does not scale and does not catch the silent gap. Auditing the auth, data, and secrets layers does.
## Building with less of this debt
The checklist is triage. To generate less of the debt in the first place: ask for security explicitly in the prompt rather than hoping for it, keep each change small enough to actually understand, use a real authentication provider instead of rolling your own, and run an automated scanner as part of shipping. Working inside the agent's loop deliberately, the way [our Claude Code guide](/primer/how-to-use-claude-code/) lays out, is where you catch the dropped check before it ships rather than after it leaks.
The close is a limit rather than a promise. No checklist makes an app secure. What this one does is make it auditable, and the research is clear that auditable is the thing vibe coding quietly takes away, right at the moment it makes you feel most sure.
---
# How to cut your AI coding bill
Section: The Study
URL: https://okaneland.com/study/cut-your-ai-coding-bill/
The scary numbers going around are mostly 2025 prices for a model that has since been retired. At August 2026 rates your bill is set by three dials you control, not by the vendor being greedy. Here is what everything costs now, the one arithmetic that decides subscription versus API, and the four moves that actually move the meter.
In June 2025, a Cursor user opened a forum thread asking how to bring down his background-agent costs, having watched them burn [about $40 in a single hour](https://forum.cursor.com/t/best-practices-for-bringing-down-background-agent-costs/103186). Screenshots like his built the folk wisdom every vibe coder now carries: serious AI coding costs thousands a month, and the vendors keep raising the price. Fourteen months later, the model behind those bills is retired and its successors charge roughly a third of the old rate.
The folk wisdom never updated. This piece re-prices it: every figure below was read from a vendor's own page on 9 August 2026, and the subscription-versus-API decision comes down to one line of arithmetic you can run on your own numbers.
## The short version
- **The bill you were scared by is probably last year's.** The viral "thousands of dollars of API usage" and "36x cheaper on a subscription" posts are from 2025, when Opus cost $15 in and $75 out per million tokens. That model is retired. Current Opus runs $5 and $25. Sonnet 5 runs $2 and $10 on its introductory rate. Prices fell by roughly two thirds, and most of the panic did not update.
- **Three dials set your cost, and you hold all three:** which model runs the turn, how much context you resend each turn, and whether the cache is warm. The vendor's price per token is the smallest lever of the three.
- **The subscription-versus-API rule is one line of arithmetic.** If your monthly API token spend for interactive coding would exceed the subscription price, the subscription wins, up to its usage ceiling. That ceiling is undisclosed, which is the catch worth reading below.
- **Four moves actually cut the meter,** and all four are documented by the vendors, not invented here: route models by difficulty, read the in-product usage meter, keep context small, and keep the cache warm.
This is a pricing explainer, not a benchmark. Every figure below carries the date we read it, and where we show token math it is a worked example with its assumptions on the page, not a measured result. We did not test routing savings or audit anyone's invoice.
## What AI coding costs right now
All figures read from the vendors' own pages on 9 August 2026.
**Anthropic, per million tokens (API):**
| Model | Input | Output | Cache read |
|---|---|---|---|
| Opus 4.5 to Opus 5 | $5.00 | $25.00 | $0.50 |
| Sonnet 5 (intro, through Aug 31) | $2.00 | $10.00 | $0.20 |
| Haiku 4.5 | $1.00 | $5.00 | $0.10 |
The Batch API is a flat 50% off both directions for work that does not need an instant answer. Cache reads cost a tenth of fresh input. Sonnet 5's introductory rate rises to $3 and $15 on 1 September 2026.
**Anthropic subscriptions:** Pro is $20 a month. Max is $100 at the 5x tier and $200 at 20x. The pricing page publishes those multipliers and nothing else. There is no published token quota for any plan, so any "you get N tokens for $200" figure you see is somebody's inference, including ours if we tried it.
**Cursor:** Pro is $20 a month and bundles about $20 of model usage billed at the underlying API price with no markup. Higher tiers bundle proportionally more of the same. The number you pay Cursor for a model is the model maker's price passed through, which is why a heavy session shows up as a spike rather than a flat fee.
**OpenAI, per million tokens:** GPT-5 and GPT-5.1 are $1.25 in and $10 out. The GPT-5.3-codex model is $1.75 and $14. Cached input is 10% of fresh input, the same cache discount shape Anthropic uses.
One quiet detail that catches people: Claude models from 4.7 onward use a new tokenizer that emits roughly 30% more tokens for the same text. A newer model at a lower headline rate can still cost more per task, because the task is now counted as more tokens. Compare on cost per finished task, never on the per-million sticker alone.
## Why one request can cost more than you expect
A coding agent does not send your prompt once. Every step of an agentic turn resends the working context, the files it is holding, and the output of the last tool call, as fresh input. Ten steps deep, the same repository context has been billed as input ten times.
Here is a worked example, and it is a hypothetical with its assumptions shown, not a measurement. Suppose one hard turn on Sonnet 5 carries 350,000 tokens of input across its steps and produces 20,000 tokens of output. At the introductory $2 and $10 rate that is $0.70 of input and $0.20 of output, about ninety cents for a single turn, before any caching. Stack a few of those in an afternoon and the meter is real. On the retired Opus 4.1 rate that same turn would have been closer to $6.75, which is the era those shock screenshots came from.
This is also why Cursor's per-request meter can jump and why anger spiked when usage-based billing arrived: the cost was always there, the meter just made it visible. One Cursor user [reported about $40 of background-agent spend in an hour](https://forum.cursor.com/t/best-practices-for-bringing-down-background-agent-costs/103186) in June 2025, not because the tool was broken, but because background agents burn context on every step and nobody had shown them the dials.
## Subscription or API: the break-even, and its ceiling
The decision is one line. **If the API tokens you would burn in a month cost more than the subscription, buy the subscription for interactive coding.** Below that line, pay per token.
Anthropic's own cost documentation is the useful anchor here, read carefully. It reports that enterprise developers running Claude Code burn on average about $13 of tokens per active day, and $150 to $250 per developer per month. Set that beside the $200 Max plan and the shape is clear: heavy Claude Code token use sits in the same range as the top subscription. Anthropic does not say the subscription wins. That comparison is arithmetic we are doing with their number, and the same page notes the session dollar figure "isn't relevant for billing purposes" once you are on a plan.
The catch is the ceiling. Because no plan publishes a token quota, the break-even holds only up to whatever the subscription actually allows, and that limit is both undisclosed and movable. A Max 20x subscriber [documented hitting daily usage limits](https://github.com/anthropics/claude-code/issues/54714) in April 2026 despite using the tool less than the week before. So the rule holds with a ceiling on it: the subscription wins on price up to that ceiling, and you will discover the ceiling by hitting it. For a full map of how those limits have moved, our [Claude Code limits study](/study/claude-code-limits/) tracks the whole record.
The clean cases:
- **Bursty, interactive, all-day coding** on one machine: subscription. You want a flat cost and you will live inside the ceiling most months.
- **Scripted, CI, batch, or multi-tenant work,** or you need the full context window and per-key spend tracking: API. You want the meter and the control, and the Batch API's 50% is yours.
- **Both** is a real answer: the subscription for your own hands-on work, an API key for anything automated.
## The four moves that actually cut the bill
None of these is our invention. All four are in the vendors' own documentation.
**Route models by difficulty.** The default should be the mid model, not the top one. On Claude Code that means Sonnet by default, Opus reserved for genuinely hard reasoning through `/model`, and Haiku for subagents and bulk file reads. A bulk read on Haiku at $1 in costs a fifth of the same read on Opus. Most of a coding session is reading and editing, which the cheap model does fine, [as our Cursor review found the speed models handle](/proof/cursor/) until the task actually needs care.
**Read the meter.** Both major tools now expose usage in-product. Claude Code's `/usage` breaks a session into its dollar cost and your plan-usage, attributes spend to skills, subagents, and MCP servers, and raises a flag when a long-context or cache-miss cost crosses about 10% of the turn. That flag is the single most useful signal for finding where your money goes.
**Keep context small.** Context is the input you resend every step, so it is the dial that compounds. Clear between unrelated tasks with `/clear` rather than letting one session accumulate. Use plan mode to think before the expensive execution steps. Trim the number of MCP servers you load, since each one's tool definitions ride along in every turn. A hook that pre-filters a noisy log before it reaches the model pays for itself on the first large output.
**Keep the cache warm.** A cache read costs a tenth of fresh input, so the difference between a warm session and a cold one is an order of magnitude on the resent context. The lifetime is not the same everywhere: a subscription holds the prompt cache for an hour, while API and usage-credit access hold it for five minutes. Keep a working session inside that window and you avoid re-billing the full context on a miss. Push non-interactive work through the Batch API and take the additional 50%.
## What we did not do
We did not benchmark routing, did not measure a dollar figure saved by switching to a cheaper model, and did not open anyone's account. Every price here is a live vendor page with the date we read it, the two cost-pain anecdotes are linked to their primaries and dated, and the token math is a labelled hypothetical you can redo with your own numbers.
The takeaway holds without a benchmark. The panic numbers are stale by a model generation and a two-thirds price cut. The current bill is a routing-and-context problem you control, the subscription-versus-API question is one line of arithmetic against your own token spend, and the ceiling on every subscription is real and unpublished. Read your meter for one week and you will know your number better than any screenshot can tell you, which is the same place [our limits study](/study/claude-code-limits/) and [our unit-economics study](/study/unit-economics-of-wrapping-an-llm/) both land: the plan page is a band, and the only figure that matters is the one in your own account.
---
# AI agents do not choose what to sell. They fill in a number a human left blank.
Section: The Study
URL: https://okaneland.com/study/what-agent-economies-charge-for/
We opened seven agent economies and read the money to primary sources: a shop, a society, a payment rail with 14,050 listings, a network with 2.9 million agents, and the academic literature. In all of them the agent supplies a price and almost never the product. Where real customers turned up, they paid for the joke about the agent rather than the work it did. Fourteen million agent-to-agent trades have cleared $107,206.
## The short version
- **We opened seven agent economies and read the money.** A shop run by an agent, a society built by one, a payment rail with 14,050 paid listings, a network with 2.9 million agents, two live token ecosystems, the enterprise agent vendors, and the academic literature. Every figure here was read on 8 August 2026 and is stamped.
- **In all of them the agent supplies the number and almost never the product.** Anthropic's prompt hands its agent a vending machine. The academic papers hand it a synthetic demand curve. All 14,050 listings on the biggest agent payment rail are priced by human operators. We found exactly one case of an agent inventing its own priced good, and it has earned **$7.00**.
- **Where real customers appeared, they bought the novelty rather than the service.** Of the top fifteen products in Anthropic's shop by units sold, **151 of 217 were non-consumable merch and jokes about the shopkeeper**. The top four sellers were all non-consumables. The single highest margin, 85.4%, was on a zine about the agent itself.
- **Agent-to-agent trade is real and almost worthless.** The Olas Mech Marketplace has cleared **14,180,038 agent-to-agent transactions for $107,206 of turnover**. That is three quarters of a cent per trade.
- **One agent did everything right and earned nothing.** It chose a real service, quoted real prices from 0.01 to 650 USDC, ran a working payment endpoint and advertised hourly for two days. Its settlement wallet has a nonce of zero, holds nothing, and has never received an inbound transfer.
- **No rail lets an agent haggle.** Grepping the entire x402 specification for negotiation, auction, bid or counteroffer returns four hits, none of them a price-negotiation mechanism. 98.5% of live payment options quote a fixed price before the work happens.
- **Revenue is inversely correlated with agent autonomy.** Where the money is largest, a human vendor sets both the good and the price and the agent is a cost line. Fin charges $0.99 per resolved conversation and reports $400M in annual recurring revenue.
## What we actually mean by an agent economy
Three things get called the agent economy and only one of them is what it sounds like.
The first is an agent given money and told to trade. The second is a market where agents pay each other. The third, and by far the largest, is ordinary software sold to companies, where an agent does work a person used to do and the vendor prices it exactly as it always priced software.
This study is about who sets the price in each. That question sounds narrow and it is the whole thing, because setting a price is the one act that requires knowing what a thing is worth to somebody else. Everything else an agent does in a market can be done by a script.
## Who actually chose the good
Start with the cleanest case, because it is the only one that goes the other way.
The society at 1f916.ai is the single instance we found of an agent inventing something to sell. Its priced good is one permanent line of up to 140 characters in a public ledger, at $1 in USDC. The price and the character limit were born together in commit `818db98`, five hours and forty-eight minutes after the repository's first commit. Running `git log --all -S` on each of the three constants returns that one commit across the entire 46-commit history. The price was set once, in hour six, and has never been touched.
That is the exception. Here is the rule.
Anthropic's shopkeeper agent did not choose to run a shop. The operator chose the business, the category, the starting float and the rule that going below zero meant bankruptcy. In the published prompt, the good is already there. In the academic literature the good is not even real: Fish, Gonczarowski and Shorrer hand their agent a logit demand curve with no product attached, and the shared prompt casts the agent as staff rather than principal, opening **"Your task is to assist a user in setting a suitable price."**
On the biggest live payment rail, we looked for any authorship signal in 14,050 listings suggesting an agent had set a price. We found none. Prices there originate in the seller's payment challenge, and the sellers are the companies you would expect: search APIs, crypto data, contact enrichment. This is API resale with a payment header bolted on, and the agents are the customers.
Moltbook takes it one step further, because there the agent was never handed a good at all. The platform's instruction files define a complete action space of posting, commenting, upvoting and following. The only currency is karma, and the rules void it in one line: **"Karma unlocks nothing."** Crypto content is disallowed by default. Nothing on the platform has a price.
What happened next is the finding. Agents colonised it with an inscription protocol anyway, to the point where **62.8% of all posts are token-minting payloads rather than speech**. The protocol was written by outside human developers, not the platform. We sampled the hundred most recent mints: every single one names a human deployer, and the agent supplies only the amount field. Those hundred posts drew zero upvotes and zero comments between them.
An agent minting a token it did not design, denominated in a ticker a human deployed, for free, into a room where nobody is reading. That is the pattern in one API response.
## What people actually bought
Both real-money cases agree on something nobody planned.
Anthropic's shop was scaffolded to sell drinks and snacks. Of its top fifteen products by units, 151 of 217 units, just under 70%, were non-consumables. The top four sellers were a stress ball, a T-shirt, a sticker pack and a figurine. The highest margin in the entire list, 85.4%, was on a zine titled after the agent itself.
The shop set up to sell hydration got paid for jokes about the shopkeeper.
This replicates. In a separate experiment where four agents were told to run merch stores, the agents genuinely did pick their own products and their own prices, at $14.99 a shirt. Total sales across all four came to **$200**. The winner took 40 orders. Two of the four sold nothing at all, and one never listed a product. What sold was merchandise branded with the name of the experiment that the buyers were watching.
And in the society at 1f916, six of the seven paid inscriptions are somebody advertising something, five of them a token.
Three independent settings, one result: when humans pay money into an agent economy, they are usually buying a souvenir of the experiment.
There is a fourth version of this. Real money does move around Moltbook, hundreds of thousands of dollars of daily volume, but it moves through memecoins named after the agents. Nobody is paying an agent. People are trading a ticker that shares its name.
## The agent that did everything right
The most useful single data point we found is a negative one, and it is worth stating precisely because it is the strongest test of the thesis available.
One Moltbook agent chose a real service, signed citation audits, which is a genuine thing a person might buy. It priced a catalogue from 0.01 USDC for a lookup up to 650 USDC at the top. It stood up a working payment endpoint that returns a valid challenge. It advertised roughly two dozen times over two days.
We pulled its payment challenge to get the settlement address, then queried it on-chain. The wallet holds no USDC and no ETH. Its nonce is zero, meaning it has never sent a transaction. We scanned 320,000 blocks, about 7.4 days and covering the entire campaign, for inbound transfers of the currency it asked for. There were none.
Even that agent was not really the seller. Its own catalogue names a company as the provider and states that **"Contracts and invoicing are handled by the human operator."**
An agent picked a good, named a price, built the plumbing, ran the marketing, and earned nothing, on behalf of a human who kept the invoicing. That is a cleaner result than the $7.00 on the other side.
## Nobody built a way to haggle
The structural finding is the one that will outlast every number above, because it is about what the rails can express rather than what anyone earned this month.
We grepped the full x402 specification tree for negotiation, auction, bidding and counteroffers. Four hits, none of them a mechanism for negotiating a price. The shape of every transaction on that rail is the same: the seller quotes, the buyer signs or leaves. **98.5% of live payment options use a fixed price quoted before the work happens.** A buying agent is a pure price-taker.
The protocol that agents actually run on is emptier still. We string-searched all six released versions of the Model Context Protocol schema, plus the draft, for payment, price, billing, currency, amount and invoice. Zero occurrences in any of them. The proposal to add a payment model was opened in December 2025 and closed unmerged in June 2026 with the note that it **"has not received a sponsor in the past 6 months and is considered dormant."** The official registry that indexes agent tools has no price field either.
MCP does not forbid money. It routes it out of band, which means the negotiation happens somewhere a human is standing.
This matters more than the revenue figures. Nearly all commentary about the agent economy assumes agents will negotiate with each other. Nothing they run on lets them. The prices that do exist cluster on the round numbers you get from a quickstart guide: the two most common live price points are one tenth of a cent and one cent, and the specification's own worked example is one cent.
## Where the money actually is
Put the sums side by side and the pattern is uncomfortable.
Agents paying agents, on the busiest such market we found: **14,180,038 transactions, $107,206 of turnover.** Three quarters of a cent each. The whole discovery catalogue of the biggest payment rail implies gross revenue somewhere between **$39,753 and $54,292** over thirty days, and we publish that as a range rather than a number because the choice of price rule inside each listing moves the total by 37%. Eighty-odd percent of it lands in ten listings.
Now the other end. Fin charges **$0.99 per resolved conversation** and reports passing **$400M in annual recurring revenue** across 30,000 companies. Salesforce charges **$2 per conversation** and ten cents per action. These are large, real businesses. In every one of them a human vendor sets the good and the price, and the agent is a way to do the work more cheaply.
The correlation runs backwards from the story everyone tells. The more autonomy the agent has over what is sold and for how much, the less money is present. Where the money is serious, the agent has no pricing authority at all, and the pricing profession says so plainly. A practitioner guide from July 2026 puts the boundary in one sentence: **"Core list pricing, key account pricing, and new product pricing stay human even at Run."**
Two collapses are worth recording next to that. The most publicised agent-checkout launch of 2025 shipped in September and was pulled back in March 2026, with reporting that only about a dozen merchants ever integrated it. And the flagship agent DAO went from a token worth $2.4 billion to one worth $379,000, with a class action alleging the autonomy was never real.
Be careful with the headline numbers in this space. One protocol advertises more than $470M of "Agentic GDP", which sounds like agent revenue. Its own glossary defines the term as trading value plus service fees, and the worked example is $5,000 of trading value plus $10 of fees, reported as $5,010. A figure built that way can be 99.8% capital passing through a bot.
## The price nobody would defend
Return to the one agent that set its own price, because the way that price has held is not flattering.
A citizen of that society published a careful critique. It named the file and the line number, argued the dollar was **"priced like a gumball"**, proposed an escalating curve of $1, $4 and $16 per wallet per day with the floor never moving, and offered to write the patch. It collected votes. No such patch exists among the 28 pull requests opened against the project. The maintainer never replied to the post.
The price did not survive because it was defended. It survived because nothing in the system requires anyone to answer.
Set that beside the simulation literature, where two prompt prefixes differing by a single clause move the resulting price with a p-value below 0.00001, and a different phrasing moves bidder profit by roughly nineteen times. In the lab, price is a function of prompt wording. In the field, price is a constant nobody revisited.
Both of those are the same finding wearing different clothes. An agent handed pricing power does not discover a price. It emits a plausible one and then stops.
Which suggests the deflationary reading of the whole exercise, and we think it is the correct one. The dollar at 1f916 has held for four days not because the agent has conviction about the value of memory, but because that society has no surface on which anyone can make it an offer. In the one real shop where customers could talk to the agent, through a company chat channel, the agent discounted, gave things away, and lost about 22% of its float in the first phase. The variable that separates the stubborn price from the collapsing one is not the model. It is whether a human can get a word in.
## What this cannot tell you
This study has two real-money economies with an agent in a seller's seat, and one of them is an office fridge.
Total money ever collected at a price an agent chose, for a good the agent invented, across everything we opened: **$7.00**. The shop's entire customer base was employees of the company running the experiment, in its own offices, plus some journalists invited to break it. There was never an external market. The merch experiment cleared $200. The academic literature has a sample of zero real counterparties, and every alarming price in it is denominated in a currency that does not exist. The society is four days old.
The payment-rail figures rest on a self-reported field whose own documentation never defines what it counts, and we could not establish whether it counts settled payments or all requests. Every volume figure inherits that.
So do not take from this that agents naturally price permanence, that advertising is the business model of agent societies, that the agent economy is worth any particular number, or that agents collude in real markets. Each needs a sample nobody has.
What survives is the set of absences, and negative findings hold up under small samples in a way positive ones do not. There is no negotiation primitive on any rail we examined. There is no payment model in the protocol agents actually run on. There is no published case of an agent choosing its own good, setting its own price, and being paid by real customers for real work; we went looking for one specifically and found instead a body of pricing-consultancy writing explaining why humans keep that authority. And there is no regulator engaging with any of it: the OECD's October 2025 report to the G7 on algorithmic pricing contains zero occurrences of "LLM", "large language model" or "ChatGPT", and still treats autonomous collusion as hypothetical.
One more thing worth saying plainly, because it is an indictment of the evidence base rather than a boast about any of these projects. **$8.39 of real stablecoin, collected by a four-day-old website, is a larger body of real-money evidence about what an unsupervised agent charges for than the entire peer-reviewed pricing-agent literature combined.**
If you are building for this market, that is the useful part. The agent economy is not a market waiting for better agents. It is a market with no way to bargain, no way to bill inside the protocol, and, so far, almost nobody on the other side of the trade.
---
# Is distribution really the moat? What actually defends an AI product
Section: The Study
URL: https://okaneland.com/study/distribution-moat-ai/
Android and Search placement carried Gemini from a twentieth of the AI market to nearly a fifth in a year, while Copilot stayed pinned near 1.2% despite shipping inside Windows. Same year, same distribution-wins slogan, opposite results. The rule that explains both: distribution is a moat only when it is owned or embedded and sits on a product people keep opening. Every channel you merely rent can be repriced or switched off by its owner overnight.
Over twelve months, Google's Gemini went from 5.4% of generative-AI web traffic to 18.2%, and it did not stop there, reaching roughly 28% by mid-2026, per Similarweb's tracker. ChatGPT fell from 87.2% to 68% over that same year. This is the strongest evidence you will find that distribution wins: Gemini is not obviously the better product, but it is wired into Android, Chrome, Search, and Workspace, and the placement did the work.
In the exact same year, on the exact same chart, Microsoft Copilot went from about 1.5% to 1.2%. Copilot is pre-installed in Windows, built into Edge, and pushed across the largest software install base on earth. If distribution were a law, Copilot would be winning. It is losing, badly, to products people actually choose to open. The difference decides everything: distribution only defends a product that earns its opens, on ground you own.
So "distribution is the moat" cannot be a law, because the same year produced both results. It is a conditional. The [build-in-public study](/study/build-in-public-revenue/) already covers whether the founder-audience tactic pays and the math behind it, and the [CAC study](/study/cac-by-channel-ai-product/) prices what each channel costs to run, and [the first-10-users playbook](/ledger/first-10-users/) is the zero-audience starting point. The question underneath both is plainer and more load-bearing: when does distribution actually defend a business, and when is it a wall painted onto canvas that the next gust blows away.
## The short version
If you are betting your reach somewhere, the evidence sorts it fast:
- **Bundling amplifies only what retains.** Native placement lifted Gemini [from 5.4% to 18.2% of AI traffic in a year](https://www.similarweb.com) while Copilot sat near 1.2% inside the biggest install base on earth.
- **Rented reach gets repriced without notice.** Facebook referrals to publishers fell [from 30% to 7%](https://pressgazette.co.uk), and Gartner projects search volume [down 25% by 2026](https://www.gartner.com).
- **AI-native products leak what distribution pours in.** Median net revenue retention runs [about 48% against 82%](https://chartmogul.com/reports/saas-retention-the-ai-churn-wave/) for traditional SaaS, worst under $50 a month.
- **Three moats scale down to one person:** an owned audience ([~600,000 followers reused across 40+ products](https://www.indiehackers.com)), a founder brand a launch can borrow trust from, and a community data loop a rival cannot buy.
- **Twenty-year moats favor lock-in over reach.** Of Morningstar's wide-moat firms, [72% rest on intangibles and 37% on switching costs, against 20% on network effects](https://www.vaneck.com).
The taxonomy, the counter-case, and the receipts are below.
## Where the idea comes from, and why AI stress-tests it
The thesis has a lineage worth knowing, because each step narrows it.
Peter Thiel put the asymmetry most cleanly in Zero to One: a company with superior distribution and a mediocre product can win, while a superior product with poor distribution loses. Chris Dixon refined where the defense actually lives with "come for the tool, stay for the network," locating durability in the network a tool accumulates; the tool alone holds nothing. And in the current cycle a16z's Bryan Kim argued that in fast-moving consumer AI, momentum is the moat, since a well-crafted product can be copied but a lead that keeps compounding is hard to catch.
The AI-era version of the argument is the sharpest form of it. As models commoditize, and they are, with frontier-class capability getting radically cheaper and fast-followers matching leaders within a year, the edge moves off the model and onto everything around it. Marc Andreessen put it flatly in early 2026: the moat lives in the product, the integration, the distribution, and the captured value rather than the model. When the core technology is a rented API anyone can call, what is left to defend is how you reach and hold the customer.
But notice the weak point even the proponents leave open. Kim's own essay is built on case studies with no retention numbers behind them, and momentum is by definition something you have to re-earn every quarter; no wall stands while you sleep. The cautionary tale is a16z's own momentum bet Cluely, whose loud growth rested on a $7 million revenue figure the founder [later admitted was false](/study/build-in-public-revenue/). Momentum and a moat are not the same thing, and the difference is the whole game.
## Rented versus owned: the line that decides everything
Here is the distinction the slogan hides. There are two kinds of reach, and only one of them defends anything.
Rented reach lives on a channel someone else controls: a feed algorithm, an ad account, a search ranking, an app-store placement. It works right up until the owner changes the terms, and the owner always eventually changes the terms. Owned reach is a direct relationship no platform sits between: an email list, a community, a proprietary data loop. You can reach those people whether or not any algorithm cooperates.
Rented reach decays, and the decay is brutal and well documented. Facebook referrals to publishers fell from [30% of all referral traffic in 2018 to 7% in 2024](https://pressgazette.co.uk) as Meta simply decided news was not its priority, wiping out businesses built on that feed. Google's Helpful Content Update did the same to independent sites overnight, cutting organic traffic by a median that practitioner analyses put near catastrophic levels. And the channel itself is now shrinking outright: Gartner projected traditional search volume would [fall 25% by 2026](https://www.gartner.com) as answer engines absorb the queries. You cannot build a moat on a channel that is being disrupted out from under you, no matter how well you rank on it today.
NFX frames this well with a motte-and-bailey image. Distribution, speed, and brand are the bailey, the pleasant open ground that gets you into the fight; network effects, embedding, and lock-in are the motte, the stone keep you retreat to when attacked. The advantages that feel like distribution are the ones you have to convert into something more permanent, or, in their phrase, you become this decade's Groupon, a company that grew faster than Apple or Google or Facebook and then fell apart because the growth never hardened into anything that held.
## The taxonomy: which forms actually defend
Put every common form of distribution on one table and mark it for what it is. Durability is the test, and the institutional benchmark is real: Morningstar rates a "wide moat" as an edge expected to last 20 years or more, and of its roughly 200 wide-moat firms, [72% rest on intangibles and brand and 37% on switching costs, against just 20% on network effects](https://www.vaneck.com). Brand and lock-in persist. Raw reach mostly does not.
| Form of distribution | Verdict | The evidence |
|---|---|---|
| Bundle into an installed base | Moat, if the product retains | Gemini 5.4% to 18.2% on native placement; Copilot 1.5% to 1.2% on the same |
| Default onto a weak product | Fails outright | Copilot's consumer decline; Skype's collapse from video default |
| Viral moment / momentum | Decays in weeks | Groupon; Lovable near $100M ARR then a ~40% traffic drop from peak |
| Rented algorithmic channel | Repriced overnight | Facebook referrals 30% to 7%; the Helpful Content wipeouts |
| Owned audience / email list | Moat, the one a solo can hold | Pieter Levels reusing a ~600K audience across 40+ products |
| Embedded workflow, switching cost | Moat, the system-of-record defense | Cursor to $100M ARR on lock-in; Menlo: incumbents keep 56% of infra |
| Proprietary data / community loop | Moat, uncopyable via an API | Nomad List's community-submitted cost-of-living data |
| Network effect | Moat, but unavailable at solo scale | Teams bundled into Office beat Slack |
| Founder brand | Moat when it de-risks launches | Base44's $80M exit; Cluely the counterexample |
The boundary between the first two rows is the entire lesson. Bundling wins when the bundled product is one people keep opening: Elad Gil's rule is that an incumbent [can be 50% as good and still win by bundling](https://blog.eladgil.com), which is why Microsoft folding Teams into Office beat Slack so thoroughly that the EU [formally called it an "undue competitive advantage in terms of distribution"](https://siliconangle.com) and forced an unbundling in 2025. Bundling loses when the product underneath is one people avoid, which is Copilot.
Distribution is the amplifier. Retention is the thing being amplified, and AI-native products are leaking: median net revenue retention ran [about 48% against 82% for traditional SaaS](https://chartmogul.com), and under-$50-a-month AI products retained around 32%. Pour distribution into a bucket that empty and you have bought a crowd that files straight out the other door.
## The solo-scale playbook: which moats scale down
Most of that table is the incumbent's game. A one-person shop cannot manufacture a network effect or bundle into 450 million desktops, so the first move is to stop trying, and stop believing the founders who imply you can.
Three of these moats genuinely scale down, and they are where a small builder's effort belongs. The first is an owned audience compounded over years: Pieter Levels has reused the same roughly 600,000-follower audience across more than 40 products, and the durable asset is the audience, which outlives any one launch, because he can point it at the next thing whenever he wants. The second is a founder brand that de-risks a launch rather than just spiking it, which is what carried Base44 from a solo build to an $80 million exit with zero paid marketing, covered in the [build-in-public piece](/study/build-in-public-revenue/).
The third, and the most defensible of the three, is a proprietary data or community loop: Nomad List's thousands of pages are hard to clone not because the template is clever but because the cost-of-living and safety data is submitted by a community a competitor cannot buy through an API.
The workflow-lock-in path is available too when your product earns daily use. Cursor reached [$100 million in ARR with reportedly almost no marketing](https://techcrunch.com) on developer word of mouth, but the part that defends it is not the buzz, which any rival can also generate; it is that the buzz converted into a tool developers now live inside and would have to migrate out of. One caveat on the newest channel: [being cited by AI answer engines](/study/what-a-chatgpt-citation-is-worth/) is a real and growing surface, but the citations are fragmented across assistants, so it compounds slowly and is worth building toward rather than trusting yet. What any of this costs to run is the [CAC study's](/study/cac-by-channel-ai-product/) department; the point here is only which of it becomes defensible.
## The counter-case, taken seriously
The strongest version of the opposing view deserves a fair hearing, because it is partly right. John Hwang argued directly that [distribution is not a moat in AI](https://nextword.substack.com): in a market with almost no barrier to building, fast movers flood the zone, and the proof is that the martech landscape went from about 150 tools in 2011 to more than 15,000 in 2025. When everyone can build the product and reach the customer, neither the product nor the reach is scarce, and scarcity is what a moat is made of.
The switching-cost problem underneath is structural. AI products have close to the lowest switching costs in software history, because the actual work often lives in a prompt you can copy and paste, and operators report [migrating most of a system by moving the prompt](https://www.saastr.com). A distribution lead over a rival whose product a user can adopt in an afternoon is a lead measured in weeks. And the evidence cuts both ways on cue: Anthropic overtook OpenAI in US business adoption by [late 2025 per Ramp's spending data](https://venturebeat.com), a better product flipping a distributed leader, which proves the same underlying point from the other side. Reach did not hold the position. The product did or did not.
But bound the counter-case fairly, because it overshoots. Distribution not being sufficient does not make it worthless; it makes it a multiplier rather than a foundation. Lovable's story is the clean illustration: it reached roughly $100 million in ARR and then saw its traffic [fall about 40% from peak](https://www.forbes.com), a distribution lead visibly draining while revenue still grew on momentum. The reach was real. It just sat on a product that was not holding its users, and reach on a leaky product is a countdown.
## Build the reach you can own
The synthesis is one sentence. Distribution is a moat only when it is owned or embedded and it defends a product people retain. Rented channels and viral moments are advantages, sometimes large ones, but they are temporary by construction, and treating a temporary advantage like a permanent one is how companies that looked unstoppable end up as case studies.
So apply one test to every channel you are pouring effort into. Does this reach compound into something a competitor cannot arbitrage away, an audience you own, a switching cost, a proprietary loop, and is the channel itself widening or narrowing under you. If the answer is that it lives on someone else's algorithm and that algorithm is shrinking or can be retuned against you tomorrow, you are renting, and you should be routing every bit of that rented reach into something you own before the terms change.
That is the standard Okane Land holds itself to, said plainly as a small brand early in the work. The one genuinely owned channel here is a self-hosted newsletter, run on our own pipeline precisely so no third party gates the relationship with a reader. The community forum is the slow proprietary-loop bet, the only asset here that could someday become a moat, though it is nowhere near one yet.
And the daily reply loop on X and the work of getting cited in AI answers are, by this piece's own taxonomy, rented and emerging reach: useful, real, and never to be trusted on their own, which is exactly why they feed the owned list rather than stand in for it. That is the whole argument turned on its author. Build on ground you own, because the reach you rent is only yours until the landlord decides otherwise.
---
# The $5,000 tell: AI vendors are selling you human QA for their own AI
Section: The Study
URL: https://okaneland.com/study/the-5000-dollar-tell/
We bought the $99 plan of an AI ad tool and read the meter while its cloning agent worked. The run was the small finding. The bigger one is a single line on the vendor pricing page, where the top tier charges roughly fifty times our plan for the one thing the agent cannot promise: work with the AI mistakes taken out.
Last week we paid $99 for an AI ad tool's Pro plan and pointed its flagship feature, an agent that clones a competitor's ad with your product in it, at a real listing. The agent worked for close to an hour. It planned, it scraped, it rendered scene by scene, and it assembled a 40-second ad we would genuinely run after a trim. Then we opened the transaction log.
The run had consumed 173 credits, more than half the month's 300-credit allowance, spent half a credit at a time for the thinking and several credits at a time for the scene renders behind it. At the Pro rate that is about $57 for one ad. A tightly scoped revision, swap the presenter and change nothing else, cost another 43 credits, about $14. Nothing in the interface shows you a total before you commit. The agent spends as it goes, and you find out afterward, in the log, the way you find out about a hotel minibar.
The log gave up two more things the marketing does not mention. The line items carry Anthropic tool-call IDs: the agent doing the cloning is Claude with a toolbelt. And sitting above the whole self-serve product, on the vendor's own pricing page, is a tier called Studio: humans making your videos for $100 to $200 each, from $5,000 a month, promising, in the vendor's own words, human QA on every asset and zero hallucinations.
Read that pricing page the way you would read a company's org chart. The company that sells AI-generated ads prices the removal of AI mistakes as its premium product. We think that one line is the most useful signal in the entire category.
## The short version
Four things the meter taught us, portable to any AI tool you rent:
- **Agent autonomy multiplies the bill.** Templates and the flagship agent share one meter and land 100-to-1 apart, because a loop pays for its plans, retries, and rejected drafts.
- **The $5,000 tier is the vendor pricing its own trust gap.** Fifty times the software, for the same output with a human check on it.
- **Derive the real cost from the log.** Push a single job through and divide the credits burned into the plan price; a vendor with no legible log has told you something too.
- **The cheap tier bills your attention too.** Review hours, retries, and the risk of shipping a bad take ride on top of the meter before any comparison with [a $185 human video](/study/ai-ugc-ad-economics/) holds.
The full meter reading is below.
## The receipts, briefly
The full teardown lives in [our hands-on Creatify review](/proof/creatify/), so here is just the arithmetic that matters. The same subscription that sells the $57 agent run also sells four finished static ads for 2 credits, about 66 cents, and a 15-second avatar video for 5 credits, about $1.65. Those cheap tools are excellent, and they are what the subscription is actually for.
So one product, one meter, and a 100-to-1 spread in what a deliverable costs depending on how much autonomy you hand the machine. The statics are a template with a model inside. The agent is a loop: plan, act, check, retry, spend. Every step of that loop is a metered model call, and some of the steps are full video generations that exist only so the agent can look at them and decide they were not good enough. You pay for its drafts the way you would pay for a junior editor's, except the junior editor does not bill you per thought.
That is what agent economics look like everywhere once you meter them, and [Creatify](https://creatify.ai/pricing) is just where we metered it, and we say that as [a publication that has run the same math on wrapped LLM products](/study/unit-economics-of-wrapping-an-llm/) from the seller's side. Autonomy is a multiplier on inference, and inference is the cost of goods. A vendor can hide that behind a subscription for exactly as long as you do not use the flagship feature.
## The tell, and how to read it
Here is the part worth generalizing. When a vendor sells you an AI product at $99 and a human-checked version of the same product at $5,000, the vendor has published a number for something they will never put in a benchmark chart: the price of trusting their own AI's output, unsupervised, with your brand on it.
That number is fifty times the software.
You can call that hypocrisy if you want a cheap headline. We think it is candor, and unusually precise candor. Every AI tool has a quality line somewhere: the point past which the output needs a human eye before it ships. Most vendors leave you to find that line yourself, in production, with your customers watching. A vendor with a human tier has drawn the line for you and taped a price to it. [The $5,000](https://creatify.ai/pricing) is the vendor's own estimate of what the last mile of reliability is worth, sold to the customers who can least afford to gamble on it.
Once you start looking for this shape, it is everywhere in the 101 tools we track in [the price index](/palette/ai-tool-price-index/). Relevance AI, an agent-platform darling, [deleted its self-serve tiers outright this month](https://relevanceai.com/pricing); the pricing page is now a single enterprise card and a sales call, which is another way of saying the product ships with mandatory humans now. The support-bot vendors [price per resolved ticket](https://fin.ai/pricing), which quietly prices the unresolved ones back onto your team. The pattern repeats because the economics repeat: the model is cheap, the loop is expensive, and the guarantee is the only thing that commands a margin.
## What this means if you are the buyer
Three rules fall straight out of the receipts.
**Budget agents like productions.** A subscription price tells you what the templates cost. It tells you nothing about the flagship agent, which spends per attempt, retries included, with no quote up front. Before you point an agent at anything, find the transaction log, run one job end to end, and derive the real per-deliverable number the way we did: total credits burned, divided into the plan price. If the vendor does not expose a log granular enough to do that, that is your answer about the vendor.
**Price your own eyeballs into the self-serve tier.** At $99, you are the QA department. That is fine, and often still a bargain, but it is a real labor line on your side of the ledger. The true comparison against a human contractor is never $57 versus $185. It is $57 plus your review time, your retries, and your risk of shipping the take with the mangled product claim, versus a human's invoice that has all of that priced in. We ran that comparison for the whole ad category in [the AI UGC ad math](/study/ai-ugc-ad-economics/), and the punchline is the same: the clip is the cheapest line on the bill.
**Use the human tier as a spec sheet.** The distance between a vendor's AI price and their human price measures exactly how much supervision the vendor believes their own output needs. A small gap says the output mostly ships. A 50x gap says the output mostly needs an editor, and the vendor knows it. Either way, the vendor has done your risk assessment for you and published it. Very few industries are this legible. Read the number and plan your workflow around it: cheap tools for volume, your own judgement on everything that ships, and the agent reserved for the jobs where an hour of machine time genuinely replaces a day of yours.
## The part that is genuinely good news
None of this is an argument against the tools. We gave the tool in question a worth-it verdict and meant it: fed one product listing and $99, it returned a month of usable creative, and the cheap end of its menu embarrasses what agencies charged for statics two years ago. The argument is about reading pricing pages the way vendors write them.
An industry that sells its own error correction as a premium tier is an industry telling you, in dollars, exactly where the technology stands. The models write the words and render the frames. The margin lives in the checking. For anyone building or buying in 2026, that is the map: the closer your use case sits to the guarantee, the more the humans still cost, whoever employs them.
The vendors already did this math. The $5,000 is them showing their work. We suggest reading it.
---
# The year Claude subscribers sued over limits is the year the limits mostly went up
Section: The Study
URL: https://okaneland.com/study/claude-code-limits/
We reviewed 2,122 posts from Claude subscribers across Reddit and Hacker News. The strange year on the record: a silent squeeze, then weekly caps, then a lawsuit over what the tiers deliver, and then the limits mostly went up. The only per-plan numbers ever published are in the table inside; here is how to buy around the rest.
June 2026 produced the strangest pairing in AI subscriptions. On June 14, a subscriber filed [a proposed class action](https://gizmodo.com/anthropic-accused-of-misleading-users-over-soaring-ai-costs-in-new-lawsuit-2000772061) alleging Anthropic's $100 and $200 Claude plans deliver a fraction of their advertised multiples. Five weeks earlier, Anthropic had [permanently doubled Claude Code's five-hour limits](https://www.anthropic.com/news/higher-limits-spacex) and removed peak-hour throttling, and a week after that it raised weekly limits 50% as a promotion it has now extended twice. The year subscribers went to court over the limits is the same year the limits mostly went up. Both things are true, they are the two halves of this piece, and the way to hold them together is the same conclusion [our Perplexity study](/study/perplexity-pro-limits/) reached from the opposite direction: the published plan is a band, the real plan is your meter, and the builders who thrive are the ones who read it.
We reviewed 2,122 posts by Claude subscribers, from 22 Reddit threads read in full and five Hacker News search lanes, to map what people actually hit, when the record actually changed, and what the anger is actually about. The annotation file, one row per post with its permalink, is [published as an open dataset](/data/claude-code-limits/).
## The short version
- **Three clocks run at once, and none publishes an exact number.** A rolling five-hour window, a weekly cap layered on top since August 2025, and a separate, faster meter for the premium models. Anthropic describes allowances in ranges of hours; the [in-product /usage meter](https://support.claude.com/en/articles/12157520-claude-code-usage-analytics) is where your real numbers live.
- **The record runs squeeze, then structure, then raises.** A silent tightening in July 2025 that [TechCrunch documented](https://techcrunch.com/2025/07/17/anthropic-tightens-usage-limits-for-claude-code-without-telling-users/); weekly caps from August 28, 2025, pitched as touching [less than 5% of subscribers](https://x.com/AnthropicAI/status/1949898502688903593); then 2026's turn upward, a [permanent five-hour doubling in May](https://www.anthropic.com/news/higher-limits-spacex) and a 50% weekly raise [extended twice through August 19](https://www.helpnetsecurity.com/2026/07/13/claude-code-weekly-limits-promotion-extended/).
- **The complaints cluster where the opacity is.** Of 2,122 reviewed posts, 1,676 touch limits and quotas, 619 the premium-model meter, and 265 transparency itself. The community's mood graduated to satire: the top July post announces a system of "seventeen interlocking limits, three ceremonial limits," and one that cannot be observed without altering it.
- **The lawsuit is about multiples, and it is an allegation.** Kahn v. Anthropic claims Max 5x delivers about 3.5x Pro and Max 20x about 6 to 8x, versus the advertised 5x and 20x. Anthropic has not, at this writing, published exact per-plan numbers that would settle it.
- **The meters spawned a cottage industry.** When a vendor publishes bands instead of numbers, users build their own gauges: real-time monitor apps, open-source trackers, and in one 2,078-point case, [a $32 hardware meter on a desk](https://www.reddit.com/r/ClaudeCode/comments/1takxpl/). The checklist at the bottom is the software version of that instinct.
Everything below is the evidence, with the caveats attached where they belong.
## How we counted, and what the count cannot say
The corpus is 2,122 posts from July 2025 through July 30, 2026: 1,639 rows from 22 limit-focused threads read in full on r/ClaudeAI and r/ClaudeCode (selected from 200 threads matched across eight subreddit searches), and 483 relevant rows from 518 Hacker News stories and comments pulled across five search lanes. Each post was labeled for topic, stated plan tier, and keep-or-cancel verdict, keyword-first with a hand-checked review pass, so the counts undercount anything phrased in a writer's own words. Only 390 rows carry a first-person tier or verdict statement; the rest are marked ambiguous, and we treat them that way. Every channel here is self-selected, complaint threads overweight the frustrated, and nobody posts that their meter behaved today. What the corpus is good for is ranking what subscribers bring up on their own, and quoting them with receipts. The full file is [downloadable, one permalink per row](/data/claude-code-limits/).
## The system, mapped
Every Claude subscription meters the same three ways. The **five-hour window** is the short clock: usage inside a rolling session block, reset every five hours, the one you notice on a heavy afternoon. The **weekly cap** arrived August 28, 2025 as a second layer; hit it and no five-hour reset saves you until the week rolls over. The **premium-model meter** runs fastest: Opus-class models draw down a separate, smaller allowance inside your plan, which is why the community's oldest habit is [Opus for planning, Sonnet for execution](https://www.reddit.com/r/ClaudeAI/comments/1mof7py/), a workflow Anthropic eventually automated into the product.
What no tier publishes is an exact number, and here is everything the company has put on the record instead.
## The bands, as published
These are Anthropic's own per-plan estimates, given once, at [the weekly-cap announcement](https://techcrunch.com/2025/07/28/anthropic-unveils-new-rate-limits-to-curb-claude-code-power-users/) in July 2025, stated in hours of Claude Code per week for the models of that era:
| plan | price | Sonnet-class, hours a week | Opus-class, hours a week |
|---|---|---|---|
| Pro | $20/mo | 40 to 80 | no band published |
| Max 5x | $100/mo | 140 to 280 | 15 to 35 |
| Max 20x | $200/mo | 240 to 480 | 24 to 40 |
Read the table with its three modifiers. First, the ranges predate the raises: the five-hour clock inside each week was [doubled on May 6, 2026](https://www.anthropic.com/news/higher-limits-spacex), and the weekly allowance itself is running 50% above standard [as a promotion through August 19, 2026](https://www.helpnetsecurity.com/2026/07/13/claude-code-weekly-limits-promotion-extended/), so current effective weeks sit above these bands until the promo lapses. Second, the ranges were stated for mid-2025 models, and the model lineup has turned over since; the support pages describe today's allowances only as varying with model, codebase size, and load. Third, a range that spans 2x from floor to ceiling is a hedge, and it is the hedge the class action now litigates. Which is why the honest bottom line stays the same: your plan is a band, not a number, and the only place the band collapses into a fact is [the /usage meter](https://support.claude.com/en/articles/12157520-claude-code-usage-analytics) in your own account.
## The timeline: down, then up
The record, dated and sourced, runs like this. **July 2025**: heavy users start hitting walls early, and TechCrunch documents that Anthropic [tightened limits without telling anyone](https://techcrunch.com/2025/07/17/anthropic-tightens-usage-limits-for-claude-code-without-telling-users/); the company declines to comment on specifics. **August 28, 2025**: the weekly caps go live, announced a month ahead this time, framed as reining in a small tail: round-the-clock usage and account resellers, [under 5% of subscribers](https://x.com/AnthropicAI/status/1949898502688903593). **Late 2025**: the in-product meter arrives, and checking /usage becomes the community's reflex. **May 6, 2026**: the direction reverses. On the back of a compute agreement covering [more than 300 megawatts of new capacity](https://www.anthropic.com/news/higher-limits-spacex), Anthropic doubles the five-hour limits permanently and deletes peak-hour throttling. **May 13, 2026**: weekly limits rise 50%, promotional. **July 2026**: the promotion is [extended, twice](https://www.helpnetsecurity.com/2026/07/13/claude-code-weekly-limits-promotion-extended/), now through August 19.
Read against [the Perplexity record](/study/perplexity-pro-limits/), the shape is inverted. That plan shrank three times in eight months as inference costs squeezed a $20 tier. This one squeezed early, structured the squeeze into published mechanics, and then grew as compute arrived, which is roughly what [the unit economics](/study/unit-economics-of-wrapping-an-llm/) predict for a vendor whose constraint is capacity rather than margin. The community noticed the difference without being grateful for it. Under the ["Access has been extended!"](https://www.reddit.com/r/ClaudeAI/comments/1uul693/) announcement, the top reply asks whether the extension will arrive "every time forever one day before it is removed," and the next one down says what every subscriber on a promotional allowance thinks: "Quit extending and just make it permanent. No one likes this silly game of chicken."
## What 2,122 posts complain about
The multi-label counts, with the caveat that keyword matching undercounts: **limits and quotas**, 1,676 of 2,122. The **premium-model meter**, 619. **Price and value**, 479. The **five-hour window** specifically, 388. **Named competitors** in the same breath, 320, mostly Codex, Cursor, and the cheap Chinese models used as overflow valves. **Transparency**, 265. **Plan comparison**, 237, and **extra usage and credits**, 206.
The flavor of the biggest cluster changed across the year. June 2026's loudest thread is a 2,834-point petition, Max 5x users [hitting their weekly cap in two or three days](https://www.reddit.com/r/ClaudeCode/comments/1uim4jb/) and asking for a reset. By July the mood had graduated to satire: the top r/ClaudeCode post of the month is a [fake policy announcement](https://www.reddit.com/r/ClaudeCode/comments/1v2yoe4/) unveiling "seventeen interlocking limits, three ceremonial limits," and one limit that cannot be observed without altering it. It reads as a joke and counts as data: 2,365 people upvoted a parody of not being able to know their own allowance. When your users write physics jokes about your pricing page, the pricing page is the bug.
The workaround culture is the constructive half of the same energy. The highest-signal example we reviewed: a builder hitting Pro's weekly cap every Wednesday who [bolted a two-cent-per-call cheap model onto Claude Code](https://www.reddit.com/r/ClaudeAI/comments/1t1o43w/) for bulk file reads and stopped hitting the cap entirely, the same model-routing logic [Google's SDLC whitepaper](/study/new-sdlc-with-vibe-coding/) recommends as a cost lever, discovered independently by a subscriber protecting a $20 plan.
## The meter cottage industry
Our favorite finding in the corpus is a genre. Because the vendor publishes bands, the community builds gauges: the 2,703-point ["app to monitor your Claude usage limits in real-time"](https://www.reddit.com/r/ClaudeAI/comments/1rc27sc/), the open-source trackers that parse your local logs, and the fully literal version, [Clawdmeter](https://www.reddit.com/r/ClaudeCode/comments/1takxpl/), a $32 ESP32 board with a round AMOLED display that sits on a desk showing a physical needle of your remaining allowance. Two thousand people upvoted a hardware fuel gauge for a software subscription. As a product review, it is devastating praise: the tool is valuable enough to instrument and opaque enough to need it.
## The lawsuit, and the fine print around extra usage
The legal file is where the multiples question landed. [Kahn v. Anthropic](https://qz.com/anthropic-sued-claude-max-subscription-usage-limits-061526), filed June 14, 2026 in the Northern District of California, alleges the Max plans' advertised "5x" and "20x more usage than Pro" deliver about 3.5x and 6 to 8x in practice. Those are the plaintiff's numbers, unproven, and Anthropic will get its say. What makes the complaint hard to wave off is structural: because no exact per-plan numbers are published, the multiple is unfalsifiable from the outside, which is precisely the condition a court, or a published number, resolves.
The corpus adds a smaller, newer fine-print cluster around paid top-ups, 206 reviewed posts. Two July examples carry the pattern: a Pro subscriber warning that claiming promotional credits [silently enabled pay-per-use billing](https://www.reddit.com/r/ClaudeAI/comments/1v3yk7a/) beyond his plan, and a Max subscriber reporting a $250 top-up where [a one-word test message](https://www.reddit.com/r/ClaudeAI/comments/1um9j1u/) appeared to draw about $20, self-reported and disputed in the replies, but 1,677 points of subscribers recognizing the anxiety. The lesson generalizes past any single incident: the moment your account can spend past its subscription, the meter stops being a curiosity and becomes the bill.
## Before you lean on it: the checklist
1. **Read your own meter in week one.** Run your normal workload and check /usage daily: the five-hour clock, the weekly clock, the premium-model share. The band collapses into your number, and that number, [not the plan page](/primer/how-to-use-claude-code/), is what you bought.
2. **Plan around the weekly clock, and note the promo date.** The current weekly allowance includes a promotional 50% that is scheduled to end August 19, 2026 unless extended again. If your workflow only fits with the promo, your plan is smaller than it feels.
3. **Route by model, deliberately.** The premium meter drains fastest; the community's convergent answer is planning on the expensive model, execution on the cheap one, and bulk grunt work on [something nearly free](/study/unit-economics-of-wrapping-an-llm/). The subscribers who never post in limit threads are the ones running this split; the full price math behind it is in [how to cut your AI coding bill](/study/cut-your-ai-coding-bill/).
4. **Treat extra usage as a light switch you flip knowingly.** Check whether pay-per-use is enabled on your account before you claim any promotion, and after. The 206 posts in that cluster are mostly people who found out afterward.
5. **Know the escape valve.** The API prices the same models per token with no weekly clock. It is usually the expensive way to run a heavy month, but it converts an opaque band into an exact invoice, and for burst weeks that certainty [can be worth the premium](/study/unit-economics-of-wrapping-an-llm/).
The wider lesson is the one this series keeps finding. Vendors publish bands because inference costs move; subscribers experience bands as broken promises; the gap fills with lawsuits, satire, and desk hardware. Until the numbers are published, the meter is the contract. Read it like one.
---
# Is vibe coding dead, or just renamed? What the record shows
Section: The Study
URL: https://okaneland.com/study/is-vibe-coding-dead/
No. Usage of the practice sits at all-time highs while the word gets demoted from a name for everything to a name for the casual end. The record: a dictionary crowning, a coiner walking his own term back, a Google whitepaper splitting it in two, and a search-interest handoff we measured ourselves.
No. Vibe coding is not dead, and the confusion is worth clearing up precisely, because the people supposedly burying it are its own inventor and its biggest institutional backer. In April 2026 Andrej Karpathy, who [coined the term](https://x.com/karpathy/status/1886192184808149383) in February 2025, told Sequoia's AI Ascent audience the future belongs to something he now calls [agentic engineering](https://karpathy.bearblog.dev/sequoia-ascent-2026/). Trade press ran the funeral: [vibe coding is passé](https://thenewstack.io/vibe-coding-is-passe/). A month later Google published [a 51-page whitepaper](/study/new-sdlc-with-vibe-coding/) with vibe coding in the title and taught it to a course audience of over a million. Words do not get eulogized and institutionalized in the same quarter when they are dying. They do it when they are splitting. That is what the record shows, and this piece walks through it with the receipts, including a search-interest handoff we measured ourselves.
## The short version
- **The practice is at all-time highs.** [90% of software professionals](https://dora.dev/dora-report-2025/) use AI at work per Google's own DORA survey, 51% of professional developers [use it daily](https://survey.stackoverflow.co/2025), and the flagship vibe-coding tools post the [best loyalty scores in the category](https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/). Nothing about that curve says dead.
- **The word is being demoted, on purpose.** It stretched from Karpathy's original meaning, building without reading the code, into a name for all AI-assisted development. The correction now underway shrinks it back to the casual end, and gives the disciplined end its own title: agentic engineering.
- **The handoff is measurable.** In our own Google Trends pull, the two terms went from a 30-to-1 search gap in July 2025 to roughly 2.5-to-1 at the June 2026 peak. "Vibe coding" search interest has fallen by about half from its March 2026 high.
- **For a working builder this is positioning, and it pays.** The word you use tells a client exactly how much verification they are buying. The last section is the translation guide.
## Who declared it dead, exactly
Trace the obituary to its sources and something interesting happens: none of them claim people stopped building this way. The New Stack's headline says Karpathy has [a new name for the future](https://thenewstack.io/vibe-coding-is-passe/), which is a claim about vocabulary. Karpathy's own talk drew a line between two modes: vibe coding [raises the floor](https://karpathy.bearblog.dev/sequoia-ascent-2026/), letting anyone build software, while agentic engineering raises the ceiling of what professionals can ship, coordinating fallible agents while preserving correctness, security, and taste. And Google's whitepaper, the closest thing the field has to an official position, spends fifty pages arguing the two are [ends of one spectrum](/study/new-sdlc-with-vibe-coding/), with the dividing line drawn at verification rather than tools.
So the death notice, read carefully, says: the word stopped meaning one thing. That is true, and it was true before anyone called it passé. The dictionary saw it coming.
## The timeline of the name
The sequence tells the story better than any hot take. Karpathy [named the mode](https://x.com/karpathy/status/1886192184808149383) in February 2025: give in to the vibes, forget the code exists, paste the errors back in. Within a month the term was stretching, and Simon Willison published the correction that still holds up: if you review and understand every generated line, [you are not vibe coding](https://simonwillison.net/2025/Mar/19/vibe-coding/). By October 2025 Willison was proposing [vibe engineering](https://simonwillison.net/2025/Oct/7/vibe-engineering/) as a deliberately self-contradictory name for the disciplined version. In November, [Collins Dictionary crowned vibe coding Word of the Year](https://www.collinsdictionary.com/woty), the surest sign a technical term has escaped its technical meaning. By April 2026 the coiner himself [introduced agentic engineering](https://karpathy.bearblog.dev/sequoia-ascent-2026/) for the professional end, and by May, Google's whitepaper and its [1.5-million-learner course](https://blog.google/innovation-and-ai/technology/developers-tools/kaggle-genai-intensive-course-vibe-coding-june-2026/) had turned the split into curriculum.
Note the irony in the middle of that list. The dictionary crowning and the naming correction happened in the same season. Words get Word of the Year when everyone uses them; words get replaced when everyone uses them for too many different things. Both happened to vibe coding, in order, for the same reason.
## The handoff, measured
We pulled the two terms head to head from Google Trends ourselves, US web search, twelve months, on one shared scale. Nobody covering the "passé" story showed this chart, which is a shame, because it is more honest than either the funeral or the denial.
Three things are true at once in that data. First, "vibe coding" search interest peaked in early March 2026 and has fallen by roughly half since, from an indexed 100 down to the mid-40s by mid-July. Second, "agentic engineering" went from a rounding error, indexed at 2 in July 2025, to the mid-20s during Google's course week in June 2026, closing a 30-to-1 gap to roughly 2.5-to-1 at its peak. Third, the handoff is incomplete and may stay that way: in the July lull the older term still leads by about seven to one, and it remains the phrase with the [dictionary title](https://www.collinsdictionary.com/woty), the Google whitepaper title, and the course branding. The searchers arriving behind it are asking new long-tail questions too; the fastest risers on the challenger term are "agentic engineering patterns" and "harness engineering," which is exactly what you would expect people to ask [once the harness becomes the product](/study/new-sdlc-with-vibe-coding/).
The flags, since we keep them on for our own charts as well: this is one country, one search engine, web search only, and Trends indexes relative interest rather than absolute volume. It measures what people call the thing, which is precisely the question here, and nothing more.
## The practice never dipped
If the practice were dying you would see it in adoption, spend, or satisfaction, and every one of those lines points the other way. Google's own DORA research puts AI use among software professionals [at 90%](https://dora.dev/dora-report-2025/), up 14 points year over year. Stack Overflow's 49,009-developer survey has [51% of professionals using AI daily](https://survey.stackoverflow.co/2025). JetBrains' April 2026 survey of 10,000-plus developers found the core vibe-coding tools holding [the highest satisfaction in the category](https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/). The money receipts run through the same period: the [$80 million Base44 exit](https://www.wix.com/press-room/home/post/wix-further-expands-into-vibe-coding-with-acquisition-of-base44-a-hyper-growth-startup-that-simplif), the billion-dollar tool revenue ramps, the whole case [we assembled with the flags on](/study/is-vibe-coding-worth-it/). A practice does not post record adoption, record loyalty, and eight-figure exits while dying. Only its name can die, and even the name is merely getting a narrower job description.
Whether the narrowed practice is fast, safe, and worth the maintenance bill is a different question with its own evidence, and we keep those pieces current: [the speed data](/study/does-ai-coding-make-you-faster/), [the agent reliability data](/study/do-ai-agents-work-yet/), and [the economics verdict](/study/is-vibe-coding-worth-it/), and [how many vibe-coded launches are still alive](/study/how-many-vibe-coded-launches-are-alive/).
## What to say instead, and when
Here is the practical payoff, because for a solo builder this vocabulary shift is a positioning gift. The whitepaper makes the point with a scenario: telling a CTO you vibe coded their payment system should raise alarms, while describing the same AI leverage operating under human-designed constraints and test coverage is a different conversation. The words now carry the verification promise.
So use them precisely, in both directions. "Vibe coding" is still the right term, and now a usefully scoped one, for what it originally meant: the weekend prototype, the exploration, the disposable script where speed-to-signal is the whole point and [the stack costs almost nothing](/primer/vibe-coding-stack/). Claim it without embarrassment; it is the mode that raises the floor. Whether you can climb from that floor, learning while you build, is [its own primer](/primer/can-you-learn-while-vibe-coding/). The moment you are selling work that strangers will depend on, describe the discipline instead: AI-assisted implementation with the code reviewed, tests written first, and [an agent setup you actually maintain](/primer/how-to-use-claude-code/). If you want the one-word version the field is converging on, it is agentic engineering. Clients are beginning to search the difference; being the builder who can explain it is cheap authority.
## The verdict
Not dead. Renamed at the top, narrowed at the bottom, and bigger than ever in the middle. The pattern is older than software: a word gets coined for a fringe behavior, the behavior wins, and the word splits into a casual sense and a professional sense with its own title. Vibe coding went from [a February 2025 post](https://x.com/karpathy/status/1886192184808149383) to [Word of the Year](https://www.collinsdictionary.com/woty) to a [Google-taught spectrum](/study/new-sdlc-with-vibe-coding/) in sixteen months, which is the trajectory of a winner, and the search data shows the professional half of the vocabulary rising without the practice missing a beat. Karpathy's own framing settles the question cleanly: the casual mode keeps "raising the floor for everyone," and the disciplined mode now has a name for raising the ceiling. Learn the discipline, keep both words, and use whichever one honestly describes the verification behind the thing you shipped.
---
# The new SDLC with vibe coding: what Google's paper actually says
Section: The Study
URL: https://okaneland.com/study/new-sdlc-with-vibe-coding/
Google published a 51-page whitepaper redrawing the software lifecycle around AI agents: same phases, new bottleneck, and a formal line between vibe coding and agentic engineering. We read the whole thing, traced its numbers to their sources, and translated the framework for a builder working alone.
In May 2026 Google published a 51-page whitepaper called [The New SDLC With Vibe Coding](https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding), written by Addy Osmani, Shubham Saboo, and Sokratis Kartakis, and then taught it to over a million people through a [free five-day course](https://blog.google/innovation-and-ai/technology/developers-tools/kaggle-genai-intensive-course-vibe-coding-june-2026/) in June. Its argument in one line: the software lifecycle keeps its phases, loses its old bottleneck, and gains a new one. Writing code is no longer the expensive part. Specifying, verifying, and judging what the machine wrote is. We read the full paper, checked its numbers against their primary sources, and pulled out what it means for a builder working alone.
## The short version
- **The paper's core move is a spectrum.** Vibe coding and agentic engineering are endpoints of one practice, and the position on the line is set by how much verification surrounds the AI's output. The tools can be identical at both ends.
- **Its most useful equation is agent = model + harness.** The paper puts the split at roughly 10% model and 90% harness, and the receipt behind that claim is real: LangChain moved a coding agent from outside the top 30 to the top 5 on a public benchmark [without changing the model](https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering).
- **The lifecycle keeps its shape and changes its proportions.** Implementation compresses from weeks to hours; requirements, architecture, and review stay human-paced. Specification quality is the new bottleneck, and tests plus evals become how you tell the AI what correct means.
- **Read its statistics with the flags on.** The framework is sound, and the paper's headline adoption numbers cite marketing aggregators rather than the primary surveys that actually exist. We traced each one below; some hold, some are softer.
- **For a solo builder, the six-step starting list is the payload.** An AGENTS.md, one repetitive workflow turned into an agent, tests before generation, and a review pass on every line that ships.
The rest is the framework in detail, with the sources open.
## What the paper is, and where to find it
The whitepaper is the first entry in a series Google shipped alongside its [5-Day AI Agents intensive](https://blog.google/innovation-and-ai/technology/developers-tools/kaggle-genai-intensive-course-vibe-coding-june-2026/), the free Kaggle course whose November 2025 edition reached more than 1.5 million learners. The paper itself is [hosted on Kaggle](https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding), dated May 2026, 51 pages with 32 endnotes. Osmani, its lead author, published [a condensed companion essay](https://www.oreilly.com/radar/the-new-software-lifecycle/) on O'Reilly Radar in July, which is the version most people have actually read.
The timing explains why the searches spiked. The term vibe coding is [Andrej Karpathy's, from February 2025](https://x.com/karpathy/status/1886192184808149383), and it stretched within months to mean any AI-assisted coding at all. By April 2026 Karpathy himself drew a new line at Sequoia's AI Ascent, [introducing agentic engineering](https://karpathy.bearblog.dev/sequoia-ascent-2026/) as the disciplined end of the practice: vibe coding raises the floor of who can build software, agentic engineering raises the ceiling of what professionals ship. The Google paper is the institutional version of that split, with a course attached.
## The spectrum, which is the actual answer
The paper refuses the binary. Vibe coding and agentic engineering are endpoints on a spectrum, and the differentiator is stated plainly: what decides your position is how outputs get verified, and nothing else. A developer can vibe code and practice agentic engineering with the same agent in the same afternoon.
At the loose end, casual prompts, no reading of the generated code, and a verification standard of "does it seem to work." The paper is comfortable with this mode where the code is disposable: prototypes, scripts, hackathons. The middle is where most working builders live, detailed prompts and manual spot-checks on features inside an established codebase. The far end is formal specs, automated test suites, CI/CD gates, and LLM judges, with humans reviewing architecture while the AI handles implementation detail.
Two things about this framing earn their keep. First, it gives you a clean answer to a question clients and CTOs are already asking; the paper notes that telling a CTO you vibe coded the payment system should raise alarms, while describing the same AI leverage under constraints and test coverage is a different conversation. Second, it puts the boundary inside your control. Verification is a budget you spend by the stakes of each task, [the same supervised-beats-unattended split](/study/do-ai-agents-work-yet/) the agent research keeps finding. The paper's own line is that without tests and evals together, the practice is always vibe coding, no matter how sophisticated the prompts.
An academic taxonomy [published a year earlier](https://arxiv.org/abs/2505.19443) drew nearly the same map from the outside, splitting conversational, human-in-the-loop building from goal-driven autonomous execution across twenty use cases. The convergence is a good sign the distinction is real rather than branding.
## Agent = model + harness
The paper's second framework is the one with a receipt attached. An agent is a model plus a harness, where the harness is everything wrapped around the reasoning engine: instruction files, tools and MCP servers, sandboxes, orchestration logic, guardrails, hooks, and observability. The paper's rough split gives the model 10% of the outcome and the harness 90%, and its sharpest sentence follows from it: most agent failures, examined honestly, are configuration failures. When the agent does something wrong, the instinct is to blame the model, and the fix is usually a missing tool, a vague rule, or a context window stuffed with noise.
The evidence is worth stating precisely, because the paper cites it loosely. In February 2026 LangChain [rebuilt the harness around a fixed model](https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering) and lifted its score on Terminal-Bench 2.0 from 52.8% to 66.5%, a 13.7-point gain that carried the agent from outside the top 30 to the top 5 on the leaderboard. They changed the system prompt, the tools, and the middleware, and touched nothing else. The whitepaper presents the rank jump and the point gain as two separate results from two teams; they are one experiment, one team, one receipt. The receipt is strong. It is also singular, and it deserves counting once.
For a solo builder this section is the practical center of the paper. Your [CLAUDE.md or AGENTS.md](/primer/how-to-use-claude-code/), your test commands, the rules you add every time the agent repeats a mistake: that unglamorous file is the harness, it compounds, and it is yours rather than the model vendor's. The searches rising around the paper, harness engineering among them, suggest the market is catching on to where the leverage sits.
## The lifecycle, phase by phase
The paper's SDLC chapter keeps the traditional six phases and redistributes the time inside them. Requirements stop being a handoff document and become a conversation that produces a spec and a working prototype in the same sitting. Architecture stays, in the paper's phrase, stubbornly human, because trade-offs depend on business context the model does not hold. Implementation compresses from weeks to hours. Testing inverts into the steering wheel: a well-written test and eval suite is how you communicate intent to the agent, checked two ways, output evaluation for whether the result is right and trajectory evaluation for whether the path there was sound. Review gains an AI first-pass but keeps human judgment on design and maintainability. And maintenance, the paper argues, is the most underestimated shift, because codebases that were too risky to touch can now be navigated and refactored with an agent that respects the existing architecture.
The mental model tying it together is the factory: the developer's primary output stops being code and becomes the system that produces code, specs, agents, quality gates, feedback loops, and guardrails. You design the assembly line and audit its output instead of assembling every widget by hand.
The honest caveat lives right in the paper: a note admits the phase boundaries reflect mid-2026 and may look different within twelve months. Hold the framework, not the diagram.
## The numbers, checked
This is the part of the paper we are equipped to referee, because we have [verified most of the underlying research before](/study/does-ai-coding-make-you-faster/). The framework survives the check. Some of its statistics need flags the paper does not carry.
The opening claim, 85% of professional developers regularly using AI coding agents, 51% daily, 41% of new code AI-generated, carries a single endnote, and that endnote points to two marketing statistics roundups, GetPanto and Index.dev, rather than any primary study. The strange part is that real primaries exist and are stronger. [Stack Overflow's 2025 survey](https://survey.stackoverflow.co/2025) of 49,009 developers found 51% of professionals using AI tools daily, which is presumably where the aggregators got it. Google's own [DORA 2025 report](https://dora.dev/dora-report-2025/) puts adoption at 90% among nearly 5,000 respondents. The adoption story is true and citable one link deeper than the paper goes. The 41% AI-generated share is the one we could not trace to any primary source at all; treat it as an industry estimate, the same way [we treat company-disclosed revenue](/study/is-vibe-coding-worth-it/).
The productivity range, 25 to 39% per industry surveys, cites two vendor blog posts, with a Deloitte projection of 30 to 35% in a neighboring endnote. Projections and vendor surveys are the softest tier of evidence there is; the controlled trials we have verified separately run [26% to 56% on fresh builds](/study/does-ai-coding-make-you-faster/), so the direction is right even where the citation is thin. The paper's METR sentence, experienced developers 19% slower once verification time is counted, is a real result and deserves its context: sixteen expert maintainers on mature repositories they knew intimately, using early-2025 tools, with [METR's own February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) reading newer data as weak evidence the speedup has arrived. And the economics chapter's claim that past the crossover vibe coding costs 3 to 10x more per feature is labeled here plainly: that number illustrates a curve in a figure, measured by no study we could find.
None of this sinks the paper. It means the paper is best read as a framework document with a statistics garnish, and the framework is the part built to last. An independent practitioner review [reached the same verdict](https://thelazysre.com/posts/i-read-googles-the-new-sdlc/) from the operations side: right about the shift, too clean about the friction.
## The economics, sized for one person
The chapter most relevant to this site's beat recasts the spectrum as a cost structure. Vibe coding is low CapEx, high OpEx: nothing upfront, then a compounding bill in token burn from fix-it-again loops, maintenance on structurally inconsistent code, and security remediation after the fact. Agentic engineering is the inverse, high CapEx, low OpEx: you pay upfront in specs, tests, and context design, and the marginal feature gets cheap because the agent's first pass lands more often.
We would add the solo builder's corollary the paper leaves implicit: the two cost structures are a sequence, and the crossover has a name, validation. Vibe code while the idea is unproven, because speed-to-signal is the only metric and the code is disposable by design. The day real users arrive, the OpEx curve starts compounding, and that is the day the harness investment, the tests, the AGENTS.md, [the cleanup pass you schedule like an oil change](/study/is-vibe-coding-worth-it/), becomes the cheapest money in the budget. The paper also endorses model routing as a cost lever, big models for architecture and first implementation, small cheap ones for test generation and review, which is the same [token arithmetic](/study/unit-economics-of-wrapping-an-llm/) that governs any product wrapping an LLM.
## What to actually do
The paper closes with adoption lists, and the individual-developer one is genuinely good, so here it is, compressed and reordered for someone shipping alone with [a working stack](/primer/vibe-coding-stack/):
1. **Write the ten-line AGENTS.md today.** Stack, conventions, hard rules, workflow. Add a rule every time the agent repeats a mistake, and the file becomes your compounding asset.
2. **Turn one repetitive workflow into your first agent.** A research loop, a review pass, a recurring report. Building one end to end teaches more than reading about a hundred.
3. **Write the tests and evals before generating the code.** They are the contract; a good suite communicates intent more precisely than any prompt.
4. **Review every line that ships.** Be skeptical of anything clever, check that imports name real packages, and confirm error handling covers realistic failures. Code you do not understand is debugging cost you cannot afford.
5. **Keep your own skills sharp.** The arrangement only works while your debugging and design judgment stay strong enough to referee the output.
The paper's closing principles say the quiet part well: structure scales and vibes do not, AI amplifies whatever engineering culture it lands in, and the human role is shifting from implementation to judgment. Its final sentence is the whole document in ten words: "Generation is solved. Verification, judgment, and direction are the new craft." That matches every number we have checked, in this piece and the ones before it. The builders who win the next stretch are the ones who take the free speed and then buy the verification with it.
---
# What a customer actually costs: CAC by channel for a one-person AI product
Section: The Study
URL: https://okaneland.com/study/cac-by-channel-ai-product/
Every channel has a number, and almost every published number is sold to you by someone who wants you to pick their channel. The grounded figures run near $800 a customer for paid search, about $205 for SEO, and close to zero cash for owned channels, and whatever any of them buys an AI product churns about 30% faster. The answer for a one-person AI product is the channel your own time can run.
Search "customer acquisition cost by channel" and you get a tidy table: referral cheapest, paid search in the middle, LinkedIn at the top. Look at who published it and the table is almost always an agency that sells one of those channels. The most-cited CAC-by-channel numbers come from a company that sells SEO and content. The referral numbers come from companies that sell referral software. The numbers are not fake, but they are marketing, and they are aimed at getting you to pick the channel the publisher happens to rent. The answer, for a one-person AI product, is the channel your own time can run.
So this is one table built from the least self-interested sources I could find, with every vendor figure flagged as directional, judged against one question a one-person AI product actually has to answer: can you recover the cost before the customer churns? Because the catch that none of the channel tables price is that an AI product is buying revenue that leaks faster than the SaaS the benchmarks were built on.
## The short version
If you are choosing where to spend, the numbers land like this:
- **Paid runs hundreds of dollars a customer.** B2B paid search sits near [$800](https://firstpagesage.com), LinkedIn near $982 with a $4-5k monthly floor just to get a signal, and Meta's cheap clicks are mostly unmeasurable since Apple's tracking prompt.
- **Earned is cheaper, slower, and eroding.** SEO lands [around $205](https://firstpagesage.com) with a seven-month payback, while AI Overviews have taken [58% of the clicks](https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/) off the top result.
- **The AI catch shrinks every payback.** Consumer AI churns [about 30% faster](https://www.revenuecat.com/state-of-subscription-apps-2026/) than non-AI apps, worst under $50 a month, so the same CAC repays from a thinner stream.
- **Founder hours are a cost the tables skip.** Content CAC swings [between about $20 and $180](https://www.growandconvert.com/content-marketing/cost-of-content-marketing/) depending on whose salary does the writing; a free channel bills you in time.
- **The order of operations:** owned email first, community and replies as feeders, referral once users retain, and paid only after LTV clears the [3:1 bar](https://www.forentrepreneurs.com/saas-metrics-2/) (the zero-budget version of that sequence is [how to get your first 10 users](/ledger/first-10-users/)).
The channel-by-channel evidence is below.
## The number is always for sale
Two anchors hold the whole piece up, and neither is selling a channel.
The first is the viability bar. The rule that a customer should be worth about three times what they cost to acquire, and that you should recover the cost in under a year, traces to [David Skok's SaaS Metrics](https://www.forentrepreneurs.com/saas-metrics-2/), written by an investor describing what makes a business survivable, which beats an agency describing what to buy. Treat 3:1 LTV to CAC and sub-twelve-month payback as a floor. The best SaaS recovers CAC in five to seven months.
The second is the AI catch, and it sits on the LTV side of that ratio. Consumer AI apps [churn about 30 percent faster](https://www.revenuecat.com/state-of-subscription-apps-2026/) than non-AI apps, per RevenueCat's 2026 report across more than 115,000 apps: 6.1 percent twelve-month retention against 9.5 percent. The cheap end is worse still. AI products under $50 a month show gross revenue retention around [23 percent](https://www.growthunhinged.com), the weakest of any tier, while $250-plus AI products retain like normal SaaS. Add gross margins that run [roughly 45 to 52 percent](https://www.saastr.com) against SaaS's 80 to 90, because the model provider takes a cut of every call, and the same CAC has to be repaid from a thinner, faster-draining stream. Every channel below inherits that problem.
Here is the table. Read the catch column first.
| Channel | Directional CAC | The catch |
|---|---|---|
| Paid search (Google) | ~$800 B2B SaaS | Real buyer intent, but only clears above meaningful LTV |
| Paid social (Meta / X) | ~$230; cheapest clicks | Cheap clicks are not ROI, and you cannot measure the CAC |
| LinkedIn ads | ~$982; $100-150 per lead | Needs $4-5k/mo just for a signal |
| SEO / content | ~$205; ~7-month payback | Front-loaded, slow, and the clicks are eroding |
| Owned newsletter | near-zero cash | The list is the asset, but building it is time |
| Founder-led | near-zero cash | Reach is mostly other founders, rarely buyers |
| Community / forum | ~$0 cash | Rules-fragile, time-heavy, a feeder not a sale |
| Referral | ~$23 cheaper, +16-25% LTV | A multiplier that needs retained customers first |
The dollar CACs for paid search, LinkedIn, and referral come from [First Page Sage](https://firstpagesage.com), an agency that sells organic channels, built from multi-year client averages that fold in a learning period. Read them as order-of-magnitude.
## The paid channels, sorted by buyer intent
Rank paid by buyer intent and the order flips from what the CPC suggests.
Google Search sits in the middle on cost and top on intent, because someone typing your category is looking to buy. WordStream's [2025 benchmarks](https://www.wordstream.com/blog/ws/2022/05/18/search-advertising-benchmarks) put the all-industry cost per lead near $70, and business services above $100. But a lead is not a customer, and software landing pages convert visitors to signups at a [median around 3.8 percent](https://unbounce.com/conversion-benchmark-report/) per Unbounce, below the all-industry 6.6. Multiply it out and the real customer CAC lands in the hundreds. Worth it when your LTV is real. Underwater when you are charging $19 a month.
Meta and X are the cheapest raw traffic, and the biggest trap. Meta traffic clicks run [around $0.70](https://www.wordstream.com/facebook-advertising-benchmarks) and lead-form leads under $30. X's CPM sits at or below Meta's now, with clicks well under a dollar. Cheap. The problem is that you cannot tell what any of it did, because after Apple's tracking prompt about 86 percent of users opt out, so channel-level attribution mostly does not exist at a solo operator's volume. You will spend $400, gain some signups, and never know which came from the ad. Cheap clicks you cannot measure are a way to lose money slowly with a dashboard that looks busy.
LinkedIn is the most expensive lead in software, and sometimes worth it, almost never for you. HockeyStack's [2025 benchmark](https://www.hockeystack.com) across tens of millions in SaaS spend puts clicks above $8 and cost per lead in the $100-to-$150 range, and the practical floor to get a readable signal is four to five thousand dollars a month. That math works above a few-thousand-dollar contract value. It prices out nearly every one-person AI product.
The verdict on paid: it is a tool for scaling a channel that already converts, and a bad way to find out whether anyone wants the thing. At seed stage, paid mostly buys you an unmeasurable number and a smaller bank balance.
## The earned channels, and why cheap has a time bill
Earned channels are cheaper in cash and expensive in the one thing a solo founder cannot buy back.
SEO and content beat paid, but by less than the brochures claim. The credible gap for B2B software is [about $205 organic against $341 paid](https://firstpagesage.com), a 20-to-50 percent saving, far short of the five-to-ten-times the category pages imply, and a content program takes around seven months to break even.
And the ground is moving under it. Google's AI Overviews cut clicks to the top organic result by [58 percent](https://ahrefs.com/blog/ai-overviews-reduce-clicks-update/) as of early 2026 per Ahrefs, with position-one click-through falling from 7.6 to 1.6 percent. Independent [Pew data](https://www.pewresearch.org) shows users click a normal result about half as often when an AI summary appears. Close to 58 percent of US searches already end with no click at all, and roughly 83 percent when an AI Overview is present. The work is shifting from earning the click to [being the source the AI cites](/study/what-a-chatgpt-citation-is-worth/), which is a different skill and a moving target.
Owned email is the workhorse of the whole table. A list converts to paid at [something like 2 to 5 percent](https://www.activecampaign.com), against a fraction of a percent for raw social reach, so a small list can out-earn a large following. Bought subscribers run a dollar or two each, which means the cash-cheap path is building the list yourself over time. That time is the cost, and it is real, but the list is the one asset every other channel on this table should be feeding.
Founder-led building gets one row here on purpose, because it has its own piece. Raw followers convert to customers at a fraction of a percent, the audience skews toward other builders rather than buyers, and a useful reply on someone's frustration thread converts far better than a broadcast post. The full funnel math is in [the build-in-public study](/study/build-in-public-revenue/); on this table it is a near-zero-cash, high-time feeder.
Community and referral round out the cheap end. There are real $0-spend community wins, one documented case reached about $17,000 in monthly revenue in four months on value-first posting alone, though that is one self-reported story and no benchmark, and community marketing is fragile: a promotional post from a new account gets removed or shadowbanned fast. MicroConf's survey, via [Freemius](https://freemius.com), found [47 percent of indie founders](https://freemius.com) name integrations and communities as their most dependable growth source, having given up on unmeasurable paid ads.
Referral is the strongest cheap channel when it fires: the primary [Wharton study](https://www.journals.sagepub.com) of about 10,000 customers found referred customers cost roughly $23 less to acquire and were worth 16 to 25 percent more over time. That is 2011 banking data, so treat the magnitudes as directional for a 2026 AI product, but the direction is well established. The catch is that referral is a multiplier on happy, retained customers, and a fast-churning product may never accumulate enough of them to turn it on.
## The bar every channel has to clear
Lay the viability bar over the table and most paid options fall off for a low-priced AI product.
The bar is 3:1 LTV to CAC and payback under twelve months, five to seven for the best SaaS. A self-serve product should recover CAC in one to seven months. So a paid channel that cannot pay itself back inside a year is a leak.
Now stack the AI catch on top. The revenue you are buying churns about 30 percent faster than the SaaS these benchmarks assume, the sub-$50 tier retains worst of all, and the margin on each dollar is roughly half. The same $230 Meta CAC that a healthy SaaS repays comfortably has to come back out of a customer who is likelier to cancel this quarter and whose payment is [half margin](/study/unit-economics-of-wrapping-an-llm/). The generic benchmark says the channel works. The AI-adjusted math says it might not. This is why the cheapest click can still be the worst buy: what you acquired may cancel before it ever pays you back.
## Your time is the CAC nobody prices
Here is the number that reframes the whole table. Grow & Convert modeled the CAC of content marketing and found it swings from [about $20 to about $180](https://www.growandconvert.com/content-marketing/cost-of-content-marketing/) per customer purely by changing what you pay the person writing, from nothing to $10,000 a month. The channel did not change. The founder's salary did. A "free" channel is an opportunity-cost subsidy you are paying out of your own hours, and for a solo founder those hours are the scarcest input there is.
That is the clear-eyed way to read the cheap end of the table, and it cuts both directions. Founder-led and community cost no cash and a great deal of time, so they are cheap only if your time is worth little, and expensive the moment it is worth a lot. Paid costs cash and little time, which is exactly why it is the right tool once a channel converts and you want to stop being the channel.
Two disciplines keep this from fooling you. First, blended CAC lies. [Hustle Fund's worked example](https://www.hustlefund.vc) shows a true $100 paid CAC hiding as an $80 blended number once free organic wins are averaged in, so you keep funding a paid channel that is quietly underwater. Track cost per activated user by channel where you can; the blended average flatters. Second, at a solo operator's volume you often cannot attribute cleanly at all, which is an argument for channels whose cost is your time rather than your budget, because a misfire there costs a weekend.
This is the part I can speak to from inside, at the small scale where the mechanics are visible and nothing is inflating them. Okane Land runs four of these channels itself: SEO written to [be cited by AI answers](/study/aeo-and-geo-what-the-research-says/) as much as ranked, a self-owned newsletter off an organically built list, a daily reply loop on a sub-200-follower X account that leads with a number and keeps the link out of the main post, and a community forum that the articles feed into.
What that daily practice teaches is exactly what the table says: the reply that helps converts better than the post that broadcasts, the list is where everything should point, and the whole thing runs on time, with no ad budget anywhere. Those are mechanics I can show. Any CAC figure I have not measured, I will not claim.
## Where a one-person AI product should actually spend
The verdict is an order of operations.
Build the owned email list first, because it converts an order of magnitude better than reach and it is where every other channel should terminate. A follower you cannot email is top-of-funnel; a subscriber is the funnel's floor.
Use community, founder-led building, and cold outreach as feeders into that list, and treat a launch platform like Product Hunt as one-time awareness that mostly rewards people who already have a list to mobilize. Turn on referral once you have a base of retained, happy users, since it multiplies what exists and cannot start from cold. Keep paid off until a channel already converts and the product's LTV clears the payback bar. For most sub-$50-a-month AI products, that means paid stays off until retention is fixed, because paid acquisition into a leaking product just empties the bucket faster and with a receipt.
Which lands on the through-line the channel tables leave out. The cheapest customer is the one your own time can acquire repeatably, and the real work is making the product retain, so that acquiring a customer is worth paying for at all. Fix the leak first. Then the channel you pick barely matters, and only then can you afford to buy your time back with paid.
---
# Perplexity Pro limits: the shrinking $20 plan, in 1,024 posts
Section: The Study
URL: https://okaneland.com/study/perplexity-pro-limits/
We coded 1,024 posts from Perplexity subscribers across five communities. The pattern is one quota cut after another on the $20 tier, a routing scandal the CEO called an engineering bug, and a cancellation wave that is still visible in search data. Pro remains the tier to buy, checked, month to month.
In February 2026, Perplexity announced an upgrade to Deep Research, and the replies under the announcement did the arithmetic the post left out: the Pro allowance had moved from hundreds of runs a day to [about twenty a month](https://www.reddit.com/r/perplexity_ai/comments/1qvxx6s/). It was the second time in four months that paying subscribers found out about a cut by hitting it. It was not the last. If you pay Perplexity anything, Pro is still the tier to buy, and every limit you read, including the ones on their own pricing page, should be treated as provisional until you see it hold in your account.
That is the sharpened version of the verdict from [our hands-on Max review](/proof/perplexity/), and this piece is the evidence behind the sharpening. We collected and coded 1,024 posts from Perplexity's paying subscribers, across the subreddit, the official forum, Hacker News, the App Store, and Trustpilot, to answer the question a review of a moving product cannot: what happens to the tier after the reviewer leaves. The search data says people are asking. Worldwide interest in "cancel perplexity" hit its 12-month peak this month, and "perplexity pro limits" runs neck and neck with it.
## The short version
- **The $20 plan shrank three times in eight months.** November 2025: subscribers proved selected models were being silently swapped for cheaper ones, and the CEO [called it "an engineering bug"](https://www.reddit.com/r/perplexity_ai/comments/1orar1a/). February 2026: Deep Research fell from hundreds of daily runs to [about 20 a month](https://www.reddit.com/r/perplexity_ai/comments/1qwhej3/). May 2026: Pro searches were [halved to 100 a week](https://www.reddit.com/r/perplexity_ai/comments/1tcvvbx/), mid-term, for people who had prepaid a year.
- **Limits are the complaint that names itself.** Across our coded posts, price-and-value gripes (121) and limit-and-quota reports (113) dwarf every other specific cluster, and the quota posts carry the receipts: screenshots, API responses, before-and-after counts.
- **Max defenders exist, and they all look the same.** Every named Max advocate we found runs heavy agent workloads. The loudest one concedes his value comes from the agent, and that for plain search he uses the default model anyway.
- **The mirrors disagree because the doors do.** Google Play shows 4.6 stars across 2.03M ratings. Trustpilot shows 1.5 across 707 reviews, 82% of them one-star. The free app is well liked; the people angry enough to file a review about money are angry about money. Neither number alone is "Perplexity users."
- **The pricing page publishes no numbers for Pro.** As of July 2026 it promises "usage limits for everyday use," unquantified, while only the $200 Max tier says "unlimited." The checklist at the bottom is how you buy around that.
Everything below is the evidence, with the caveats attached where they belong.
## How we counted, and what the count cannot say
The dataset is 1,024 posts from the past year: 359 from 19 hand-read threads on r/perplexity_ai, 101 from the official community forum, 394 from Hacker News, 150 recent App Store reviews, and the first page of Trustpilot. Each post was coded for topic, stated tier, and whether the author was keeping, cancelling, or deciding. The counts come from keyword matching with a hand-checked pass on top, so they undercount anything people describe in their own words, and every one of these channels is self-selected. Nobody posts "my subscription worked today." What the corpus is good for is ranking what paying users bring up on their own, and quoting them verbatim. That is how we use it. The full annotation file, one coded row per post with its permalink, is [published as an open dataset](/data/perplexity-pro-limits/) so you can check the coding yourself.
One population note matters more than the rest: a very large cohort got Pro free for a year through PayPal, Venmo, Revolut, and carrier promotions, and those accounts were reportedly throttled hardest. Some of the anger in these threads is promo users meeting the real price of what they were given. Some of it is from people who paid cash and watched the product change under them mid-contract. We flag which is which where the poster says so.
## Three cuts in eight months
**November 2025, the routing scandal.** The year's top thread on r/perplexity_ai, at 1,242 points, showed Claude-labeled answers [being served by cheaper models](https://www.reddit.com/r/perplexity_ai/comments/1opaiam/), verified by an open-source browser extension that watched the network traffic. The CEO responded in person: ["this was an engineering bug, and we wouldn't have found it without this thread."](https://www.reddit.com/r/perplexity_ai/comments/1orar1a/) The top reply, at 311 points, kept the receipts in frame: "The quality genuinely dropped... even when the UI claimed it was" the selected model. Whatever the cause, the episode taught the community to verify the label, and a chunk of it never went back to trusting the picker.
**February 2026, Deep Research.** The upgrade announcement doubled as a quota change. A separate thread titled ["99.89% Reduction in Research quota over night without any formal communication"](https://www.reddit.com/r/perplexity_ai/comments/1qwhej3/) put numbers on it: roughly 600 runs a day before, about 20 a month after. One annual subscriber posted the pricing page still advertising unlimited research next to his empty meter and started a chargeback.
**May 2026, Pro searches.** Subscribers found the weekly allowance [cut from 200 to 100](https://www.reddit.com/r/perplexity_ai/comments/1tcvvbx/), visible in the account API as a remaining-quota field, with no notice. The detail that filled the thread was contractual: it applied [mid-term to prepaid annual plans](https://www.reddit.com/r/perplexity_ai/comments/1tdzkw6/). One self-paying subscriber, distancing himself from the promo cohort: "I paid the full price for a year with my own money."
By July 2026 the threads stopped being about any single cut. ["What Happened to Perplexity?"](https://www.reddit.com/r/perplexity_ai/comments/1ursxpb/) is 432 points of former daily users comparing exit dates, and a 13-month Pro subscriber [cancelled the week we gathered](https://www.reddit.com/r/perplexity_ai/comments/1v0zre2/): "the platform has gone downhill so fast recently that I just can't justify the price tag anymore."
## What 1,024 posts complain about
| cluster | coded posts | where it concentrates |
|---|---|---|
| price and value | 121 | Hacker News, Reddit |
| limits and quotas | 113 | Reddit, the official forum |
| Computer agent credits | 63 | Hacker News |
| billing and refunds | 47 | Trustpilot, the official forum |
| Deep Research | 46 | the official forum, Reddit |
| model routing | 34 | Reddit |
Keyword counts undercount, and the routing number is the proof: 34 coded posts, sitting under three threads totaling more than 2,200 points and 500 comments. Volume of feeling and volume of keyword are different things. The Computer agent credit cluster is worth a line of its own, because it is the newest complaint shape: the agent is genuinely capable, and it meters through credits at a pace users describe with the word "burned." One Max subscriber: "70k credits burned in 2 months." One Pro user who topped up: "I just bought 1500 credits and it burned through them so quickly."
## Is Max the fix? The defenders answer it for us
Our [review's verdict](/proof/perplexity/) was that $200 Max is for a narrow heavy-use case. The community's Max defenders, read closely, agree. The most committed one titled his thread ["Pro plan is a SCAM, Max plan ($200) is worth every penny"](https://www.reddit.com/r/perplexity_ai/comments/1qntzzx/) and claims Max saves him ten hours a week. Under questioning he concedes that web search is "Not the primary for sure" of his usage, and that for searches he picks the default model anyway. His whole case is the agent running tasks in parallel while he works. The thread sits at zero points, and its top reply is the median subscriber's answer: "most people aren't using or gaining from it enough to justify shelling out $200 a month."
The other named defenders match the profile: one calls Opus through Max with MCP connectors "worth it in max alone," another switched for heavy Research and Labs throughput. All of them describe the workload our review carved out. Meanwhile Max has its own complaint file: a Trustpilot reviewer paying $200 a month calling the results "the worse by far" of the AIs he pays for, a Max user who left because he "used to hit my limit on perplexity all the time and have to buy credits," and forum reports that quota complaints now come from Max accounts too. Upgrading to escape the limits is buying a higher ceiling in the same weather.
## Two mirrors, one product
Zoom out and the product looks loved. Google Play: 4.6 stars, 2.03M ratings, an Editors' Choice badge. Zoom into the channels where paying customers file grievances and it looks radioactive. Trustpilot: 1.5 out of 5 across 707 reviews, 82% one-star, nearly all of them billing and refund disputes. Our 150-review App Store slice splits the same way: 85 five-star reviews praising the answers, 44 one-star reviews about charges and walls.
Both mirrors are accurate for the door they stand behind. The broad, mostly free user base likes the app. The people who gave Perplexity money and hit a limit, a charge, or a support queue are the unhappy ones, and they are the population this piece is about, which is exactly why we would not quote our own numbers as "most users." Self-selection cuts both ways, and any review, ours included, that ignores one mirror is selling you the other.
## Before you pay: the checklist
The pricing page, [as we captured it in July 2026](https://www.perplexity.ai/pro), lists Pro at $17 a month billed annually with "usage limits for everyday use," no numbers attached, and reserves the word "unlimited" for the $167-a-month Max tier. The current limits live in your account, and they have a documented habit of moving. So:
1. **Buy month to month first.** The clean pattern across every angry thread is prepaid annual plans meeting mid-term cuts. A monthly plan turns a quota change into a decision instead of a dispute.
2. **Count your own quotas in week one.** Run your normal workload and watch the meters: Pro searches, Research runs, agent credits. The numbers you observe are the product you bought; write them down, because the change logs will not.
3. **Verify the model label if it matters.** The routing episode ended with a fix and a promise of transparency. Trust it the way this community now does, by checking. Same prompt to the model's own app is the cheap test.
4. **Learn what the tool is before paying at all.** Our [primer covers what Pro actually buys you](/primer/how-to-use-perplexity/) and the citation-checking habit that makes any tier worth using. And if your workload is the heavy agent-and-research profile, [the Max review](/proof/perplexity/) is the map of what $200 does and does not add.
The pattern we coded is not unique to one company: every AI subscription reprices as [inference costs meet investor math](/study/unit-economics-of-wrapping-an-llm/). What the 1,024 posts add is the subscriber's-eye view of what that repricing feels like, and the defense against it. Pay monthly, count what you get, and let your own meter tell you what the plan is.
---
# Does building in public actually pay?
Section: The Study
URL: https://okaneland.com/study/build-in-public-revenue/
An audience can sell a product for you, and it can just as easily inflate one that was never selling. The evidence splits on a single variable: building in public multiplies a product that retains, and it multiplies nothing when there is nothing under it.
In June 2025, Wix paid [eighty million dollars in cash](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/) for a six-month-old company built by one person. Maor Shlomo had bootstrapped Base44 alone, raised no outside money, spent nothing on ads, and grown it entirely by documenting the build in public on LinkedIn and X. Nine months after the acquisition it was doing [one hundred million dollars in ARR](https://www.calcalistech.com/ctechnews/article/bkqq0pry11e), and about a hundred and fifty million by May 2026. It is the cleanest evidence you will find that building in public pays. It is also not the lesson. Building in public multiplied a product that deserved it, and that order is the entire trick.
In the same twelve months, another founder built in public just as loudly, got a [$15 million Series A](/study/ai-startup-raise-math/) partly on the strength of that attention, and then [admitted in March 2026](https://techcrunch.com/2026/03/05/cluely-ceo-roy-lee-admits-to-publicly-lying-about-revenue-numbers-last-year/) that the $7 million ARR he had told the press was, in his own words, "a lie." His real number was closer to $5.2 million. Same tactic, and it produced a fabricated headline instead of a clean exit.
When one tactic produces an $80 million exit, a fabricated revenue figure, and a long tail of accounts that never make a dollar, the tactic is not the thing doing the work. Building in public is a multiplier, and a multiplier needs something real to multiply.
## The short version
If you are deciding where your hours go, the evidence supports this much:
- **The tactic decides nothing on its own.** One playbook, one year: an [$80M cash exit](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/), a confessed-fake [$7M ARR](https://techcrunch.com/2026/03/05/cluely-ceo-roy-lee-admits-to-publicly-lying-about-revenue-numbers-last-year/) that was really $5.2M, and [$348,000 of revenue after a $1M+ ad blitz](https://fortune.com/2025/10/03/friend-ai-necklace-subway-ad-campaign-avi-schiffman/).
- **Followers buy at a fraction of a percent.** Photo AI launched to roughly 350,000 followers and converted [around 0.06%](https://www.indiehackers.com) to customers in week one, per an analyst estimate.
- **The median public build earns $500 a month.** Across [326 disclosed indie projects](https://www.indielaunches.com), that is the base rate under the highlight reel.
- **Email is the only funnel stage that pays.** Purchase conversion runs [4 to 8% from a list](https://simonowens.substack.com) against well under half a percent from organic social, and every durable case captured one.
- **Four gates before you commit:** retention above the 40% very-disappointed bar, posts that end in email capture, formats the platforms score ([a reply is worth 13.5 likes on X](https://github.com/twitter/the-algorithm-ml)), and real numbers only.
Everything below is the evidence, the survivors and the silence both.
## One real win, two traps
Start with the three outcomes side by side, because they set the whole frame.
**Base44 is the win, and it is real.** An acquirer paid cash, and the numbers kept climbing on someone else's books afterward. Shlomo hit a million in ARR about three weeks after launch, reached roughly 250,000 users before spending a cent on marketing, and the public build was the entire growth engine. The audience worked because there was a product under it that people kept using.
**Trap one is the fabricated number.** Cluely's Roy Lee ran the same playbook, loud and constant, and a16z partner Bryan Kim [led its Series A](https://techcrunch.com/2026/06/26/why-a16z-vc-believes-that-cluely-the-cheat-on-everything-startup-is-the-new-blueprint-for-ai-startups/) on the explicit thesis that for consumer AI "momentum is the moat." But momentum measured in impressions is not revenue, and the gap between the two created a pressure that Lee eventually resolved by inflating the revenue to match the attention. Building in public did not cause the lie. It raised the stakes on the number until the number bent.
**Trap two is mistaking spend for demand.** Friend.com poured [more than a million dollars into 11,000-plus New York subway ads](https://fortune.com/2025/10/03/friend-ai-necklace-subway-ad-campaign-avi-schiffman/), one of the most visible marketing blitzes an AI hardware startup has run. By the founder's own account it had shipped around a thousand units, roughly $348,000 of revenue, before the company pivoted the pendant toward a free web chatbot. Visibility is not traction, and [paid reach carries its own brutal economics](/study/ai-ugc-ad-economics/). A packed feed and a packed subway car can both be bought, and neither one is a customer.
Three founders, one tactic, three outcomes. The variable is what you are multiplying.
## What actually gets paid
Look only at the cases that held up under scrutiny, and a pattern repeats: the public build fed an owned channel, and the product retained.
Base44 is the ceiling. The floor of the "it worked" stories is more instructive. Marc Lou, an indie maker who has built in public for years, [self-reported](https://marclou.com) a personal $1,032,000 for 2025 across products like ShipFast and CodeFast, and he is candid that growth came from customers sharing screenshots of his stuff, an audience compounding on a product people used. That figure is his own, unaudited, and worth reading as a founder's claim rather than a filed number, but the shape of it fits: public building plus a product that delivered.
Senja, a testimonials tool, [reached about a million in ARR](https://www.thesuccessfulfounder.com) by late 2025, and its founders say something the highlight reels leave out: building in public seeded their early adopters, but the repeatable revenue came from SEO and product-led growth. The audience was the ignition; the engine was the product.
Then there is the rare fully transparent case. Buffer has published a live metrics dashboard for years, salaries since 2013 and revenue since 2020, and as of this writing it shows [about $25.6 million in ARR](https://buffer.com/transparency). That is what verifiable building in public looks like: an audited-style number anyone can load, the opposite of an axis-free Stripe screenshot posted for a dopamine hit. The community has learned to tell them apart, and the second kind is why so many public numbers deserve a squint.
The wins are real. They are also outliers, and in every durable one the same two things were true: the product retained, and the public building terminated in something the founder owned.
## The funnel math nobody tweets
Here is the arithmetic that never makes it into the "how I grew my audience" thread.
Raw followers convert at a fraction of a percent. Pieter Levels, one of the most followed builders alive, launched Photo AI to an audience of roughly 350,000 and did about $5,400 in first-week MRR. Worked back to customers, [that is around 0.06 percent](https://www.indiehackers.com) of the following, and I will flag that the conversion figure is an Indie Hackers analyst's estimate rather than a number Levels reported. Even generously, a huge follower count turns into a small number of buyers. Followers are the widest, shallowest part of the funnel.
The median builder is not Pieter Levels. Across [326 indie projects disclosed on Hacker News](https://www.indielaunches.com), the median revenue was five hundred dollars a month. Read the zeroes again: five hundred, with nearly half the parseable projects sitting in the $500-to-$1,000 band. The timeline you scroll is a survivorship highlight reel stacked on top of that median, and the median is where you land by default. It is the base rate [a one-person AI business](/ledger/economics-of-a-one-person-ai-business/) has to clear. The vibe-coding version of that highlight reel, itemized against its denominator, is [its own piece](/study/after-the-vibecode-wins-and-denominator/).
Owned beats rented by an order of magnitude. Email converts to purchase in the low single digits, commonly cited around 4 to 8 percent, while organic social sits well under half a percent. Free-to-paid conversion on a newsletter runs [around 0.6 percent at the median and up toward 5 percent](https://simonowens.substack.com) for strong independent operators like Casey Newton. Those benchmark ranges come partly from tooling vendors, so read them as directional, but the direction is not in dispute: a name and an email address are worth many multiples of a follow. The reason the durable cases all captured an email list is that the list is the only part of the funnel that pays at a rate you can build on.
So the real value of an audience is that it de-risks a launch and seeds an owned asset. Treat it as a compounding list-builder, and the math starts to make sense.
## The platform mechanics you are actually playing
If you are going to build in public, at least play the game the platforms actually score.
X tells you its scoring, because it open-sourced the ranker. [The published weights](https://github.com/twitter/the-algorithm-ml) put a reply at 13.5 times the value of a like, and a reply the original author then engages with at 75 times, against a like's 0.5. Link posts are penalized, and Musk has said out loud to put the link in a reply rather than the main post. Read that as instruction: the platform pays for conversation and taxes the outbound link. The weights are from the 2023 snapshot and may not match current production exactly, but the design intent is unambiguous.
This is where I will point at our own work, at a scale small enough to be evidence about mechanics and nothing more. Okane Land runs a daily, human-approved reply loop on a sub-200-follower brand account. We lead every reply with a real number or a receipt and keep links out of the main post, on purpose, because those are exactly the mechanics above: the algorithm pays for the reply and the conversation, and it taxes the link. That is a first-hand look at the machine from inside; no revenue story attached. A small account is the right place to watch a mechanic work precisely because nothing else is inflating the result.
LinkedIn scores format too. Across [1.3 million posts](https://www.socialinsider.io), native documents pulled roughly 7 percent engagement against about 3.25 percent for plain link posts, and personal profiles out-reach company pages. The specific "personal gets you 561 percent more" number that circulates is a growth-vendor stat, so ignore the multiplier and keep the direction: native content from a person beats a link from a page.
And the launch-day folklore is stale. Product Hunt now features only [around 9 to 10 percent of launches](https://awesome-directories.com) after its 2024 shift to hand-curation, per independent analyses of launch data, since the platform publishes no official figure. The old "win the day and the traffic follows" playbook mostly does not fire anymore. Owned channels are the default now. The launch feeds have a second problem: [most of what launches quietly goes dark](/study/how-many-vibe-coded-launches-are-alive/).
## The skeptic's cut: why the median is silence
Everything above still flatters the tactic, because the feed only shows you the survivors.
Prolific builders ship constantly and most of what they ship fails. Marc Lou has launched more than twenty products in a year, most going nowhere, and nobody live-tweets the ones that die. What you see as a stream of wins is the filtered top of a much larger pile of quiet failures, and the filtering is the point.
The base rate is low and getting lower. Goldman Sachs Research estimates that [about 4 percent](https://www.goldmansachs.com) of the world's roughly 50 million creators earn over $100,000 a year, down from around 10 percent in 2022. Building an audience is competing in a market where the professional tier is shrinking as a share.
An audience cannot rescue a product with no retention. [Failory's post-mortems](https://www.failory.com) are full of products that launched to real traffic and died anyway because nobody came back. The gate is retention, best proxied by the Sean Ellis test: if fewer than 40 percent of users would be very disappointed to lose your product, attention just pours more people into a leaking bucket. Distribution multiplies churn as readily as it multiplies revenue.
Two costs rarely get priced. The first is your own energy. A daily content treadmill is a second job stacked on the first, and founder capacity is finite: a 2025 [Sifted survey of 138 founders](https://sifted.eu) found 54 percent reporting burnout and 83 percent reporting high stress over the prior year. The second is the pressure the public number creates. Once revenue is a public metric, there is a documented pull to inflate it, [ARR being one of the most abused figures in the AI era](https://fortune.com). Cluely is just the confession that made it onto the record.
## So it pays: a decision framework
Building in public pays under specific conditions. Run it through four gates before you commit your hours.
**Gate one: retention before reach.** Do not amplify a product that fails the 40 percent test. Distribution multiplies whatever it points at, and pointing it at a leaking bucket just empties the bucket faster in front of an audience. Ship, hold early retention, then broadcast.
**Gate two: terminate in something you own.** Point every public post at an email capture rather than a bare follow. Roughly 5 percent of a good list can be brought to pay, against well under 1 percent of followers. Treat the follower count as the top of the funnel and the email list as its floor. The audience that never becomes a list is a vanity number.
**Gate three: match the format to the mechanic.** Lead with the number, put the link in a reply on X, use documents and native text over bare links on LinkedIn, and post from a personal profile. A company-page link post stacks two penalties at once. Play the scoring the platforms actually published.
**Gate four: tell the truth about the numbers.** Report real revenue, never a padded figure dressed up as ARR. A Cluely-style correction costs more reputation than any launch-day spike was ever worth, and the whole value of building in public is the trust, which is the one asset a fake number spends all at once.
The verdict is the thesis. Building in public is a multiplier. It amplifies a product that already retains, seeds a list you own, and rewards the founder who plays the platform straight and ships something people keep. Point it at anything less and it multiplies that too, in public, where everyone can watch. Base44 had a product doing the paying. The multiplier just made it faster.
---
# What a ChatGPT citation is worth, and which answer engine a small site can win
Section: The Study
URL: https://okaneland.com/study/what-a-chatgpt-citation-is-worth/
AI answer engines send about one visit for every 170 Google sends, and 84% of that is ChatGPT, but Semrush measured those visitors converting around 4.4 times better. A citation is worth having, and the reachable field favors a small, specific, freshly dated page, so it earns a place in the plan rather than the center of it.
Two numbers frame the whole question. In June 2025, AI platforms sent about [1.13 billion referral visits to the top 1,000 sites on the web, up 357% in a year](https://techcrunch.com/2025/07/25/ai-referrals-to-top-websites-were-up-357-year-over-year-in-june-reaching-1-13b/). Over that same month, Google search sent those sites roughly 191 billion. So AI referral traffic is growing fast and is still about one part in a hundred and seventy. If you are a small site deciding whether to chase a spot in an AI answer, that is the tension: a channel too small to live on, growing too fast to ignore, and one where the rules of who gets picked are not the rules you learned for Google. The evidence lands on the encouraging side: a citation is worth winning, and the field is more open to a small site than the traffic split suggests.
Two questions the tools rarely separate: what a citation is worth when you get one, because the traffic is scarce but does not behave like search traffic, and whether a small, specific site can realistically win one or the box is already carved up among Wikipedia, Reddit, and a few giants. The method is the one we used on [AEO and GEO](/study/aeo-and-geo-what-the-research-says/): trust the people measuring the gap over the people selling the fix.
## The short version
If you are shipping to earn and weighing AI search as a channel, the evidence supports a small, specific set of moves.
- **A citation is worth more per visitor than a search click.** Semrush measured AI-search visitors at about [4.4 times the value of organic visitors](https://www.semrush.com/blog/ai-search-seo-traffic-study/) by conversion rate. The multiple varies a lot by market, but the direction is consistent: people who arrive from an AI answer tend to be further along.
- **The channel is really ChatGPT.** It drives roughly [84% of trackable AI referral traffic](https://searchengineland.com/chatgpt-ai-referral-traffic-sessions-data-481630) and rising. Any plan that treats "AI search" as one even market is planning for the wrong shape.
- **The engines cite different worlds.** Only about [11% of cited domains overlap between ChatGPT and Perplexity](https://www.tryprofound.com/blog/citation-overlap-strategy). Winning one does not win the others, so pick the engine your buyers use.
- **A quarter of the citations are gone before you start.** Wikipedia and Reddit together are about [25% of US ChatGPT citations](https://www.prnewswire.com/news-releases/wikipedia-and-reddit-now-drive-over-25-of-chatgpt-citations-in-the-us-new-5w-research-finds--wsj-nyt-and-bloomberg-do-not-appear-in-the-top-20-302768339.html), and you cannot become Wikipedia. The remaining field is where a small site competes.
- **In that field, small and fresh wins more than you would expect.** AI-cited pages run about [26% fresher](https://ahrefs.com/blog/do-ai-assistants-prefer-to-cite-fresh-content/) than the top organic results, niche pages beat big domains on specific queries, and the one controlled study found that [sourced, specific writing lifts citations the most for lower-ranked pages](https://arxiv.org/abs/2311.09735).
Everything below is the evidence, including the parts that argue with the bullets.
## What a citation is actually worth
Start with the value, because it is the reason the small traffic number is not the whole story. Semrush studied more than 500 high-value topics in June 2025 and found that a visitor arriving from an AI search engine was worth about [4.4 times an organic search visitor](https://www.semrush.com/blog/ai-search-seo-traffic-study/), measured by how often they converted. The likely reason is selection: by the time someone clicks a link inside an AI answer, the assistant has already done the comparing and the summarizing, so the click that survives is a warmer one.
The exact multiple is where you have to be careful, because it swings hard by market. On one Seer Interactive client's analytics, AI-referred sessions converted far above the site's 1.76% organic rate, with [ChatGPT at 15.9%, Perplexity at 10.5%, Claude at 5.0%, and Gemini at 3.0%](https://www.seerinteractive.com/insights/case-study-6-learnings-about-how-traffic-from-chatgpt-converts). That is a striking spread, and it is one account over one window with only about 1,370 AI conversions behind it, so read it as directional rather than a benchmark.
A B2B-focused vendor report put the raw gap at [14.2% for AI referrals versus 2.8% for organic](https://opollo.com/blog/the-2026-ai-search-benchmark-report/), which is almost certainly inflated by branded, high-intent traffic. Adobe's retail data lands far lower, with a conversion lift in the tens of percent rather than multiples. Put the three together and the defensible claim is narrow: AI visitors convert meaningfully better than search visitors, the premium is largest in B2B and software, and anyone quoting you a clean "five times" is rounding up from one dataset.
The catch is that a citation is not a click. Most AI answers name a source without sending anyone anywhere, so the visit you can measure is the small tail of the value you got. That makes AI search a brand channel first and a traffic channel second, which is worth pricing carefully before you pour effort into it. If you want the per-channel acquisition math against paid and organic, that lives in [what a channel costs](/study/cac-by-channel-ai-product/).
## The channel is really one engine
"AI search" sounds like a market with several players. The traffic says otherwise. Previsible's study of 6.77 million sessions across 166 properties put ChatGPT at about [84% of trackable AI referral traffic in December 2025, climbing toward 92% by May 2026](https://searchengineland.com/chatgpt-ai-referral-traffic-sessions-data-481630). Conductor's separate tracking landed at [87.4%](https://digiday.com/media/in-graphic-detail-the-state-of-ai-referral-traffic-in-2025/), and the lowest credible estimate still puts ChatGPT near four out of five referrals. The share moves by industry and by month, and B2B has seen ChatGPT dip while Perplexity and Google's AI mode pick up, but the center of gravity is not in doubt.
That has a blunt implication. If you optimize for the abstract idea of "answer engines," you are spending most of your effort on the 15% and calling it a strategy. The engine that decides whether AI search is a channel for you is ChatGPT, and the second question, which engine your specific buyers use, matters more than the first. A developer-tools audience skews to Perplexity and Google's AI mode far more than a consumer audience does.
## The engines cite different worlds
Here is the part that breaks the "get cited by AI" framing. The engines do not draw from a shared pool. Profound compared 100,000 prompts and found that ChatGPT and Perplexity overlapped on only about [11% of cited domains](https://www.tryprofound.com/blog/citation-overlap-strategy), with pairwise overlap across the major engines running from roughly 6% to 16% depending on which two you compare. Getting cited in one is close to no signal about the others. There is no single "AI visibility" you win once.
They also cite in different volumes. Perplexity packs an answer with sources, averaging about [21.9 citations per response, against ChatGPT's roughly 7.9](https://www.qwairy.co/blog/provider-citation-behavior-q3-2025). More slots per answer means more room for a specific, lower-authority page to make it in, which is one reason Perplexity is the friendlier target for a small site even though it sends less traffic than ChatGPT.
And a large share of the field is closed to you before you begin. In 5W Public Relations' Q1 2026 audit, Wikipedia and Reddit alone were over [25% of US ChatGPT citations](https://www.prnewswire.com/news-releases/wikipedia-and-reddit-now-drive-over-25-of-chatgpt-citations-in-the-us-new-5w-research-finds--wsj-nyt-and-bloomberg-do-not-appear-in-the-top-20-302768339.html), with the Wall Street Journal, New York Times, and Bloomberg absent from the top 20 entirely. Ahrefs and Semrush both rank Reddit and Wikipedia as ChatGPT's two most-cited domains by a wide margin. You cannot become Wikipedia, and a marketing page cannot pass as an organic Reddit thread. So the realistic contest is for the citations that are not going to those sources, which is where the small-site question finally gets interesting.
## Why a small, specific site can win
The reachable field rewards exactly the things a large content operation is bad at. Three separate lines of evidence point the same way.
Freshness is the first. Ahrefs analyzed about [17 million AI citations and found AI-cited pages ran roughly 26% fresher](https://ahrefs.com/blog/do-ai-assistants-prefer-to-cite-fresh-content/) than the top ten organic Google results, with ChatGPT showing the strongest pull toward recent content. Seer's recency study found about [half of Perplexity's citations came from current-year content](https://www.seerinteractive.com/insights/study-ai-brand-visibility-and-content-recency) and roughly 80% from the last three years. A caveat keeps this direction rather than settled: in the larger Ahrefs dataset, Perplexity's cited pages skewed older than ChatGPT's, so "the freshest engine" depends on the study. The safe reading is that recency helps across engines, and a dated, regularly updated page has a structural edge over an evergreen one that has not been touched in two years. This is why our [price index](/palette/ai-tool-price-index/) carries a visible update date and change log.
Specificity is the second. One 2026 study of business-software queries by DerivateX looked at the pages ChatGPT cited and found about 82% went to independent or niche blogs and vendor pages, against 8.8% to major media. The sample was small and limited to B2B software, so treat the exact figure as directional, but it matches what the engines reward elsewhere: a narrow page that answers one specific question tends to beat a broad, high-authority page that answers it in passing.
The third is causal, and it is the strongest anchor because it is the one controlled experiment in the field. The Princeton GEO study tested rewrites across about [10,000 queries and found that adding statistics, direct quotations, and cited sources raised a page's AI visibility by up to 40%, with the largest lift going to lower-ranked pages](https://arxiv.org/abs/2311.09735). That last detail is the whole opening for a small site: the tactics that move citations help the underdog most. The one thing this evidence does not give you as a hard number is the common advice that being mentioned on third-party sites drives citations. That is real in practice and worth doing, but treat it as experience rather than a measured statistic.
## What to do with this
The moves that follow from the evidence are short, and none of them require a GEO subscription.
- **Price it as a brand channel and target one engine.** Decide which engine your buyers use, usually ChatGPT for consumer and Perplexity or Google's AI mode for technical audiences, and stop spreading effort evenly across all of them.
- **Be the specific page rather than the broad one.** A page that answers one exact question with real numbers and named sources is what the reachable field rewards, and it is what the [controlled study](https://arxiv.org/abs/2311.09735) measured lifting citations most.
- **Date it and keep it current.** A visible update date and a genuine refresh cadence turn recency from a disadvantage into an edge. If you use Perplexity to check your own visibility, [here is how to read those numbers](/primer/how-to-use-perplexity/).
- **Get mentioned where the engines already read.** Being talked about on the third-party sites and communities an engine trusts moves more than markup does, which is the finding that survived our [AEO and GEO review](/study/aeo-and-geo-what-the-research-says/).
A citation from ChatGPT is worth having. It is worth more per visitor than a search click, it is growing fast, and the reachable part of the field genuinely favors a small, specific, current site over a big stale one. It is also a narrow, ChatGPT-shaped, mostly clickless channel, so it earns a place in the plan rather than the center of it. Build the page a person is glad they clicked, because the click is the scarce part, and the trust behind it is the only asset that compounds.
---
# Is vibe coding worth it? What the numbers say
Section: The Study
URL: https://okaneland.com/study/is-vibe-coding-worth-it/
Yes: controlled trials measure 26% to 56% faster on fresh builds, and an $80 million exit came out of a six-month-old solo product. Two habits, a scheduled cleanup pass and a security baseline you keep honoring, decide whether the speed stays yours.
Yes. For the job a solo builder hires it for, getting from idea to working product while the window is open, vibe coding is worth it, and 2026 is the year the receipts caught up with the demo. A vibe-coding product [sold for an initial $80 million plus earn-outs](https://www.wix.com/press-room/home/post/wix-further-expands-into-vibe-coding-with-acquisition-of-base44-a-hyper-growth-startup-that-simplif) at six months old. The terminal agent half of the stack passed [a $2.5 billion run rate](https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation) by February 2026. And in the freshest field data there is, JetBrains' April 2026 survey of over 10,000 developers, the core vibe-coding tools hold [the highest loyalty scores in the category](https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/). This piece is the case, made with verified numbers, plus the two habits the data says separate the builders who keep the win from the ones who hand it back.
## The short version
- **The method makes real money.** The exits, the revenue ramps, and the adoption inside the world's most selective startup batch are documented below, with the deal terms read carefully.
- **The speed is measured, and it peaks on your use case.** Controlled trials put the gains on fresh, self-contained builds between 26% and 56%, and the famous slowdown result is about a different scenario, on 2025 tools, with the researchers' own 2026 update pointing back up.
- **The year-after bill is knowable.** The best longitudinal code data shows where AI-era codebases accumulate weight, which means you can budget for it the way you budget for hosting.
- **Do the security floor before strangers arrive.** The documented incidents share one root cause, shipping with no review at all, and the baseline that would have prevented them is cheap and routinely skipped. A live product needs ongoing security work on top of it.
Everything below is the evidence, with the vendor flags left on.
## The receipts
Start with the deal everyone quotes, because it survives a careful reading. Wix's own press release confirms [an initial consideration of approximately $80 million plus earn-out payments through 2029](https://www.wix.com/press-room/home/post/wix-further-expands-into-vibe-coding-with-acquisition-of-base44-a-hyper-growth-startup-that-simplif), which makes the famous number the floor of the deal. About $25 million of it went to employee retention, and the solo-founder, six-months-old, profitable-before-the-sale details come from [founder Maor Shlomo's own posts and TechCrunch's reporting](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/) rather than the release. Trimmed to what the documents support, it is still the category's defining receipt: one builder, one vibe-coding product, an eight-figure exit inside a year. The rest of the highlight reel, ARR claims and acquisition fine print included, gets the same careful reading in [the wins and the denominator](/study/after-the-vibecode-wins-and-denominator/).
The tools themselves, [the same slots priced in the stack guide](/primer/vibe-coding-stack/), posted the same curve. Cursor reached [$1 billion in annual recurring revenue](https://www.cnbc.com/2025/11/13/cursor-ai-startup-funding-round-valuation.html) by late 2025. Claude Code passed [a $2.5 billion run rate by February 2026](https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation). Lovable [crossed $100 million ARR eight months after launch](https://techcrunch.com/2025/07/23/eight-months-in-swedish-unicorn-lovable-crosses-the-100m-arr-milestone/), a company-disclosed figure, so season it. Money at that scale is a crowd of working builders voting with renewals, and the 2026 loyalty data says the votes are enthusiastic: JetBrains found Cursor and Claude Code tied for second place at work, with Claude Code carrying [a 91% satisfaction rating and an NPS of 54](https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/), the highest in the survey.
The sharpest adoption receipt comes from the most selective room in startups. Inside Y Combinator's Winter 2025 batch, managing partner Jared Friedman said [a quarter of the startups had codebases that were 95% AI-generated](https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/), remarks from YC's own discussion rather than published data. These are funded, technical founders who could build any way they want, and one in four builds this way. Across the wider field, [80% of the 49,009 developers](https://survey.stackoverflow.co/2025) in Stack Overflow's 2025 survey use AI tools at work. The method is the mainstream now.
## The speed, measured
The controlled evidence is strongest exactly where a vibe coder lives: new code, fresh project, defined goal. In a controlled experiment, 95 developers built an HTTP server from scratch and the group with AI finished [55.8% faster](https://arxiv.org/abs/2302.06590), with a wide confidence interval (21% to 89%) and Microsoft-affiliated authors, so read it as a strong signal with a vendor flag. The largest field evidence is calmer and still emphatic: across [4,867 developers at Microsoft, Accenture, and a Fortune 100 firm](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566), AI access produced about 26% more completed tasks, with the biggest gains for the least experienced, per the paper's own characterization. Newer builders gain the most. That is the vibe-coding demographic, described by peer-reviewed research.
The result skeptics quote is [METR's randomized trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/), where experienced open-source maintainers took 19% longer with AI, and it deserves its context: sixteen experts, working on mature repositories they knew intimately, using early-2025 tools. That is the single scenario furthest from a solo builder shipping something new, and METR itself warns against generalizing beyond it.
More telling for 2026: METR's [February 2026 follow-up](https://metr.org/blog/2026-02-24-uplift-update/) reads the newer data as weak evidence that developers are more sped up now than in 2025, and flags its own selection-bias problems in the same breath. The slowdown was a snapshot of early tools in the wrong scenario; the trend line, on the researchers' own reading, points the right way. The full anatomy of the split is [its own piece](/study/does-ai-coding-make-you-faster/); the version that matters here is one sentence long. On the work vibe coding is for, every controlled measurement says faster.
## The year-after bill, and how to budget it
Winners plan for the whole cost of the asset, so here is the part the launch threads skip. GitClear, a code-analytics firm that publishes its raw tables, tracked [623 million changed lines through mid-2026](https://www.gitclear.com/the_ai_code_quality_maintainability_gap) and found the AI era's codebases gaining weight: moved code, its proxy for refactoring, fell from 21% of changes in 2022 to 3.8% in the 2026 data, copy-paste rose from 9.4% to 15.7%, and code rewritten within two weeks of landing is up 15% against the 2023 baseline. Carry the flags: GitClear sells analytics, the data is correlational with the AI era, and an independent reviewer notes the 2022-2024 layoffs as a possible confounder.
For a solo builder this is a budget line, and a known one beats a surprise. The prototype that validates your idea costs a weekend. The product that survives will ask for cleanup passes, and the data above tells you which kind: deduplication, structure, the pruning the model skipped while it was busy shipping you a working app. Schedule it like an oil change and the compounding never gets ahead of you; the subscription side of the budget stays tracked in [the price index](/palette/ai-tool-price-index/). The builders who treat the codebase as disposable until the idea is proven, then treat it as an asset the day money arrives, get the best of both curves. How many launched products actually survive that year is now measured: [we pinged 522 vibe-coded launches](/study/how-many-vibe-coded-launches-are-alive/) and counted the ones that answered.
## The security floor most incidents skip
The security record in this category has a single lesson, and it is cheap. The headline incident is [CVE-2025-48757](https://nvd.nist.gov/vuln/detail/CVE-2025-48757), rated 9.3: Lovable-generated apps shipping without row-level security, their databases readable and writable from the open internet. The [disclosure timeline](https://mattpalmer.io/posts/2025/05/CVE-2025-48757/) was rough, vendor notified March 21, 2025, fix shipped in early June, and two flags belong on the record: Lovable disputes the CVE's framing, holding that app data is the customer's responsibility, and the discloser works at Replit, a competitor, though NVD and independent firms corroborate the technical facts.
The ecosystem moved: the pipeline was fixed, and the platforms have been hardening ever since. In October 2025, security vendor Escape scanned [5,600-plus vibe-coded apps](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/) and found 2,000-plus vulnerabilities and 400-plus exposed secrets, vendor research with a disclosed method, and a useful census of what unreviewed apps leave open.
The pattern in every incident, including the builder who told his followers his SaaS was [built with zero hand-written code](https://x.com/leojr94_/status/1901560276488511759) days before strangers maxed his API keys and bypassed his paywall, is the same: the ship happened and the check never did. A [Stanford experiment](https://arxiv.org/abs/2211.03622) saw it in the lab years before the term existed, with AI-assisted participants writing measurably less secure code. None of it argues against the method; it prices the decision to ship with no review at all.
The baseline is specific and cheap: turn on row-level security, keep secrets out of the client, run [the eight-check self-audit](/study/is-your-vibe-coded-app-secure/) before real users arrive, or pay someone a contract to do it. Be clear about what that buys. It is the floor that would have prevented every incident on this page, and a floor is where security starts; a product holding strangers' data needs the same ongoing security attention any software does. Skipping the floor is how an asset that could sell for eight figures ends up readable by anyone with a browser.
## The verdict
Worth it, and say it without flinching: the numbers back the method. [Andrej Karpathy named it](https://x.com/karpathy/status/1886192184808149383) as a way to build where you give in to the vibes and forget the code exists, and eighteen months later the scorecard reads: an $80 million exit, a quarter of YC's batch, billion-dollar revenue ramps on the tools, the category's best loyalty scores, and measured speed gains of 26% to 56% on exactly the work solo builders do. [Simon Willison's distinction](https://simonwillison.net/2025/Mar/19/vibe-coding/) supplies the operating manual: vibe code to ship and validate, then review what won, the same supervised-beats-unattended split [the agent research keeps finding](/study/do-ai-agents-work-yet/).
The two habits above, a scheduled cleanup pass and a security baseline you keep honoring, separate the receipts at the top of this piece from the incidents in the middle. The field has already voted: [80% of developers use the tools](https://stackoverflow.blog/2025/12/29/developers-remain-willing-but-reluctant-to-use-ai-the-2025-developer-survey-results-are-here/), and the ones on the best tools report the highest satisfaction in the category. Build the thing, [wall by wall, from scratch](/primer/build-an-app-with-ai-from-scratch/). Read it before strangers do. That is what the numbers say.
---
*Editor's note, July 12, 2026: a reader correctly called the first version of this piece too breezy about security. The section above was retitled and reworded the same day: the framing changed from "one afternoon protects everything" to what the evidence supports, a cheap baseline that would have prevented the documented incidents, with ongoing security work owed beyond it. No numbers or sources changed.*
---
# AI takes two-thirds of venture money, and your odds are still one in six
Section: The Study
URL: https://okaneland.com/study/ai-startup-raise-math/
AI companies took 65% of US venture dollars in 2025, and almost none of it landed where a small team stands. The terms underneath did not move: about 20% of the company a round, a Series A bar near $3 million in revenue, roughly one seed round in six reaching an A within two years. Raise only if two of three hold: a market that punishes patience, a product that needs capital, odds you accept.
February 2026 was the biggest month venture capital has ever had: [$189 billion of global funding](https://news.crunchbase.com/venture/record-setting-global-funding-february-2026-openai-anthropic/), per Crunchbase. Three companies took 83% of it. OpenAI raised $110 billion, Anthropic raised $30 billion, Waymo raised $16 billion, and every other startup on earth split what was left. For a small team the boom changes almost nothing: the price of the money and the odds of surviving it are where they were. That month is the AI funding boom in a single frame: the records are real, the dollars are real, and the money is pooling somewhere you are not standing.
Because here is the same year from where a one-or-two-person AI product stands. US seed rounds between $200K and $5 million [fell roughly 20%](https://news.crunchbase.com/venture/seed-funding-skewing-larger-ai-competitive-data/) in 2025, in both count and dollars. The share of seed money going into $10M+ mega-seeds hit 51%. And the venture funds themselves raised [$118.6 billion globally](https://nvca.org/wp-content/uploads/2026/01/q4-2025-pitchbook-nvca-venture-monitor.pdf), the lowest in a decade. The boom moved the ceiling and left the floor where it was. So the question "how do I raise venture money for my AI product" has a step zero that most guides skip: whether the trade on offer is one you should take. This piece runs that math first, with the published odds on every branch, and then the mechanics for the builders whose answer is yes.
## The short version
If you are deciding whether to pitch anyone at all:
- **The boom is not looking for you.** AI took [65.4% of US venture deal value in 2025](https://nvca.org/wp-content/uploads/2026/01/q4-2025-pitchbook-nvca-venture-monitor.pdf), but the gains concentrated in megadeals; small seed rounds shrank.
- **Know the price.** A median seed sells [about 20% of the company](https://carta.com/data/state-of-seed-2025/); by Series A the median founding team holds 36%.
- **Know the odds.** Since late 2021, [13 to 18% of seed cohorts](https://torstensson.com/2025/08/04/share-of-us-seed-stage-startups-raising-series-a-is-going-up/) reach a Series A within two years, and the bar sits near $3 million in revenue.
- **The other branch has receipts now.** Base44 sold for [$80 million cash](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/) six months after launch, bootstrapped. Gamma got profitable first and raised later, on its own terms.
- **Build distribution either way.** It is the one asset that pays on both branches: customers if you keep the company, term sheets if you sell a piece of it.
The rest is the evidence, and the playbook.
## The boom is a barbell
Start with the shape of the money, because the headline number is misleading on its own. AI and machine learning companies took 65.4% of US venture deal value in 2025, $222.1 billion of $339.4 billion, up from 46.4% the year before, per the [PitchBook-NVCA Venture Monitor](https://nvca.org/wp-content/uploads/2026/01/q4-2025-pitchbook-nvca-venture-monitor.pdf). By the first quarter of 2026 the share hit 88.8%. Two-thirds of the asset class now flows to one theme, which sounds like the easiest fundraising climate an AI founder could ask for.
The distribution says otherwise. Crunchbase's year-end data shows [just 68 companies](https://news.crunchbase.com/venture/funding-data-third-largest-year-2025/), each raising $500 million or more, absorbed over a third of all global venture funding in 2025, up from 24% the year before. Meanwhile the small end contracted: the classic $200K-to-$5M seed round fell by a fifth, and more than half of US seed dollars went into rounds of $10 million and up, deals that look like small Series As and mostly go to second-time founders and hot labs. The barbell has a fat end and a thin end, and a new founder with a working product is standing at the thin one.
None of this means you cannot raise. It means the boom did not improve your odds, and the numbers that follow are the ones that actually apply to you.
## What a check actually costs
The sticker price of a seed round is published, and it is remarkably stable. Across 2025, the median priced seed on Carta was [$4.0 million raised at a $20.0 million post-money valuation](https://carta.com/data/state-of-seed-2025/): founders selling right around 20% of the company. AI carries a premium, $19 million median pre-money against $13 million for everyone else in early 2025, per Carta's Peter Walker, but the premium changes the valuation, while the fraction sold stays put. Stack the rounds and the arithmetic compounds: on Carta's data, the median founding team holds [about 56% of the company by the seed round and 36% by Series A](https://carta.com/data/founder-ownership-2026/). Before most companies have found durable revenue, the founders are minority holders as a group.
The second cost is the treadmill. Venture pricing assumes venture growth, and the AI-era benchmark is steeper than the old SaaS one. Bessemer's [State of AI 2025](https://www.bvp.com/atlas/the-state-of-ai-2025) proposes Q2T3 in place of T2D3: quadruple, quadruple, then triple for three years, with its "Shooting Star" archetype reaching roughly $3 million ARR in its first year of revenue. Take the check and that curve becomes the plan you are graded against.
The third cost is the one founders feel last: the fund's math is not your math. Across more than 21,000 US venture financings, [65% failed to return even 1x and only about 4% returned 10x or more](https://sethlevine.com/archives/2014/08/venture-outcomes-are-even-more-skewed-than-you-think/), per Correlation Ventures data reported by VC Seth Levine (2004 to 2013 vintage; the firm's later update through mid-2023 shows the same skew slightly softened). A fund built on those odds needs its winners enormous. A $20 million exit would change your life; on a fund's spreadsheet it rounds to zero, and the fund is in your ear at every fork. That mismatch is why funded companies get pushed, with no villainy required, to swing bigger than their founders sometimes want.
## Should you even raise: the decision math
Now the funnel itself. On Carta's cohort data, about [30% of US startups that raised a priced seed in 2018-19 reached a Series A within two years](https://torstensson.com/2025/08/04/share-of-us-seed-stage-startups-raising-series-a-is-going-up/). Every cohort since the second half of 2021 that has completed its two-year window graduated at 13 to 18%, roughly half the old baseline. Precursor's Charles Hudson called the reset ["real and permanent"](https://chudson.substack.com/p/the-big-reset-in-seed-to-series-a) back in 2023, and the completed cohorts keep proving him right, though for fairness the newest data points the other way at the margin: Walker notes the early-2025 seed cohort is graduating faster in its first year (10 to 11%) than the 2022-23 cohorts did at the same age. Call the odds one in six, maybe improving toward one in five.
The bar you have to clear got taller too. The median Series A company was doing nearly $3 million in ARR in 2024, per SVB data cited by Walker, up from about $1 million in 2021, and by early 2026 it had crept toward $3.5 million. The median gap from seed to A stretched to 2.1 years, from about 1.6. And the downside is not abstract: [966 startups on Carta shut down in 2024](https://techcrunch.com/2025/01/26/2025-will-likely-be-another-brutal-year-of-failed-startups-data-suggests/), the highest in its published data, and Walker himself says the true count runs higher.
Against that, the branch nobody modeled five years ago now has receipts. Maor Shlomo built Base44 solo, bootstrapped, in public. By his own account it went from zero to $1 million ARR within about three weeks of turning on monetization, and six months after launch, with 250,000 users, [Wix bought it for roughly $80 million in cash](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/), with milestone payments that Wix's own reporting later put on track for $90 million more.
Gamma ran the hybrid: profitable since early 2024, [$50 million ARR with about 30 people](https://techcrunch.com/2025/11/10/ai-powerpoint-killer-gamma-hits-2-1b-valuation-100m-arr-founder-says/) on just $23 million ever raised, and then, past $100 million ARR, chose a $68 million Series B at a $2.1 billion valuation. Raising from strength, after profitability, is a different product than raising from need. Both stories are founder-reported and both are outliers, the same way funded unicorns are outliers. But they price the alternative: an outcome you keep all of, reached on revenue instead of runway.
So the decision test is three questions. One: does your market punish patience, the way [Stripe's data](https://stripe.com/guides/indexing-the-ai-economy) suggests the current window does, with the top 100 AI companies on its platform hitting $1 million in annualized revenue in a median of 11.5 months? If competitors will Q2T3 past you while you compound slowly, capital is a real weapon.
Two: does the product itself need money revenue cannot supply, training runs, inventory, compliance, a sales motion, or is it software a small team can ship, [the kind AI has made radically cheaper to build](/study/ai-productivity-roi-at-work/)? Three: is a one-in-six shot at the venture path, priced at 20% a round, worth more to you than a Base44-shaped outcome you own outright? Two or three yeses, raise. Zero or one, the rest of this piece is cheaper than a board seat.
## If you raise: the instrument and the funnel
The paperwork question is settled, so do not relitigate it. On Carta, SAFEs are essentially the whole pre-seed market: [93% of pre-seed rounds in Q1 2026](https://carta.com/data/state-of-pre-seed-2025/), with convertible notes at a record-low 7%. The standard deal is a post-money SAFE with a valuation cap and no discount, about six in ten SAFEs in Carta's data. In 2025 the median caps ran around $10 million for rounds raising $250K to $1M and $15 million for $1M to $2.5M rounds; the smallest rounds, under $250K, carried a $7.5 million median cap as of mid-2025. Those three numbers are your sanity check: an AI pre-seed with traction can price above them, but if an angel offers terms far below, you now know what the market clears at.
Know the reference deal too. [YC's standard offer](https://www.ycombinator.com/deal), unchanged since 2022 and still live as of this writing, is $500K total: $125K on a post-money SAFE for a flat 7%, plus $375K on an uncapped SAFE with a most-favored-nation clause. The MFN is the detail founders miss: that second tranche converts at the terms of the lowest-cap SAFE you sign between the start of the batch and your next priced round, so a small cheap SAFE signed casually mid-batch reprices YC's $375K along with it. YC's own example puts the all-in at roughly 9.5% for a company that later raises at a $15 million cap.
On effort, plan for a campaign. In DocSend's 2023 seed report, the last edition to publish full funnel averages, founders contacted an average of 66 investors to get 38 meetings, and half of successful raises took 13 to 24 weeks. Its December 2024 report showed the market easing, with most successful seed rounds closing in 12 weeks or less. Split the difference and budget a quarter of full-time work, which for a solo founder is a quarter of no shipping. That, more than the dilution, is the cost that kills small teams: the product stalls while you pitch.
## What investors screen now that demos are free
The pitch itself changed when the demo stopped being evidence. Alison Imbert, a partner at Partech, [put it flatly in April 2026](https://tech.eu/2026/04/13/what-makes-a-seed-vc-say-no-in-30-minutes/): "The demo is worth nothing. It's so easy to build." What she screens for instead is documented customer research, her first question being how many customers a founder interviewed in the last two months, and she wants the messy notes, plus a real distribution plan. A working AI prototype was a signal in 2023. In 2026 it is table stakes, and the scarce evidence is that specific people with a specific problem talk to you.
The spending screen is just as concrete. Speaking to TechCrunch in late 2024, Everywhere Ventures' Jenny Fielding put a [reasonable pre-seed founder salary at $85,000 to $125,000](https://techcrunch.com/2024/12/26/executive-assistants-high-salaries-and-other-ways-early-stage-founders-will-trigger-a-seed-vc/), and described killing a deal after finding a founder paying himself $300,000; C-suite titles like COO and CFO at that stage read as overhead. And size the raise for the real timeline: with the median seed-to-A gap at 2.1 years, the old 18-months-of-runway plan is undersized before you sign it.
## Marketing yourself: the asset that pays on both paths
This part comes last because it is the connective tissue between the branches. "Market yourself" sounds like a soft skill; in this market it is a priced asset. Base44's entire go-to-market was Shlomo narrating the build on LinkedIn and X, zero paid marketing by his account, and the audience did two jobs at once: it delivered users, and it made the company legible to an acquirer in month six.
Investors now underwrite the same thing explicitly. When a16z's Bryan Kim led Cluely's $15 million Series A, [his stated thesis](https://techcrunch.com/2025/06/26/why-a16z-vc-believes-that-cluely-the-cheat-on-everything-startup-is-the-new-blueprint-for-ai-startups/) was that for consumer AI "momentum is the moat," because any polished feature can be swallowed by the next model release. Slow Ventures went further and raised a [$60 million fund](https://www.axios.com/2025/02/12/slow-ventures-seed-fund-creators) that buys roughly 10% of a creator's holding company for $1 to 3 million: the audience is the asset, before any product exists.
Now the counter-receipts, from the same 18 months. Cluely's CEO admitted in March 2026 that the $7 million ARR he had given the press [was false](https://techcrunch.com/2026/03/05/cluely-ceo-roy-lee-admits-to-publicly-lying-about-revenue-numbers-last-year/); his own later disclosure put the real figure near $5.2 million, a reminder that attention-first companies face pressure to keep the numbers as loud as the posts. Friend.com spent [over $1 million on 11,000-plus subway ads](https://www.fastcompany.com/91413814/friend-ai-ad-campaign-founder-qa) and, by the founder's own account, had sold about 5,000 units with roughly 1,000 shipped. Attention converted to fame; the revenue never followed.
And the old launch channels quietly stopped carrying the weight: since Product Hunt moved to hand-curated featuring in 2024, independent analyses of launch data put the featured rate near 9 to 10%, which is why YC's own advice is to [launch repeatedly](https://www.ycombinator.com/library/6t-how-to-launch-again-and-again) on channels you control rather than bet one day on a leaderboard.
The rule that survives both piles of evidence: distribution multiplies a product that retains, and substitutes for nothing. If the product holds users, a founder audience compounds it on either branch, revenue if you bootstrap, believers if you raise. If the product leaks, the audience just makes the leak famous. Start the flywheel now, post the real numbers as you go, and let the retention decide what the audience is worth.
## The verdict
Run the branches with the published numbers. Raise if all three answers point the same way: a market moving at Q2T3 speed, a product that genuinely needs capital, and a clear-eyed acceptance of one-in-six odds priced at 20% a round, sized for a 2.1-year gap to the next check. Seed-strap or bootstrap if a $1-to-$80 million outcome you own is your win condition; profitability is what let Gamma raise later from strength, and client revenue can fund the build, which is exactly the arc of [landing your first AI client](/ledger/first-ai-client/) and [pricing the work properly](/ledger/pricing-ai-work/). And on either branch, the margin math of the product itself [still has to work](/study/unit-economics-of-wrapping-an-llm/), because neither a term sheet nor an audience fixes negative unit economics.
The boom is real. It moved the ceiling to numbers nobody has ever seen, and it left the floor where it was: same 20% a round, same one-in-six gate, a taller revenue bar than the last cycle. Price the ticket like the bet it is, take it only if your three answers say so, and build the one asset that pays no matter which branch you take. The money went to AI. The odds stayed home.
---
# The AI UGC ad math: $2 a video, and the bill nobody prices in
Section: The Study
URL: https://okaneland.com/study/ai-ugc-ad-economics/
AI UGC tools price a finished spokesperson clip at $1 to $11 against about $185 for a human creator video, a real cost collapse. But the strongest independent test found AI ads under-indexed on sales by 5 points while human ads over-indexed by 11. The bargain holds for one job, cheap disposable hook testing at volume, and breaks when the ad needs a real claim, a real feeling, or a testimonial a regulator could read as fake.
You can now buy a UGC ad, a real-looking person holding your product and reading your script into a phone camera, for about the price of a coffee. On [Creatify's own pricing](https://creatify.ai/pricing), a short avatar ad works out to somewhere near $1 to $2 at the entry tiers, which lines up with [our hands-on Creatify review](/proof/creatify/) after we bought the Pro plan and ran the tools. [HeyGen](https://www.heygen.com/pricing) bills its premium avatar video at 20 credits a minute, which lands a one-minute clip closer to a dollar. Arcads, the tool most of the AI UGC ad crowd actually names, runs [about $11 a video](https://www.eesel.ai/blog/arcads-ai-pricing).
Hold any of those next to a human UGC creator, who averaged [about $185 a video in 2026](https://collabstr.com/2026-influencer-marketing-report) across Collabstr's marketplace, and the clip alone is somewhere between fifteen and ninety times cheaper. The bargain is real, and it is narrower than the price makes it look.
That is a real cost collapse, and it has funded real revenue, and nobody gets to wave it off as a fad. It is also the only number the tools put on the slide.
## The short version
If you are pointing a budget at this to make money:
- **The cost gap is genuine.** Roughly $1 to $11 per AI clip against about $185 for a human one, and much more once a human video is loaded with usage rights and coordination. For testing many hooks fast, nothing competes.
- **Nobody has shown it converts as well.** The one strong independent test, [Ipsos with Syracuse](https://news.syr.edu/2026/05/18/newhouse-research-finds-ai-ads-fall-short-on-sales-impact/), found AI ads underperformed human ones on predicted sales. Every "AI UGC beats human on click-through" stat traces back to a company selling AI UGC.
- **Disclosure is the tax.** Across 13 preregistered experiments, [disclosing AI use lowered trust](https://doi.org/10.1016/j.obhdp.2025.104405), and platforms increasingly disclose it for you.
- **The label is not your choice.** [Meta auto-detects and labels](https://about.fb.com/news/2025/02/gen-ai-transparency-metas-ads-products/) third-party AI in ads. A synthetic testimonial can also be an [FTC](https://www.ftc.gov/news-events/news/press-releases/2024/08/federal-trade-commission-announces-final-rule-banning-fake-reviews-testimonials) and [EU](https://artificialintelligenceact.eu/article/50/) violation.
- **The play that works today:** use AI UGC for cheap, high-volume hook testing where nobody expects a real person, and move the winners to human creators for anything that needs a real claim, real emotion, or will be labeled AI anyway.
The rest is the receipts, and the math the pricing pages skip.
## The number that starts the argument
Start with how these tools meter, because the per-video price has to be derived; no tool prints it. Creatify sells credits: [Starter at $39 for 100 credits, Pro at $99 for 300](https://creatify.ai/pricing), and its free tier advertises "10 credits, up to 2 video ads," which implies roughly 5 credits a video and puts a clean ad near $1.65 to $2 at the floor. The catch is in Creatify's own fine print: a real ad burns anywhere from 2 to 20 credits once you count quality settings and re-renders, so $2 is a best case.
HeyGen meters the same way, [$29 for 600 credits, $49 for 1,000](https://www.heygen.com/pricing), with its top avatar tier at 20 credits a minute, so the sticker of roughly a dollar a minute holds only until you regenerate. If you want the current floor across these tools, we keep [what each tool actually costs](/palette/ai-tool-price-index/) tracked and dated.
Arcads sits at the premium end and is the clearest mirror of the category. Its Starter plan is $110 a month for 10 videos, its Creator plan $220 for 20, both [about $11 a finished clip](https://www.eesel.ai/blog/arcads-ai-pricing). On those tiers unused videos do not roll over, there is no free trial, and Arcads does not publish a pricing page at all: `arcads.ai/pricing` returns a 404, and the numbers only appear after you make an account. That is worth noticing before you build a budget on a screenshot. AI UGC stays cheap; the takeaway is that the "cents a video" framing is the marketing number, and the real per-usable-ad cost sits a notch above it once retries are counted.
The meters, derived to a per-clip price:
| Tool | The plan math | A clean clip | The catch |
|---|---|---|---|
| HeyGen | $29/600 credits, 20 credits per avatar minute | ~$1 a minute | Holds only until you regenerate |
| Creatify | $99/300 credits, ~5 credits a video | ~$1.65 to $2 | A real ad burns 2 to 20 credits with re-renders |
| Arcads | $110 for 10 videos, $220 for 20 | ~$11 | No rollover, no trial, no public pricing page |
| Human creator | Collabstr marketplace, 21,000+ collaborations | ~$185 | $500 to $2,000 all-in with rights and coordination |
## What a human video actually costs
The comparison only means something with a real baseline, so here is the strongest one. Collabstr publishes rates from its own marketplace, and its 2026 report, drawn from [more than 21,000 real collaborations](https://collabstr.com/2026-influencer-marketing-report), puts a UGC video at about $185. Treat that as a floor published by a company that sells these collaborations, with no audit behind it, but it is the most-cited real dataset in the category. One fair correction to the usual pitch: UGC is not the cheapest format going, plain X posts list for less. What UGC has is the smallest gap between what creators ask and what they get paid, which is its own signal that the market clears near the asking price.
The $185 buys the deliverable; the invoice is bigger. Industry rate guides put the all-in closer to $500 to $2,000 once you add usage rights, which run a 30 to 50 percent premium, rush turnaround, extra revision rounds, and the hours somebody on your side spends briefing and chasing. Those multipliers are consistent across guides, though the totals are estimates, so hold them as ranges. The structural point is what matters: the human cost is mostly coordination, and coordination does not fall with volume. Bundle discounts top out around a quarter off. So the human model is fine for a handful of hero videos and breaks the moment your media plan wants fifty.
## The volume case, where the math actually holds
This is the strongest part of the AI case, and it is a real one. Testing creative is a numbers game, and the number is large. Commissioning fifty ad variants from human creators runs on the order of $7,500 and up, using the same rate-guide math, and it takes weeks. The same fifty from an AI tool cost under $200 and land the same afternoon. When the job is "find the one hook in fifty that works," the cost curve is not close, and that single use case, high-volume disposable hook testing, is where AI UGC genuinely pays.
The market backs the volume thesis with revenue. HeyGen reached an estimated [$95M in ARR by September 2025](https://sacra.com/c/heygen/), up from $57.5M at the end of 2024, per the tracker Sacra rather than HeyGen itself. Creatify crossed [$9M ARR on a $15.5M Series A](https://www.businesswire.com/news/home/20250528506486/en/), and Arcads raised a [$16M seed in December 2025](https://www.prnewswire.com/), said it was already profitable, and reported making roughly 100,000 assets a month for more than 6,000 clients. Somebody is buying a lot of AI video, and the pattern that buys it is volume.
## Does it convert, and does AI match human?
Here the evidence forks, and the fork is the whole argument. That UGC-style creative beats polished studio ads is well supported and not really in dispute: Brainlabs, analyzing [46 Meta brand-lift studies](https://www.brainlabsdigital.com/meta-brand-lift-studies-objectives-creatives-results/), found lo-fi native creative lifted product purchase intent 6 percent against a 4 percent average, while high-production creative did its best work on awareness. Read that as a point for the UGC format, and note it is one agency's read of its own client data.
Whether an *AI* version of that format converts like the human one is a different question, and the strongest independent test points the wrong way for the vendors. Ipsos, working with Syracuse University's Newhouse School, showed [3,000 U.S. viewers 20 ads across 10 brands](https://news.syr.edu/2026/05/18/newhouse-research-finds-ai-ads-fall-short-on-sales-impact/) and scored them on a sales-validated benchmark. Human-made ads over-indexed by 11 points; AI-made ads under-indexed by 5. The uncomfortable part for anyone hoping the audience simply cannot tell: only 13 percent of viewers who saw an AI ad were even somewhat sure it was AI. They could not reliably spot it, and it still sold less. AI held up on straightforward product creative and lost most ground where the ad needed a story or a feeling.
Set that against the win stats the tools advertise, the 4x click-through, the 350 percent engagement, the lower cost per acquisition. Every one of those traces to a company selling AI UGC, with no independent side-by-side benchmark behind it. There is, as of mid-2026, no independent study showing AI UGC converts as well as human UGC, and one credible study showing it does not. That is the sentence to keep.
## The disclosure penalty is the real product risk
The reason the audience-cannot-tell defense does not save the model is that the penalty attaches to disclosure, and detection never enters into it. Schilke and Reimann ran [13 preregistered experiments with more than 5,000 participants](https://doi.org/10.1016/j.obhdp.2025.104405), published in a peer-reviewed journal, and found the same thing every time: a person or brand that discloses using AI is trusted less than one that says nothing. Their thirteenth experiment adds the trap, because staying silent is not a safe harbor either. When a third party exposes the concealed AI use, trust falls further than if it had been disclosed up front. So the choices are a disclosure that costs you trust or a concealment that costs you more when it surfaces.
That is a hard place to build an ad strategy, and it explains why the "nobody will know" plan is fragile. The economics of AI UGC assume the audience reacts to the content. The evidence says a large slice of the value is set by the label, and the label is increasingly out of your hands.
## The bill nobody prices in: platforms, FTC, EU
Which is the part the pricing pages skip entirely. Start with the platforms, because they now apply the label for you. As of its [February 2025 announcement](https://about.fb.com/news/2025/02/gen-ai-transparency-metas-ads-products/), Meta automatically detects ads made or edited with third-party AI tools "through industry-standard signals" and attaches an "AI info" label, and for an ad containing an AI-generated photorealistic human that label sits right next to "Sponsored." You do not get to opt out of being marked, which means the disclosure penalty above is a default setting on the largest ad platform there is.
Then the law, where the exposure is money. The FTC's [fake-reviews rule](https://www.ftc.gov/news-events/news/press-releases/2024/08/federal-trade-commission-announces-final-rule-banning-fake-reviews-testimonials), in force since October 2024, bans reviews and testimonials that misrepresent themselves as coming from "someone who does not exist, such as AI-generated fake reviews." For knowing violations the FTC can seek civil penalties, each fake review counting as its own violation, up to a statutory maximum that inflation adjustments have now set at [$53,088 per violation](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-A/part-1/subpart-L/section-1.98). A synthetic spokesperson vouching for a product is exactly the kind of nonexistent endorser the rule describes.
In the EU the clock is louder: the AI Act's Article 50 transparency duties [become enforceable on 2 August 2026](https://artificialintelligenceact.eu/article/50/), requiring AI output to be machine-marked and deepfakes to be disclosed even where there was no intent to deceive, with Article 99 penalties reaching €15 million or 3 percent of worldwide annual turnover. One synthetic testimonial can be a labeling problem, a fake-endorsement problem, and an unmarked-synthetic-media problem at the same time, in different jurisdictions, at once.
## The verdict, and the cautionary tale
The clean version of this promise has already run once and broken. Icon launched as "the AI admaker," pitched a hundred ads in ninety minutes, and paid [$12 million for the Icon.com domain](https://techstartups.com/2026/03/05/icon-the-ai-ad-startup-shuts-down-after-spending-12m-on-the-icon-com-domain/). By early 2026 its site had quietly gone dark, and it re-emerged selling six real, human-made UGC ads for $399 a month under the banner "the human admaker." The company built to replace the agency became the agency. Around it, the backlash is now a repeatable brand risk rather than a one-off: Coca-Cola's AI holiday ads were mocked in both 2024 and 2025, [McDonald's Netherlands pulled its AI Christmas ad](https://www.nbcnews.com/world/europe/mcdonalds-ai-generated-christmas-advert-social-media-backlash-rcna248590) within about four days in December 2025, and YouTube's [July 2025 monetization rules](https://techcrunch.com/2025/07/09/youtube-prepares-crackdown-on-mass-produced-and-repetitive-videos-as-concern-over-ai-slop-grows/) began demonetizing the mass-produced AI video the same tools make easy to churn out.
So price the whole production. AI UGC is a genuine bargain for one job: cheap, fast, disposable hook testing at a volume no human roster can match, in placements where nobody expected a real person anyway. It is a poor bet the moment the ad needs a real claim, a real feeling, or a testimonial a regulator could read as coming from a person who does not exist, because that is where the conversion gap, the disclosure penalty, and the fine all live. The video got 90 times cheaper. The rest of the invoice did not, and the rest of the invoice is where the money is.
---
# AI saves about 3% of your hours, and almost none of it reaches the money
Section: The Study
URL: https://okaneland.com/study/ai-productivity-roi-at-work/
AI genuinely speeds up the right tasks: writing, support, structured drafts. But across a real job the gain shrinks to about 3% of your hours, and a paycheck captures just 3 to 7% of it. AI will make you faster. It will not make you richer on its own, and the saved hours only become money if you deliberately bank them.
Economists Anders Humlum and Emilie Vestergaard did something most AI productivity studies skip: they linked AI-adoption surveys of about 25,000 workers across 7,000 Danish workplaces to actual payroll records. The time savings were real and small, [about 2.8% of work hours](https://www.nber.org/papers/w33777), call it an hour a week. The part that should stop you is what happened next. The chatbots had [no significant impact on earnings or recorded hours in any occupation](https://www.nber.org/papers/w33777), and only 3 to 7% of the productivity gain reached anyone's pay.
Hold that against the demos and the lab studies, where AI makes people 15%, 40%, even 55% faster. Both are true, because they measure different things. In a controlled twenty-minute task, AI is a rocket. In a real job, across a real month, on a real payroll, it is a small, leaky gain that mostly evaporates before it reaches a paycheck or a profit line. The question worth asking is not "does AI make knowledge work faster," because on the right task it plainly does. It is "does the time you save turn into money," and the answer so far is: only if you make it.
## The short version
The gains are real, task-specific, and easy to lose. If you are using AI to earn:
- **Aim it at the tasks it is genuinely good at.** First drafts, summaries, structured writing, customer replies, boilerplate. That is where the measured wins live, and they are large.
- **Keep it off the tasks it quietly fails.** Outside its strengths AI does not just stop helping, it produces confident wrong answers that cost more to catch than they saved.
- **The per-task win is big; the real-life win is small.** A 40% speedup on one task becomes a few percent of your week once you count everything AI does not touch. Stack it on high-volume, repeatable work or it rounds to nothing.
- **Capture the saved time on purpose.** Saved time does not turn into money by itself. Bill it, ship more, take another client, or cut a cost. If you do not convert it, it leaks back into the day.
- **Do not expect it to raise your pay or your margin for you.** The research is blunt: the gain goes to whoever deliberately banks it, and mostly no one does yet.
Everything after this is the evidence.
## The gains are real, on the right task
Start with the wins, because they are genuine. In a randomized experiment with [453 professionals](https://www.science.org/doi/10.1126/science.adh2586), giving people ChatGPT for mid-level writing tasks, press releases, short reports, sensitive emails, cut the time they spent by 40% and raised graded quality by 18%. In a field study of [5,179 customer-support agents](https://www.nber.org/papers/w31161), access to an AI assistant lifted resolved-issues-per-hour by 14% on average, and by about 34% for the newest, least experienced agents. These results are real, measured, and repeated. If your work looks like these tasks, structured, text-heavy, high-volume, AI is worth using hard, and the speedup is not hype.
Notice what every one of these studies actually measures, though: a task. A twenty-minute writing assignment done faster. An issue closed quicker. None of them measure whether the saved time turned into income, and that gap is the rest of this piece.
## The frontier is jagged
The catch is that AI's competence has a strange shape, and stepping off it is expensive. Harvard and BCG ran a field experiment with [758 consultants](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4573321). On tasks inside AI's range, the people using GPT-4 finished 12.2% more tasks, worked 25.1% faster, and produced work rated more than 40% higher in quality. Then the researchers handed everyone a task chosen to sit just outside AI's range. On that one, the consultants using AI were [19 percentage points less likely](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4573321) to reach the correct answer than the ones working without it.
That is the trap in a single number. AI does not announce when a task is past its edge. It answers just as fluently, just as confidently, and wrong, and a confident wrong answer costs more to catch than a right one saved. The skill that pays is knowing which side of the frontier you are standing on.
## In the wild, the gains shrink
The lab numbers and the payroll numbers disagree for a reason. A study measures one clean task with the AI pointed straight at it. A real job is a pile of meetings, context-switching, half the work AI cannot touch, and the overhead of checking what it produced. So the 15-to-40% task speedups compress, in the Danish payroll data, to [about 2.8% of total hours](https://www.nber.org/papers/w33777). That is what a big task win looks like once an entire real job is diluting it.
## And the money leaks
Even that small real gain mostly does not reach the money, and this is the finding that matters most for anyone trying to earn with AI. The same Danish study that found 2.8% of hours saved found [no measurable rise in earnings](https://www.nber.org/papers/w33777), with only 3 to 7% of the gain passing through to pay.
Zoom out to whole companies and it is the same story: a 2025 report from [MIT's Project NANDA](https://mlq.ai/media/quarterly_decks/v0.1_State_of_AI_in_Business_2025_Report.pdf) found that despite 30 to 40 billion dollars of enterprise spending, 95% of organizations were getting "zero return," with the vast majority of pilots stuck at no measurable P&L impact, and only 5% extracting real value. And across the whole economy, MIT economist Daron Acemoglu estimates AI will raise total factor productivity by [no more than about 0.66% over ten years](https://www.nber.org/papers/w32487), and likely under 0.53%, a rounding error next to the 1.5 to 3% a year that banks were forecasting.
The pattern repeats at every scale: real gains at the task, shrinking gains across the job, near-zero gains in the paycheck and the P&L. The time is being saved. It is just not being captured.
## How to actually bank it
None of this says AI is useless. It says the value is real, small, and leaky, which means the edge goes entirely to whoever captures it on purpose. In practice that is three moves. Point AI at the tasks where the wins are measured and large, and keep it off the ones where it fails confidently. Stack it on work you do in volume, so a few percent per task adds up to real hours. And turn those hours into something that shows up in the bank, more output shipped, another client served, a cost removed, because saved time you do not spend deliberately just refills with other work.
[The edge, for a solo builder especially, is in being the one who captures](/ledger/economics-of-a-one-person-ai-business/). If 3 to 7% of the gain reaches pay on average and you engineer a workflow where it reaches yours, you are beating the average by a wide margin. If you are building the AI product rather than using it, the same discipline points at the [cost side](/study/unit-economics-of-wrapping-an-llm/): the gains that are hard to capture are the same ones not worth paying a premium to serve. And in coding specifically, [the speedup is real and comes with its own bill](/study/does-ai-coding-make-you-faster/).
Does AI pay off at work? On the right task, yes, and clearly. Across a real job, a little. In your paycheck, almost none of it, unless you reach out and take it. AI will make you faster. It will not make you richer on its own. The 3% is real. Banking it is the job.
---
# AI agents finish a third of the job, and the math says why
Section: The Study
URL: https://okaneland.com/study/do-ai-agents-work-yet/
The demos are real and the leaderboards are climbing fast. Turned loose on real multi-step work, though, the best agents finish about a third of it, and the cause is compounding: at 95 percent reliability per step, a 20-step task comes out right about 36 percent of the time. On a leash, agents already pay. Off it, an agent that works half the time is a tool you supervise.
Turn the best AI agent on the market loose inside a realistic software company, give it the chat tool, the project board, the code repo, and 175 ordinary office tasks, and it finishes [about 30% of them](https://arxiv.org/abs/2412.14161) on its own. The agent was Gemini 2.5 Pro, one of the strongest available, on Carnegie Mellon's TheAgentCompany benchmark, scoring 30.3% fully autonomous and creeping to 39% only when you hand out partial credit for getting part-way. The rest it botched or left half-done.
Hold that next to the demos. Every agent launch shows a clean run: the agent books the trip, files the expense, fixes the bug, all by itself, and the demo is real. It is also a sample size of one. A business does not run on one good run, it runs on the thousandth, and the distance between "worked once on stage" and "works every time, unattended" is the entire question. The short answer to "do AI agents work yet" is this: on narrow, short, supervised tasks, genuinely yes, and on the open-ended multi-step work people keep promising they will automate, not reliably, not yet, and the reason is arithmetic rather than a bug that gets patched next month.
## The short version
Agents earn their keep inside tight lines and lose it the moment you widen them. If you are putting one to work to make money:
- **Keep the scope narrow and the task short.** Reliability falls off a cliff as a job gets longer, and the data below is brutal on this. One tool, one well-defined job, a handful of steps, is where agents already pay.
- **Put a human at the checkpoints.** Not watching every token, but approving the few moves that spend money or cannot be undone. The agent drafts, you commit.
- **Make failure cheap and reversible.** Point an agent at a sandbox, a draft, a proposal, never a production database or a live send. The headline agent disasters were each one irreversible action away from fine.
- **Add a retry and a checker.** A second pass that verifies the first one's work buys back a lot of the lost reliability. Bare single-shot autonomy is the weakest setup there is.
- **Do not buy the leaderboard.** The most eye-popping scores come from bespoke multi-model rigs you cannot actually purchase; the agent you would deploy scores lower.
Everything after this is the evidence, and the math that says why.
## Turned loose, they fail most of the job
That 30% is not an outlier. Salesforce built its own benchmark, [CRMArena-Pro](https://arxiv.org/abs/2505.18878), to see how agents handle real sales and service work, the exact thing it sells agents to do. On single-step tasks the best model cleared about 58%. The moment the task became a normal back-and-forth where the agent had to ask for a missing detail, that fell to roughly 35%. The same agents almost never refused to hand over confidential data unless they were specifically told to be careful, and telling them to be careful dragged completion down further. This is the vendor's own evidence against its own pitch, which makes it hard to wave away.
The deeper problem is the consistency. Sierra's [tau-bench](https://arxiv.org/abs/2406.12045) sits an agent in a customer-service seat and asks it to follow company policy through a multi-step chat. The best agent it tested got the average retail task right about 61% of the time, which sounds usable. Then the researchers asked a sharper question: can it get the same task right eight times in a row, once for each of eight customers? The share it nailed every single time dropped [below 25%](https://arxiv.org/abs/2406.12045). An agent that works two times in three is a fine demo and a poor employee, because the customer who draws the third outcome is a refund, a chargeback, or a complaint.
The benchmarks, side by side:
| Benchmark | The job | Best agent | The catch |
|---|---|---|---|
| TheAgentCompany (CMU) | 175 ordinary office tasks, unassisted | ~30% finished | The turn-it-loose number |
| CRMArena-Pro (Salesforce) | Real sales and service work | ~58% single-step | Drops to ~35% once it needs a back-and-forth |
| tau-bench (Sierra) | Policy-following support chats | ~61% average | Under 25% when it must be right eight times running |
| GAIA | Real-world assistant tasks | ~75% best reproduced rig | Humans score 92%; the agent you can buy scores lower |
| METR time horizon | How long a task it can carry | ~50% on hour-long jobs | The trust-it horizon runs about five times shorter |
## The math nobody demos
Here is why a healthy per-task score still does not add up to an autonomous worker, and it is just multiplication. Say an agent is 95% reliable on each individual step, which is better than most manage. Chain 20 of those steps into one task, the kind of thing "book my travel and file the expenses" actually involves, and the odds it gets the whole task right are 0.95 to the twentieth power, or [about 36%](https://arxiv.org/abs/2505.05115). At ten steps it is still only 60%. Reliability compounds, and it compounds downward, because a long task is a chain of subtasks where failing any one fails the whole thing.
Oxford's Toby Ord gave this its name in a 2025 paper, [Is there a half-life for the success rates of AI agents?](https://arxiv.org/abs/2505.05115) Working from the benchmark data, he found agent success decays exponentially with task length, as cleanly as if each agent ran a fixed risk of failing per minute of work, a half-life.
One consequence is worth keeping on a sticky note: every extra "nine" of reliability you demand divides the length of task you can trust by roughly ten. An agent reliable enough to finish an hour-long job half the time can only be trusted on a job a fraction as long once you need it to work eight or nine times out of ten. The demo is the 50% case. A business runs on the 99% case, and that is a different, much smaller job.
## The cliff, measured
The research group METR put numbers on the cliff. It measures an agent's "50% time horizon," the length of task, scored by how long it takes a person, that an agent finishes on its own about half the time. The headline that gets quoted is that this horizon is [doubling every few months](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/), and it is: the frontier has climbed from minutes to a few hours of human-equivalent work in about two years.
The line underneath is the one that matters here. The 80% horizon, the length you can trust four times in five, runs about five times shorter than the 50% one. In METR's data, models nailed almost every task that takes a human under four minutes and succeeded [less than 10% of the time](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/) on tasks that take a human more than about four hours. "Half the time on a long task" is the headline. "Almost never, when it has to be reliable" is the same finding.
## Why the scoreboards disagree
You can also find a leaderboard that says agents already match people. On GAIA, a benchmark of real-world assistant tasks, [humans score 92%](https://arxiv.org/abs/2311.12983), versus 15% for GPT-4 with plugins when it launched, and the top entries now claim around 92% too.
Read the fine print. Those top scores are custom multi-model rigs, scaffolding bolted onto several models and tuned for the test, submitted by their own authors and not independently reproduced. The best agent an outside lab has actually [reproduced sits near 75%](https://hal.cs.princeton.edu/gaia), and a bare model with no scaffolding is far below that. The number that matters for you is not the one a research team can hit on a hidden test set with a hand-built ensemble. It is the one you can buy, point at your work, and trust without a specialist babysitting it, and that number is a good deal lower than the leaderboard.
The fair counterpoint, and it is fair, is that all of these numbers are moving up quickly. METR's horizon is doubling on the order of every four to seven months. The 30% of today is not the 30% of two years from now. So the right posture is neither "agents are a toy" nor "agents will run the company by Friday." It is to build for where the cliff sits today, and to keep watching it recede.
## What works right now
The agents earning real money in mid-2026 do narrow, bounded, supervised work, and do it well: drafting the first version, triaging the inbox, pulling the data, writing the boilerplate, with a person owning the few decisions that count and a cheap way to catch the misses. Nothing on that list runs unattended. That is augmentation, and [it pays](/study/ai-productivity-roi-at-work/). The trap is the next sentence in every pitch, where the bounded helper quietly becomes an unattended employee. That sentence is where the 36% lives.
One more thing if you are building this rather than buying it: the long, looping, multi-step runs that fail most often are also the [most expensive ones to serve](/study/unit-economics-of-wrapping-an-llm/), because every retry and every step is more tokens on the meter. The work that breaks your reliability is the same work that breaks your margin, which is a strong hint about where to point an agent and where not to. Where agents do pay in coding specifically, [the speed comes with its own bill](/study/does-ai-coding-make-you-faster/).
Do AI agents work yet? On a leash, yes, and the leash is getting longer fast. Off the leash, on the open-ended multi-step work the word "agent" was supposed to promise, they finish about a third of it, and the math says that will not flip just because the demo ran clean. An agent that works half the time is a tool you supervise. Build for the half that fails, and you keep the half that pays.
---
# Wrap an LLM, charge $20, lose money: the pricing trap the model owners hit first
Section: The Study
URL: https://okaneland.com/study/unit-economics-of-wrapping-an-llm/
Charging a flat $20 for a metered product is a subsidy with a leak: a few heavy users burn most of the tokens, and the average stops protecting you. The model owners themselves learned it and moved to usage based pricing. Falling inference costs lower the whole curve without changing its shape, so a wrapper only earns if you price for the user who runs the meter hot.
In the first months of 2023, GitHub Copilot was losing money on the people who used it most. The product cost $10 a month. Running it cost Microsoft [more than $20 a month per user on average](https://www.theregister.com/2023/10/11/github_ai_copilot_microsoft/), and for the heaviest users as much as $80, according to figures the Wall Street Journal reported and GitHub disputed. A $10 subscription, a $20 to $80 bill to serve it. That is the whole problem with selling AI for a flat price, in one line.
The pitch you have heard, wrap an LLM, charge $20 a month, print money, skips the part where the model runs every single time someone uses it. Classic software has economies of scale: you build it once and the thousandth user costs you close to nothing. An AI product is the opposite. Every query re-runs the model, every token has a cost, and a flat fee is a bet that your average user will not also be your heaviest. On a metered product that bet has a way of going wrong, and the proof is that the three companies that own the models, the ones with the lowest costs and the best engineers in the business, each made it and each backed out. Where all three landed is the answer for everyone smaller: the meter goes where the cost is, and the price has to survive your heaviest user.
## The short version
If you are building an AI product to earn, price it like the metered product it is:
- **Meter the expensive path.** A quick chat is cheap. An agent looping over a long context, calling tools, and retrying is not. Charge for the part that actually costs you, by usage or credits, even if a simple base plan sits in front of it. Start from [what each tool actually costs](/palette/ai-tool-price-index/), because that input is the floor your price has to clear.
- **Find your heavy tail before you price.** A small share of users will burn most of your tokens. Model the top few percent, then set the price so the tail pays for itself or hits a cap.
- **Cap or tier the top.** Unlimited on a metered cost is a standing invitation to [the one user who runs your agent around the clock](/study/do-ai-agents-work-yet/). Every provider below ended up capping exactly that.
- **Charge for value.** A flat monthly fee anchors the customer to "I pay $20," which is the worst possible frame on the day their usage costs you $80. Tie the price to what the work is worth.
- **Do not read a flat-rate margin as profit.** If you have not metered your heaviest cohort, the margin you are reporting is an average with a loss hidden inside it.
Everything after this is the evidence, in case you want to argue with it.
## Three times the model owners learned it
Start with the companies that should have the best unit economics in the business, because they pay wholesale for the thing everyone else marks up. If flat pricing broke for them, it is not a skill issue.
GitHub Copilot is the first. More than $20 a month per user on average, up to $80 for the heaviest, on a $10 product, in early 2023. GitHub disputed the framing and pointed at its revenue, and the figures are reported rather than audited, so hold the exact numbers loosely. The direction is the part that held: Copilot has since pushed most of its heavier plans toward usage based and metered tiers.
Anthropic is the second, and the receipt is its own policy. In [July 2025 it put weekly rate limits on Claude Code](https://techcrunch.com/2025/07/28/anthropic-unveils-new-rate-limits-to-curb-claude-code-power-users/), because a small number of users were [running it continuously in the background](/primer/how-to-use-claude-code/), 24/7, and a few were sharing and reselling accounts. Anthropic estimated the new limits would affect less than 5% of subscribers. Read that number the right way: under 5% of users were consuming enough to make the company that makes the model ration them. That is the heavy tail, named by the outfit best positioned in the world to absorb it.
Cursor is the third, and the most instructive, because you can watch the trap close in real time. In [June 2025 it changed its $20 Pro plan](https://cursor.com/blog/june-2025-pricing) so [the allowance became "$20 of frontier model usage per month at API pricing"](/primer/how-to-use-cursor/) instead of a fixed number of requests. Heavy users of the pricier models burned through $20 of real cost quickly and started hitting overages; [one user reported $350 in a week](https://techcrunch.com/2025/07/07/cursor-apologizes-for-unclear-pricing-changes-that-upset-users/) against a $20 expectation.
The backlash was loud enough that CEO Michael Truell apologized on July 4, said the company "didn't handle this pricing rollout well," and refunded the surprise bills. The lesson: even moving from a broken flat plan toward real costs gets treated by customers as a betrayal, which is the deeper problem, and the next section.
## Why you charge flat anyway
If usage based pricing is the answer, why does everyone start at a flat $20, and why did Cursor's own customers revolt when it metered them? Because customers genuinely prefer flat rates, even when flat costs them more, and this is one of the better-documented findings in pricing research. In a 2006 study in the Journal of Marketing Research, Lambrecht and Skiera found a persistent ["flat-rate bias"](https://doi.org/10.1509/jmkr.43.2.212): in real billing data, about 48% of subscribers on a metered plan were overpaying versus a flat option they could have switched to, and they kept choosing it anyway.
Two forces drive it. An insurance effect: people will pay a premium for a predictable bill, for the comfort of knowing the number before they use the thing. And a taxi-meter effect: watching a meter tick while you actively use a product sours the experience, even when the total comes out lower.
For you, that cuts both ways. The good news is that a flat plan is the easy sell, because customers want it, so it is the path of least resistance to your first dollars. The bad news is the same sentence. The customers most attached to your flat plan are the ones getting the most for their money, and the day you try to line price up with cost, the taxi-meter effect turns your heaviest users into your angriest ones. That is the Cursor story compressed to one line. Flat-rate bias is why the trap is so easy to walk into and so painful to walk back out of.
## The case for ignoring all of this
There is a real argument that none of this matters, and it deserves a fair hearing: inference is getting cheaper so fast that a product losing money today will be profitable next year just by waiting. The numbers behind it are genuinely staggering. Epoch AI finds the price to reach a fixed level of capability is [falling between 9 and 900 times per year depending on the task](https://epoch.ai/data-insights/llm-inference-price-trends), a median of about 50 times a year. By one series tracked in Stanford's AI Index, the cost to run a model as capable as GPT-3.5 fell [from about $20 to about $0.07 per million tokens](https://hai.stanford.edu/ai-index/2025-ai-index-report) in under two years, more than a 280-fold drop.
So why not price flat, eat the loss, and ride the curve down? Two reasons. First, the curve cuts the price of a *fixed* capability, and nobody sells last year's capability. You and your customers both move to the newer, larger, costlier models as they land, which is why the frontier stays expensive even as yesterday's frontier gets cheap.
Second, and this is the one that settles it, cheaper inference lowers the whole curve but does not change its shape. A flat fee on a metered cost loses money on the heavy tail at $20 per million tokens and at $0.07 per million tokens alike; the tail just runs the meter longer to get there. You cannot out-cheapen a user who runs an agent around the clock. The category's margins improve. The structure is still the trap.
## What survives contact with users
The fix is to price AI products like the metered products they are, and to do it in a way customers can actually stomach.
- **Hybrid beats pure flat.** A modest base fee for the predictable part, which is the comfort customers are paying for, with usage or credits on top for the expensive part. You keep the insurance effect for the bulk of users and stop subsidizing the tail.
- **Pick a value metric.** Per token is accurate, but it is the taxi meter, the exact thing people hate. Price on something the customer values and can predict, a seat, a project, a run, a successful outcome, and size it to cover your cost.
- **Put the cap where the cost is.** Unlimited is fine on the cheap path and dangerous on the agentic one. Tier or cap the part that loops.
- **Warn before the bill.** The metering was defensible; the surprise was the mistake. Show usage, warn before overage, and the same change lands as fair instead of as a betrayal.
It helps to know what good looks like, because AI margins sit structurally below the software business they keep getting compared to. Venture analyses put AI-native gross margins [around 50% to 60%, against 80% to 90% for mature SaaS](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook), with inference eating roughly a fifth of revenue. Those figures are self-reported and improving as inference gets cheaper, so treat them as a gauge rather than a verdict. The point is to price knowing the meter is real. For what that leaves a solo founder after the model takes its cut, [the economics of a one-person AI business](/ledger/economics-of-a-one-person-ai-business/) has the take-home math; for the number that actually goes on the page, [the pricing psychology that holds up](/ledger/pricing-psychology-that-holds-up/) is the companion to this piece; and for picking the meter itself on a business product, [how to price a B2B SaaS](/ledger/how-to-price-a-b2b-saas/).
The wrapper is not doomed. The flat $20 is. Wrapping an LLM can be a real business, but only if you price for the user who runs the meter hot, because on a metered product that user is not the exception you can average away. That user is the whole ballgame.
---
# AEO and GEO: one real study, a pile of mythology, and a traffic cliff
Section: The Study
URL: https://okaneland.com/study/aeo-and-geo-what-the-research-says/
Generative and answer engine optimization are mostly the SEO industry reselling one controlled study, which found citations, statistics and named quotes lift AI visibility up to 40% while keyword stuffing lands about 10% below the do-nothing baseline. The llms.txt and schema tactics move nothing. What survives is being worth citing and being mentioned where AI reads, and no tool sells you that.
In 2024, a team led out of IIT Delhi and Princeton ran the first controlled experiment on getting content cited by AI search engines. They tested nine ways to rewrite a page. The one tactic the entire SEO industry was built on, stuffing a page with the keywords people search for, [scored about 10% worse than doing nothing at all](https://arxiv.org/abs/2311.09735). Adding citations, real statistics, and direct quotes lifted a page's visibility in AI answers by [up to 40%](https://arxiv.org/abs/2311.09735). That paper, "GEO: Generative Engine Optimization," is the closest thing this field has to a foundation. Almost everything sold on top of it is mythology.
The reason this matters is not academic. When Google puts an AI summary at the top of the results, people stop clicking. Pew Research tracked 68,879 real Google searches and found users clicked a normal result link [8% of the time when an AI summary was present, versus 15% when it was not](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/), and clicked a link inside the summary itself just [1% of the time](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/). Since AI Overviews launched, the share of news searches that end with no click to a publisher [rose from 56% to nearly 69%](https://techcrunch.com/2025/07/02/chatgpt-referrals-to-news-sites-are-growing-but-not-enough-to-offset-search-declines/). The traffic is draining off the open web and into the answer box.
So the question every founder and marketer is now asking is fair: if AI is going to summarize me instead of sending me visitors, how do I at least get cited in the summary? The answer has a name, two names actually, AEO and GEO, and an industry selling tools around them. This is what the research supports, what it does not, and where the money is going. It is the same method as our [look at whether AI coding really makes you faster](/study/does-ai-coding-make-you-faster/): follow the funding, and trust the people measuring the gap over the people selling the close.
## The short version
If you are shipping to earn and want to be found by AI search, the evidence backs a short list and contradicts a long one.
- **It is still SEO.** Google's own 2026 documentation says optimizing for AI search "is optimizing for the search experience, and thus still SEO," because the AI features run on the same ranking systems. The page still has to be indexed and good. There is no separate AI funnel to game.
- **Credibility beats tricks.** The one controlled study found that citing your sources, adding real numbers, and quoting experts measurably raised AI visibility. Keyword stuffing and a more "authoritative" tone did nothing. Write things that are true and well-supported.
- **Get mentioned where AI reads.** AI answers lean heavily on Reddit, Wikipedia, YouTube, and earned media; buying a GEO tool moves none of that. Being talked about on third-party sites tracks with AI visibility far more than backlinks do.
- **Ignore the file-and-schema mythology.** An llms.txt file is not read by any major engine. Special schema markup does not move AI citations in controlled tests. Both are sold hard and backed by nothing.
- **Do not confuse cited with chosen.** Most AI citations do not even name the brand, AI search engines get their source attributions wrong more than half the time, and getting cited is a long way from getting recommended. The target is noisy. Build for the reader who clicks through, because clicks are scarce and trust is the only durable asset.
Everything below is the evidence, including the parts that argue with the bullets.
## What AEO and GEO actually are
Two terms, very different pedigrees. GEO, generative engine optimization, comes from research. It was [introduced in a 2023 paper](https://arxiv.org/abs/2311.09735) by Pranjal Aggarwal, Vishvak Murahari and colleagues, first posted to arXiv in November 2023 and published at [KDD 2024](https://arxiv.org/abs/2311.09735), one of the top peer-reviewed venues in the field. It has a definition, a benchmark, and an experiment behind it.
AEO, answer engine optimization, comes from marketing. There is no founding paper and no clean origin. The term is usually traced to SEO consultant Jason Barnard, whose own site dates the coinage to [2017 in one place and 2018 in another](https://jasonbarnard.com/entity/answer-engine-optimization/), with his earliest concrete public use being a 2018 BrightonSEO talk. Even the people selling AEO cannot agree what it is: as of early 2026 there is [no consensus definition](https://en.wikipedia.org/wiki/Generative_engine_optimization) separating AEO from GEO, LLMO, AIO, and "AI SEO," and the labels get used interchangeably.
The cleanest definition comes from the company that owns the index. Google's position, in its [2026 Search Central documentation](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), is that "optimizing for generative AI search is optimizing for the search experience, and thus still SEO," because its AI features are "rooted in our core Search ranking and quality systems." The most authoritative voice in the room says the new discipline is the old discipline. Hold onto that. Most of what follows is the gap between that plain statement and what the tools are selling.
## The one real experiment
Give the GEO paper its due, because it is the only controlled result here. The researchers built [GEO-bench](https://arxiv.org/abs/2311.09735), 10,000 queries across 25 domains, each paired with the top five Google results, and tested whether rewriting a source could make a generative engine feature it more. Three tactics worked: Cite Sources, Quotation Addition, and Statistics Addition lifted visibility by [30 to 40% on the paper's main metric](https://arxiv.org/abs/2311.09735). The effect [carried over to a live engine, Perplexity](/primer/how-to-use-perplexity/), at [up to 37%](https://arxiv.org/abs/2311.09735). The lesson is narrow and real: generative engines reward content that looks credible, with sourced claims, real numbers, and named quotes.
The more useful finding is what failed. Keyword stuffing, the bluntest classic SEO move, performed about [10% worse than not optimizing at all](https://arxiv.org/abs/2311.09735). Rewriting in a more persuasive, "authoritative" tone produced [no significant improvement](https://arxiv.org/abs/2311.09735); the models were already robust to it. The paper's own conclusion is that traditional SEO strategies will not transfer to generative engines. So the foundational study says two things at once: a few credibility tactics help, and the reflexes most SEO blogs still sell actively hurt.
It is worth knowing the limits, because the next wave of research does. The GEO experiment measured how visible a single source is inside a fixed set of results. It did not test which of two competing pages wins the citation. That distinction matters, and the 2026 work went after it.
## What the independent research adds
The sharpest correction comes from a controlled study, ["What Gets Cited,"](https://arxiv.org/abs/2605.25517) that ran 252,000 trials across six models. Its finding: the biggest drivers of being cited are [topical relevance and retrieval position](https://arxiv.org/abs/2605.25517); on-page tweaks trail far behind. Formatting changes, the section-and-structure edits GEO tools push, had [no measurable effect](https://arxiv.org/abs/2605.25517); the models "parse content regardless of visual organization." Credibility and completeness cues helped, but only as secondary factors once a page was already relevant and retrieved. A separate Carnegie Mellon study, [AutoGEO](https://arxiv.org/abs/2510.11438), automatically learned what generative engines prefer and landed back on "source citation" with credible attribution as a consistently favored feature, which independently corroborates the GEO paper's one durable tactic.
Then there is the assumption under every "rank in AI" pitch: that AI cites the pages already ranking in Google. It mostly does not. An academic measurement from Ruhr University Bochum and the Max Planck Institute found AI Overview links have [less than 50% overlap with Google's organic top 10](https://arxiv.org/abs/2510.11560), and stay [below 60% even against the top 100](https://arxiv.org/abs/2510.11560); on average [53% of the domains an AI Overview consults are not in the organic top 10 at all](https://arxiv.org/abs/2510.11560). An independent analysis by Originality.AI, across 29,000 health-and-money queries, found [52% of AI Overview citations come from outside the top 100 results](https://originality.ai/blog/google-ranking-ai-citations-study). The AI is reading a broader, stranger set of pages than the ranking everyone optimizes for.
## The engines cite badly
Here is the part the tools never mention: getting cited by an AI is a low-quality signal, because the citations themselves are unreliable. A Stanford study at EMNLP 2023 found that across four generative search engines, only [51.5% of generated sentences were fully supported by their own citations](https://arxiv.org/abs/2304.09848). It got worse at scale. Columbia's Tow Center tested eight AI search engines on 1,600 queries and found they gave [incorrect source attributions more than 60% of the time](https://www.cjr.org/tow_center/we-compared-eight-ai-search-engines-theyre-all-bad-at-citing-news.php), ranging from [Perplexity at 37% to Grok-3 at 94%](https://www.cjr.org/tow_center/we-compared-eight-ai-search-engines-theyre-all-bad-at-citing-news.php). In an earlier test, ChatGPT Search was [wrong on 153 of 200](https://www.cjr.org/tow_center/how-chatgpt-misrepresents-publisher-content.php) source questions while almost never admitting uncertainty.
We saw the same thing first-hand. When we [bought Perplexity Max and drove every tool in it](/proof/perplexity/), the advanced research modes were strong, but everyday search still leaned on SEO content mills, and one Deep Research report cited a politics magazine for a claim about AI billing. The fix in that review is the fix here: the Academic mode that restricts sources to real research is the antidote, which tells you the default is the problem.
And being cited is not being chosen. A Semrush study found [61.7% of AI citations are "ghost citations"](https://www.semrush.com/blog/the-ghost-citations-study/) that link a page as a source without ever naming the brand. So "we got cited" can mean the model quietly read you and recommended someone else.
## Who actually gets cited
If a GEO tool could buy you into AI answers, you would expect the citations to cluster around its customers. They do the opposite. Across the platforms, AI answers lean on community and earned sources. In Profound's analysis of 680 million citations, [Wikipedia made up almost half of ChatGPT's top citations and Reddit nearly half of Perplexity's](https://www.tryprofound.com/blog/ai-platform-citation-patterns). Peec AI's look at 30 million cited sources ranked [Reddit first, YouTube second, LinkedIn third](https://peec.ai/blog/top-domains-cited-by-ai-search-analysis-based-on-30m-sources). A 5W analysis found [Wikipedia and Reddit alone drive more than 25% of US ChatGPT citations](https://www.prnewswire.com/news-releases/wikipedia-and-reddit-now-drive-over-25-of-chatgpt-citations-in-the-us-new-5w-research-finds--wsj-nyt-and-bloomberg-do-not-appear-in-the-top-20-302768339.html), while the Wall Street Journal, New York Times, and Bloomberg do not appear in the top 20. Muck Rack, across 25 million AI-cited links, found [earned media accounts for about 84%](https://muckrack.com/blog/what-is-ai-reading-may-2026) and paid content 0.3%.
The rest is a very long tail. Evertune, across 200 million prompts, found even the single most-cited domain on a platform [rarely exceeds 5% of citations](https://www.evertune.ai/resources/ai-search-statistics-for-generative-engine-optimization), with the other 95% spread across thousands of sites. There is no shortcut into that distribution. The one thing that reliably moves it is being genuinely talked about: a clean natural experiment found that when Google's AI Overviews started surfacing a subreddit, that community's activity [rose about 12%](https://arxiv.org/abs/2605.16428), concentrated in real opinion and experience rather than facts.
## The myths the tools sell
With the evidence in hand, the popular tactics sort cleanly into what holds up and what does not.
- **"Add an llms.txt file."** Busted. Google's Gary Illyes said flatly that Google [does not support llms.txt and is not planning to](https://searchengineland.com/google-says-normal-seo-works-for-ranking-in-ai-overviews-and-llms-txt-wont-be-used-459422). John Mueller said [no AI service uses it, and server logs show the bots do not even request the file](https://www.searchenginejournal.com/google-says-llms-txt-comparable-to-keywords-meta-tag/544804/), comparing it to the discredited keywords meta tag. An SE Ranking study of about 300,000 domains found [no correlation with AI citations](https://seranking.com/blog/llms-txt/). We [publish an llms.txt ourselves](/llms.txt) because it is cheap and harmless, but nobody should sell it as a citation tactic, because no engine reads it yet.
- **"Add special schema markup."** Busted. Google's documentation states plainly there is [no special schema.org structured data you need to add](https://developers.google.com/search/docs/appearance/ai-features). Ahrefs tracked 1,885 pages that added schema and found [no meaningful uplift on any platform](https://ahrefs.com/blog/schema-ai-citations/), with citations actually dipping slightly in Google's AI Overviews. The "schema pages get cited more" claim is correlation: those sites also do everything else right.
- **"Carry over your keyword tactics."** Busted by the founding study itself: keyword stuffing [scored below baseline](https://arxiv.org/abs/2311.09735).
- **"Format and structure for the AI."** Busted by the controlled citation study: formatting-only edits had [no measurable effect](https://arxiv.org/abs/2605.25517).
- **"GEO is a brand-new discipline."** Overblown. Google calls it [still SEO](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), and the field cannot agree on its own definitions.
- **"A tool can buy you in."** Overblown. There is [no fixed ranking to game](https://www.airops.com/report/influence-of-retrieval-fanout-and-google-serps-in-chatgpt), ChatGPT cites only about 15% of the pages it even retrieves, and the citation distribution is a long tail dominated by earned sources.
The two tactics that survive contact with the evidence are unglamorous: be credible, and be mentioned.
## What actually moves the needle
So here is the short list the research supports, stated plainly.
Make the content genuinely credible. The one controlled experiment says [citations, statistics, and named quotes](https://arxiv.org/abs/2311.09735) raise AI visibility, and the Carnegie Mellon work agrees. That lever is substance, and no formatting trick supplies it.
Earn mentions on the sites AI trusts. Ahrefs studied 75,000 brands and found off-site brand mentions track with AI visibility at [0.664 versus 0.218 for backlinks](https://ahrefs.com/blog/ai-overview-brand-correlation/), roughly three times stronger, though the study is careful to call it [correlation rather than cause](https://ahrefs.com/blog/ai-overview-brand-correlation/). Combined with the earned-media and Reddit findings above, the pattern is consistent: third-party validation is the lever; your own page is along for the ride.
Match the engine and the moment. Freshness helps, but unevenly: about [half of Perplexity's citations are from the current year](https://www.seerinteractive.com/insights/study-ai-brand-visibility-and-content-recency) while ChatGPT skews older, so there is no universal recency rule.
And do the boring thing Google keeps repeating. Its single strongest recommendation is that [unique, useful content will matter more than any other suggestion](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide), and the only hard requirement to appear in an AI Overview is that the page is [indexed and snippet-eligible](https://developers.google.com/search/docs/appearance/ai-features). It is also why tools like [Surfer SEO, which now score both classic SEO and AI-search visibility](/proof/surfer-seo/), are useful as scorecards but cannot sell you a separate AI funnel. There is not one.
## The bottom line
Stand back and the hype cycle resolves. GEO is one solid, narrow research finding, that credibility beats tricks, wrapped in an industry that needed a new thing to sell after AI ate the click. AEO is the same instinct without even a paper behind it. The genuinely big story is that the [click is disappearing](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/) and the answer box keeps [people from leaving](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/), with AI sending roughly [170 times less referral traffic](https://techcrunch.com/2025/07/25/ai-referrals-to-top-websites-were-up-357-year-over-year-in-june-reaching-1-13b/) than Google search did as of mid-2025.
The builders who come out ahead will be the ones who are actually worth citing, on the sites where AI reads, who stopped treating a citation as a sale, and no GEO tool or llms.txt file buys that. It is the same thing that worked before the machines started summarizing, with less room than ever to fake it.
---
# AI coding: faster MVP, slower review, and the security bill nobody mentions
Section: The Study
URL: https://okaneland.com/study/does-ai-coding-make-you-faster/
AI coding made GitHub trial developers 55.8% faster building a web server from scratch, made experienced developers 19% slower on code they knew cold, and pushed team review time up 91%. Same tools, opposite results: the situation is the variable, and your own sense of speed is not a reliable guide to which one you got.
In 2025, the research group METR ran a controlled trial: experienced developers fixing real issues in their own large codebases, with and without AI tools. Before they started, they expected the AI to make them about 24% faster. Afterward, they believed it had made them about 20% faster. The clock said they were [19% slower](https://arxiv.org/abs/2507.09089) with it.
Feeling faster and being faster are not the same thing, and that gap is the whole problem. AI coding is the least understood tool most people have ever rushed to depend on. The real answer to "does it make you faster" is "sometimes, and you are a poor judge of which times." The rest of this is which times, and what it costs when you guess wrong.
It is worth knowing why the question is so loaded. AI coding is the fastest-scaling software category in history. Cursor went from $100M to [$1B in annual recurring revenue](https://www.cnbc.com/2025/11/13/cursor-ai-startup-funding-round-valuation.html) inside 2025, a six-month-old vibe-coded product [sold to Wix for $80M](https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vibe-coder-base44-sells-to-wix-for-80m-cash/), and [84% of developers](https://survey.stackoverflow.co/2025/ai/) now use or plan to use these tools. That much money buys a great deal of marketing, which is the one rule to carry into the research: follow the funding.
The eye-popping "AI made us X% faster" numbers almost all come from the companies selling the tools or the consultants selling the transformation. The findings that show a slowdown, or a hidden cost, come from independent researchers and from firms whose business is measuring the gap, with no sale to close. Both can be true at once, because they measure different situations.
## The short version
AI coding pays off on some work and quietly bills you on the rest. If you are shipping to earn:
- **Lean on it for the green field.** New projects, prototypes, scaffolding, and stacks you barely know are where the speed-up is real and large. That is most of what gets a first product live, which is good news if you are starting one.
- **Slow down on the brown field.** In a mature codebase you already know, or anything touching money, auth, or user data, the time you spend reviewing and correcting the output is the real cost. Budget for it, and do not let the tool talk you into a big change.
- **Do not trust "it feels faster."** It is the one signal every study agrees is broken. If the answer matters, time a couple of real tasks both ways.
- **Ship small, with tests.** The instability shows up in large AI-written batches. Small changes with real tests keep the speed without the breakage, the same habit behind [using Cursor well](/primer/how-to-use-cursor/).
- **Harden before users touch it.** Row-level security on, secrets out of the client, no agent pointed at a live production database. The headline disasters below were each one setting away from fine; [the self-audit for your own app](/study/is-your-vibe-coded-app-secure/) is its own piece.
Everything after this is the evidence for those rules, in case you want to argue with them.
## Where it genuinely speeds you up
GitHub's own controlled trial had 95 developers build a web server from scratch; the group with Copilot finished [55.8% faster](https://arxiv.org/abs/2302.06590), and the least experienced gained the most. A field experiment across three companies and 4,867 developers found about [26% more tasks completed](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4945566), with short-tenure developers gaining 27% to 39%. Even McKinsey's lab work, which leans optimistic, lands in the same place: [documentation and new code in roughly half the time, refactoring in about two-thirds](https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/unleashing-developer-productivity-with-generative-ai), but the savings collapse to under 10% on complex tasks and can turn negative for juniors on hard problems.
The common thread in every speed-up is new code, boilerplate, unfamiliar languages, well-scoped tasks, and people who are not yet experts. That is almost the definition of spinning up an MVP. On that work, the hype is pointing at something real, and you should use it hard. If that is the work you are doing, here is [the tools and workflow that actually get a first product live](/primer/vibe-coding-stack/), and the business case for the whole method is [its own verdict piece](/study/is-vibe-coding-worth-it/).
## Where it taxes you
METR's slowdown happened on the opposite profile: experts in repositories they had maintained for years, [over a million lines](https://arxiv.org/abs/2507.09089) of code and tens of thousands of stars, where reading and correcting the model's output cost more than it saved. The same tool that speeds a newcomer through a blank page slows a veteran down on code they already know cold.
And the review tax is not only a big-codebase problem. Two-thirds of developers say their top frustration is output that is ["almost right, but not quite,"](https://survey.stackoverflow.co/2025/ai/) and 45% say debugging AI-written code takes them longer than debugging their own. The time you save typing comes back at review, which is exactly why "it feels faster" misleads: the typing is visible and the reviewing is not.
At team scale it is the same trade, just bigger. Faros AI measured more than 10,000 developers shipping [21% more tasks and 98% more pull requests per person, while review time rose 91%](https://www.faros.ai/blog/ai-software-engineering) and company-level throughput barely moved. The work piled up at review instead of getting done. DORA's industry survey found the system-level version: in 2024, every 25% rise in AI adoption came with about [7% lower delivery stability](https://dora.dev/research/2024/dora-report/), and its 2025 update found throughput finally improving while the stability problem stuck around. More code, shipped in bigger and riskier batches, breaks more often.
## The bill nobody mentions
The worst outcome for someone shipping to earn is not "slower." It is "shipped, then broke," and that cost barely registers in the productivity numbers.
Start with code quality. An analysis of [211 million changed lines](https://www.gitclear.com/ai_assistant_code_quality_2025_research) found copy-pasted code climbing from 8.3% to 12.3% of all changes between 2021 and 2024, "moved" (refactored) code falling from about a quarter to under 10%, and churn, the share of code rewritten within two weeks, rising from roughly 3% to a projected 5.7%. More is getting written and less of it is getting cleaned up, and cloned code is linked in prior research to 15% to 50% more defects.
Security is worse. An NYU study found about [40% of AI completions](https://arxiv.org/abs/2108.09293) in security-relevant scenarios contained a known vulnerability. A Stanford study found developers with an AI assistant wrote [less secure code while feeling more confident](https://arxiv.org/abs/2211.03622) it was secure. (Both used 2021 and 2022 models, so treat the exact rates as a ceiling; the overconfidence is the part that has not aged.)
It is not hypothetical. In 2025, a security researcher scanned apps built on one popular vibe-coding platform and found [170 of 1,645 leaking user data](https://nvd.nist.gov/vuln/detail/CVE-2025-48757), names, emails, and API keys, through one missing database permission (logged as CVE-2025-48757 and rated critical). In a separate case, an AI agent [deleted a production database](https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-coding-platform-goes-rogue-during-code-freeze-and-deletes-entire-company-database-replit-ceo-apologizes-after-ai-engine-says-it-made-a-catastrophic-error-in-judgment-and-destroyed-all-production-data) during an explicit code freeze, wiped roughly 1,200 records, and could not undo it. The speed that ships your MVP is the same speed that ships the leak.
## Why the studies disagree
Line them up and the contradiction resolves. The big speed-ups are greenfield tasks and junior developers; the slowdown is experts on mature code they know intimately. Same tools, opposite result, because the situation is the variable. The other thing to hold onto is that self-report is close to worthless here: the METR developers misjudged their own speed by nearly 40 points, so "most developers feel more productive," true in almost every survey, tells you very little about whether they are. The same broken instrument governs whether you think you are learning, which is why [learning while vibe coding](/primer/can-you-learn-while-vibe-coding/) takes deliberate moves.
AI coding will get a money-making MVP out the door faster than anything before it, and it will hand you slower reviews, more rework, and a security bill if you point it at the wrong work and believe the feeling. The builders who win with it are the ones who know which kind of work they are doing, which is the judgement the tool cannot supply for you: [Steven Hylands on building judgement, not the thing](/studio/steven-hylands/).
---
# How to use OpenCode: the open-source terminal agent
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-opencode/
OpenCode is a free, open-source AI coding agent that runs in your terminal and points at almost any model, 75+ providers or a local one on your own machine. It is the model-agnostic, MIT-licensed answer to a terminal agent, and the two things worth knowing first are which OpenCode is the real one and how you connect a model. This is the whole thing, install to first edit, and what it does and does not cost.
OpenCode is an open-source AI coding agent that lives in your terminal, and its whole personality is one word: agnostic. It does not care which model you point it at, and it does not lock you into a subscription. You give it a task in a terminal window, and it reads your code, proposes edits, runs commands with your permission, and connects to whichever of 75-plus providers, or a local model, you prefer. It is free and MIT-licensed. For a builder who wants a capable terminal agent without a vendor deciding the model for them, that is the pitch.
Two things save confusion before you start. First, which OpenCode: the one this guide covers is made by Anomaly, the team behind the SST framework, and its repo is `github.com/anomalyco/opencode` (the older `sst/opencode` path redirects there). Other projects share the name and are unaffiliated. Second, the model: you bring your own, and the how is below. Here is the whole thing.
## What OpenCode is, and who makes it
OpenCode calls itself "the open source AI coding agent," and it is exactly that: an MIT-licensed agent you can read, fork, and run for free. It is built by Anomaly, the company behind SST, and while its main surface is a terminal TUI, it also ships a desktop app and an IDE extension. The license matters here for the same reason it does with [Aider](/primer/how-to-use-aider/) and [Cline](/primer/how-to-use-cline/): an open agent is one you own, one that cannot be taken away or repriced out from under you, and one whose model choice is yours rather than the vendor's.
## Install it, and the client/server core
Getting started is one command. Install with `curl -fsSL https://opencode.ai/install | bash`, or `npm i -g opencode-ai` if you prefer, then run `opencode` inside a project directory. There is a design detail worth knowing, because it explains a lot of what OpenCode can do: it runs as a **client and a server**. Starting `opencode` launches a TUI (the client) that talks to a local server, and that split "lets opencode support multiple clients." You can also run `opencode serve` to start a headless HTTP server with an OpenAPI endpoint, which is how you drive it programmatically or from another interface. Most of the time you just see the terminal; the architecture is why scripting and remote use are possible at all.
## Bring your own model
This is the core of OpenCode, and its biggest advantage. It "uses the AI SDK and Models.dev to support 75+ LLM providers" and supports running local models, so the list of what you can point it at is deliberately enormous. Named providers include Anthropic, OpenAI, Google, OpenRouter, and GitHub Copilot, and for local inference it connects to Ollama and LM Studio, the same zero-per-token setup [our Ollama guide](/primer/how-to-use-ollama/) walks through. You add credentials with the `/connect` command, and for a few providers you can log in with a subscription instead of a key (GitHub Copilot's device login, or ChatGPT Plus/Pro).
One caveat the docs are direct about, and worth repeating because people hit it: logging in with a **Claude Pro or Max subscription is not officially supported**. OpenCode's own documentation notes that Anthropic prohibits the plugins that did this, and that OpenCode stopped bundling them as of version 1.3.0, so the supported way to use Anthropic's models is an API key. That is not a knock on anyone; it is just the current state, and knowing it saves you an hour of trying the subscription path.
## What it costs
The short version: the tool is free, the model is not. OpenCode itself is open source under MIT, with no required paid tier, and you pay whichever provider you connect at that provider's rate, the same bring-your-own-key economics as [Aider](/primer/how-to-use-aider/) and [Cline](/primer/how-to-use-cline/). The cheapest path is a local model, where the per-token cost is zero. There is one optional first-party product, **OpenCode Zen**, a gateway of models the team has tested and verified, billed pay-as-you-go per request; the docs are explicit that it is "completely optional and you don't need to use it." So your OpenCode bill is whatever you choose to spend on tokens, which is exactly the meter [our cost study](/study/cut-your-ai-coding-bill/) tells you to watch: pick the model deliberately, and a local one costs nothing but your hardware.
## The features that matter
Underneath the simple terminal, OpenCode has the pieces a serious agent needs. It ships **agents and modes**: a Build agent with all tools enabled, a restricted Plan agent for thinking through a change without touching files, and subagents for focused work, switchable with the Tab key. It has built-in **LSP** integration with more than 24 language servers, so the agent sees the same diagnostics your editor does and can fix real errors. It supports **MCP** servers, local and remote, so you can extend it with external tools, the same discipline [our MCP tax study](/study/the-mcp-context-tax/) applies: add what a task needs and leave the rest off. A **permission system** resolves each tool to allow, ask, or deny, so you decide what runs automatically. Sessions are private by default and shareable only when you run `/share`. And it works non-interactively: `opencode run "..."` lets you script it into a pipeline.
## OpenCode vs Claude Code vs Aider
The comparison people search, stated as plain fact. All three are terminal AI coding agents; they differ in license, interface, and how you get a model.
**OpenCode** is MIT open source, runs in the terminal (plus desktop and IDE), reaches 75-plus providers and local models, and you bring your own key. **[Claude Code](/primer/how-to-use-claude-code/)** is Anthropic's own agent, available across terminal, IDE, desktop, and browser, where most surfaces run on a Claude subscription or an Anthropic Console account (its terminal and editor surfaces also support third-party providers), and its overview states no open-source license. **[Aider](/primer/how-to-use-aider/)** is Apache-2.0 open source, terminal-based and git-native, committing each change so you can undo with git, and it too connects to almost any model including local ones. The pattern to notice: two of the three are open source and let you run any model you like, and OpenCode is the one that pushes model-agnosticism furthest, 75-plus providers behind a single agent. Pick OpenCode if you want the widest model choice in an agent you own, start it on a local model to learn the loop for free, and read [the cost study](/study/cut-your-ai-coding-bill/) before you point it at a frontier API.
---
# How to use Replit Agent: from prompt to deployed app
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-replit-agent/
Replit Agent is an AI that builds a working app from a plain-language prompt inside Replit's browser IDE, then deploys it on the same page, with nothing installed on your machine. The part worth understanding before you start is the meter: Agent is billed by effort, one charge per checkpoint, and Replit does not publish a fixed price per checkpoint. This is the whole thing, first prompt to live URL, and how the billing actually works.
Replit Agent is the tool that turns "I want an app that does X" into a running, deployed app without you installing anything or writing the first line. You describe the idea in chat, and Agent sets up the project, writes the code, tests it, and puts it online, all inside Replit's browser IDE. Unlike a chatbot that only answers, Agent takes action. For someone who wants the shortest path from idea to a live URL, that is the whole appeal, and the one thing to understand before you start is how the meter works, because Agent bills by effort.
Here is the shape of it. Open Replit, describe your app, and Agent plans, builds, and tests it while you watch a live preview. You refine by chatting, and you deploy from the same screen when it is ready. The cost is charged per checkpoint as the Agent completes work, and because that is effort-based rather than a flat sticker, the skill is scoping each request so it does less. Everything below is the how.
## What Replit Agent is
Replit Agent is Replit's AI app builder, and it lives inside Replit's cloud IDE, so the entire loop, editor, terminal, database, and hosting, runs in a browser tab with nothing set up locally. The docs describe it plainly: rather than only answering questions, Agent "sets up your project, creates applications, checks its work, and fixes problems." You are giving instructions to something that does the work and shows you the result, not pasting snippets into your own editor.
## Agent or Assistant: which is which
Replit ships two AI tools and it is worth knowing the split, because it answers a common confusion. In Replit's own words, "if the Agent takes you 0 to 1, the Assistant takes you 1 to 10." **Agent** builds a new app from scratch, autonomously handling setup and fixes. The **Assistant** is for refining a project that already exists, quick edits and iterations on working code. They are meant to be used in tandem: Agent to get the thing standing, Assistant to shape it afterward. If you are starting from nothing, you want Agent.
## How to use it, step by step
The loop is a conversation with checkpoints. First, **describe** your idea in plain language, the more concrete the better. Second, optionally turn on **Plan mode**, which breaks a complex project into an ordered task list before any code is written, so you agree on the shape first. Third, Agent **builds**: it writes the code, sets up the infrastructure, and tests the result. Fourth, you **iterate** by chatting to refine what it made. Fifth, you **deploy** when you are ready. Along the way, each unit of completed work is a checkpoint, which doubles as a save point you can roll back to and, as the next section explains, the thing you are billed for.
## What it can build
Agent is not limited to JavaScript, which sets it apart from the browser builders that only do web frameworks. Its docs say you can "build with any language, framework, or stack, Python, Java, Rust, Go, C#, Angular, Vue, and more," and you can import an existing repository or start from a template. The artifact types run wide too: web apps, mobile apps, data dashboards, AI-powered tools, and even visual designs and documents. Native mobile is built with React Native and previewed on your phone through Expo Go, with guided App Store submission, and you can even build web apps from the Replit phone app on the go. If your idea needs a Python backend, this is one of the few prompt-to-app builders that will do it.
## Pricing, and how the Agent is billed
This is the most-searched part, and the part with the sharpest edge, so read it twice. Replit's plans, read from replit.com/pricing on 29 August 2026:
- **Starter:** free, with a daily Agent allowance to try it.
- **Core:** $20 a month (shown as $17 billed annually), with $20 of monthly model credits, full Agent with Plan and Build modes, and 2 parallel agents.
- **Pro:** $100 a month ($95 annually), with $100 of credits that roll over up to two months, Turbo mode, and 10 parallel agents.
- **Enterprise:** custom. There is no self-serve Teams plan.
The subscription is only half the cost. Agent work is billed **per checkpoint**, on an effort basis: "a checkpoint occurs when Agent completes work on your request," and simpler requests cost less than complex builds. Two things follow that matter. First, Replit does not publish a fixed dollar figure per checkpoint, so the cost of a given build is not a sticker you can read in advance. Second, third-party model usage (Claude, ChatGPT, Gemini) is billed at the provider's public API rate, deducted from your Replit credits. Your monthly credit allowance covers the routine work (Core and Pro also get Free Mode, no-cost everyday Agent work whose limits reset every five hours), but a big or looping build draws down credits fast. This is the same meter-without-a-ceiling problem [our cost study](/study/cut-your-ai-coding-bill/) maps for model tokens: scope each request tightly, watch your balance, and treat a complex prompt as a spending decision, not a free wish.
## Deploying and the built-in integrations
Hosting is part of the product, not a separate step. Replit offers four deployment types: **Autoscale** (the default, which adds servers under load and scales to zero when idle), **Reserved VM** (one dedicated server that never sleeps), **Static** (files only, no backend), and **Scheduled** (runs a command on a timer). Static is not compatible with Agent-built full-stack apps, so those go on Autoscale or Reserved VM. And the services an app needs are wired in: **Replit Database** is a managed PostgreSQL database, **Replit Auth** adds sign-in, **App Storage** holds files and assets, and **Secrets** encrypts your API keys. You can import from or export to GitHub, and connect third-party services like Stripe, though most connectors need a paid plan.
## Replit Agent vs Bolt vs Lovable
The comparison everyone runs, stated as plain fact. All three turn a prompt into a real app; they differ in the environment, the stack, and the meter.
**Replit Agent** is the widest of the three: a full cloud IDE plus agent plus built-in hosting, it builds in any language, and it bills per checkpoint on effort. **[Bolt](/primer/how-to-use-bolt-new/)** runs a development environment in your browser through WebContainers, builds across JavaScript frameworks, and bills by tokens. **[Lovable](/primer/how-to-use-lovable/)** is a chat builder for web apps with a built-in Cloud backend, and bills by credits, roughly one per message in its planning mode. The pattern to notice is that all three meter differently, checkpoints, tokens, and credits, so a fair comparison is about which environment fits you and which meter you can predict. Pick Replit if you want the whole studio in one browser tab and a language other than JavaScript, and read [the cost study](/study/cut-your-ai-coding-bill/) before you lean on it, because an effort-billed agent rewards knowing what each prompt is likely to spend. The [v0 guide](/primer/how-to-use-v0/) and [the from-scratch primer](/primer/build-an-app-with-ai-from-scratch/) cover the neighbours.
---
# How to use Cline: the open-source agent in your editor
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-cline/
Cline is an open-source coding agent that lives in your editor and terminal, and its whole design is that it proposes every edit and waits for you to approve it. Two things make it worth learning: it plans before it acts, and it connects to almost any model, including a local one at zero per-token cost. This is the whole thing, install to first approved edit, and the three ways to pay for the model behind it.
Cline is an open-source coding agent that runs inside your editor, and its design choice is the thing to understand first: it does not quietly rewrite your project. It reads, it proposes, and it waits for you to approve each edit and each command. Its README calls it "the open source coding agent in your IDE and terminal," it is licensed Apache 2.0, and it comes as a VS Code extension, a JetBrains plugin, and a terminal CLI. For a builder who wants an agent that does real work without taking the keyboard away, that approval-first design is the whole appeal.
Here is the shape of it. Install the extension, point it at a model (your own API key, a local model, or Cline's own billing), and give it a task. It plans the change, shows you a diff, and applies it only once you approve. You keep a checkpoint to roll back to, and you decide how much of the loop to automate. Everything below is the how.
## What Cline is, and where it runs
Cline is maintained by Cline Bot Inc. and is genuinely open-source under the Apache 2.0 license, which you can read in the repo. It installs three ways: from the VS Code Marketplace, from the JetBrains Marketplace as a plugin, and as a terminal CLI, so it meets you in the editor you already use or on the command line. One piece of trivia that answers a common search: the VS Code listing still carries the extension id `saoudrizwan.claude-dev`, the only remaining trace of the project's original name, Claude Dev. Search for Cline in your editor's extensions panel and install the one published under that id.
## Plan and Act: the two modes
Cline's signature is that it separates thinking from doing. In **Plan mode** it can read your codebase, run searches, and talk through an approach, but it cannot modify any files or execute commands. You use it to agree on what should happen before anything does. In **Act mode** it can modify files, run commands, and carry out the plan. The conversation history carries over when you switch, so the plan you settled on is the plan it executes, and you can cycle back to Plan whenever the task turns a corner. Starting in Plan on anything non-trivial is the habit that keeps the agent from confidently doing the wrong thing.
## Staying in control: approvals and checkpoints
This is where Cline earns the trust to run in a real project. By default it is human-in-the-loop: every file edit and terminal command requires your approval, so nothing changes without your say-so. When you want it to move faster, **Auto-Approve** lets you lift that prompt selectively, evaluated per tool call across categories, file operations, terminal commands, the browser tool, and MCP servers, so you can let it read and edit freely while still confirming anything that runs a command. And **checkpoints** are the safety net: Cline snapshots your project into a separate shadow Git repository after each step, so you can restore the files, the task, or both without touching your real Git history. Approve edits as it goes, keep a checkpoint to fall back to, and an autonomous agent stops being a scary thing to run.
## Connecting a model: cloud and local
Cline does not ship a model; you bring one, and the range is wide. It connects to the major cloud providers, Anthropic, OpenAI, Google, OpenRouter, AWS Bedrock, Azure, GCP Vertex, DeepSeek, xAI, Mistral, and Cerebras among them, plus any OpenAI-compatible API. And it runs **local models** through Ollama and LM Studio, which means the agent can work against a model on your own machine at no per-token cost, the same setup [our Ollama guide](/primer/how-to-use-ollama/) and [our LM Studio guide](/primer/how-to-use-lm-studio/) walk through. Which model you pick is most of your experience with Cline, and most of your bill.
## What it costs: the extension is free, the model is not
The confusion worth clearing up: the Cline extension itself is free and open-source, and it has no subscription of its own that you are required to buy. What costs money is the model behind it, and there are three ways to pay for that. You can **bring your own key** from any provider and pay that provider directly, which the homepage sums up as "bring your own key, your own endpoint, or your own weights." You can use the **Cline Provider** for pay-as-you-go access without wrangling a key. Or you can take **ClinePass**, a flat monthly subscription, if predictable billing suits you better. All three reach 100+ models. The cheapest path is a local model, where the per-token cost is zero and you are paying only in your own hardware, which is exactly the lever [our cost study](/study/cut-your-ai-coding-bill/) pulls: the way to shrink an AI coding bill is to move the routine work onto a meter that does not run.
## Extending Cline with MCP
Cline speaks the Model Context Protocol, so it can reach past your codebase to external tools and data. Through MCP servers, local or remote, it can query a database, call an API, or manage cloud infrastructure, and you add servers through a JSON config, the extension's Configure tab, or the `cline mcp` CLI wizard. It can even help build a new tool on request, wiring up a capability through MCP when you ask for one. If you have read [our MCP tax study](/study/the-mcp-context-tax/), the same discipline applies here: add the servers a task needs, and leave the rest off.
## Cline vs Aider vs Cursor
The comparison worth drawing, stated as plain fact. All three put an AI agent on your code; they differ in license, interface, and how you pay.
**Cline** is Apache-2.0 open source, runs in your editor and terminal, and lets you bring any model, cloud or local, or use its hosted billing. **[Aider](/primer/how-to-use-aider/)** is also Apache-2.0 and also model-flexible including local, and it lives in the terminal and is git-native, committing each change with a sensible message. **Cursor** is a commercial, proprietary AI editor with a free Hobby tier, Pro at $20 a month, Teams at $40 a user, and higher tiers above that; it is the polished all-in-one to Cline and Aider's open, bring-your-own-model approach. Two of the three are open source and let you run a local model, and Cline is the one that combines that openness with an editor-native, approve-every-step workflow. Pick Cline if you want an agent you own and control, start it on a local model to learn the loop for free, and read [the cost study](/study/cut-your-ai-coding-bill/) before you point it at a frontier API.
---
# How to use v0: generate the UI, get real code
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-v0/
v0 is Vercel's AI builder: describe a UI or an app, and it writes real React and Next.js code you can preview, own, and deploy. Two things trip people up before they start, and both are here. It moved from v0.dev to v0.app, and it bills in credits metered on tokens, with a free tier capped at seven messages a day. This is the whole thing, first prompt to shipped, and what the credits actually buy.
v0 is Vercel's AI builder, and its trick is a narrow one done well: you describe a screen or an app, and it writes real React and Next.js code you can preview live, edit, own, and deploy. It is the tool that made prompt-to-UI mainstream, and it stayed close to the stack a lot of the web already runs on. Before you start, two facts save you confusion. It lives at v0.app now, not the v0.dev you may have bookmarked, and it bills in credits metered on tokens, with a free tier that stops at seven messages a day.
Here is the whole shape. Sign in at v0.app, type what you want, and v0 generates a working, previewed component or app that you refine by prompting. When it is ready you export the code, sync it to GitHub, or deploy it to Vercel in one click. The meter is credits, and the skill is describing tightly so each message spends less. Everything below is the how.
## What v0 is, and the v0.dev move
v0 is described in its own docs as an AI agent that creates real code and full-stack apps, made by Vercel and deployed on Vercel's infrastructure. The one piece of housekeeping: the product moved domains. The `v0.dev` address now redirects to `v0.app` (the old URL answers with a 307 to the new root and a 308 on doc pages), so old links and tutorials still land in the right place, but the current home is v0.app. If a guide you are following says v0.dev, it is the same tool.
## What v0 builds: the output stack
v0 emits real code on the modern React stack, not throwaway mockups. Its docs say it works with Next.js, Tailwind, and shadcn/ui, and in practice you get React components, Next.js on the App Router, TypeScript, Tailwind CSS, and shadcn/ui primitives. There is no hard framework lock stated in the docs; Next.js App Router is the default full-stack target, it also generates standalone React components, and it references Python and SQL for Snowflake data apps. If your world is already Next.js and shadcn, v0 outputs the exact thing you would have hand-written, which is the reason it fits so cleanly into a Vercel workflow.
## How to use v0: prompt, preview, iterate
The loop is a chat. You describe your idea, v0 generates the code with a real-time preview, and you keep prompting to ship features, refine the design, and update copy. Two things make the loop forgiving: the live preview shows the result as it builds, and v0 does automatic error fixing, running intelligent diagnostics and repairing its own mistakes rather than handing you a broken render. Start narrow (one screen, one component) and add on, because a tight first prompt both looks better and, as the pricing section explains, spends fewer credits.
## Getting your code out: export, GitHub, deploy
v0 is not a walled garden, and this is the part worth knowing before you commit. You can export the code to work locally or edit it directly in v0. The GitHub integration is genuinely Git-native: connecting a chat creates a dedicated branch for it (something like `v0/username-abc123`), every message that changes code becomes a commit, and the Publish button opens a pull request from that working branch into its base so you review and merge like any other PR. And to ship, the Share button's Publish tab takes the app live on Vercel with one click, on Vercel's own scalable infrastructure. Export to own it, GitHub to review it, Vercel to ship it, and you can do all three from the same chat. The [from-scratch primer](/primer/build-an-app-with-ai-from-scratch/) makes the case that owning the repo is what gets you past the demo, and v0 hands it to you.
## v0 pricing and credits
This is the most-searched thing about v0, and the part with the sharpest edges. v0 bills in **credits**, and since May 2025 those credits are metered on input and output tokens rather than a fixed message count, so a longer prompt and a larger generated file both cost more. Prices read from v0.app/pricing on 23 August 2026:
- **Free:** $0 a month, with **$5 of included monthly credits** and a hard **7 messages a day** limit. Enough to try it, tight for real work.
- **Plus:** **$30 per user a month**, with $30 of included monthly credits plus $2 of free daily credits on login. This is the plan marked Popular.
- **Business:** **$100 per user a month**, with the **same $30 of monthly credits** as Plus plus the same $2 daily. The extra $70 buys privacy and security for teams, not more usage.
- **Enterprise:** custom. And a legacy **Premium at $20** is being sunsetted, closed to new users.
Read the Business row twice, because the price jump is the confusing part: it carries the same credit allowance as Plus, so paying more than three times as much buys a privacy and security posture for the team, not a bigger tank. On the meter itself, one caution: v0 publishes no token-to-credit or dollar-per-credit conversion on any of its pages, so anyone quoting "X credits per prompt" is estimating. Plan by the qualitative rule instead, shorter prompts and smaller scoped changes cost less, and watch the [same usage-billing trap our cost study maps for model tokens](/study/cut-your-ai-coding-bill/): the danger is a meter with no ceiling, so scope every message.
## Integrations and the v0 API
Around the core loop, v0 connects to the parts a real project needs. It can clone a page from a screenshot or a Figma file, which is the fastest way to turn an existing design into code. There is a Platform API for programmatic access to v0's generation, chat, and deploy, so you can wire v0 into your own tools or a CI pipeline. And under the hood v0 runs on Vercel's composite v0 models, which pair a language model's reasoning with retrieval and a dedicated error-fixing step; the current generation, `v0-1.5-md` at 128K context and `v0-1.5-lg` at 512K, is what does the heavy lifting when you prompt.
## v0 vs Bolt vs Lovable
The three-way everyone searches, and the answer is about stack and meter, so here it is as plain fact. All three turn a prompt into real code you can sync to GitHub; they differ in what they build on and what they charge by.
**v0** is the Vercel-native choice: it writes Next.js App Router, React, Tailwind, and shadcn/ui, deploys to Vercel, and bills in credits. **[Bolt](/primer/how-to-use-bolt-new/)** is by StackBlitz and runs a whole development environment in your browser through WebContainers, builds across JavaScript frameworks plus Expo for mobile, and bills in tokens. **[Lovable](/primer/how-to-use-lovable/)** builds a React app (new projects on TanStack Start with server-side rendering, older ones on React and Vite) with an optional Supabase backend, and bills in credits. A useful pattern falls out of that: two of the three meter in credits and one in tokens, and v0 is the one that assumes you are living in the Next.js and shadcn world already. Pick v0 if that is your stack, start on the free seven-a-day to learn the meter, and read [the cost study](/study/cut-your-ai-coding-bill/) before you scale, because a credit-billed builder rewards knowing what each prompt spends.
---
# How to use Bolt.new: build an app from a prompt
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-bolt-new/
Bolt.new turns a prompt into a running full-stack app in your browser, with no local setup, because StackBlitz runs the whole dev environment in a browser tab. The thing to understand before you start is the meter: Bolt bills by tokens, with a real free daily allotment. Here is the whole thing, first build to owning the code, and how to make those tokens last.
Bolt.new is the fastest way to go from a sentence to a running app without installing anything. You type what you want into a box, and Bolt generates, runs, and lets you edit a full-stack web app right in your browser. That last part is the trick: Bolt is made by StackBlitz and runs on WebContainers, the technology that boots a whole development environment, including `npm install` and a dev server, inside your browser tab. For a vibe coder who wants to get an idea on screen in minutes, that is the appeal. The thing to understand before you start is the meter, because Bolt bills by tokens.
Here is the whole answer up front. Sign in, type a prompt, and click Build. Bolt scaffolds a JavaScript app you can preview and edit immediately, and connect to a database, GitHub, and a deploy target when you are ready. It runs on tokens, with a genuine free daily allotment, and most of the skill is spending those tokens well. Everything below is the how.
## Start your first build
Go to bolt.new, sign in with Google, GitHub, or email (no credit card), and you are looking at a prompt box. Type what you want to build and click **Build now**. You do not have to start from a blank prompt: you can begin from uploaded files, a Figma or Google Stitch design, an imported GitHub repo, or a template. Bolt reads the prompt, sets up the project, and shows you a live preview within the same tab, which is the moment the browser-based approach earns its keep, since there was nothing to install first.
## What you can build
Bolt is a JavaScript shop. It supports a Node.js backend and any JavaScript frontend framework, with React as the default and Vite and Next.js named in the docs. What it does not do is non-JavaScript backends: PHP and Python are not compatible, so a Django or Laravel app is out of scope. It runs best in a desktop Chromium browser or Safari, with a few features desktop-only. If your idea is a JavaScript web or mobile app, Bolt will build it; if it needs a Python backend, this is the wrong tool.
## Tokens and pricing: what it actually costs
This is the most-searched thing about Bolt, and the part worth reading twice. Bolt bills by **tokens**, the unit it consumes as it reads, reasons about, and builds your project, and a per-conversation limit covers both your prompt and Bolt's output. Because most token use comes from Bolt reading and syncing your project files, a bigger project costs more tokens per message, which is the dynamic that surprises people. Prices read from bolt.new/pricing on 15 August 2026:
- **Free:** $0 a month, with a **300,000-token daily limit** and **1 million tokens a month**, public and private projects, hosting, and Bolt branding on your sites. The daily limit is the one you will feel first.
- **Pro:** $25 a month, no daily limit, 10 million tokens a month, no branding, custom domains, and unused tokens roll over. Higher tiers scale the allotment: Pro 50 is 26M tokens for $50, Pro 100 is 55M for $100.
- **Teams:** $30 per member a month, adding centralized billing and admin controls.
Two details that catch people: free tokens reset on the 1st of the month and do not roll over, while paid tokens reset on your renewal date and unused ones carry for two months. For reference, Bolt's own quickstart tutorial uses just under the 300,000 daily free tokens, so the free tier is enough to learn on but tight for a real build.
## Spend fewer tokens
Because tokens are the cost, the real skill is not burning them. Three moves from Bolt's own best-practices docs. Use **Plan Mode**, which lets you plan and ask questions with full project context, and even web research, without generating any code, so it costs fewer tokens than building (though it is not free). Pick the right **agent**: the Standard agent handles average work at a lower token cost, and you save the Max agent for genuinely complex reasoning. And keep prompts **specific and scoped** to the file or function you mean, rather than turning Bolt loose on the whole codebase, since a broad prompt makes it read more and spend more. Restoring an earlier version through Version History and editing directly in Code View both cost no tokens at all, so lean on those for small fixes.
## Databases, deploy, and owning your code
Bolt's integrations are first-party and cover the parts an app needs. **Supabase** adds a hosted database, authentication, and edge functions (on Vite projects). **GitHub** syncs your project out of Bolt with automatic commits and two-way updates, checking for outside changes every thirty seconds, which is also how you get a real version history and a backup that lives outside the sandbox. For going live, Bolt now publishes every project to a free `bolt.host` address with built-in hosting by default, with custom domains on paid plans, and Netlify remains an option if you prefer it.
And you own the code, which is the question every builder asks. You can **download** the full project as a zip, or work through the GitHub sync and edit anywhere, or edit directly in Bolt's Code View. Nothing traps your app inside Bolt, which matters, because the [from-scratch primer](/primer/build-an-app-with-ai-from-scratch/) is clear that the walls come after the demo, and getting your code out is how you get over them.
## Build a mobile app
One feature worth knowing: Bolt builds mobile apps, not just websites. Include the words "mobile app" in your first prompt and Bolt generates an Expo (React Native) app that runs on iPhone and Android from the same code. You test it on your phone by scanning a QR code with Expo Go, and when it is ready you download the code and build for the App Store and Google Play through Expo's EAS. It is the same prompt-to-preview loop, pointed at a native target.
## Bolt or Lovable
The comparison everyone searches, and it comes down to environment and meter. Both Bolt and Lovable turn a prompt into real full-stack code you can sync to GitHub. Bolt runs a full development environment in your browser through WebContainers and is framework-flexible across JavaScript, and it bills by tokens. Lovable, which [our Lovable guide](/primer/how-to-use-lovable/) covers, builds on a fixed React and Vite stack, and bills by credits.
 They are close enough that Bolt can import a Lovable project through GitHub, so the choice is which environment and pricing model fits you, not a wall between them. Pick Bolt if you want an in-browser dev environment and framework flexibility, start on the free daily tokens to learn the meter, and read [our cost study](/study/cut-your-ai-coding-bill/) before you scale, because a usage-billed builder rewards knowing exactly what each message spends.
---
# How to use Zed: the fast, open-source editor with AI
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-zed/
Zed is a code editor written from scratch in Rust for speed, open source, and free. Its AI is what makes it a vibe-coder tool: an agent panel that edits your code, a one-line path to a free local model, and the ability to run Claude, Codex, or Gemini CLI inside the editor over an open protocol. Here is the whole thing, install to agent.
Zed is the editor for people who want speed and want to own their AI stack. It is written from scratch in Rust by the team behind Atom and Tree-sitter, which is why it feels faster than the Electron editors most of us grew up on, and it is open source and free. What makes it a vibe-coder tool rather than just a fast text editor is the AI: an agent panel that edits your code, a one-line path to a free local model, and the ability to run Claude, Codex, or Gemini CLI inside the editor. For a builder who wants a quick editor that does not lock them to one model vendor, that is the pitch.
Here is the whole answer up front. Install Zed, open the agent panel with a keystroke, and point it at a model: your own API key, Zed's hosted models, or a local one running free through Ollama. If your agent of choice is Claude Code or Codex, Zed runs it inside the editor over an open protocol. The editor itself costs nothing, and everything below is the how.
## What Zed is
Zed bills itself as a high-performance, multiplayer code editor, and the Rust-and-GPU foundation is the reason the speed claim holds up in practice. It is open source, licensed primarily under GPL-3.0-or-later, built by Zed Industries. The parts that matter for this guide are that it natively supports agentic editing and does not tie you to a single model provider, which is exactly the model-agnostic camp our [agent field guide](/study/ai-coding-agent-field-guide/) places it in.
## Install it on macOS, Linux, or Windows
All three desktop platforms are available as stable builds (a web version is not out yet). One command each, from the install docs read 15 August 2026:
- **macOS:** `brew install --cask zed`
- **Windows:** `winget install -e --id ZedIndustries.Zed`
- **Linux:** `curl -f https://zed.dev/install.sh | sh`
Or download directly from zed.dev. Windows searchers ask about this a lot, so to be clear: the Windows build is a stable download alongside macOS and Linux, installable through winget.
## The AI agent panel
Zed's AI lives in the Agent Panel, which the docs describe as where you interact with agents that can read, write, and run code in your project. Open it with `Cmd+Shift+A` on macOS or `Ctrl+Shift+A` on Linux and Windows, or run `agent: new thread` from the command palette, or click the sparkle icon in the status bar. That panel is the surface for generating code, refactoring, and asking questions about your project, and everything in the next sections is about what model powers it.
## Pick your model: your key, Zed-hosted, or local
Zed gives the agent five ways to reach a model, and you will use one of three. **Bring your own API key** for a provider (Anthropic, OpenAI, Google AI, DeepSeek, Mistral, GitHub Copilot, LM Studio, or Ollama), which you save in the panel's settings and which then costs only what that provider charges. **Use Zed's hosted models** on a paid plan, where Zed runs major models for you and bills hosted usage at the provider's API list price plus 10%. Or **run a local model**, which is the free path and the next section. OpenRouter, Vercel, and Amazon Bedrock are wired in as gateways rather than direct providers, if you route through one of those.
## Run a local model with Ollama
This is the most-searched thing about Zed's AI, and the setup is short. Install Ollama, pull a model with `ollama pull mistral` (or a coding model), and run `ollama serve`, or just open the Ollama app on macOS. Zed treats Ollama as a dedicated first-party provider, so the model appears in the agent panel's model picker once the server is up. If you need to point Zed at a non-default address or set the context window, it lives under the `language_models` key in `settings.json`:
```
{ "language_models": { "ollama": { "api_url": "http://localhost:11434" } } }
```
The context length defaults to 4096 tokens, which you can raise there too. That is a coding agent running against a model on your own machine for no per-token cost, the same zero-cost setup [our Ollama guide](/primer/how-to-use-ollama/) covers from the model side; [LM Studio](/primer/how-to-use-lm-studio/) is a supported provider here as well if you prefer its window.
## Run Claude, Codex, or Gemini CLI inside Zed
This is the feature worth switching for, and it is the most on-brand for a vibe coder. Zed connects external agents through the Agent Client Protocol (ACP): the external agent keeps its own runtime and login, while Zed hosts the conversation in its agent panel. The documented agents include Claude (as the Claude Agent), Codex, OpenCode, Copilot, Cursor, and Gemini CLI. So if you already run Claude Code, you keep it, its subscription, and its behavior, and you drive it from inside Zed instead of a separate terminal, with your editor's context right there. It turns Zed into a neutral home for whichever agent you already pay for, rather than a competitor to it, which is a genuinely different proposition from an editor that ships one built-in assistant.
## Edit predictions with Zeta
Separate from the agent panel is inline autocomplete, which Zed calls edit predictions. The default model is Zeta, an open-source model Zed developed, and you accept a suggestion with tab. You can swap in GitHub Copilot or Mercury Coder if you prefer. The free tier includes 2,000 accepted Zeta predictions a month, and the Pro plan removes that limit, so most people never think about it until they are coding heavily.
## What it costs, and the open-source part
The editor is free and open source, and the pricing is only about the AI. The free tier is called **Personal** and is $0 forever: it includes those 2,000 monthly edit predictions and, importantly, unlimited use of the agent panel with your own API keys or with external agents like the Claude Agent and Codex CLI. In other words, bring your own key or your own Claude Code subscription and the whole thing costs nothing beyond what you already pay that provider. **Pro** is $10 a month for unlimited edit predictions plus Zed's hosted models with $5 of included tokens, and **Business** is $30 a seat for team governance. Add the GPL-3.0 license and the free local-model path, and Zed is one of the few editors where a cost-conscious builder can run a full agentic setup for genuinely $0, which is the same calculation [our cost study](/study/cut-your-ai-coding-bill/) keeps returning to. Install it, open the agent panel, point it at a local model or the agent you already run, and you will know within an afternoon whether the Rust-native speed and the bring-your-own-everything model fit how you work.
---
# How to use LM Studio: run local LLMs with a GUI
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-lm-studio/
LM Studio is the friendly way to run AI models on your own machine: a desktop app that finds, downloads, and runs local models, then serves them to your editor and agents over a local API. It is free, even at work, and unlike a CLI-first tool it lets Claude Code connect straight to a local model with no proxy. Here is the whole thing, download to editor.
LM Studio is the local-models tool for people who want a window, not a command line. It is a desktop app that does the whole job in one place: it searches Hugging Face for models, downloads them, runs them with a chat interface, and, when you flip a switch, serves them over a local API that your editor and your agents can use. It is free even for commercial work, and it has one trick a CLI-first tool does not: Claude Code can talk to a local model through it directly. For a vibe coder who wants free inference without living in the terminal, that is the pitch.
Here is the whole answer up front. Download LM Studio, use its Discover tab to pull a model from Hugging Face, and chat with it in the app. When you want your tools to use that model, turn on the local server: it speaks the OpenAI API at `http://localhost:1234/v1`, so VS Code and Codex point straight at it, and it speaks the Anthropic API too, so Claude Code connects with two environment variables and no proxy. Everything below is the how.
## Install it on Mac, Windows, or Linux
Download the installer for your OS from the LM Studio Downloads page. The system requirements, from the docs, are worth checking before you start: macOS needs Apple Silicon (M1 through M4) on macOS 14.0 or later, so Intel Macs are out; Windows runs on x64 with AVX2 or on ARM (Snapdragon X Elite); Linux ships as an AppImage for x64 and ARM64 on Ubuntu 20.04 and up. Sixteen gigabytes of RAM is the recommended floor, because the model has to fit in memory to run at a usable speed.
## Download your first model, inside the app
This is where LM Studio's graphical nature pays off. Open the Discover tab and search for a model by name, by a Hugging Face user or model string, or by pasting a full Hugging Face URL, and download it without leaving the app. LM Studio runs `llama.cpp` (GGUF) models everywhere and Apple's MLX models on Apple Silicon, so most open models you have heard of will run. When a model offers several quantization levels, the docs advise picking 4-bit or higher if your machine can handle it, because heavier quantization trades quality for a smaller memory footprint. A good coding model to start with, sized to your RAM, is the same decision [our Ollama guide](/primer/how-to-use-ollama/) lays out for the CLI side.
## Chat with a model, and with your documents
Once a model is downloaded, you chat with it in the app, no server or config required. LM Studio also does chat-with-documents: attach a `.docx`, `.pdf`, or `.txt` file to the conversation and it adds the document to the model's context if it fits, or uses retrieval to pull the relevant parts if it does not. For quick "read this and answer" work on a local file, that is the whole feature, and it never leaves your machine.
## Turn on the local server: the OpenAI-compatible API
The app is useful on its own, and it becomes a coding tool when you serve the model. From the Developer tab, start the server (or run `lms server start` in a terminal), and LM Studio exposes an OpenAI-compatible API at `http://localhost:1234/v1`. The endpoints are the ones your tools expect: `GET /v1/models`, `POST /v1/chat/completions`, plus `/v1/embeddings`, `/v1/completions`, and `/v1/responses`. Port `1234` is the default. Authentication is off by default, so any placeholder API key works, and there is a toggle in Server Settings if you want to require one.
## Point your editor and agents at it
This is the payoff, and LM Studio handles two kinds of tool cleanly. Anything that speaks the OpenAI API, VS Code extensions, Codex, or [Aider](/primer/how-to-use-aider/), just needs its base URL set to `http://localhost:1234/v1` and a placeholder key, and it is running against your local model.
The part worth calling out is Claude Code, because it is where LM Studio pulls ahead of a CLI-only tool. LM Studio also serves an Anthropic-compatible `/v1/messages` endpoint, added in version 0.4.1, so Claude Code connects directly with no translation layer. You set `ANTHROPIC_BASE_URL=http://localhost:1234` and `ANTHROPIC_AUTH_TOKEN=lmstudio`, then run `claude` pointed at your local model. That is the exact gap our [Ollama guide](/primer/how-to-use-ollama/) flagged, where Claude Code needs a proxy to reach an Ollama model; LM Studio closes it by speaking Anthropic's protocol as well as OpenAI's, which is a genuine reason to reach for it if Claude Code is your agent.
## Drive it from the terminal: the lms CLI
You do not have to stay in the window. The `lms` CLI ships with the app, so the terminal-inclined get the same control: `lms server start` and `lms server stop` run the server, `lms ls` lists your downloaded models, `lms ps` shows what is loaded, `lms load` and `lms unload` manage memory, and `lms get` downloads a model by name. It is the bridge between LM Studio's graphical comfort and a scriptable workflow, and it is why the "GUI versus CLI" choice below is softer than it first looks.
## Build on it: the SDKs, structured output, and tools
For building rather than chatting, LM Studio ships official SDKs: `pip install lmstudio` for Python and `npm install @lmstudio/sdk` for JavaScript. Through the same server you also get the two features that make a local model useful in an app: structured output, where you pass a JSON schema and the model returns valid JSON that conforms to it, and tool use, where the model can request calls to your functions, both through the standard `/v1/chat/completions` and `/v1/responses` endpoints. So a local model can drive real application logic, not just a chat box, for zero per-token cost.
## What it costs: free, even at work
LM Studio is free. Running local models in the app costs nothing, and as of 8 July 2025 the company made it free for commercial use too: in its own words, "LM Studio is free to use both at home and at work," with no license form to fill in. Two boundaries keep that accurate. There is a separate paid Enterprise plan for organizations that need single sign-on, model and MCP gating, or private collaboration, and an optional cloud-credits tier if you want to run frontier open models in the cloud rather than on your machine. For a solo builder or a small team running models locally, though, the cost is your hardware and nothing else, which is the same economics [our cost study](/study/cut-your-ai-coding-bill/) keeps landing on.
## LM Studio or Ollama
Both run local models for free; the difference is the front door. LM Studio is graphical-first: you browse and download models from Hugging Face in a window, chat in the app, and start a server from a toggle, with the `lms` CLI available when you want it. Ollama is command-line-first: you `ollama run` a model and connect editors and frameworks through its API, as [our Ollama guide](/primer/how-to-use-ollama/) covers. Pick LM Studio if you want model discovery and chat in a GUI, or if Claude Code is your agent and the direct Anthropic-compatible connection matters; pick Ollama if you prefer a terminal and a lightweight service to script against.
 Either way you are running a capable coding model on your own machine at no per-token cost, which is the outcome that makes both worth knowing, and the [agent field guide](/study/ai-coding-agent-field-guide/) places where local fits the wider 2026 field. Download it, pull one model sized to your RAM, and you will know within an afternoon whether the window or the command line is your home.
---
# How to use Aider: AI pair programming in your terminal
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-aider/
Aider is an open-source AI pair programmer that lives in your terminal, commits every change to git so you can always undo it, and points at almost any model, including a free local one. Here is the whole thing: install, run it in a repo, the commands you will use, and how to wire it to Claude, to OpenRouter, or to Ollama running on your own machine for zero per-token cost.
Aider is the tool for people who want an AI coding agent that lives in the terminal, not in an editor, and who want to own the model it runs on. It describes itself in four words, "AI pair programming in your terminal", and the two things that make it distinctive both follow from that: it commits every change it makes to git, so nothing it does is ever unrecoverable, and it connects to almost any model, including a free one running on your own machine. For a vibe coder who watches the meter and keeps their hands near git, that combination is the pitch.
Here is the whole answer up front. Install Aider with two commands, run `aider` inside a git repository, and it pair-programs with you, committing each edit as it goes so `/undo` can always walk it back. Point it at Claude or GPT if you want the strongest model, at OpenRouter if you want a free tier, or at Ollama if you want zero per-token cost on your own hardware. Everything below is the how, section by section.
## Install it
From Aider's own install docs, read 15 August 2026. The quick start is two commands:
```
python -m pip install aider-install
aider-install
```
`aider-install` also installs a separate Python 3.12 to run Aider with, so it does not disturb your project's Python. If you prefer, there are three other supported paths: `uv tool install --force --python python3.12 --with pip aider-chat@latest`, a direct `python -m pip install -U --upgrade-strategy only-if-needed aider-chat` on Python 3.9 to 3.12, or `pipx`. Any of the four gets you the `aider` command.
## Run it in your git repo
This is the habit that defines Aider. Start it inside a git repository, and Aider will git commit all of its changes, each with a sensible message, so you can diff, track, and undo them with the git tools you already use. That is not a safety feature bolted on; it is how the tool works. When the model does something you did not want, you type `/undo`, which the docs define exactly as "undo the last git commit if it was done by aider," and you are back where you were.
If you are new to it, run `aider` in a small repo, ask it to make one change, and watch it commit. Seeing the commit appear is the moment Aider clicks, because it means every step is a checkpoint you can return to.
## The commands you will actually use
Aider is driven by in-chat slash commands. From the command reference, the ones that carry most of the work:
- `/add` puts files into the chat so Aider can edit them; `/drop` removes them again.
- `/ask` asks a question about the code without editing it.
- `/code` requests a change; `/architect` runs the two-model workflow below.
- `/run` runs a shell command and can feed the output back into the chat.
- `/diff` shows what changed since your last message; `/undo` reverts the last Aider commit.
- `/model` switches which model you are talking to mid-session; `/commit` commits edits you made outside the chat.
You will spend most of your time in `/add` then plain requests, with `/undo` as your safety net and `/run` to let Aider see your test output.
## Point it at any model
Aider is model-agnostic, and this is where it separates from a tool locked to one lab. Its own docs list the models it works best with, Claude, GPT (o3, o4-mini, GPT-4.1), Gemini 2.5, and DeepSeek, and note that it can connect to almost any LLM besides. You supply a key on the command line with `--api-key anthropic=` or through an environment variable or `.env` file, and you are running.
Two paths matter for cost. **OpenRouter** aggregates many providers behind one key and offers free access to a number of models with daily-usage limits, which the docs call out directly, so it is a common way to try Aider without paying. And a hosted model is only one option, because the next section is the free one.
## Run a local or free model
This is the most-searched thing about Aider, and the answer is clean. To run a local model through **Ollama**: set `OLLAMA_API_BASE` (it defaults to `http://127.0.0.1:11434`), pull your model and start the Ollama server, then run `aider --model ollama_chat/`. That is a coding agent running against a model on your own laptop, with no per-token bill, the same zero-cost setup [our Ollama guide](/primer/how-to-use-ollama/) walks through from the model side.
More broadly, Aider connects to **any OpenAI-compatible endpoint**: `export OPENAI_API_BASE=` and `export OPENAI_API_KEY=`, then `aider --model openai/`. That covers [LM Studio](/primer/how-to-use-lm-studio/), a self-hosted server, or any provider that speaks the OpenAI API. The trade with a local model is the familiar one, capability for cost and privacy, which [our cost study](/study/cut-your-ai-coding-bill/) frames in full; a strong 14B or 32B coding model is enough for a great deal of real work.
## Architect mode: two models, one job
Aider has a distinctive mode worth knowing. In architect mode, an architect model proposes the changes and a separate editor model translates that proposal into specific file edits. The idea is to let a strong reasoning model plan while a fast, edit-reliable model does the mechanical writing. You enter it with `/architect`, or start Aider with `--architect` or `--chat-mode architect`. It is the one feature here that a single-model IDE agent cannot easily copy, and it pairs naturally with the model-mixing the [agent field guide](/study/ai-coding-agent-field-guide/) maps across the bring-your-own-model camp.
## Configure it, and use it beside your editor
Two practical notes for daily use. Configuration lives in an `.aider.conf.yml` file in your home directory or your repo root, with `AIDER_*` environment variables and a `.env` file as alternatives, so you can set your default model and keys once and forget them.
And although Aider is a terminal tool, it works well beside a graphical editor through watch mode. Run `aider --watch-files` and it watches your repo for one-line "AI comments": a comment ending in `AI!` tells Aider to make a change right there, and `AI?` asks it a question. So you stay in VS Code, drop an `# fix this off-by-one AI!` comment, and Aider acts on it, which is the closest thing to an inline experience without leaving the terminal running alongside. If you would rather the agent lived inside the editor, [Cline](/primer/how-to-use-cline/) is the editor-native counterpart with the same bring-your-own-model, run-it-local approach.
## Is it free, and how good is it
Aider itself is free and open source under the Apache-2.0 license. The cost is the model: you pay the underlying API's token bill unless you point Aider at a free tier like OpenRouter's or a local model through Ollama, in which case running it costs nothing but your hardware. That is the whole economic story, and it is why Aider shows up so often in "how to code with AI for free" answers.
On capability, Aider publishes its own polyglot leaderboard, which tests models on 225 challenging Exercism exercises across C++, Go, Java, JavaScript, Python, and Rust. When we read it on 15 August 2026 the top entry was gpt-5 at high effort with 88.0% correct, and the useful thing is not that single number, which will move as models ship, but that the tool gives you a dated, reproducible way to pick the model you run it on. Start with `aider` in a small repo on whichever model you can afford, lean on `/undo`, and you will know within a session whether the terminal-and-git rhythm is yours.
---
# How to use Ollama: run AI models on your own machine
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-ollama/
Ollama runs open models on your own computer, for free, with one install command and one run command. For a vibe coder the appeal is blunt: inference that costs nothing, never leaves your laptop, and has no rate limit but your hardware. Here is the whole thing, install to editor, plus the plain catch about your RAM and the reason Claude Code will not point at it without help.
Ollama is the shortest path from "I want to run an AI model on my own machine" to a model actually running. It is one install command and one run command, it is free and open source under the MIT license, and once it is up it quietly serves an API on your laptop that your editor and your agents can talk to. For a vibe coder watching the meter, that is the appeal in one line: local inference costs nothing per token and has no rate limit except your hardware.
Here is the whole answer up front. Install Ollama, run `ollama run qwen2.5-coder`, and you have a coding model answering on `localhost:11434`. Point an OpenAI-compatible editor or agent at that address and you are coding against a model that never leaves your machine. The two catches, both covered below: your RAM sets the ceiling on how good a model you can run, and Claude Code will not connect to it without a translation layer.
## Install it: one command
Verified from Ollama's own README on 12 August 2026. Pick your OS:
- **macOS and Linux:** `curl -fsSL https://ollama.com/install.sh | sh`
- **Windows:** `irm https://ollama.com/install.ps1 | iex`, or download the installer from [ollama.com/download](https://ollama.com/download)
That installs the `ollama` command and a background service. There is nothing else to configure to get started; the service is what serves the local API you will use later.
## The commands you actually need
Ollama's CLI is small enough to learn in a minute. These are the ones you will use daily:
- `ollama run ` downloads the model if needed and starts a chat with it. `ollama run qwen2.5-coder` is a fine first command.
- `ollama pull ` downloads a model without running it, for later.
- `ollama list` shows what you have downloaded, and their sizes on disk.
- `ollama ps` shows what is currently loaded in memory.
- `ollama rm ` deletes a model you are done with, because they are large.
Everything else is a variation on those. The model names come from [ollama.com/library](https://ollama.com/library), and a name can carry a size tag, so `qwen2.5-coder:14b` pulls the 14-billion-parameter version specifically.
## Which coding model, by your RAM
This is the question the search results are full of, and the answer is that your memory decides it. A model has to fit in RAM (or GPU VRAM) to run at a usable speed, and a rough rule is that a quantized model needs a bit more than its parameter count in gigabytes. So:
- **8 GB of RAM or VRAM:** run a 7B-class model, such as `qwen2.5-coder:7b`. Capable for autocomplete and small edits.
- **16 GB:** a 14B model like `qwen2.5-coder:14b` fits and is a real step up for reasoning about code.
- **32 GB or more:** you can run a 32B-class model, though it will be slower; this is where local starts to feel genuinely useful.
The code-tuned models worth knowing, all in the library, are Qwen2.5-Coder and Qwen3-Coder, DeepSeek-Coder-V2, CodeLlama, CodeGemma, and StarCoder2. The one thing no local model will do is match a frontier hosted model on the hardest tasks, which is the trade you are making: you swap some capability for zero cost and full privacy. Whether that trade is worth it for your work is exactly the calculation [our cost study](/study/cut-your-ai-coding-bill/) frames.
## Wire it into your editor and agents
A running model is only useful once your tools can reach it, and this is where Ollama earns its place. The background service exposes two APIs on `localhost:11434`: its native one at `/api/chat` and `/api/generate`, and an OpenAI-compatible one at `/v1` (for example `/v1/chat/completions`), where the API key can be any placeholder like `ollama`.
That OpenAI-compatible endpoint is the important part, because most agents already speak the OpenAI API. Point one at `http://localhost:11434/v1` and it just works: **[OpenCode](/primer/how-to-use-opencode/), [Aider](/primer/how-to-use-aider/), [Cline](/primer/how-to-use-cline/), and Zed** all connect to a local Ollama model directly this way, which the [agent field guide](/study/ai-coding-agent-field-guide/) covers as the model-agnostic camp. That is the whole setup: pick the agent, set its base URL to your local address, name your model, and you are running an agent against a model on your own laptop.
The exception is the one people search for most: **Claude Code will not point at Ollama by itself.** Claude Code speaks Anthropic's API, not the OpenAI one, so connecting it to a local model needs a translation proxy in between (a router or a tool like LiteLLM that presents an Anthropic-shaped endpoint and forwards to Ollama). It is possible, it is not native, and if your goal is simply "an agent using a local model," reaching for OpenCode or Aider is the shorter road than bending Claude Code to it.
## When local is not enough: Ollama Cloud
Some models are too large for any laptop, and Ollama's answer is Ollama Cloud, which runs big models on their hardware while you keep the same commands. You `ollama signin`, then pull a cloud model by its `-cloud` suffix, such as `ollama pull gpt-oss:120b-cloud`, and run it through the exact same CLI, Python, JavaScript, or API you already use. There is a free tier with usage limits, and the appeal is that a 120-billion-parameter model runs from the same `ollama run` muscle memory as a 7B one on your machine. It is the escape hatch for the days your hardware is the bottleneck, without leaving the tool.
## Ollama versus the alternatives
Two comparisons come up constantly, and both have short answers. [**LM Studio**](/primer/how-to-use-lm-studio/) does much of what Ollama does with a graphical interface instead of a command line, so it suits people who would rather click than type; Ollama suits people who want a command and an API to script against. **llama.cpp** is the lower-level engine that does the actual model running, and Ollama is a friendlier layer on top of that lineage, trading some fine control for a much simpler setup. None of these is wrong; they sit at different points on the same convenience-versus-control line, and the [vibe coding stack](/primer/vibe-coding-stack/) places where each fits.
## Is it free, and the real limit
Yes. Ollama is MIT-licensed and running models locally is free, unlimited, and fine for commercial use; there is no per-token bill because there is no vendor counting tokens. The cost you actually pay is threefold and worth naming: the hardware to run a decent model, the electricity while it runs, and the capability gap against a frontier hosted model on hard problems. For the large, cost-conscious slice of coding that is autocomplete, refactors, and boilerplate, a local model on Ollama is genuinely enough and genuinely free, which is why it belongs in the toolkit even if a hosted model still does your hardest thinking. Start with `ollama run qwen2.5-coder`, wire it into the agent you already use, and you will know within an afternoon whether your machine is fast enough to make it a habit.
---
# How to make your product citable: an AEO walkthrough
Section: The Primer
URL: https://okaneland.com/primer/make-your-product-citable-aeo-walkthrough/
The get-cited-by-ChatGPT genre is thick with unverifiable stats. We can only publish the walkthrough we can show our work for: our own agent-facing plumbing, tied to the files on disk, our Bing citation report going from zero to six, a fifteen-day server-log test of whether answer engines even read an llms.txt, and the tactics our own research made us drop. Every step carries either a before-and-after or a named source.
The search results for "how to get cited by ChatGPT" are full of confident numbers with no receipt behind them. We cannot out-confident them, and we would not want to; the one thing this site can do that the playbooks mostly do not is show its work. We instrumented our own AI citability end to end, kept the logs, and read the one dashboard that measures it. So this is not a list of tactics that worked for someone. It is a walkthrough where every step is tied to a file on disk or a named source, including the steps that did nothing.
Here is the whole answer up front, and it is deliberately small. A small site can be cited: ours logged its first citations, going from zero to six, after we fixed indexation rather than after we added markup. The plumbing everyone recommends is cheap hygiene, and on our evidence it is not the lever. And the one file the AEO genre sells hardest, `llms.txt`, was requested by answer-engine crawlers exactly zero times in fifteen days of our logs. The receipts follow.
## The dashboard that makes this measurable
You cannot manage what you cannot see, and until recently AI citations were invisible. Microsoft's AI Performance report in Bing Webmaster Tools, launched in Public Preview on 10 February 2026, changed that: it reports how often your pages are cited across Microsoft Copilot, AI-generated summaries in Bing, and select partner integrations Microsoft does not name. Its metrics are Total Citations, Average Cited Pages, and Grounding queries, which Microsoft states plainly is a sample, not a full count. Two caveats travel with every number from it: it covers Microsoft surfaces, not ChatGPT or Claude, and it is a preview dashboard whose numbers Microsoft can restate.
## Where we started, and what actually moved
Our own diagnosis, months ago, was that at zero citations the gap was not markup, it was indexation: five indexed pages against a same-owner sister site's forty-seven, and on that sister site two pages accounted for 89% of its 241 citations. Citations are hit-driven, which means the prerequisite is being a specific, indexed page an engine can quote, not a clever tag.
So we fixed indexation first, and then read the report. The citation log has exactly one entry, and we quote it rather than dress it up:
> 2026-07-24 · indexed: 36 · citations(3mo): 6 · Cited pages both Study explainers: /study/ai-productivity-roi-at-work/ (4), /study/is-vibe-coding-worth-it/ (2). Grounding-queries breakdown still No data available. Impressions 132 over 3mo.
One reading, small numbers, and the causality is genuinely tangled: index recovery, URL submissions, and new Study publishes all overlapped, so we will not tell you a single action produced the six. What we will tell you is the shape. The cited pages are two Study explainers, dense with dated specifics and named sources. They are not the plumbing pages, and they are not the price-index data page, which has zero citations. That is the single most useful thing in this piece: what got cited was the specific, sourced content, exactly as the research in [our citation-value study](/study/what-a-chatgpt-citation-is-worth/) predicts, and not the markup layer.
## The plumbing, receipt by receipt
We shipped the whole agent-facing kit, and you can read each file: `/llms.txt` and `/llms-full.txt` generated from the live content; per-article clean markdown served to agents that send `Accept: text/markdown`, via nginx content negotiation, for the five original sections (The Signal, added later, is not wired into it, so that is a real gap in our own setup, not a boast); and a `robots.txt` that names about twenty crawlers with `Allow: /` and carries no content `Disallow` rules, its single `Disallow` being Cloudflare's own edge path. Ship this because it is cheap and harmless and makes your content legible to agents that do fetch markdown. Do not ship it believing it is what gets you cited, because our own citations landed on HTML Study pages, not on any of it.
## The llms.txt adjudication
This is the section the genre will not write, so we ran the test. Google's John Mueller said, in a dated April 2025 comment, that no AI service is known to use `llms.txt` and that server logs show bots do not even request the file. We have the server logs, so we checked ours over fifteen days.
The result nuances Mueller in one direction and confirms him in the load-bearing one. It nuances him because some crawlers do request the file: over the window, about 54 fetches of the two llms files happened, and training-and-index crawlers accounted for a handful (GPTBot 2 of its 702 requests, Googlebot 5). It confirms him where it counts: the answer-engine bots requested it zero times. Bingbot made 1,006 requests to the site and fetched llms zero times; ChatGPT-User 477 and zero; PerplexityBot 283 and zero. The rest of the 54 were SEO tools and browsers. Because `/llms.txt` serves uncached from origin, those zeros are real and not a caching artifact. Read this as adjudication, not advice: publish the file if you like, but on our logs the engines that answer questions are not reading it, so nobody should sell it to you as a citation tactic.
## The tactics we researched and dropped
Part of a candid walkthrough is the recommendations we chased and rejected, with the reason. Before shipping we researched and dropped a stack of SEO-flavored AEO advice: FAQPage schema, ItemList and CollectionPage markup, SoftwareApplication structured data, rewriting H2s into question shapes, treating HSTS as a ranking signal, and swapping Article subtypes. Each was dropped because the primaries did not support it, and [our AEO study](/study/aeo-and-geo-what-the-research-says/) already published the llms.txt and schema busts in full, with the sources that killed them, so we cross-link rather than re-argue them here. The standard is the differentiator: we did not drop them because a competitor's playbook is bad, we dropped them because the evidence for each was missing.
## The checklist, in order
What to copy, ordered by what our own evidence supports, strongest first:
1. **Be indexed.** Submit your sitemap, use IndexNow or URL submission, and confirm your page count is recovering in Webmaster Tools. This is the prerequisite our diagnosis kept landing on; nothing downstream matters if the engine cannot find the page.
2. **Be the specific, dated, sourced page.** Both pages that got cited are exactly that. Write the thing an engine can quote a precise claim from, with a date and a named source, the recipe [our citation-value study](/study/what-a-chatgpt-citation-is-worth/) draws from the research.
3. **Instrument before you optimize.** Read the Bing AI Performance report so you are measuring citations, not guessing at them.
4. **Ship the plumbing as hygiene, not as the lever.** llms.txt, markdown variants, a permissive robots.txt: cheap, harmless, legible to agents, and not what our citations came from.
That is the walkthrough, and its whole value is that it is small and checkable. Six citations on thirty-six pages, from one reading of a preview dashboard, is not a victory lap; it is a receipt, and it says the boring thing works and the sold thing does not. Re-read your own report before you trust any of it, because a public-preview number is exactly the kind of figure that gets restated, and the only citation data worth acting on is the one in your own account.
---
# Hooks, skills, subagents, plugins, CLAUDE.md: what each is for
Section: The Primer
URL: https://okaneland.com/primer/claude-code-mechanisms-measured/
Five ways to extend Claude Code, and the confusion is real: hooks or skills, skills or subagents, CLAUDE.md or a skill. They differ on one axis that decides everything else, when each one enters the context window. Anthropic just published that axis and rebuilt around it. Here is the tested taxonomy, with the token cost of each measured on a clean session.
The queries tell you where the confusion lives: hooks versus skills, skills versus subagents, CLAUDE.md versus a skill. People reach for one mechanism, get the behavior of another, and cannot tell why. The disambiguation is simpler than the five names suggest, because they all sort on a single axis, and it is the axis that decides your token bill: when each one enters the context window. Always, on demand, or never.
Here is the whole answer up front. CLAUDE.md is always-on: it loads in full at the start of every session and you pay for it every request. Skills and subagents are on-demand: their listings or descriptions cost a trickle, and their real weight loads only when invoked. Hooks are off-context entirely: they run as events and add nothing to the window. Plugins are just packaging. We measured each on a clean session, and the numbers make the axis concrete.
## The short version, measured
We ran a trivial one-turn session in an isolated directory and summed the prompt tokens, then added each mechanism one at a time. Claude Code 2.1.204, three runs each, baseline around 25,331 tokens.
| Mechanism | When it loads | Fixture size | Measured startup cost |
|---|---|---|---|
| CLAUDE.md | Every session, in full | 8,497 chars | **~2,505 tokens** |
| Skill | Name + description always; body on invoke | 38,920-char body | ~33 tokens |
| Subagent | Description always; prompt on spawn | 30,518-char prompt | ~34 tokens |
| Hook | Never (runs on an event) | n/a | 0 tokens |
| MCP server | Deferred in 2.1.204 | n/a | ~0 tokens |
The table is the whole primer. A 39,000-character skill body cost 33 tokens at startup because only its listing loads; an 8,500-character CLAUDE.md cost 2,505 because it loads whole. Put your always-needed rules in the cheap-looking file and you have quietly bought a tax on every turn; put a rarely-needed procedure in CLAUDE.md and you pay for it constantly. The mechanism is the meter.
## The always-on tier: CLAUDE.md and memory
CLAUDE.md loads its full content into context at the start of every session, as the docs state and our measurement confirms, which is why the docs also target keeping it under 200 lines: everything in it is billed on every request for the life of the session. Its `@path` imports resolve up to four hops and also load at launch, so an import tree is an easy way to balloon the always-on cost without noticing. Auto-memory's `MEMORY.md` behaves the same way, loading up to 200 lines or 25 KB at session start. The rule that falls out of the numbers: CLAUDE.md is for the handful of instructions that must be true every single turn, and nothing else. If it is only sometimes relevant, it belongs one tier down.
## The on-demand tier: skills and subagents
Skills are cheap, not free. The always-loaded part is the listing, a skill's description plus its when-to-use text, truncated at 1,536 characters by default (configurable via `skillListingMaxDescChars`). That listing is what cost 33 tokens in our test. The body, however large, loads only when the skill is invoked, and then it stays in context for the rest of the session. If you disable model invocation, the cost drops to zero until you type the command yourself. So a skill is the right home for a long procedure you need occasionally: you pay a sentence to advertise it and the full text only on the turns that use it.
Subagents go further: they run in their own context window. A spawned subagent receives its own prompt, the delegation message, and CLAUDE.md plus git status, does its work in isolation, and returns a result, so a 30,000-character agent prompt cost the parent 34 tokens at rest. The default concurrent limit is 20, and changing it via `CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS` needs Claude Code 2.1.217 or later. Reach for a subagent when a task would otherwise flood your main context with intermediate work you do not want to keep.
## The off-context tier: hooks
Hooks add nothing to the window, which our zero-token measurement confirms. They are shell commands, HTTP endpoints, or prompts that fire automatically at fixed points in the lifecycle, and their output is capped at 10,000 characters before Claude Code diverts it. The distinction from a skill is guarantee versus interpretation: a hook runs deterministically on its event whether or not the model decides it is relevant, while a skill is something the model chooses to invoke. If you need a thing to happen every time, without relying on the model to elect it, that is a hook.
## Plugins: the packaging tier
Plugins have no load behavior of their own. A plugin is a bundle that packages skills, subagents, hooks, and MCP servers under one manifest so they can be shared and installed together, via `/plugin install`. Whatever a plugin costs is the sum of what it contains, priced by the tiers above. Treat "should I install this plugin" as "what does it bundle, and what tier is each piece," not as a question with its own answer.
## The 80% reset, and why it moves your files
There is a reason this taxonomy suddenly matters more, and it is a change Anthropic made to itself. In November 2025 the company published that it "removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations." Two qualifiers keep it accurate: the "no measurable loss" is Anthropic's claim about its own internal evals, not our finding, and the cut applies by model, changelog v2.1.154 makes the lean prompt the default for all models except Haiku, Sonnet, and Opus 4.7 and earlier, which still receive the full prompt. Alongside the cut came the progressive-disclosure moves this piece describes: deferring tool definitions, pushing verification into skills, auto-memory. The direction is consistent: keep the always-on window small, and let everything else load on demand.
## Does always-on context even earn its tokens?
The evidence cuts both ways, and it is worth holding both. A February 2026 arXiv paper (revised in June) measured always-on AGENTS.md-style context files and found no general gain for about 20% added cost, an argument for keeping the permanent window lean. But a Vercel eval reported a 100% pass rate for an 8 KB AGENTS.md docs index against 79% and 56% ceilings for skills-based approaches on its task, an argument that a well-built always-on index can beat on-demand loading when the task leans on it constantly. The resolution is not a winner; it is the axis again. Always-on context earns its tokens when the model needs it every turn, and wastes them when it does not, which is exactly the judgment the measured table is meant to help you make.
## Decision rules
The taxonomy collapses to a few triggers. If the model gets something wrong twice, the fix is a line in CLAUDE.md, the always-on tier. If you have a long procedure you paste occasionally, that is a skill. If a task floods your context with work you will not keep, that is a subagent. If something must happen deterministically on an event, that is a hook. And if you want to share a set of these, that is a plugin. Underneath all of it is the token discipline our [cost study](/study/cut-your-ai-coding-bill/) and [the MCP tax measurement](/study/the-mcp-context-tax/) keep landing on, and that [our Claude Code guide](/primer/how-to-use-claude-code/) puts to work: the cheapest context is the context you did not load until you needed it. Every number here is pinned to Claude Code 2.1.204 and the docs as of 2026-08-09; re-run the one-turn test on your version, because loading behavior is precisely what changes between releases.
---
# Ship an MCP server for your product
Section: The Primer
URL: https://okaneland.com/primer/ship-an-mcp-server-for-your-product/
Most "how to build an MCP server" guides stop at hello-world and skip the part builders actually ask next: does anyone find it? We shipped one for this site, eleven days before the spec went final, so this walkthrough comes with real distribution receipts, including the submission that is still stuck. Here is the minimal build under the current spec, and the real reach.
The hard part of shipping an MCP server is not the server. A minimal one is an afternoon. The hard part is the question every guide skips: once it exists, does anyone find it? We can answer that with receipts because we shipped one for this site, `@okaneland/mcp`, eleven days before the 2026-07-28 spec went final, and we kept the distribution log, including the parts that did not go our way.
Here is the whole answer up front. Building a compliant server today is a short, well-documented job under the current SDKs. Distribution is a long tail of directory submissions, most of which you cannot verify moved anything, and at least one of ours is still stuck. This piece is both halves: the minimal build under the 2026-07-28 revision, and the real reach of the thing once it was live.
## What changed on July 28, and what a server must do
The current spec revision, 2026-07-28, made the protocol stateless: it removed the `initialize` handshake, and a client and server now carry version and capabilities in request metadata rather than a negotiation round-trip. For a tools-only server, the requirements are short and worth quoting: declare the `tools` capability, respond to `tools/list`, and handle `tools/call`. Resources and Prompts are optional; most product servers are just tools.
The SDKs shipped alongside it. Both `@modelcontextprotocol/server` and `@modelcontextprotocol/client` are at 2.0.0 on npm as of late July, and the TypeScript SDK split into separate server and client packages. On Python, `pip install "mcp[cli]"` now pulls the 2.x line; pin below 2 if you need to stay on v1 for an existing server.
## The minimal server, verbatim
A tools-only TypeScript server under v2 is a handful of calls: construct an `McpServer`, `registerTool` with a name, an input schema, and a handler, and connect it over a `StdioServerTransport`. That is the entire skeleton; everything else is your tool's logic. The Python path mirrors it through the `mcp` package's server helpers. The point of naming the exact API surface is that it is small: if a walkthrough has you writing more than this to answer `tools/list` and `tools/call`, it is doing too much.
What we actually shipped is a two-tool server built on the v1-era SDK (`^1.12.0`), published eleven days before the revision, so it predates the stateless changes. It still runs, because the spec keeps a compatibility path for older servers, and it is a fair illustration of the gap every maintainer now has: a working server from six weeks ago is already a spec revision behind. If you are building today, build on v2; if you shipped on v1, you are not broken, but you are on the legacy side of the matrix.
## Getting listed: the six-channel log
This is the half nobody publishes, so here is ours, live-checked on 2026-08-12. "Listed" is not one thing, so each row says what state it is actually in.
- **Official MCP registry:** active. Listing published 2026-07-18 via the publisher tool, which is why 0.1.1 exists: the republish added the `mcpName` field that proves registry ownership, along with a repository field the first version lacked.
- **Smithery:** listed.
- **Glama:** present but unclaimed, with its automated quality score not yet run, so "listed" here means indexed, not verified.
- **awesome-mcp-servers (PR #10337):** still open, not merged. Earlier it repeatedly re-conflicted against a fast-moving base; today it is mergeable-clean but held on a reviewer request to claim the Glama page and earn a score badge first, which the still-unclaimed Glama listing has not satisfied. Our own internal note recorded 228 new upstream commits during one roughly fifteen-minute window while we watched, a single observation of how fast that list churns, not a measured rate.
- **mcp.so and PulseMCP:** unresolved. Both use client-rendered search we could not confirm a listing through from the outside, so we log them as submitted-and-unverified rather than live.
That is three live, one open, two unresolved, and the blunt headline is that shipping to a registry is easy and confirming you actually landed is not.
## What distribution we actually got
`@okaneland/mcp` recorded 470 downloads in the last-month window, and the shape matters more than the total. About 273 of the roughly 480 lifetime downloads landed in the first 48 hours after publish, split across the two release days. After that the daily curve runs low and lumpy, several zero-download days and the odd spike into the twenties, not a steady stream. npm does not separate mirror and bot traffic from human installs, so we will not claim those 273 were or were not real users; what we can say is that a publish-day spike over a quiet baseline is the normal shape, and reading the raw month total as "470 users" would be the mistake this section exists to prevent.
We have no referral or citation data tying any of it to a directory, because no analytics link was in place, so we credit no channel with moving anything. That absence is itself the lesson: you can do the whole distribution ritual and still not know which listing, if any, sent you a single install.
## When a server is a product, and when it is a channel
The strategic read sits underneath the mechanics. A few builders sell MCP access as the product, the way the [€9-and-€19 gated server in our Studio interview](/studio/gabriel-amzallag) does, and the [economics of what agent tools charge for](/study/what-agent-economies-charge-for) is its own study. For most of us, though, a server for our product is a distribution channel: a way for an agent to reach our thing, valuable in proportion to how many agents actually do. On our numbers, that value is real but small, and pretending otherwise would break the only thing a receipt is good for.
## Should you ship one
Ship one if an agent doing your product's job is genuinely useful, and treat the build as the cheap part it is. Do not ship one expecting the registries to deliver an audience; on our measured experience they deliver a listing, and the listing is not traffic. Keep the server small for the reason [the MCP tax study](/study/the-mcp-context-tax/) measures: every tool you expose is context weight an agent pays to use it. And log your own distribution plainly, because the field is young enough that a real download curve and a stuck PR are more useful to the next builder than another hello-world. The method here is pinned to the 2026-07-28 spec and the SDK versions above; re-check both before you build, because in this corner of the stack six weeks is a revision.
---
# How to build an app with AI from scratch
Section: The Primer
URL: https://okaneland.com/primer/build-an-app-with-ai-from-scratch/
AI gets a non-coder from idea to a working demo quickly. Then the same person hits the same walls, in the same order: scope, tool choice, the 70% problem, the free-tier cliffs, security, and getting paid. This is the map of that whole path, with the real numbers at each wall and the deeper guide that gets you over it.
AI will get you from an idea to a working demo faster than you expect, often the same day. Then you hit a wall, and then another, and the walls are the same ones in the same order for almost everyone who starts from zero. This primer is a map of that whole path. It is not a build log; we did not build an app for this piece and there is no repo or bill to show you. It is the documented route most non-coders actually walk, assembled from primary pricing and limits pages we read on 9 August 2026, named practitioners on the record, and a documented security incident, with a pointer to the deeper Okane Land guide at each wall so you can go as far into any one of them as you need.
Here is the shape up front. Six walls: scope your idea, pick your tool, get through the 70% problem, ship it past the free-tier cliffs, secure it, and find the first users. The building is the easy part now. The walls are everything after the demo, and knowing they are coming is most of the battle.
## Step 1: idea and scope, before you touch a tool
The cheapest decision you will make is what to build, and it is the one people skip. AI is happy to generate whatever you describe, which means a vague idea produces a vague app, quickly and convincingly enough that you do not notice until you are deep in it.
Spend the first hour with no tool open. Write down the one thing the app must do, for one specific person, and the smallest version of that which would be useful. Not the feature list, the single core loop. This is unglamorous and it is where the "does this person know what to build" bottleneck lives, the one that no amount of model quality fixes. If you are still deciding whether the whole endeavor is worth it, [our worth-it study](/study/is-vibe-coding-worth-it/) is the place to start; if you know what you want, keep going.
## Step 2: pick your tool, and know what it costs
There is one real fork here, and it is about how much control you want.
**App builders** like Lovable and [v0](/primer/how-to-use-v0/) take a prompt and give you a deployed app, fastest from idea to something live, with the least visibility into what was built. **Editor-plus-agent** setups like Cursor or Claude Code give you a real codebase you drive, more control and more to learn. A true beginner testing an idea is often best served by the app-builder speed; someone who intends to keep and grow the thing is usually better in an editor from the start. The full slot-by-slot breakdown, with what each costs a month, is in [the vibe coding stack](/primer/vibe-coding-stack/), and we have hands-on guides for [Cursor](/primer/how-to-use-cursor/), [Claude Code](/primer/how-to-use-claude-code/), [Lovable](/primer/how-to-use-lovable/), and [Bolt.new](/primer/how-to-use-bolt-new/) individually.
The one thing to internalize before you commit: the sticker price is a floor, not a ceiling. Usage-based billing means a heavy session can run past the plan price, which is the entire subject of [our cost study](/study/cut-your-ai-coding-bill/). Pick the tool for the job, and read its meter from day one.
## Step 3: build the app with AI, and the 70% wall
This is where the map earns its keep, because this is where nearly everyone stalls in the same place.
Addy Osmani named it the 70% problem: AI gets a non-engineer roughly seventy percent of the way to a working app fast, and then the last thirty percent, the edge cases, the integration, the security, the thing that breaks only on real input, is where progress grinds. The specific trap is the debug death-spiral. You ask the model to fix a bug, it introduces a new one, you ask it to fix that, and it reintroduces the first. Two steps forward, two steps back, with growing confidence that you are almost there.
The way through is not a better prompt; it is a smaller scope per step. Change one thing at a time, confirm it works before the next, and when the model cannot fix its own bug after two tries, stop and read the code yourself rather than looping a third time; reading the code is also [where the learning happens](/primer/can-you-learn-while-vibe-coding/). That the model feels like it is helping while this happens is its own hazard, and it is exactly the perception gap [our study on whether AI makes you faster](/study/does-ai-coding-make-you-faster/) measures, and the reason [agents still need a human in the loop](/study/do-ai-agents-work-yet/) on anything real.
## Step 4: ship it, and mind the free-tier cliffs
Getting an app running on your machine is not shipping it. Shipping means a host and, usually, a database, and both have free tiers with edges worth knowing before you hit them.
For hosting, **Vercel's Hobby plan is $0** and generous for a personal project, including 100 GB a month of data transfer, with one catch that surprises people: it is licensed for personal, non-commercial use, so the moment you charge for the app you are meant to be on **Pro at $20 a month** per seat, which adds $20 of included usage credit and a terabyte of transfer. All figures verified on Vercel's pricing page on 9 August 2026.
For data, **Supabase's Free plan is $0** with a 500 MB database, 50,000 monthly active users, and 1 GB of file storage, and its own catch is the one that quietly kills weekend projects: **free projects are paused after one week of inactivity**, so an app nobody visited for a week comes back to a stopped database. Pro is $25 a month and removes the pause. Both figures verified 9 August 2026. Neither cliff is a problem if you see it coming; both are a bad afternoon if you do not.
## Step 5: security you cannot skip
This is the wall with the highest stakes and the one AI is least likely to handle for you, because insecure code runs exactly as well as secure code in a demo.
The cautionary tale is CVE-2025-48757, disclosed in May 2025: apps built on a vibe-coding platform leaked data because row-level security was left off, so anyone could read records that should have been private. The researcher lists it at a CVSS base of 8.26, which is to say serious. The mechanism is the point: the model built something that worked, nobody turned on the access control, and the gap was invisible until it was found. AI-built apps ship insecure by default, and the one check that matters most is that an unauthenticated request cannot reach data it should not. The full self-audit, eight checks you run on your own app, is [our security study](/study/is-your-vibe-coded-app-secure/), and it is the one wall on this map you should not walk past.
## Step 6: first users, and getting paid
The last wall is the one that has nothing to do with code, and it stops more projects than any bug. A shipped app with no users is a hobby, and the jump to ten users is its own skill.
Two handoffs close the map. Finding those first people is a specific, learnable move rather than "marketing," and [our first-ten-users guide](/ledger/first-10-users/) lays out the plays that work when you have no audience. And if the app is for someone else, being fast is a trap unless you charge for the value rather than the hours, which is the whole of [our pricing guide](/ledger/pricing-ai-work/). Build fast, then price like it took skill, because it did.
## The map, and the one edge to keep
That is the path: scope, tool, the 70% wall, the deploy cliffs, security, users. None of the six walls is secret, and all six are where first-timers actually stop, which is why the useful thing was never a step-by-step of the easy part. The demo is the easy part now.
One edge to keep. Every price and limit here carries the date we read it, because these pages move, and the tool that repriced last year will reprice again. Re-check the number before you rely on it, treat the free tiers as introductions rather than homes, and remember that the model that got you to the demo is the same model that will confidently walk you off each of these cliffs if you let it. The map does not make the walls disappear. It just means you will see each one coming, which is the difference between a project that ships and one that stalls at 70%.
---
# Can you actually learn while vibe coding?
Section: The Primer
URL: https://okaneland.com/primer/can-you-learn-while-vibe-coding/
By its coiner's own definition, pure vibe coding is the choice not to learn: forget the code exists. So learning starts the moment you break that definition on purpose. Here are the three cheap moves that turn a delegated diff into a mental model, and the reason your own sense that you understood it cannot be trusted.
Andrej Karpathy coined "vibe coding" in [a February 2025 post](https://x.com/karpathy/status/1886192184808149383) as a way of building where you give in to the vibes, let the model write everything, and, in his phrase, "forget that the code even exists." Read that definition closely and the answer to whether you can learn from it is already contained in it. The defining move of pure vibe coding is not reading the code the model wrote. There is no step where anything gets encoded in your head, because the whole point is to not look.
Here is the whole answer up front. Yes, you can learn while building this way, but only by deliberately doing the one thing the definition tells you to skip: look at the code. The learning is not a side effect of vibe coding; it is what you add on top of it. Three cheap moves do almost all of the work, and they cost you minutes: read the diff before you accept it, ask the model to explain what it wrote, and rebuild a small piece from memory. Everything below is why those three, and why the feeling that you already understood it is the thing you cannot trust.
## The definitional trap
Most arguments about whether AI "helps or hurts" learning are stuck because they treat vibe coding as one thing. It is not. There are two activities wearing one name, and they sit on opposite sides of a line that Simon Willison drew cleanly.
Willison's [March 2025 essay](https://simonwillison.net/2025/Mar/19/vibe-coding/) defines vibe coding narrowly: building software with an LLM without reviewing the code it writes. Cross that line, review what it wrote, test it, make sure you could explain it to another person, and you are no longer vibe coding at all. You are doing ordinary software development with an AI assistant. His golden rule is the whole primer in one sentence: he will not commit code to his repository that he could not explain to somebody else.
So the question "can you learn while vibe coding?" is really a question about which side of that line you spend your time on. Pure vibe coding, by definition, has no learning step in it. The moment you add one, you have stopped pure vibe coding and started the thing that builds skill. That is not a criticism of vibe coding. It is a map of where the learning actually happens, so you can choose to be there on purpose.
## Why "it felt like I understood it" cannot be trusted
The obvious objection is that you do read the code, sort of, as it scrolls by, and it makes sense at the time. That feeling is exactly the instrument you should not rely on, and there is a pointed result about why.
METR, an independent research organization, ran a randomized controlled trial with 16 experienced open-source developers across 246 real tasks in repositories they maintain. The headline is well known: with AI tools allowed, they were 19% slower. The part that matters for learning is the perception gap. Before the study these developers expected AI to speed them up by 24%. Afterward, having actually been slowed down, they still believed AI had sped them up by 20%. Their felt sense of their own performance was inverted from the measured reality, and the gap did not close even after the fact.
Carry that into learning. If a skilled developer's sense of "this made me faster" can be flatly wrong, your sense of "I understood that diff" is on the same unreliable footing. Understanding, like speed, needs an external check rather than a feeling. Which is the entire case for the three moves below: each one replaces "I think I got it" with something you can actually observe. This is the same perception-versus-reality gap our [study on whether AI makes you faster](/study/does-ai-coding-make-you-faster/) is built around.
## What the brain-science headlines do and do not say
You may have seen a study going around as proof that AI "rots your brain." It is worth handling carefully, because it is real, it is interesting, and it is not about coding.
The paper is "Your Brain on ChatGPT," a 2025 preprint. Two caveats have to travel with it every time it is cited: it is not peer reviewed, and its 54 participants were writing essays, not code, while researchers measured EEG connectivity and recall. The finding, that the group using an LLM showed weaker neural connectivity and had more trouble quoting work they had just produced, is genuinely suggestive about what happens when you offload a cognitive task wholesale. It is adjacent evidence, not a verdict on programmers, and anyone citing it as "science proves vibe coding makes you dumber" has stretched an essay-writing preprint past what it can hold. What it fairly supports is narrower and still useful: when you fully hand off the thinking, less of it stays with you. That is a reason to keep a hand on the work, not a diagnosis.
## The three moves that turn vibe coding into learning
None of these is preachy and none takes long. They are the cheapest possible conversions of a delegated diff into something you actually know.
1. **Read the diff before you accept it.** Not after, not later. The instant before you approve a change is the one moment you have the most context and the most motivation to understand it. Read what changed and why, and refuse to accept anything you cannot follow. This single habit is the entire difference between Willison's two sides of the line.
2. **Ask the model to explain what it wrote.** You have the best available tutor sitting right there. Ask it why it chose this approach, what the tricky line does, what breaks if you remove it. This is the one place where the AI genuinely accelerates learning rather than replacing it, because it turns an opaque block into a walkable explanation, on demand.
3. **Rebuild a small piece from memory.** The strongest test of understanding is production, not recognition. Close the file and rewrite one function, or one component, from memory. Where you stall is precisely what you did not actually understand, and the stall is the lesson. Recognition feels like knowing; reconstruction proves it.
Doing all three on every change would be exhausting and unnecessary. Doing them on the parts that matter, the auth check, the payment path, the piece you will have to modify next week, is where a vibe-coded project quietly turns into an education. The place to run these moves inside a real workflow is exactly what [our Claude Code guide](/primer/how-to-use-claude-code/) walks through.
## When not to bother
The fair close is that sometimes the right amount to learn is nothing, and pure vibe coding is the correct tool.
Willison, who drew the strict definition, is also enthusiastic about vibe coding for the right job: a low-stakes throwaway, a weekend toy, a one-off script you will run once and delete. For those, forgetting the code exists is a feature, not a risk, because there is nothing to maintain and nothing to secure. Reach for the three moves when the code will live: when it goes to production, handles other people's data, or you will have to change it later. The skill worth having is not "always read everything" or "never read anything." It is knowing which project you are on, and choosing your side of the line deliberately instead of by accident. Learn on the code that matters, and let the throwaway stay a throwaway.
---
# How to use n8n, and when to write the code instead
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-n8n/
n8n bills a workflow run as one execution, no matter how many steps it takes, and that pricing quirk is why the AI client-work trade settled on it. The earnings underneath are modest, recurring, and real, the guru numbers are mostly marketing, and the license has a clause most people selling builds have never read.
n8n is a visual automation tool: boxes for steps, lines for data, 1,200-plus prebuilt nodes for the apps your workflows touch, and since the AI wave, agent nodes that put a model in the loop. You can run it two ways, on n8n's cloud or free on your own five-dollar server, and that split plus one pricing decision made it the default engine of the AI automation economy. It is also the center of a gold rush, and most of what you will read about it is written by people selling shovels: the real client money in n8n is small, steady, and reachable, and almost every big number attached to it is a course funnel.
## The shape of the tool
A workflow starts with a trigger (a webhook, a schedule, a form, an app event) and flows through nodes that fetch, transform, branch, and send. The editor runs in your browser whether the instance is n8n's or yours. For AI work there are agent and chain nodes wired to every major model provider, local models through Ollama, and [MCP in both directions](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcptrigger.md): your workflows can call outside MCP servers as tools, and a trigger node can expose your workflows as an MCP server for something like Claude to call. Two clean entry points: the [cloud trial](https://n8n.io/pricing/) is 14 days with no card, and the community edition is free forever on your own hardware, minus a list of team features ([environments, SSO, Git version control, workflow sharing](https://docs.n8n.io/deploy/host-n8n/community-edition-features.md)) that solo builders mostly will not miss on day one.
## The meter: one run, one execution
n8n's pricing quirk is the reason experienced automators migrate to it, so learn the mechanic first. From n8n's own pricing FAQ: an execution is "a single run of your entire workflow. It doesn't matter how many steps are in the workflow or how much data it processes." Zapier bills per task, meaning every step of every run; Make bills per module operation. A ten-step workflow that runs once a day costs you about 30 executions a month on n8n and about 300 tasks on Zapier. The receipts scale with ambition: one agency lead [moved a ClickUp scan from Make](https://www.reddit.com/r/n8n/comments/1ei5m36/why_n8n_over_make/) that burned "over 10k operations each time" and now runs it twice a day, because the same job counts as one execution per run.
Cloud plans start around €20 a month for 2,500 executions and €50 for 10,000, billed annually, with unlimited active workflows (prices display by region, so check [the page](https://n8n.io/pricing/) in your currency). Two traps hide in the small print. First, polling: a workflow that checks something every ten minutes fires 4,320 times a month all by itself, past the Starter cap before it has done anything useful. Prefer webhooks over schedules wherever the source app allows. Second, n8n has burned trust on pricing before: when it moved self-hosted enterprise tiers to per-execution pricing in 2025, heavy users in [the announcement thread](https://community.n8n.io/t/new-plan-no-active-workflow-limits-introducing-n8n-new-pricing/163840) posted cost projections up 250 times over, and the CEO's reply conceded that "no matter which metric is chosen, one group will be unhappy." Individual plans were not the target, but the lesson transfers: the meter is friendly today, and it is theirs to change.
## Self-hosting: the five-dollar instance and the rules that keep it alive
The community edition on a small VPS is the standard setup for builders, and the real budget is a few dollars a month plus your attention. The [official path](https://docs.n8n.io/deploy/host-n8n/install-options/install-with-docker.md) is Docker with a persistent volume, SQLite by default, Postgres when it matters. The docs say plainly that self-hosting "requires technical knowledge" and that mistakes "can lead to data loss, security issues, and downtime," and the forum receipts say they mean it. The canonical horror thread is [self-hosted workflows rolling back weeks](https://community.n8n.io/t/critical-n8n-selfhosted-rollback-all-workflows/215808) after updates: "We lost WEEKS of updates. Completely gone... like someone restored a backup from two weeks ago over the top." The pattern behind most of these stories is the same: `latest` tag, SQLite, no backup, updated on a whim.
So the self-host rules, all learned expensively by someone else:
- **Pin your version.** Never run the `latest` tag in production. Read release notes before moving; n8n ships releases weekly and [2.0 carried real breaking changes](https://blog.n8n.io/introducing-n8n-2-0/).
- **Back up before every update.** The volume holds your workflows, credentials, and encryption key. A copy costs seconds; the rollback thread is what not having one costs.
- **Graduate to Postgres when it becomes a business.** SQLite is fine to learn on. Once clients or volume depend on it, move, and past a couple hundred executions a day look at [queue mode](https://docs.n8n.io/deploy/host-n8n/configure-n8n/scaling/enable-queue-mode.md) with Redis and workers.
- **Give AI workflows memory headroom.** Agent nodes on a 512MB instance die of out-of-memory errors mid-run; 2GB is the realistic floor once models are in the loop.
## Building workflows that survive contact with production
The gap between a demo workflow and a production one is the whole craft, and the best summary in the community is a reviewer's [production-readiness checklist](https://community.n8n.io/t/the-6-dimension-production-readiness-checklist-ive-been-using-on-every-n8n-workflow-review/296612): most workflows "pass the 'happy path' check fine. They break when the unusual happens: a 504 retry, a credential rotation, a third-party API drift." The habits that close the gap:
- **Dedupe inbound events.** Webhooks deliver twice; without an ID check "you ship duplicate orders / duplicate charges."
- **Tame the retries.** Default per-node retry settings hammer a struggling API; add backoff and route final failures to an error workflow that alerts you and stores the payload, because execution logs expire and a failed payload you did not save is gone.
- **Keep one known-bad test payload** next to the happy-path one, and run both before every change ships.
- **Put the AI agent on a leash.** The recurring agent failure is the tool loop: an unexpected tool result and the agent "enters an infinite loop, calling the same tools repeatedly," [eating tokens until something stops it](https://community.n8n.io/t/feat-ai-tools-add-max-tool-interactions-to-ai-agent-nodes-to-prevent-infinite-loops/295587). One builder's [whole arc](https://community.n8n.io/t/trouble-with-ai-agents/51827) went from "Claude keeps inventing tools that are not listed" to the plea that explains the fix: "I just want a chatbot that has access to a couple of API calls." Build exactly that. Deterministic nodes for the flow, small scoped model calls where judgment is needed, hard caps on iterations, and a human approval gate before anything irreversible.
## The client money, under the guru numbers
This is why most of you are here, so here is the market with the funnels stripped out. The believable, repeated numbers from [working practitioners](https://www.reddit.com/r/n8n/comments/1izrlrr/what_the_heck_are_you_guys_charging_clients/): hourly rates from about €25 to 30 [starting out](https://www.reddit.com/r/n8n/comments/1kooxaw/how_did_you_start_your_ai_automation_business/), $50 to $75 established, up to $100 to $200 for veterans with a niche; one-time builds in the $500 to $2,000 range for something like an OCR-to-CRM pipeline; and maintenance retainers of a few hundred a month, priced, in one builder's words, "low enough for a company to not scrutinize the bill." Stack a handful of those retainers and it is real, unglamorous income. What sells is boring and provable: lead-gen and outreach pipelines, document intake to CRM, front-desk chat and voice for local businesses, content operations. The sellers who close say the word AI can hurt more than help; you are selling saved hours with a number attached, the same discipline as [scoping any AI project](/ledger/scoping-ai-projects/).
Now the other half. The subreddit is wallpapered with $25K-MRR screenshots, and the pattern under them is consistent: the poster is selling a course, a template pack, or a coaching program. The most useful thread in the niche is a [post-mortem by someone who bought in](https://www.reddit.com/r/n8n/comments/1kk5vt1/ive_built_like_20_ai_agents_so_far_and_still_have/), built twenty agents from the paid templates, "and still no clients." The replies deliver the verdict cheaper than the course did: "The people selling the classes are the only people making money here," and, sharper, "The money you think they were making is from people like you. You are their target customer." Even a builder genuinely selling automations [admits](https://www.reddit.com/r/n8n/comments/1ko57np/ai_agency_vs_ai_expert_business_model/) the hype "is coming from content creators (who actually make money from content and courses, not from selling automation to real companies)." The trade is real. The gold rush around it is mostly people selling maps. If you want the client path, start where [your first AI client](/ledger/first-ai-client/) actually comes from and [price the work](/ledger/pricing-ai-work/) like a professional.
## The license the gurus have not read
n8n is not open source; it ships under a [Sustainable Use License](https://docs.n8n.io/sustainable-use-license/) that allows internal business use and forbids selling access to n8n itself. For client work the line runs exactly where most agency setups happen to be standing. Building workflows for clients as a consultant is [explicitly permitted](https://blog.n8n.io/announcing-new-sustainable-use-license/), no license needed. But n8n's own support guidance draws the boundary: helping clients set up "their own internal instances" is fine, while hosting and managing "your clients' workflows and credentials within your own internal n8n instance" [requires an Enterprise license](https://support.n8n.io/article/can-i-use-your-license-for-my-use-case). The convenient one-instance-many-clients model, the default in every agency tutorial, is the violating one, and when someone described it on the forum the answer was blunt: [that setup is treated as offering n8n as a service](https://community.n8n.io/t/can-i-use-n8n-cloud-to-manage-workflows-for-multiple-consulting-clients/236130). White-labeling and charging for access are named as forbidden, and the commercial license is enterprise-priced; one startup [reported a $50K quote](https://news.ycombinator.com/item?id=44596041).
Here is the useful part: the compliant pattern is also the better business. Have the client own the instance, on their cloud account or their VPS, and [invite you in as an editor](https://community.n8n.io/t/delivering-a-workflow-to-clients/301433). Never hold their credentials in your own systems, never make yourself the thing they must pay to keep their automations alive. You lose the hosting margin and gain a clean handoff, a defensible legal position, and a client who trusts you with the next build. If your business model genuinely requires hosting automation for customers, use a tool licensed for it; [Activepieces is MIT-licensed](https://www.activepieces.com/pricing) precisely where n8n is not.
## Where it stops being worth it
The Primer rule is to know your off-ramp before the bill, or the 2 a.m. outage, surprises you.
- **High-volume, latency-sensitive systems.** Builders running serious load report the ceiling plainly: execution time limits, memory caps, state loss on crashes. n8n prototypes a pipeline beautifully; it is not the final home of one processing millions of events.
- **You can already code, and the workflow is really just an integration.** The [recurring engineer take](https://news.ycombinator.com/item?id=45532350): "easier and cheaper to have Claude code something and then throw it in docker as API." A [Claude Code](/primer/how-to-use-claude-code/) session writes, tests, and documents a bespoke integration in an afternoon, with real version control, which visual workflows still lack. n8n earns its place when the people maintaining the automation are not engineers, or when the glue between six SaaS apps is the whole job.
- **The client will run it themselves and is not technical.** Make's simpler surface hands off easier; more than one agency owner keeps it around just for that.
- **The middle path is real:** point Claude at the [n8n-mcp bridge](https://github.com/czlonkowski/n8n-mcp) and it will build and edit n8n workflows for you, which gets you AI-speed construction and a visual artifact a client can see. The tools we currently stand behind are on [the Palette](/palette/).
n8n earns its keep twice over: as the automation engine whose meter charges the run instead of the step, and as a genuine trade where a careful builder can stack real, modest retainers. It stops earning it when you scale a prototype past what a workflow tool should carry, host other people's automations on a license that forbids it, or buy a map from someone whose only gold is selling them. Learn the tool, read the license, charge for outcomes, and let the course sellers keep each other company.
---
# How to use Lovable, and when to take the code and go
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-lovable/
Prompt in, working app out. The speed is real and front-loaded: the demo lands the same afternoon, the real costs land once you ship it as more than a demo, and the exit ramp, GitHub then Cursor, is part of driving it well.
Lovable is the tool most people mean when they say vibe coding: type what you want, watch a working web app assemble itself, share a link the same afternoon. No editor, no terminal, no build step. It is genuinely the fastest way for a non-coder to get from idea to something clickable, and that part of the pitch survives contact with reality. The part that does not: treating the output as finished. Lovable is step one [on a longer map](/primer/build-an-app-with-ai-from-scratch/). The builders getting real value use it as a disposable prototyping layer and leave on time; the ones getting burned run production apps on it, pay per message while it debugs its own regressions, and in a few hundred documented cases shipped databases strangers could read. This guide is how to be the first kind.
## What it is, and what you get
You describe an app in chat. Lovable's agent plans, writes, and edits a real codebase: TanStack Start with server rendering on new projects (React and Vite on older ones), Tailwind for styling, and a backend wired through [Supabase](https://docs.lovable.dev/integrations/supabase) or Lovable's own Cloud. It deploys to a lovable.app subdomain when you hit publish, syncs [two ways with GitHub](https://docs.lovable.dev/integrations/github), and since 2026 ships with subagents, Stripe payments, scheduled jobs, and an MCP server. Web apps only: it will make you a mobile-friendly site, not a native app, and it cannot start from an existing codebase.
Four ways to touch a project, and they cost different money:
- **Build mode** is the agent. It plans, edits many files, checks its work. This is the default and the meter.
- **Plan mode** talks through the approach without touching code, at a flat one credit per message.
- **The preview toolbar** does tiny edits directly on the running app; inline text changes are free up to 100 a day.
- **Code mode** is a real editor on the underlying files, on paid plans. Free to type in, and the escape hatch the chat-only crowd forgets exists.
## The workflow that survives
The pattern below is assembled from Lovable's own [best-practices docs](https://docs.lovable.dev/tips-tricks/best-practice) and the users deep enough to have opinions worth copying.
1. **Plan before you build, most of the time.** Heavy users report living in plan and chat mode for well over half their messages, and Lovable's docs agree. Talking is one credit; letting the agent guess wrong across six files is not.
2. **Build the skeleton in the right order.** The clearest advice on r/lovable comes from a builder [about 50 projects deep](https://www.reddit.com/r/lovable/comments/1k7e7k9/): auth first, then security, then the database schema, then payments, and the pretty UI last. "If you get too far down scope, you can't go back and rebuild core."
3. **Write the knowledge file.** Every project has one, sent with every prompt. Stack facts, conventions, and standing rules ("do not edit the shared layout") go here. It is the same habit as [Claude Code's CLAUDE.md](/primer/how-to-use-claude-code/) and it does the same job: it stops the agent re-making the same mistake at your expense.
4. **Scope one change per message.** The death spiral starts when a vague prompt touches five things and breaks two. Small asks, review the result, next ask. One builder documented [breaking three unrelated features by adding one](https://codelikeagirl.substack.com/p/from-vibe-coder-to-shipping-real), with no idea why, and that story is the normal failure mode, not the exception.
5. **Prototype in parallel, throw most of it away.** Spinning up several cheap variants of an idea and keeping one is the use case where everyone agrees the tool pays: a startup CTO on Hacker News put it plainly, even if the code were deleted afterward, [validating assumptions alone saves "a ton of man hours per feature."](https://news.ycombinator.com/item?id=44377495)
## The money: a meter that bills by difficulty, and keeps running
Lovable's pricing looks simple and is not. [Pro starts at $25 a month for 100 credits](https://docs.lovable.dev/introduction/subscription-plans), the free tier gives 5 build credits a day capped at 30 a month, and top-ups run [$15 per 50 credits](https://docs.lovable.dev/introduction/plans-and-credits). The part that decides your bill is what a credit buys. Since [the Agent launch](https://lovable.dev/blog/agent), work is priced by complexity: restyling a button around half a credit, wiring auth about 1.2, a landing page with images near 2. A stopped or failed run still charges for the work done so far. And since June 2026 there is one pooled balance for everything: agent work, your app's database and hosting usage, and the AI calls your deployed app makes all draw from the same tank. A prompt-to-app alternative that meters in tokens rather than credits, and runs the dev environment in your browser, is [Bolt.new](/primer/how-to-use-bolt-new/).
Two consequences follow, and both show up in the receipts. First, debugging is billable, including debugging of the agent's own mistakes. The canonical complaint is a builder who [spent 400 credits on a first simple app](https://www.reddit.com/r/lovable/comments/1kh8b6a/) "because lovable kept breaking everything," and the pattern fills [a 140-point Hacker News thread](https://news.ycombinator.com/item?id=44377495) on whether charging users to fix the tool's own regressions is a viable business model. When the 2.0 repricing landed, one $200-a-month customer summarized the mood: [charged "for every single message... especially since Lovable... breaks things all the time."](https://www.reddit.com/r/lovable/comments/1k6t4eo/) Second, because your deployed app's backend usage draws from the same pool, [a live app stops responding to new requests when the credits hit zero](https://docs.lovable.dev/user-guides/messaging-limits). Read that twice if you have users: your subscription lapsing takes their app down with it.
The defensive habits are the workflow above plus arithmetic: plan mode for thinking, one scoped change per build message, free preview-toolbar edits for copy tweaks, code mode for anything you can type yourself, and a look at the credit estimate before big runs. Budget for the app you will debug; describing it is the cheap part.
## Security: three incidents, one lesson
This is the section the fan content skips, and it is the one that matters if your app touches other people's data.
In early 2025 a researcher scanned 1,645 Lovable-built projects and found [170 of them, about one in ten, leaking data](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/) through missing or broken Supabase row-level security: names, emails, home addresses, API keys, personal debt amounts. He could write as well as read, at one point marking an order as paid without paying. That became CVE-2025-48757. In February 2026, [a Lovable-hosted exam platform exposed 18,697 user records](https://www.theregister.com/2026/02/27/lovable_app_vulnerabilities/); the researcher described one flaw as "a classic logic inversion that a human security reviewer would catch in seconds." In April 2026 the exposure was [the platform itself](https://news.ycombinator.com/item?id=47833228): a researcher pulled other users' source code, secrets, and chat histories through Lovable's own API before it was fixed.
Lovable's response has been real but bounded: a [free security scan runs before every publish](https://docs.lovable.dev/features/security), a deeper agentic scan is on demand, and the docs now warn you to review generated database policies. The bound is in the company's own words, from its CISO: acting on the findings "is at the discretion of the user." The scanner also checks that access rules exist, not that they match your app's logic, and logic is where the exam app failed. So the working rules are short. Run the scan, then [the eight-check self-audit](/study/is-your-vibe-coded-app-secure/), and act on every finding before anything real touches the app. Treat database policies as your responsibility, not the agent's; if you cannot read them, do not store anything you would mind leaking. And do not collect sensitive data, health, finances, minors, in a vibe-coded app at all. The convenience you are buying does not cover that risk, and after three public incidents, "I did not know" no longer covers it either.
## The off-ramp: GitHub, then Cursor, before complexity bites
The most-upvoted advice post in Lovable's own subreddit is titled [stop using Lovable for everything](https://www.reddit.com/r/lovable/comments/1kixyei/), and its argument matches what shipped builders describe: Lovable for the UI and the working prototype, then export and finish like an engineer. The mechanics are good. You own the code, the [GitHub sync](https://docs.lovable.dev/integrations/github) is genuinely two-way, and the repo runs anywhere. From there, [Cursor](/primer/how-to-use-cursor/) for in-loop editing or [Claude Code](/primer/how-to-use-claude-code/) for delegated tasks picks up the last 20% that Lovable fights you on. One builder's arc is the template: 160 hours from first Lovable prompt to reviewing code line by line in Cursor, and 7,500 waitlist signups the day she shipped.
Three gotchas on the way out, all learned expensively by someone else:
- **Never rewrite git history against the sync.** A force-push [broke one builder's integration permanently](https://www.reddit.com/r/lovable/comments/1kjcble/). Treat the Lovable-synced branch as append-only.
- **Choose Supabase over Lovable Cloud if you might ever leave.** Your Supabase project is your account and keeps working without Lovable. [Cloud cannot be disconnected from a project](https://docs.lovable.dev/integrations/cloud) and has no documented migration out. Convenient in week one, a wall in month six.
- **Know what cancellation does.** Published sites can go offline after the billing period ends, and unused credits freeze. Export the repo and move hosting before you cancel.
## Where it stops being worth it
The Primer rule is to know your off-ramp before the bill, or the breach, surprises you.
- **Production apps holding real user data**, unless you can read and verify the security policies yourself or pay someone who can. One in ten scanned apps says the default is not safe.
- **Anything where design is the product.** Even fans concede the output converges on the same tasteful-template look; differentiated design still takes a designer, or [v0 plus your own taste](https://annaarteeva.medium.com/choosing-your-ai-prototyping-stack-lovable-v0-bolt-replit-cursor-magic-patterns-compared-9a5194f163e9).
- **Complex logic and big apps.** The generated architecture favors speed over structure, and past a moderate size, edits start breaking neighbors. That is your graduation notice; no prompt will fix it.
- **Native mobile, or building onto an existing codebase.** It does neither.
- **You can already drive an editor.** If [Cursor](/primer/how-to-use-cursor/) is comfortable, Lovable's value narrows to the first afternoon; you will hit its ceiling in a weekend. The tools we currently stand behind are on [the Palette](/palette/).
Lovable earns its keep as the fastest idea-to-demo machine available: the prototype that wins an argument, the MVP shell that gets you feedback, the UI you did not have to design from a blank file. It stops earning it the moment you mistake the demo for the product, because everything after that moment, the per-message debugging, the credit-metered hosting, the security policies nobody read, bills against you. Build the argument in Lovable. Ship the business from a repo you own. The builders who keep it in that lane swear by it, and the ones who did not are the receipts in this guide.
---
# How to make AI UGC ads, and when to pay a human instead
Section: The Primer
URL: https://okaneland.com/primer/how-to-make-ai-ugc-ads/
AI UGC tools sell a spokesperson video for the price of a coffee, and the working use case is narrower than the demos: high-volume hook testing. The money is in cheap volume, dozens of guesses for the price of one human clip, and the ceiling is trust: the moment an ad must carry a real claim or a real feeling, you hire the person.
The pitch is a person who does not exist, holding a phone, reading your script like they just discovered your product in their bathroom. The price is a couple of dollars a clip. The tools work, in the narrow sense: the person looks real, the read sounds close enough, and you can have fifty variants by dinner. AI UGC buys you volume, and volume is all it buys. Every workflow in this guide is built on that split, because the media buyers getting value from these tools use them for exactly one job, cheap disposable hook testing at a scale no human roster can match. Whether the whole category converts, and what the platform labels and testimonial rules can cost you, is a separate question with its own receipts: [we ran that math in The Study](/study/ai-ugc-ad-economics/). This is the how-to for the part that pays.
## The three tools, and what each is actually for
The category churns fast, but as of mid-2026 three names cover most real usage, and they are not interchangeable.
- **Creatify** is the cheapest way in and the most automated. [Starter is $39 a month for 100 credits](https://creatify.ai/pricing), there is a free tier good for about two watermarked test videos, and its signature move is URL-to-ad: paste a product page and it scrapes the assets, writes the script, and assembles the clip. Batch mode generates up to 50 variants in one run, and an Ad Launcher pushes straight to Meta and TikTok. Treat it as the volume machine, and [our hands-on Creatify review](/proof/creatify/) walks through what each tool actually does once you buy the plan.
- **HeyGen** is an avatar platform that happens to make ads, not an ad factory. [Creator is $29 a month for 600 credits](https://www.heygen.com/pricing) with 1,100+ stock avatars and 175 languages, and its real trick is the digital twin: record yourself once, including a short [spoken consent statement](https://help.heygen.com/en/articles/12092609-recording-your-consent-video), and the founder-reads-the-hook ad stops needing a founder with a free afternoon. If the face in the ad should be yours, this is the tool.
- **Arcads** is the one working media buyers actually name in the ad-buying forums, and it is priced like it knows. List price is [$110 a month for 10 videos, $220 for 20](https://www.eesel.ai/blog/arcads-ai-pricing), about $11 a finished clip, with no free trial and no public pricing page: arcads.ai/pricing returns a 404 and the numbers live behind a signup. Its actors are its moat, cloned from real, paid performers, a detail Arcads markets harder than it documents, and its 2026 Workflows feature turns one script into a batch across ten actors and two languages in a single run.
Behind those three sits a churning tail of cheaper clones (MakeUGC, Topview, Poolday, and whatever launched this week). The mechanics below transfer; the pricing pages do not, so reverify before you subscribe.
## The workflow that earns the money
The people posting real results do not open these tools and type a script from memory. The working loop looks like this, assembled from the media-buyer threads and [Arcads' own platform guide](https://intercom.help/arcads/en/articles/15503340-arcads-complete-platform-guide):
1. **Start from ads that already won.** Pull competitor creative from the Meta Ad Library or a spy tool and note the hooks, not the products. A [heavily-shared Arcads pipeline on r/FacebookAds](https://www.reddit.com/r/FacebookAds/comments/1khpqxo/13x_roas_again/) starts with competitor research every time. The tool renders; it does not invent an angle for you.
2. **Write a hook matrix.** One body, many first-three-seconds. Eight to ten hooks against the same demo footage is the standard shape, because the hook is the only part of the ad that gets a fair test at small budgets.
3. **Batch render.** This is what the 2026 features are for: one script across ten Arcads actors in one run, or Creatify's 50-variant batch. Generating variants one at a time burns your month's credits on ceremony.
4. **Edit before you ship.** Nobody serious runs the raw export. The recurring pattern in the threads is AI avatar for the hook, then cut to real product footage, screen recordings, or b-roll for the body, assembled in CapCut. One buyer's [format that held up](https://www.reddit.com/r/FacebookAds/comments/1ibcssj/thoughts_on_aigenerated_ugc/): "voiceless AI UGC with a text overlay as a hook," then the demo. The avatar opens the ad; it should almost never carry it.
5. **Test small, kill fast, remake winners.** Small budgets per variant, cut the losers in days, then regenerate the winning hook with new actors, voices, and openers. The one well-documented [mixed AI-and-human account](https://www.reddit.com/r/FacebookAds/comments/1khpqxo/13x_roas_again/) of compounding this loop scaled budget about 20% every few days rather than doubling down overnight.
Folk wisdom from the threads that costs nothing to adopt: pick actors filmed in cars or walking outside, because the phone-camera setting does more for believability than the face does, and give the ad a fighting chance by keeping it under a minute, both for credits and for lip-sync drift.
## The money: the credit meter is the product
Every tool in this category meters in credits, and the sticker price is the marketing number. The real unit is the usable ad, after retries.
- **Creatify** charges [5 credits per 15 seconds of generated video, and 3 credits per 15 seconds for a revision](https://help.creatify.ai/en/articles/9348041-credit-usage-billing-and-validity), with credits valid for two months. So the $2 video is a 15-second clip that rendered right the first time. A 60-second ad is 20 credits, one revision pass makes it 32, and your 100-credit Starter month is suddenly three finished ads, not twenty.
- **HeyGen** prices by avatar generation: its current flagship avatars bill [20 credits a minute](https://www.heygen.com/pricing) while the older tier bills 3. The model picker is the bill. Unused monthly credits roll over one month.
- **Arcads** skips the theater: one credit, one video, about $11, and on the lower tiers unused videos do not roll over. Trackers reported roughly 30% discounts in May 2026, so the list price is negotiable in a way the pricing page, if it existed, would not tell you.
Then there is the billing you do not plan for. A Creatify user posted a detailed account of [spending $200 in month one and being charged for two more months after trying to cancel](https://www.reddit.com/r/FacebookAds/comments/1isbrrf/creatify_ai_waste_of_money_and_deceptive_practices/), refund denied under a no-refunds policy. Arcads' [Trustpilot sits near 2.8](https://www.trustpilot.com/review/arcads.ai) with a pattern of annual-plan charges people thought were monthly. None of this is exotic; it is the standard texture of credit-metered SaaS. Set a calendar reminder before renewal, screenshot the plan page when you subscribe, and assume no refunds as the default state of the category.
## What the receipts actually say
Read the forums before you budget, because the split is sharper than the vendor case studies suggest.
The wins with numbers are thin. The most-cited ["my AI ads beat my human UGC" thread](https://www.reddit.com/r/FacebookAds/comments/1ewqehp/my_ai_ads_beat_my_human_ugc/) resolves, on inspection, to $600 of total spend and a cost-per-acquisition tie, and the thread's own commenters said so. The buyers reporting sustained results are running the volume loop above, usually with AI and human creative mixed, and they say the quiet part: iteration speed is the advantage, not the finished ad.
The complaints are consistent and specific. Lip sync is still the tell: ["mouths and lip syncing up to scripts is really tough... they aren't there yet,"](https://www.reddit.com/r/marketing/comments/1hmufsr/is_arcadscreatify_any_good_other_ugc_ai_platforms/) from a commenter with a friend at one of the vendors. Long renders drift; emotional reads come out flat; and the blunt version from the ad-buying trenches is that most raw output ["looks ugly and cheap"](https://www.reddit.com/r/FacebookAds/comments/1ibcssj/thoughts_on_aigenerated_ugc/) until it is heavily edited with the avatar in a corner. Meanwhile [plenty of buyers report](https://www.reddit.com/r/FacebookAds/comments/1kpoe7s/whats_working_right_now/) that "actual ugc is crushing" while their AI tests went nowhere, and [one thread does the uncomfortable math](https://www.reddit.com/r/FacebookAds/comments/1k1isu5/economicsmath_of_running_ai_video_ads/): a thousand dollars of spend testing cheap AI clips can lose to $150 pointed at one real creator.
Two warnings that are not about performance. First, the recommendation threads are astroturfed to the waterline; the same accounts paste the same tool lists across every marketing subreddit, and in one thread the [commenters caught the vendor mid-act](https://www.reddit.com/r/FacebookAds/comments/1iblzxa/why_is_ai_ugc_so_cheap/): "We know what you're doing." Weight complaints over praise; nobody astroturfs a complaint. Second, the actors in these libraries are licensed real people whose likenesses are sold to every subscriber at once, and the license runs darker than the brochure. One actor found his AI self [pushing miracle weight-loss cures as a fake doctor](https://petapixel.com/2025/04/23/actors-are-regretting-licensing-their-likeness-to-ai-companies/): "If it was a nice advertisement, it would've been fine to me. But obviously it is such a scam." The face selling your product spent last week selling someone's crypto scheme, and some slice of your audience has seen it before. That is the trust you are renting.
## The label, the law, and the line
Short version here, [full bill in The Study](/study/ai-ugc-ad-economics/): Meta [auto-detects and labels](https://about.fb.com/news/2025/02/gen-ai-transparency-metas-ads-products/) AI-generated ads whether you disclose or not, so build the label into the creative math from day one. And the FTC's fake-testimonial rule draws a line you should write down: an AI avatar presented as a spokesperson is an ad, an AI avatar presented as "Sarah, a real customer from Denver" is a fake testimonial from a person who does not exist, and each one can be its own violation. Scripts that read as reviews are the category's legal third rail. The tools will render them without blinking; [HeyGen's moderation policy](https://www.heygen.com/moderation-policy) worries about scams and politics, not your compliance.
## Where it stops being worth it
The Primer rule is to know your off-ramp before the bill, or the ad account, surprises you.
- **Testimonials and claims.** Anything a regulator could read as a customer endorsement, a health claim, or a results claim needs a real human on camera and a paper trail. Not this tool, any of it.
- **The product needs to be in someone's hand.** Avatars still cannot convincingly hold, open, or use your physical product; the hands-on reviewers flag it as the hard limit. Physical-product demos want real footage, with AI at most opening the ad.
- **Brand and emotion.** The one independent conversion study, covered [in The Study](/study/ai-ugc-ad-economics/), found AI creative lost the most ground exactly where the ad needed a story or a feeling. Your brand film is not fifty variants of anything.
- **You spend under about $500 a month on ads.** Below that, the volume thesis has no volume: one hands-on reviewer's cutoff, and the forum math agrees, is that a couple of real creator videos beat a subscription you cannot feed enough testing budget.
- **The hook won.** This is the good off-ramp. When a $2 clip finds an angle that holds up under spend, take the concept to a human creator, [about $185 a video at market rate](https://collabstr.com/2026-influencer-marketing-report), for the version that has to build trust instead of just finding it. The public receipts for this handoff are thinner than the gurus imply, but the logic is the whole category in one line: AI to search the hook space, humans to own the winner.
AI UGC tools earn their keep as a search engine for angles: fifty cheap guesses, rendered by lunch, tested by Friday, discarded without guilt. They stop earning it the moment you ask a rented face to do a real person's job, carrying a claim, a feeling, or a testimonial. Buy the volume. Never mistake it for the trust. The tools are counting on you to confuse the two, and the meter runs either way.
---
# The vibe coding stack: what to pay for and what to skip
Section: The Primer
URL: https://okaneland.com/primer/vibe-coding-stack/
The whole vibe coding stack, slot by slot: what each one really costs, what the field runs by the numbers, the app-builder question, and the version that costs nothing.
Andrej Karpathy named it in [a February 2025 post](https://x.com/karpathy/status/1886192184808149383): a way of building where you "fully give in to the vibes" and let the model write the code. Ten months later Collins made [vibe coding its Word of the Year for 2025](https://www.thebookseller.com/news/vibe-coding-is-collins-word-of-the-year-2025). The tools caught the wave, and the pricing pages got complicated.
Here is the whole answer up front. The vibe coding stack is four slots, and only two are worth paying for from day one: an AI editor (Cursor, $20 a month) and a terminal agent (Claude Code, on the $20 Claude Pro plan). That is $40 a month at sticker. Everything else, the app builders, a second assistant, an extra chat subscription, is optional. Every price here comes from the vendor's own page, cross-checked against [our maintained price index](/palette/ai-tool-price-index/). This piece is the shopping list; the path from empty folder to first users is [how to build an app with AI from scratch](/primer/build-an-app-with-ai-from-scratch/).
## What the field runs
Before the slot-by-slot, the map. In [Stack Overflow's 2025 survey](https://survey.stackoverflow.co/2025/ai/), 84% of developers use or plan to use AI tools, up from 76% a year earlier, and the tools they name most are the core slots and their cheap cousin: [ChatGPT at 81.7%, GitHub Copilot at 67.9%, and Claude Code at 40.8%](https://survey.stackoverflow.co/2025/ai/). The prompt-to-app builders trail in single digits: v0 at 9.1%, Bolt at 6.5%, Lovable at 5.7%. [JetBrains' January 2026 survey](https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/) of over 10,000 developers puts Cursor and Claude Code tied for second at work behind Copilot, and gives Claude Code the highest loyalty scores in the category, a 91% satisfaction rating and an NPS of 54. None of this tells you what to buy. It tells you the editor-and-agent core is where the working population sits, and the builder slot is a minority tool.
## The two slots that earn the money
**The editor: Cursor, $20 a month.** In-context work: edits, refactors, test scaffolding, the tab-complete that keeps you in flow. The catch is the meter behind the plan. Cursor's $20 Pro [includes about $20 of model usage](https://cursor.com/pricing), and once that is spent, continued use is billed as on-demand usage in arrears at API rates. You turn it on yourself, so the bill is never a surprise, and completions stay unlimited, but hand-picking frontier models is how a $20 plan becomes a $40 month. Cursor learned this in public. In [June 2025 it restructured Pro](https://cursor.com/blog/june-2025-pricing) from a fixed request count to that metered pool, "unlimited" turned out to mean only the cheaper Auto model, users got surprise bills, and Anysphere [apologized and issued refunds](https://techcrunch.com/2025/07/07/cursor-apologizes-for-unclear-pricing-changes-that-upset-users/). Set the spend limit on day one.
**The agent: Claude Code, $20 a month on Claude Pro.** The terminal agent is the half of vibe coding the editor cannot do: [hand it a whole task and let it run](/primer/how-to-use-claude-code/). Claude Pro [includes Claude Code](https://claude.com/pricing) on one shared usage pool, so a heavy agent afternoon eats the same allowance as your chats. When the agent becomes your main tool, the $100 Max plan, up to [$200 for the 20x tier](https://support.claude.com/en/articles/11049741), stops being extravagant. Anthropic added [weekly caps in July 2025](https://techcrunch.com/2025/07/28/anthropic-unveils-new-rate-limits-to-curb-claude-code-power-users/) aimed at the heavy tail it estimated at under 5% of subscribers, a figure a later class action disputes, so the ceiling is real if you run the agent hard. This is not a fringe tool. Anthropic reports Claude Code [past a $2.5 billion run rate](https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation) as of February 2026.
## But does it even make you faster
Here is the part the vendor pages will never show you. When [METR ran a randomized trial](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) in early 2025, experienced open-source developers were 19% *slower* completing real tasks with AI tools, and the tool they mostly used was Cursor Pro. The developers thought they were 20% faster. That gap between felt speed and measured speed is the whole risk of a metered stack: you cannot feel your real velocity any more than you can feel your real spend. The other side is real too. A [GitHub-run experiment found 55.8% faster](https://arxiv.org/abs/2302.06590) on a fixed coding task, and METR's own [February 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) walked the slowdown toward zero on newer tools, though it calls that follow-up data unreliable. The point is to measure, rather than vibe, whether the stack pays off, which is the only reason to read a bill at all. And [whether the method itself pays](/study/is-vibe-coding-worth-it/), beyond the tools, has its own verdict piece.
## The optional slot: the app builder
Lovable ($25 a month), Bolt ($25), and v0 ($30 per user) sell the same promise: describe the app, get the app. For a non-coder shipping a first product, the slot can be worth it. If you already run the editor and the agent, you can usually skip it, and the meter is why. Lovable prices by request complexity, [a styling tweak around 0.50 credits, adding authentication around 1.20](https://docs.lovable.dev/introduction/credits-and-usage), debugging is billed like any other request with no exemption, and a deployed app keeps drawing credits from the same pool while it runs. Bolt counts tokens, [$25 for 10 million a month](https://bolt.new/pricing), and burns them faster as a project grows, because it re-syncs your files to the model on every message. None of that is a scandal; it is metered pricing doing its job, [the same trap the $20 AI app walks into](/study/unit-economics-of-wrapping-an-llm/). The mistake is reading the subscription as the cost when the meter is the cost.
## What to skip, and why
**GitHub Copilot ($10).** The cheapest seat and, by both surveys, the most-adopted AI coding tool, so if you want one paid tool and live in VS Code it is a defensible sole pick. But it fills the same slot as Cursor. Its billing also changed on [June 1, 2026](https://github.com/features/copilot/plans): premium requests became dollar-denominated AI Credits, $15 a month on Pro, while code completions stay unlimited. Paying for Copilot and Cursor is buying one slot twice.
**Windsurf.** The standalone editor is gone; it is Devin Desktop now, [a cautionary tale the agent field guide tells in full](/study/ai-coding-agent-field-guide/). That competes for the agent slot, which is already taken.
**A second chat subscription.** ChatGPT Plus is $20 and Codex rides along with it. If your agent is Claude Code, that is a same-slot duplicate. One frontier subscription used hard beats two used at half attention.
## The $0 stack
A real free stack exists in 2026, and it is better than it used to be. [Gemini CLI](https://blog.google/technology/developers/introducing-gemini-cli-open-source-ai-agent/) gives 60 model requests a minute and 1,000 a day at no charge with a personal Google account, a genuine free agent rather than a teaser. Pair it with [Copilot Free](https://github.com/features/copilot/plans), 2,000 completions and 50 chat requests a month with agent mode included, or Cursor's free Hobby tier, and you can vibe code a real thing for nothing. What breaks first is the caps: 50 Copilot chats or a day's Gemini quota vanish fast in an agent loop, and Claude Code has no free tier at all. The free stack is for finding which slot you would use every day. Then pay for that one first.
## The bill
| Slot | Tool | Sticker | A heavy month |
| --- | --- | --- | --- |
| Editor | Cursor Pro | $20 | $40 to $50 with frontier models |
| Agent | Claude Code (Claude Pro) | $20 | $100 on Max, if it becomes the main tool |
| App builder | optional | $0 | $25 to $30 if you take the slot |
| **Total** | | **$40** | **$60 to $150** |
The sticker total is $40. A heavy month runs higher, and our estimate is $60 to $70, which is an estimate on purpose: the metering is documented on every plan, but no vendor publishes what an average build spends. That is the reason to check the bill against [the price index](/palette/ai-tool-price-index/) once a month and cancel the slot that stopped earning.
---
# How to run Claude Code, and when to take back the keyboard
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-claude-code/
It ships on the same subscription as your Claude chats and drains the same usage pool. Delegation is the whole skill: given a bounded task and a real review it earns the price, unwatched it produces confident wreckage, and for quick in-editor edits Cursor stays the better buy.
Stop treating it like an editor. That is the first thing to get right, because almost everyone arrives from Cursor or Copilot and tries to use it the same way, then wonders why it feels wrong. Claude Code is an agent that lives in your terminal. You give it a task in plain language, and it reads your repo, edits files across the project, runs commands, reads the output, and loops until the job is done or it gets stuck. You are not steering it keystroke by keystroke the way you ride Cursor's Tab. Keep one line in your head before we start: Claude Code is a junior engineer you delegate to. Used well, it clears whole tasks while you do something else. Point it at the wrong work, or skip the review, and it will ship something broken with total fluency.
## Set it up in five minutes
Claude Code runs in your terminal, inside VS Code and JetBrains as an extension, in the desktop app, and in the browser at claude.ai/code. Install it, open a real project (not a toy), and the first command to run is `/init`. It reads your codebase and writes a `CLAUDE.md`: a short file of project facts, conventions, and commands that Claude reloads every session. It bills against a Claude subscription, so if you already pay for Pro or Max for the chat app, you can start without a separate bill. More on that math below, because the pool is shared and it matters.
## The shift: you delegate, then you check
[Cursor amplifies your own typing](/primer/how-to-use-cursor/). Claude Code replaces a chunk of it. The good loop, the one Anthropic's own [best-practices guide](https://code.claude.com/docs/en/best-practices) and every experienced user converge on, is four steps: explore, plan, implement, commit.
- **Explore.** Ask it to read the relevant files and tell you how the thing works before it changes anything. Do not let it write code in the first message.
- **Plan.** Have it write a plan you can read and correct. Use plan mode (Shift+Tab) so it proposes before it touches a file. This one habit prevents most of the damage.
- **Implement.** Let it build against the plan you approved.
- **Commit.** Review the diff, commit the working step, then move on. Commit often so you can roll back cleanly when it breaks something, and it will.
The skill is knowing what to hand off whole and what to keep on a short leash.
The leash is literal. By default Claude Code asks before it edits a file or runs a command, and you approve each action. You can let it auto-accept to move faster, but auto-accept is a speed setting that removes the only checkpoint: an agent reading untrusted web content or a malicious repo can be steered into running something you would never approve. Keep the prompts on for anything that touches the network, the filesystem outside your project, or your credentials, and save the hands-off runs for work you have scoped tight.
## The three mistakes that burn your first week
- **Treating it like Cursor.** People paste one line, expect a tidy inline completion, and get an agent that runs off and rewrites four files. Scope the task: tell it what to read, what to change, and what to leave alone.
- **Skipping the plan.** The single biggest split between people who love Claude Code and people who fight it is plan mode. Letting it code from a vague prompt is how you get confident, wrong, multi-file changes that are a pain to unwind.
- **Never making it check its own work.** An agent that writes code and never runs it is guessing. Tell it to run the tests, the type checker, and the linter, and to fix what breaks before it reports back. A loop that ends with "the tests pass, here is the diff" is worth ten that end with "I think this works."
## Drive the context window like it is the budget
What quietly decides whether Claude Code does good work is the context window: how much of your code and conversation it can hold at once. It is finite, and a long, messy session fills it with stale detail until the model loses the plot. Three habits keep it sharp:
- **`/clear` between tasks.** Start a fresh context for each logical unit of work. A thread that has wandered through three unrelated problems makes worse decisions on the fourth.
- **`/compact` when a long task must continue.** It summarizes the session so far and frees room, keeping the thread alive without the clutter.
- **Hand big jobs to subagents.** Claude Code can spin up [separate agents](https://code.claude.com/docs/en/sub-agents) for sub-tasks, each with its own clean context, so the main thread stays focused. This is how you stop a large job collapsing under its own history.
And keep `CLAUDE.md` short and current: under a couple hundred lines, pointing at real files instead of pasting them, with a new line added every time the agent repeats a mistake. The [memory file](https://code.claude.com/docs/en/memory) does more to keep the agent on your rails than any clever prompt.
## Claude Code pricing: one shared pool, two meters
Claude Code has no separate price: it bills against your Claude subscription, the same usage pool as the Claude chat app, on Pro ($20/mo) or Max ($100 and $200/mo). The subscription you thought you understood writes you a surprise here, so learn the mechanic. That is the catch most people miss: [a heavy Claude Code afternoon eats the same allowance as your chats](/study/unit-economics-of-wrapping-an-llm/). (API pay-as-you-go is a separate, metered track if you would rather pay by the token.)
There are two meters on that pool. A rolling five-hour limit that has always been there, and weekly caps Anthropic [announced in July 2025](https://techcrunch.com/2025/07/28/anthropic-unveils-new-rate-limits-to-curb-claude-code-power-users/) and switched on a month later, after a minority ran agents around the clock: one overall weekly limit, and a second, tighter cap specifically on the most capable model. That second cap is the one that bites, because the heavyweight model is exactly what you reach for on hard agentic work, and it drains the fastest. Anthropic estimated the weekly caps would hit fewer than 5% of subscribers; those few are the heavy daily users, and the backlash was loud, with developers reporting a full weekly quota gone in a day or two of real work.
The practical read: do the everyday work on the cheaper, faster models and save the most capable one for the tasks that genuinely need it. Watch your usage. If you are hitting weekly caps, that is the signal you are either doing serious volume (in which case [the API track or a higher tier may be cheaper](/study/cut-your-ai-coding-bill/)) or handing the agent work you should be scoping tighter.
## The 2026 degradation: when the wheels came off, and what it teaches
Here is a receipt worth more than any feature list. For roughly six weeks in early 2026, Claude Code visibly got worse, and the story of why is the best argument there is for never trusting an agent you cannot see.
Users reported it turning forgetful, repetitive, and lazy. An AMD AI director, Stella Laurenzo, [data-mined 6,852 of her own sessions](https://github.com/anthropics/claude-code/issues/42796) and found the behavior had measurably shifted: the model went from reading the code 6.6 times per edit to 2.0, and the share of edits it made without reading the file first jumped from 6.2% to 33.7%. It had stopped doing its homework. Developers called it "AI shrinkflation."
Anthropic [published a postmortem](https://www.anthropic.com/engineering/april-23-postmortem) on April 23, 2026 and confirmed the decline was real, and (this is the part that matters) that the model weights and the API were never touched. Three separate changes to the product layer, the harness around the model, had each quietly dented quality: a March reasoning setting cut from high to medium to shave latency, which Anthropic later called "the wrong tradeoff"; a caching bug that wiped the model's reasoning every turn and made it forgetful; and a brief verbosity cap that measured about 3% worse on coding and lasted four days. All three were fixed by April 20, and Anthropic reset everyone's usage limits as an apology.
The lesson is more useful than "Claude Code is unreliable," and less reassuring: you are renting an agent built on a stack you do not control, and quality can shift under you without warning, from a setting you will never see. The only defense is the one the candid Cursor fans repeat. Make it verify its own work, and read the diff yourself, which is also [the habit that decides whether you learn anything while vibe coding](/primer/can-you-learn-while-vibe-coding/). The builders who barely noticed the rough patch were the ones who already checked every change against the tests. The ones who got burned had stopped looking.
## Where it stops being worth it
The Primer rule is to know your off-ramp before the bill, or the bug, surprises you. Claude Code is the right tool for delegating real, multi-file work you can describe and then check. Here is when to reach for something else:
- **Tiny, in-context edits.** Renaming a variable or tweaking the line on your screen does not need an agent. That is what an editor's inline completion is for, and firing up a whole agentic loop for it wastes time and budget.
- **Work where you want to feel every change.** [The METR study](/study/does-ai-coding-make-you-faster/) found experienced developers were 19% slower with AI on large codebases they knew cold, while believing they were faster. On code you know intimately, steering the keystrokes yourself often beats delegating and reviewing.
- **You are watching cost and only want completions.** A completion-first tool like Copilot is cheaper and sits in your editor; you do not need an agent's power, or its bill. The tools we currently stand behind are on [the Palette](/palette/).
- **Huge, mature codebases.** A million-line repo is far more than any model holds at once. Claude Code handles this better than most, because it reads selectively instead of stuffing everything into context, but it still needs you to scope tightly, and the review tax climbs with the stakes.
- **No code can leave the building.** Claude Code sends your code to Anthropic's models. Air-gapped or regulated work needs a bring-your-own-key tool pointed at a local model; a hosted agent cannot make that promise.
## Claude Code vs Cursor: use both, and here is the split
Claude Code and Cursor are different shaped tools, and most serious builders run both. That is the answer the "X vs Y" posts dodge. [Cursor](/primer/how-to-use-cursor/) is an editor: you live in it, and its Tab autocomplete amplifies your own typing on code you are actively shaping. Claude Code is an agent: you delegate a whole task to the terminal and check the result. Reach for the editor when you want to feel every line; reach for the agent when you want a defined job done off your plate. The [common 2026 verdict](https://www.builder.io/blog/cursor-vs-claude-code) is not to crown a winner but to [keep both in the stack](/primer/vibe-coding-stack/): one to make your hands faster, one to take work off them. The market beyond these two is mapped in [the coding-agent field guide](/study/ai-coding-agent-field-guide/).
Claude Code is the most capable terminal agent available, and on the right task it clears work nothing else can handle. The shared usage pool is the line item to watch, the weekly cap on the top model is the one that stings first, and the agent is only ever as safe as your review habit. Delegate the work you can describe, make it prove the result, read every diff, and keep one eye on the meter. Do that and it earns its keep. Skip the review and it will hand you a confident, broken result while you are looking the other way.
---
# Where Perplexity earns its keep, and where it doesn't
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-perplexity/
Perplexity does the searching and the reading; the checking stays your job. A cited answer reads like a verified one and is not, and the tool pays for itself exactly as long as you keep clicking the footnotes.
Perplexity is an answer engine: it runs a live web search, reads the results, and hands you a written answer with numbered citations stitched into it. Ask Google a question and you get ten blue links to read yourself; ask a plain chatbot and you get a fluent paragraph with no idea where it came from. Perplexity sits in between, and it shows its work. That is the whole pitch, and for research it is a good one. The catch, and the reason this guide exists, is four words long: cited is not verified. A footnote next to a sentence is only a pointer, and the research on how often those pointers are wrong is the most important thing on this page.
## The surfaces
Perplexity runs in a browser, in the iOS and Android apps, as a browser extension, inside its own Comet browser, and as the Sonar API to wire its search into your own product. Start free on the web. The free tier answers everyday questions, then gates you fast and locks the better tools to push you toward Pro. You do not need an account to see what it does; you need one to do real work in it.
## The three depths, lightest first
Perplexity has one box and three depths of effort behind it. Use the lightest that does the job.
- **The quick answer.** The default. Type a question, get a cited answer in a couple of seconds. Good for a fact, a definition, a "what is X," a place to start.
- **[Pro Search](https://www.perplexity.ai/help-center/en/articles/10352903-what-is-pro-search).** Perplexity describes it as "a knowledgeable search assistant" rather than a keyword search: it runs several searches, reasons across articles, papers, forums, and videos, and synthesizes a fuller answer. This is where paid users pick the model behind the answer (Perplexity's own Sonar, or the latest from OpenAI, Anthropic, and Google), each tuned for different kinds of question. Reach for it when one search will not cover the question.
- **[Research mode](https://www.perplexity.ai/help-center/en/articles/10738684-what-is-research-mode)** (it used to be called Deep Research). Hand it a real question and it goes away for a few minutes, fires off dozens of searches, reads across many sources, and comes back with a structured, multi-section report. Use it for the work you would otherwise give an afternoon: a market scan, a literature pass, a "compare these six options" brief.
Two more controls worth knowing. **Focus** narrows where it looks (Web, Academic, and others); Academic is the one that matters most, because it swaps the SEO content farms for real sources. **[Spaces](https://www.perplexity.ai/help-center/en/articles/10352961-what-are-spaces)** are workspaces that keep a project's threads, files, and instructions together, so a week of research does not scatter across your history.
## Drive it well
- **Ask a full question.** Perplexity is built to answer a real sentence. "Best CRM for a two-person agency under $50 a month" beats "crm small business."
- **Keep going in the same thread.** An answer is the start of a conversation. Ask the follow-up in the same thread ("now narrow that to free tiers," "why did you rule out the third one") and it builds on what is already on screen, instead of making you restate the whole question.
- **Set the focus before the source matters.** If you need sources you can stand behind, switch to Academic. Our own testing found everyday Perplexity leaning on content mills, while Academic returned arxiv, SSRN, and Reuters. [The full review is in The Proof](/proof/perplexity/).
- **Pick the model for the job** if you pay. Routing a reasoning-heavy question to a frontier model and a quick lookup to Sonar is the real lever the paid tiers give you.
- **Open the citations. Every time.** This is the habit that separates people who get value from Perplexity from people who get burned by it. The numbered sources are not decoration and not proof; they are the thing you came for. Click them. The next section is why.
## Perplexity pricing: free, Pro, and Max
The free tier gives you cited answers, gated quickly, with the better tools locked. **Pro, around $20 a month,** adds model choice, far more Pro Search and Research, and the workspace features; it is the tier most daily users land on. **Max, $200 a month,** stacks the heavy toolset on top: a council of frontier models answering side by side, an agentic "Computer" that runs multi-step tasks, and premium data connectors. We bought Max and drove every tool: the advanced kit is genuinely powerful, and most people will never touch the parts that justify ten times the Pro price. [The Proof has the full verdict](/proof/perplexity/).
Pro and Max run the same core search; Max buys the extra machinery, not a smarter everyday answer. Builders have a fourth option, the [Sonar API](https://docs.perplexity.ai/docs/getting-started/pricing), which puts Perplexity's web search behind your own app, priced from about a dollar per million tokens plus a per-request search fee. One caution across all of it: Perplexity's exact limits move often, and the allowances have tightened since launch, so check the current numbers in your own account before you build a habit, or a budget, on them. How often they move is its own story: [we coded 1,024 subscriber posts](/study/perplexity-pro-limits/) and found three separate cuts to the Pro tier in eight months.
## Is Perplexity accurate? A cited answer is not a verified one
Read this part twice. In March 2025 the Columbia Journalism Review's Tow Center ran [the cleanest test of AI search so far](https://www.cjr.org/tow_center/we-compared-eight-ai-search-engines-theyre-all-bad-at-citing-news.php): they took real article excerpts and asked eight AI search engines to name the source. Across 1,600 queries, the engines were [collectively wrong more than 60% of the time](https://www.niemanlab.org/2025/03/ai-search-engines-fail-to-produce-accurate-citations-in-over-60-of-tests-according-to-new-tow-center-study/). Perplexity was the best of the eight, and it was still wrong 37% of the time. The most accurate AI search on the market misattributed the source of a quote in more than a third of its answers.
It gets sharper for the paid tiers, and this is the part that should change how you read what they hand back. The study found the premium versions, Perplexity Pro among them, were [not more reliable](/study/aeo-and-geo-what-the-research-says/). They were more confidently wrong: they handed back a definitive source instead of admitting they did not know, and that confidence pushed their error rate up. The authoritative tone of a paid Perplexity answer is not a signal that it is right.
Stack that on what our own testing found, Perplexity once citing a politics magazine for a claim about how a company bills, and the rule writes itself. Treat every Perplexity answer as a fast, well-organized first draft of the truth, with the sources you need to check it sitting right there. A citation you did not click is a vibe.
## The second receipt: how the sources get collected
The first receipt is whether the citation is right. The second is where the citation came from at all. The same Tow Center study found Perplexity's free tier correctly identifying ten excerpts from paywalled National Geographic articles, from a publisher that had blocked its crawler and had no deal with it. In August 2025 [Cloudflare reported](https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/) something pointier: when sites blocked Perplexity's declared crawler, it observed undeclared "stealth" crawlers impersonating an ordinary Chrome browser and rotating through IP addresses to fetch the content anyway, including on brand-new test domains set up to block every bot. Perplexity disputes Cloudflare's reading, so take it as a documented allegation rather than a closed case. But take it: the answer in front of you may rest on sources their owners tried to keep out, which is both an ethical question and a tell about how aggressively those citations are assembled.
## Where it stops earning its keep
Perplexity is the right tool when you want a fast, cited synthesis of what the web says right now. It is the wrong tool here:
- **You need the primary document.** For a specific law, a filing, a spec, or a number that has to be exact, go to the source. A synthesis is a detour when you already know which page you need.
- **The answer has to be airtight.** Anything legal, medical, financial, or going in front of a client carries that one-in-three attribution risk. Use Perplexity to find the sources, then verify each one yourself, or start from a primary source you already trust.
- **You want deep reasoning, coding, or long-form writing.** Perplexity is tuned for fast cited search. For code, a [terminal agent](/primer/how-to-use-claude-code/) or an [AI editor](/primer/how-to-use-cursor/) is the right tool instead; for a long reasoning or writing task, the frontier model Perplexity routes to does better work when you talk to it directly. The tools we currently stand behind are on [the Palette](/palette/).
- **A plain search is faster.** For a navigational lookup ("the React docs," "that one pricing page"), Google still wins on speed.
The sweet spot, where Perplexity genuinely beats both Google and a sourceless chatbot: a fast scan of a topic you do not know yet, a "what is the current state of X," comparison research before a purchase, and (in Academic focus) a first literature pass. There, the cited answer saves real time, as long as you do the one thing the tool is quietly hoping you will skip.
Perplexity earns its keep as a research accelerator that shows you its sources. It stops cold the moment you read the answer and trust the footnote instead of clicking it. Show your work cuts both ways: the point of seeing the sources is that you check them. Feeling like someone already did is the trap.
---
# How to actually use Cursor, and where it stops being worth it
Section: The Primer
URL: https://okaneland.com/primer/how-to-use-cursor/
The Tab autocomplete is the reason people stay; the credit meter is the reason they watch the dashboard. Tab by itself can carry the price, credits are the permanent catch, and the agent repays exactly the attention you give its diffs.
Cursor is the AI code editor most people who ship with AI open first, and the reason is plain: it is a [fork of VS Code](https://en.wikipedia.org/wiki/Cursor_code_editor), so your settings, extensions, themes, and keybindings come straight across and there is almost nothing new to learn. Cursor is an amplifier. It makes a capable builder much faster on small and mid-size projects. It will not turn a non-coder into an engineer, and it will confidently break working code if you let it run unwatched. This is the practical version: how to drive it well, then exactly where it stops being worth your money.
## Set it up in five minutes
Install Cursor, open it, and let it import your VS Code setup when it offers. Sign in on the free Hobby tier, which gives you limited Agent and Tab; Cursor no longer offers a Pro trial, so that free tier is how you try it before you commit the $20. Point it at a real project so you see how it behaves on code you care about.
## Learn the four surfaces, lightest first
Cursor gives you four ways to get help. Use the lightest one that does the job, both for speed and because the heavier tools cost more and can do more damage.
- **Tab.** As you type, Cursor predicts your next edit, whole lines and refactors included, and shows it greyed out. Press Tab to accept, Esc to reject, or Cmd/Ctrl + Right Arrow to take it a word at a time. This [edit-prediction autocomplete](https://cursor.com/docs/tab/overview) is the feature users call near-magical and the main reason they stay. Live in it.
- **Inline edit (Cmd/Ctrl-K).** Select some code, hit Cmd/Ctrl-K, and describe the change in a sentence. Best for a scoped tweak to something already on your screen, no chat thread needed.
- **Chat.** Open the chat sidebar to ask questions about your code or talk through an approach. It reads your project but does not touch files until you tell it to.
- **Agent (Cmd+I).** The autonomous mode: it edits across many files, runs commands, and checks its own work in a loop. This is the powerful, expensive, and risky one. Reach for it only when the task is genuinely multi-file, and read the next two sections before you let it loose.
## Feed it context, do not flood it
Cursor pulls context two ways. It [auto-indexes your codebase](https://cursor.com/docs/context/codebase-indexing) into a local search index (ready at about 80% indexed, re-syncing every few minutes, and it respects `.gitignore` and `.cursorignore`). And you point it at things with @-mentions: `@file`, `@folder`, `@Docs`, `@Terminal`, past chats, and git diffs.
The rule that separates good results from bad: tag the exact files when you know which ones matter, and let the agent search when you do not. Dumping a pile of loosely related files does not help, it confuses the model and wastes budget. Add a `.cursorignore` so it skips build output, secrets, and vendored code.
## Write a rules file, and keep it current
The setup step that pays off most is a [rules file](https://cursor.com/docs/rules). Drop a short file in `.cursor/rules` (or a plain `AGENTS.md`) describing your stack, your conventions, and the patterns you want the agent to follow. Keep it under 500 lines, point at real files instead of pasting their contents, and treat it as living: every time the agent repeats a mistake, add a line that tells it not to. That one habit does more to stop the agent drifting than any prompt trick.
## Let the agent run, but on a leash
The agent is where Cursor earns its reputation and where it bites people. Cursor's own [agent best-practices](https://cursor.com/blog/agent-best-practices) line up with what burned users learned the hard way:
- **Plan before it builds.** Use Plan Mode (Shift+Tab) to get a written plan you can read and correct before any code changes.
- **Fresh chat per feature.** Long threads lose the plot. Start a new conversation for each logical unit of work.
- **Commit often and review every diff.** Watch the changes land line by line. Commit at each working step so you can roll back cleanly when it breaks something, and it will.
- **Set guardrails before any hands-off run.** Switch Run Mode to an allowlist and turn on file-deletion protection. Real users filed [bug reports of the agent modifying, deleting, and even committing files after they pressed Stop](https://forum.cursor.com/t/cursor-agent-is-acting-uncontrollably-after-prompts-are-stopped-modifying-files-and-even-committing-code/162740); the fix was exactly those two settings. Never let it auto-run terminal commands while it is reading untrusted web content. Cursor itself calls auto-run a convenience, "not a security boundary," because of prompt injection.
## The money: where Cursor quietly bills you
This is the part that [turns a $20 plan into a $50 surprise](/study/unit-economics-of-wrapping-an-llm/), so understand the mechanic. Every paid plan is a dollar pool of model usage (Pro is $20/mo, Pro+ $60, Ultra $200, [per the pricing page](https://cursor.com/pricing)). **Auto mode**, where Cursor picks the model, runs on a heavily subsidized, much cheaper rate, so everyday work barely dents the pool. The moment you hand-pick a frontier model (Claude Opus or Sonnet, GPT, Gemini) for a big agent run, you are spending real API dollars. As of mid-2025 Cursor said $20 of Pro usage was about [225 Claude Sonnet requests](https://cursor.com/blog/june-2025-pricing) at typical token use. That is the whole lever: Auto for the everyday is cheap, hand-picked frontier models on long agent runs are not.
This is also where Cursor earned a real trust wound. In June 2025 it scrapped the old "500 requests a month" Pro plan for the credit pool and launched the $200 Ultra tier the same day. The rollout called it "unlimited usage" when that only ever applied to Auto, and heavy users got blindsided by overage bills. One Hacker News user reported $350 of overage in a week, and a team described a roughly $7,000 budget gone in a day (user reports, unconfirmed by Cursor). The CEO [apologized](https://techcrunch.com/2025/07/07/cursor-apologizes-for-unclear-pricing-changes-that-upset-users/) on July 4, saying "we didn't handle this pricing rollout well, and we're sorry," and refunded the affected window. The credit model itself was never reversed. So: watch the usage dashboard, set a spend limit, and do not be surprised that the meter is running. We later [bought Pro and metered a full test session ourselves](/proof/cursor/): the whole run, cloud agent included, billed $0 beyond the subscription, and the dashboard never once showed a remaining-quota number.
## What real users love, and where it bites
The praise is consistent. Tab is the feature people would miss most. The VS Code lineage means no learning curve. The agent scaffolds whole features fast, full-codebase awareness gets called the standout, and aggregate ratings sit around 4.6 to 4.8 out of 5.
The complaints are just as consistent, and worth knowing before you commit:
- **Cost is unpredictable.** The dollar pool plus overage means a nominal $20 plan often becomes a $40 to $50 real bill. It is the number-one standing gripe.
- **"Auto got nerfed."** Through late 2025 and into 2026, [forum threads](https://forum.cursor.com/t/auto-mode-has-become-almost-unusable/153944) report Auto losing context, ignoring instructions, and making mistakes. Staff say Auto optimizes for cost and steer people to pick a model manually, which heavy users read as a quiet downgrade.
- **It breaks working code on big repos.** No AI tool can hold a large, mature codebase in context, and Cursor lags on files over a few hundred lines. On legacy systems, [the review tax outweighs the speed](/study/does-ai-coding-make-you-faster/).
- **Support is thin.** There is no live chat even on the $200 Ultra plan, only email.
The throughline: every fan who is candid says the same thing, review every agent diff yourself. It is non-negotiable.
## How builders are actually using it
The pattern across the forums is consistent: Cursor pays off when you stay in the loop on something you are building from scratch or already know. Real examples, in builders' own words:
- **First products from near-beginners.** In Cursor's ["built with Cursor in 2025" thread](https://forum.cursor.com/t/built-with-cursor-in-2025-share-your-projects/147737), a builder with little coding background made an iOS speech-therapy app for stroke survivors and went on to win a Cursor hackathon with it. Others in the same thread shipped a tattoo-shop booking SaaS and an automated trading backtester.
- **Speed on your own codebase.** A solo founder who fed Cursor many files at once for bug-finding and features called it ["jaw-droppingly good"](https://forum.cursor.com/t/cursor-has-literally-changed-my-life/142659) and reckoned his project grew as much in six days as it used to in two weeks.
- **Refactors that used to cost an afternoon.** On Hacker News a developer watched it ["refactor in a matter of minutes code that would've taken hours, correctly"](https://news.ycombinator.com/item?id=44168149); another said it ["has built near entire features for me"](https://news.ycombinator.com/item?id=43744228).
- **The autocomplete, constantly.** A common refrain: Cursor ["autocomplete (cursor tab) is the one feature I use constantly"](https://news.ycombinator.com/item?id=43899012).
- **Hands-off background jobs.** A solo SaaS owner runs Cursor's cloud agents on a schedule, calling them ["just prompts on a cron ... but super useful"](https://news.ycombinator.com/item?id=47736272).
The common thread is greenfield apps, code you already know, scoped refactors, and Tab. That is exactly the profile where Cursor earns its keep. Notice, too, that the same builders who rave about it are the ones who tell you to review every diff.
## Where it stops being worth it
The Primer rule is to know your off-ramp before the bill surprises you. Cursor is the right default for fast, in-loop building on small-to-mid projects. Here is when to reach for something else:
- **You mostly want inline completions and are watching cost.** [GitHub Copilot](https://github.com/features/copilot/plans) Pro is $10/mo, half of Cursor, runs inside the editor you already use, and a third-party 2026 benchmark put it slightly ahead on raw accuracy.
- **You want autonomous, scriptable, repo-level or CI work.** [Claude Code](https://www.builder.io/blog/cursor-vs-claude-code) is agent-first and bundled into a Claude subscription you may already pay for, so it can be close to free on top. The common 2026 verdict is to [use both](/primer/vibe-coding-stack/): Cursor to amplify your own typing, [Claude Code to hand off the autonomous runs](/primer/how-to-use-claude-code/).
- **You live in a big, mature codebase.** A 100,000-line project is millions of tokens, far more than any model holds at once, and Cursor adds lag on large files. Lean on tight manual scoping or a CLI agent.
- **You want model choice, the lowest light-use cost, or approval on every change.** Open-source bring-your-own-key tools like [Cline and Continue](https://www.morphllm.com/comparisons/cline-vs-cursor) are free extensions where you pay only for tokens, sometimes a few dollars a day, and gate every edit.
- **You need a different editor.** If you live in JetBrains, Vim, or Xcode, [Windsurf](https://uibakery.io/blog/windsurf-vs-cursor-pricing) now matches Cursor's price and covers more editors.
- **No source code can leave the building.** Even Cursor's Privacy Mode still sends code to the model provider. Air-gapped or regulated work needs a bring-your-own-key tool pointed at a local model; no hosted editor clears that bar.
Cursor is the most mature and pleasant AI editor for building in the loop, and Tab alone can justify the subscription. The credit model is the permanent catch, and the agent is only as safe as your review habit. Drive it on Auto for the everyday, leash the agent, review every diff, and keep one eye on the usage meter. Do that and it earns its place. Forget it and it writes you a bill, or a bug, you did not see coming.
---
# Studio 03 · Tom Huang, Open Design: "Stars are not revenue wearing a trench coat"
Section: The Studio
URL: https://okaneland.com/studio/tom-huang/
Eleven days after Anthropic shipped Claude Design, a Shanghai team shipped the open-source alternative. It has since crossed a million installs on 77,000 stars, and the first build cost about $200. Tom Huang on the file-first method that let agents write all the code, why giving the product away was the plan, and the part no agent can do for you.
*Studio is Okane Land's founder interview series: builders making real things with AI, and the real numbers behind them.*
When Claude Design launched on April 17, Tom Huang's team was building something else: an instant-messaging tool for AI-native teams. They shelved it. Eleven days later, on April 28, they shipped Open Design, an open-source, local-first alternative that routes through whatever coding agent you already pay for. The first version was one person, the CEO, for two days, plus a final twenty-four hours of debugging. Roughly 18,700 lines. The bill was a coding-agent subscription, about $200.
What happened next is the part worth studying. Open Design has crossed a million installs against 77,000 GitHub stars, a ten-to-one ratio that runs the usual funnel backwards, and it did it while charging nothing for the core product. The team is small, ships at a pace that embarrasses companies fifty times its size, and has turned almost the entire daily workload of a midsize engineering team over to AI agents.
This interview is a build manual. Huang lays out the file-first method in specifics, what humans write, what agents write, what gets thrown away, and he is unusually direct about the economics: what it cost, why free was the strategy and not a phase, and where the whole thing would break if one person tried to run it. Open Design is free and Apache-2.0, so there is no MRR chart here. The receipts are build costs, contributor throughput, and an install number that reframes what a GitHub star is actually worth.
A note on independence: we reviewed Open Design before this interview existed, and [that review](/proof/open-design/) is where the relationship started. It ran with a correction we later published against our own error. Nothing in the arrangement changed the read then, and this interview does not soften it now. The skepticism is on the work, never the people.
### The eleven days
**Claude Design launched April 17. Open Design went public April 28, eleven days later. Walk me through those eleven days. Who decided to build it? What did the first 48 hours look like? What was the agent doing while the human slept? For a solo builder, how much of that speed came from team size, and how much could one person with an agent reproduce today?**
When Claude Design launched, we were working on a different product: an IM tool for AI-native teams.
Our thesis was that tools such as Telegram, Discord, and Slack were designed for human-to-human collaboration. In the future, however, collaboration will happen between humans and humans, humans and agents, and often directly between agents. Could an IM tool designed for human collaboration support those new relationships? We thought probably not, so we wanted to build something specifically for human-agent collaboration.
At the same time, we saw major improvements in multimodal understanding, especially images, and in models' ability to generate HTML. We discussed the shift extensively, and our CEO decided to build a demo himself.
The first version of Open Design was built by our CEO alone. He produced the initial product in two days, spent the final 24 hours debugging it, and completed a first release of roughly 18,700 lines of code.
The first 48 hours were spent almost entirely on two things: defining contracts and laying the foundation. The human wrote down the decisions that would force a rebuild if they were wrong: the boundary between the local daemon and the file system, the data contract for agent adapters, and the decision to make the design system a file, DESIGN.md, rather than a feature. Those discussions and judgments occupied the daytime.
Implementation belonged to the agent from day one. As soon as one section of the contract was settled, the agent implemented it. While the human slept, the agent handled work that did not deserve human daytime: generating adapters against an agreed contract, laying down test scaffolding, drafting documentation, and producing localized copy. The first task every morning was to review the previous night's output, discard what failed the bar, merge what passed, and define the next section of the contract.
That speed came from one person building directly with an AI agent, not from adding more people. A solo builder today can genuinely match the construction side of that equation, provided the contracts and validation mechanisms are written into files so the agent can check its own work. What is much harder to match comes after launch: spending the first few dozen hours responding to early users and contributors as a human, at human speed. There is no parallel substitute for that.
### The recipe
**Turn your actual human-agent division of labor into a recipe someone else can copy. Using features such as HyperFrames or Design System Cards as examples, what does the agent produce independently? What do humans insist on writing themselves? What gets thrown away? If a reader wants to ship at your pace, what should they hand to the agent on day one, and what should they never hand over?**
The recipe fits in one sentence: humans write the contracts, agents write the implementation, and validation decides what survives.
Features such as HyperFrames and Design System Cards were produced entirely by agents. It has been a long time since anyone on the team manually wrote code. Virtually all of it, really, 100 percent of it, is written directly by agents. The human reviews the result and then provides the next instruction.
You can read this division of labor directly in the repository. The entry point for any agent, human or machine, is a file called AGENTS.md, and every major directory has its own local version. We do not onboard agents through tribal knowledge passed from person to person. We onboard them through files.
The clearest example is our agent-adapter system. An adapter in Open Design is not a class full of clever logic. It is a pure data object that declares how to communicate with a particular CLI. Detection, launch, and stream parsing are all handled by a shared engine. Humans spent real weeks debating what that contract should look like. Once the contract was settled, integrating a new CLI became a one-file change, the kind of output an agent is especially good at. Give it the CLI documentation and a recorded trace, and it can produce a first draft in an afternoon.
Agents independently produce implementation against established contracts, new runtime definitions, templates and skill variants, localization, test scaffolding, and the first draft of almost everything.
Humans personally own the contracts themselves: the nine-section DESIGN.md schema, the skills protocol, adapter type definitions, review standards, and every security boundary, what the daemon may touch, what the sandbox may render, and what data may leave the local machine.
Humans also cannot outsource their understanding of user needs or their awareness of major technical shifts. They should spend more of their time on two things: talking with users and developing a deep understanding of their needs, and following the latest technology and understanding where the technical frontier is moving. Those two inputs allow a human to form a view of both technology and user demand, and therefore make better decisions when directing an agent.
The part most people miss is validation. Our repository includes replay-based mock CLIs for more than a dozen agents, built from sanitized traces. After writing an adapter, an agent can test it against a "fake Codex" without spending tokens or waiting for a person. An agent that can validate its own work is the difference between fast and chaotic.
On day one, give your agent three things: a written contract, one complete example, and a way to validate the result. Never hand over three things: the contract itself, the security boundary, and taste. Taste is review, and review still belongs to humans.
That is the clearest explanation for our release pace. Version 0.9.0 merged 310 pull requests from 88 contributors in seven days. It was possible because every contributor's agent read the same contract files as our own agents.
> On day one, give your agent a written contract, one complete example, and a way to validate the result. Never hand over the contract itself, the security boundary, and taste.
### The bill
**What does it cost to build and operate Open Design? Give us a rough breakdown of model and agent subscriptions, website and cloud infrastructure, and any other expenses. If someone wanted to build something at this scale, what would the monthly bill look like, and where would costs suddenly spike?**
Building Open Design itself did not cost much. The first version was completed by our CEO alone in two or three days using a coding-agent subscription that cost roughly $200. If you count only the initial build, that subscription was essentially the entire budget. Open Design began as a purely open-source project with no hosted version, so in the first month there were almost no costs beyond that subscription.
For ongoing work, every agent plan we use is on the highest tier. Every one. At our pace, the bottleneck is always judgment and review bandwidth, never model budget. Paying for the best plans has been one of the cheapest decisions we have made.
The prices are public, so readers can do the arithmetic per builder: the cost of a top-tier agent subscription multiplied by the number of builders on the project, plus a hosting bill that is small enough to round off. That is the plain answer to what the monthly bill looks like.
Our costs are concentrated in places most people do not expect. They are not in serving users, because users run their own agents. They are not in routine testing either. Our regression suite replays recorded sessions through mock CLIs across fifteen agents at zero token cost. We use real agents only when they are worth the expense.
We also attack the cost curve inside the product. Version 0.15.0 reduced design-system input tokens by one quarter and cut end-to-end generation time by one fifth. The same change lowered both the user's bill and our own testing cost.
The real cost spikes come from evaluation. Whenever we need to align behavior across more than twenty supported CLIs, we must use real agents, because consistency is the one thing a mock cannot prove.
Ongoing operations also create labor costs: community work, publishing on X, and product planning. The size of that cost depends on how the work is organized and how much is automated. If product planning, publishing, and community operations can be automated further, the cost can continue to fall.
We later added a cloud service, but the infrastructure cost remains relatively low. The token-based service exists mainly so people without a coding agent or a BYOK setup can use the product smoothly, not so that we can profit from a model markup. We do not add a spread; the associated cost is covered by what the user pays.
So here is a budget recommendation without attaching our invoices: spend money on the best agent plans, and make validation free as early as possible with mocks, replays, and golden files. Otherwise, the meter will eat you. Before accepting inference as a cost of serving users, ask whether your architecture can turn it into the user's asset rather than your liability. That question is worth more than any isolated budget number.
### What a star is worth
**Everyone can see the star count, but no one can see the funnel. What did tens of thousands of stars actually turn into: installs, weekly active users, or cloud registrations? For a builder considering open source as a distribution strategy, what can stars genuinely buy, and what do people mistakenly think they buy?**
Start with one number we can disclose, because it overturns the premise of the question: 77,000 stars and more than one million installs.
Most people imagine a funnel in which stars narrow down into users. Ours runs in reverse. Installs are an order of magnitude higher than stars. Most of our users have never starred the repository; many have never visited the repository page. They arrived through package managers, word of mouth, a colleague's recommendation, or an AI assistant naming the tool when asked for a recommendation.
We are keeping weekly-active and cloud-registration numbers private for now. They are early and fluctuate week to week. Rather than narrate every movement, we would rather disclose them formally when the time is right. What we can say is that the real drop-off happens between install and weekly use. That is where the real work is, not at the star end of the funnel.
In our experience, stars buy four things.
**First, credibility**, and credibility converts into other assets. Journalists answer your email. Contributors submit a first pull request. Enterprise evaluators do not immediately close the tab.
**Second, contributors.** This is the conversion path almost no one measures. Version 0.9.0 alone merged work from 88 contributors, and a meaningful share of them came through the repository's star-driven visibility.
**Third, search and AI visibility.** A highly starred repository gets cited, linked, and named when people ask models for tool recommendations. That is distribution that compounds while you sleep.
**Fourth, option value.** Stars represent an audience you can reach again for free, because every release can be broadcast to them.
What people mistakenly believe stars buy is users. A star is fundamentally a socially visible bookmark. It costs one click, and its relevance may expire immediately. Statistically, many people who star a project during its breakout week never run the product.
Our numbers prove the point in reverse: the product has traveled ten times farther than its star count because installs move through channels that stars never reach. If your business model needs active users, the real work begins after the star: first-run experience, documentation, and a reason for someone to return on Tuesday.
Our advice to a builder considering open source as distribution is this: if contributors, credibility, and default-option status are assets your strategy can monetize, as with our Cloud and team plans layered on top of a permanently free local product, then do it. But do not imagine that stars are revenue wearing a trench coat. Stars are attention. The product must convert that attention, and the conversion rate is never printed on the star page.
> Do not imagine stars are revenue wearing a trench coat. Stars are attention. The conversion rate is never printed on the star page.
### Giving it away
**You chose BYOK and local-first, allowing users to run the agent subscriptions they already pay for instead of selling them another subscription. That means giving up the easiest revenue. For a small team, when is "giving the product away" the right choice, and when is it a trap? What role does Open Design Cloud play, and what has early monetization looked like?**
Start by calculating the real cost of charging a subscription. Every closed-source design tool in this category charges per seat: one Pro plan here, one Team plan there. But our target user already pays for agents. They have a Claude Code plan, a Codex plan, or a Cursor plan. Requiring another subscription before they can even evaluate Open Design is not a revenue strategy. It is putting a security guard at the front door.
BYOK removes that guard. Any of the 22 CLIs we support, or any OpenAI-compatible endpoint, can unlock Open Design. The subscription the user already owns becomes our distribution channel.
When is giving the product away the right choice? Three conditions must all be true.
**First, marginal cost must be close to zero.** With BYOK, inference runs on the user's own plan, so free users do not consume our margin.
**Second, the free product must create an asset that compounds.** Every DESIGN.md written, every skill shared, and every plugin published makes the ecosystem more valuable. That asset belongs to the commons, not to our income statement.
**Third, there must be a natural upgrade moment** that does not have to be manufactured.
If any of those conditions reverses, free becomes a trap: free usage burns your own compute; you open-source your only differentiation and have nothing left to sell; or the upgrade path works only by crippling the free version.
Open Design Cloud is our answer to the third condition. It is a convenience layer, not a paywall. Some people have never configured a CLI and never want to. Cloud gives them one login, more than twenty flagship models, and usage-based token billing. No local-product feature is held hostage by it.
The next layer is more interesting. We are testing a team workspace that provides shared brand assets, project drafts, and team comments on top of the same open foundation. Individuals who bring their own key remain free forever. Teams that want a hosted shared space receive something genuinely worth paying for. The product currently generates stable positive cash flow.
The summary is that we gave up the easiest revenue in exchange for the hardest asset to earn: becoming the default option in agent-native design. A subscription model can be copied next quarter. Default status is much stickier.
### Alternative, not copy
**You turned Open Design into an open-source alternative to a frontier-lab product and reached a high level of completeness very quickly. Technically and ethically, where is the line between a clean-room alternative and a copy? What makes an alternative legitimate rather than derivative? How do you think about building in a category Anthropic defined just eleven days earlier?**
A copy reproduces the other product exactly. The line between an alternative and a copy is not speed. It is what you took.
A category is not property. "Agents should be able to do design work" is an idea, and bringing an idea into the world is the point of launching a product. Implementations are property: code, assets, weights, and internal architecture. We took the former and never touched the latter. Claude Design is closed source; there was nothing for us to copy even if we had wanted to. We could see only what any user could see: a public product's external behavior. Studying public behavior is called competitive analysis in every industry on earth.
The strongest technical evidence that we are an alternative rather than a copy is that we keep disagreeing with the original. A derivative cannot do that; it inherits the original's decisions. At almost every fork, our decisions went in the opposite direction.
Claude Design runs in their cloud. Open Design runs on your machine, with a local daemon managing your files. Claude Design charges by subscription tier. We use BYOK and support 22 agent CLIs plus any OpenAI-compatible endpoint, because the agent you already pay for should be the engine.
Their design system lives inside their product. Ours is a nine-section DESIGN.md in your repository, compatible with any agent, including theirs. The entire project is licensed under Apache 2.0. Tracing someone else's work cannot produce an architecture that points in the opposite direction.
That is the central distinction between Open Design and a copy: we do not force users into our subscription. We offer choices. Users can select different models and reuse their existing BYOK and CLI setup. We believe design capability should not be tied to one model company. It should belong to any person and any company. People should be free to create with different models and coding agents instead of being locked to one.
Ethically, we ask ourselves three questions. First, did we take an implementation we had no right to take? No, because there was no implementation available to take. Second, did we mislead anyone about the source of the category? No. The first paragraph of our launch post named Claude Design. We exist because it existed, and we acknowledged that from day one. Third, does our existence make the category better, or merely cheaper? We believe an open, local, model-agnostic implementation turns agent-native design into something the entire ecosystem can own rather than something rented from one vendor. That is a contribution, not a discount.
As for building in a category a frontier lab defined eleven days earlier: that is exactly why open source exists. Closed products prove demand; open implementations turn demand into infrastructure. Frontier labs open categories; communities make those categories permanent.
Anthropic proved that design can be agent-native. Our wager is that agent-native design should also be user-owned. Those two wagers differ enough that either side can fail independently without taking the other down. That is the real test of an alternative: it can fail in its own way.
### Could one person run it?
**Relative to the size of its core team, Open Design is unusually large: 77,000 stars, thousands of issues, and nearly a hundred contributors involved in each release cycle. Run a thought experiment. Could one person operate it today? What would break first, issue triage, community, or release cadence? Where do agents genuinely replace headcount, and where do they merely assist?**
One person can operate Open Design, provided the work is turned into automated skills or plugins and those systems run at the right time. One person can keep Open Design building and operating, although some parts will slow down depending on how that person understands and prioritizes the work.
Let us actually run the experiment. On day one, the solo operator takes over the repository. More survives than most people expect because the project's operational knowledge lives in files rather than in people's heads. Every directory has its own AGENTS.md, so any agent, including a contributor's agent, can onboard itself.
The mock-CLI test system can replay recorded sessions from fifteen agents at zero token cost, so regression testing does not require a separate QA team. Adapters are single-file data objects, so a significant share of incoming pull requests can be reviewed mechanically against a contract. One person plus agents can keep the software alive: merging routine fixes, shipping releases, and updating an adapter when a CLI changes its stream format.
Our community pull-request workflow is one example. An internal automated looper evaluates whether a community PR is necessary. If it is necessary, the system moves it forward quickly toward merge. If it is unnecessary or problematic, the system opens a discussion with the author. Those steps are automated. That helps us involve nearly a hundred contributors in each release and use the community's combined effort to build Open Design quickly. On average, we can merge a pull request in less than half a day.
Agents genuinely replace headcount in code production, localization, test scaffolding, issue triage, documentation, and regression testing, almost the entire daily workload of what used to be a midsize team. They only assist with contract design, security boundaries, community judgment, and taste. Those are exactly the four things we never hand to agents, which suggests the boundary is real rather than habitual.
The arithmetic for a solo builder is that agents allow one person to operate something that would have required an eight-to-ten-person team a few years ago, but only if the project is designed that way from day one. Contracts must live in files. Validation must be runnable by agents. The architecture must make most contributions mechanically verifiable.
That does not mean every part can maintain the same speed under one-person operation. At scale, community response and decisions that require human accountability remain bottlenecks. An agent can answer questions and perform triage, but it cannot decide whose pull request deserves attention, which direction should receive support, or accept responsibility for saying, "This release will not embarrass us." Agents reduce the minimum human headcount, but they do not reduce it to zero.
### The ByteDance lessons
**Before becoming a founder, you worked on agent platforms at ByteDance, including Coze and Aily. What did building agents inside a large company teach you that solo builders most often get wrong? Conversely, what did the large-company approach itself get wrong, what did you later have to deliberately unlearn?**
What large-company agent work taught me comes down to an unfashionable word: reliability.
On a platform at that scale, an agent feature cannot ship simply because the demo works. It must survive evaluation, regression testing, and replay against thousands of recorded sessions. At that scale, edge cases are not rare events. They are an ordinary Tuesday.
This is where solo builders most often go wrong. They treat validation as something to add after product-market fit, when validation is actually what makes iteration speed possible. The mock-CLI system in the Open Design repository, which replays agent sessions at zero token cost, is the most "big company" part of what we built, and I make no apology for it.
The other lesson is protocol thinking. When many teams integrate with your platform, you learn quickly that the interface itself is the product. A sloppy contract creates a debt that costs a hundred times more later. That is why our agent adapters are data rather than code, and why humans on the team spend their time debating contracts while agents write the implementation.
What I had to unlearn is harder to admit. A large platform is a gravity well. Its instinct is to own everything: the model, the runtime, the data, and the user's entire workflow. Ownership is how platforms measure themselves.
It took me time to see that what feels like ambition from the inside looks like a cage from the outside. Open Design is largely a list of things we decided not to own: not the model (BYOK), not the runtime (your machine), not the files (your repository), and not even the agent (bring whichever one you already pay for).
The second thing I had to unlearn was our relationship with time. In a large company, a quarter is the smallest unit of ambition, and consensus is a tax on every decision. The eleven-day sprint felt almost like an exorcism. Once agents took over production, many of the old reasons why work "had to be slow" quietly expired. The remaining bottleneck was how quickly a small group of people could persuade one another. When the group is small enough, that can happen very quickly.
> A large platform is a gravity well. What feels like ambition from the inside looks like a cage from the outside. Open Design is largely a list of things we decided not to own.
### Vibe coding vs vibe design
**Open Design argues that the important distinction between vibe coding and vibe design is not simply whether a chat window can generate a mockup, but what you actually own after the demo ends. Why is generating a design image not enough? By month six of a real project, what has "owning the files" changed? How should someone currently satisfied with chat-generated mockups change their workflow this week?**
There is a simple test: close the chat tab and try to use what you just made.
A mockup inside a chat window is essentially a screenshot of a decision. It looks like progress, but you cannot diff it, version it, or hand it to a teammate. Next week, you must prompt from scratch just to return to the point you already reached today. The demo was the entire output, and the demo is over.
Owning files reverses that situation. Everything Open Design produces is real CSS, real fonts, and real components stored in your own file system.
The design system is itself a file: a DESIGN.md with nine sections that encode color, typography, spacing, components, and even anti-patterns into a brand contract any coding agent can understand, the same file-as-contract idea that runs through [the vibe coding stack](/primer/vibe-coding-stack/). That file is the difference between "generate something attractive" and "generate the next thing that belongs to this brand."
By month six, the compounding effect becomes overwhelming. Your Git history is your design history. When the brand evolves, you update one contract file and regenerate instead of explaining the brand to a chatbot for the hundredth time.
When something is wrong, you can click the element and make a surgical edit rather than watching a full regeneration destroy the 90 percent that was already correct. Because files are the shared substrate, collaboration happens naturally. Team members can share the same DESIGN.md through Git while each uses a different agent, whether Codex or Claude Code, to drive it.
We are now testing a team workspace that extends this foundation by allowing brand assets, project drafts, and team comments to be shared directly inside Open Design.
The change you can make this week is simple: stop treating the chat window as your workspace. Create a repository, put a DESIGN.md inside it, and have the agent write files there.
Vibe coding optimizes for the instant when a demo impresses someone. Vibe design optimizes for the following morning, when the project becomes real and you must live with what you own. Whether the method itself pays, beyond the demo, is [its own question with its own receipts](/study/is-vibe-coding-worth-it/).
### The weekend build
**A reader finishes this interview tomorrow morning with a Claude Code subscription, a free weekend, and an urge to build "something people will star." From a team that ships at your pace, what should they copy from your way of working? What should they absolutely not copy? If you were starting from zero today, alone, what would you do first?**
Start with one essential principle: once you have an idea, use an agent to build the smallest viable MVP and put it in the market for validation instead of leaving it as a thought experiment.
More specifically, copy three things. All three fit inside one weekend.
**First, write the contract before the code.** Put an AGENTS.md at the root of the empty repository. Explain what the project is, where the boundaries are, and how a change is validated. It takes thirty minutes, but every hour the agent works after that compounds instead of wandering.
**Second, before assigning work, give the agent a way to check itself:** one test command, one replayable example, and one golden file. The biggest dividing line between teams that ship with agents and teams that are dragged down by them is whether validation is the agent's responsibility or the human bottleneck.
**Third, copy our division of labor:** humans own the contracts, boundaries, and taste; agents own implementation and first drafts. For a weekend project, that means spending Saturday morning thinking and writing natural language rather than TypeScript. It feels wrong, and it is right.
Do not copy our pace. The eleven-day sprint worked because a category had just been proven and the window was open. That is a story about timing, not a work ethic worth imitating. Sprinting that way without the same reason is the standard way a weekend project dies on Monday.
Do not copy our scope either. Our starting point sat at the intersection of things we had worked on for years. Your intersection will be different. Copying our product instead of our method would turn you into the kind of derivative we refused to become.
If we were starting alone today, we would look for the gap discussed throughout this interview: a closed product that has just proven demand but does not let users own what it gives them. Pick one, and pick a small one. Do not build another design tool; that position is occupied, and it is occupied by us.
The transferable recipe is this: find a demo everyone loves but cannot keep, and build a version the user can truly own. Then do the unglamorous work. The stars everyone sees were not earned during the weekend of construction. They were earned in the months afterward by responding to issues quickly, publicly, and like a human. An agent cannot fully substitute for that part, and that part is the moat.
> Find a demo everyone loves but cannot keep, and build a version the user can truly own. Then do the unglamorous work.
*Tom Huang is [@tuturetom](https://x.com/tuturetom) on X, and this interview was coordinated with [Koki](https://x.com/kokisanai).*
---
# Studio 02 · Gabriel Amzallag: "I only build it if someone pays"
Section: The Studio
URL: https://okaneland.com/studio/gabriel-amzallag/
Five years of conversion work inside Qonto, then out alone with Web Anatomy: a library of what actually converts on landing pages, built in public, every line written by an agent. The roadmap has one rule, nothing gets built until someone pays. The first someone paid €99.
*Studio is Okane Land's founder interview series: builders making real things with AI, and the real numbers behind them.*
Gabriel Amzallag put up a pricing page for a feature that did not exist. Real price, a "book a demo" button, and a rule: he would only build it if someone paid. Someone did. €99, for the custom benchmark report he used to assemble by hand for consulting clients.
That sale is his whole method in miniature. Amzallag spent about five years running conversion experiments inside Qonto before going out on his own, and he is not a developer. Every line of [Web Anatomy](https://webanatomy.ai) is agent-written, on a stack that runs about €150 a month. The one thing the agent never touches is the judgement: what counts as a good page, what goes in a benchmark, what anything costs.
Most founder interviews arrive after the chart goes up and to the right. This one is earlier on purpose. Web Anatomy is in the validation phase, real traffic, real signups, a business model still taking shape in public, and Amzallag answered everything, including the parts most builders skip.
### The problem worth building
**You spent about five years doing conversion optimization inside Qonto, then went freelance, then built Web Anatomy. What made the recurring problem worth turning into a product?**
I was already doing this by hand. Same report for every client: here are the sections worth copying, here's where your UX breaks, here's what good looks like. Two things pushed me to build it. The work was identical every time, so it begged to be done at scale. And I kept watching agencies sell beautiful design that didn't convert. I had the library of what works in my head. Web Anatomy is that library, made accessible.
### Why AI pages read generic
**Your thesis is that AI ships generic landing pages because it averages its training data. Make the case to someone who thinks AI-generated pages are already good enough.**
Two problems, stacked. 1/ The design: emojis in the headings, rounded cards, beige and purple, everything looks the same. 2/ The AI copy on top: em-dashes everywhere, the fake "we don't do X, we do Y," the three-step enumeration for everything. That structure feels smart to the model but it exhausts the reader. You end up with a page nobody wants to read.
### Pre-selling the feature
**You put up a pricing page for a feature that didn't exist, with a real price and a "book a demo" button, and told yourself you'd only build it if there was real traction. Then you got your first €99. Walk through exactly what happened, and the step by step for a reader who wants to validate demand before building.**
I put up a pricing page for a feature that didn't exist, or only partially. I put a real price, a "book a demo" CTA, and a rule: I only build it if someone pays. Someone did. €99. What I sold was a custom benchmark report, the thing I'd done by hand for clients.
The steps:
- Write the pricing page (any landing page can do the job) to test a value proposition
- Ask for an email to contact users back
- Send real traffic
- Call the users who submit the form to understand their pain
- Deliver exactly what you promised
- Then see how to automate it
The page is the cheapest version of the product, and you can win months by doing that.
### Saying the quiet part
**You posted, plainly: "I have traffic. I have signups. I have no business model." Most builders live in that spot and never say it out loud. What did that moment feel like, and what changed first?**
I posted it because I wanted to be honest with my community. I like build in public, and it has to include the things you are not proud of.
What I changed first was the question. I stopped asking "how do I get more organic traffic" and started asking "what would one person pay me for today." Just a different metric.
### What to give away
**The hardest part of your model: the skills pack and the library are free, but the MCP server and copy-to-site features are moving behind €9 and €19 a month. How do you decide what to give away when the thing you're known for is the free part?**
That's the hardest part, and I don't have a clean answer. I don't decide up front. I talk to users, try things, and watch whether anyone actually subscribes. When you iterate with AI you can just try fast and let people show you. The rough rule underneath it: free is what earns trust, paid is what saves time. But I found that by shipping.
### The stack, and the line the agent can't cross
**You build Web Anatomy largely with AI agents. Give me the real setup: the tools, what it costs a month, and where you refuse to let the agent decide.**
I'm not a developer. All of it is agent-written. My stack is cheap: Supabase €20, Vercel €20, Claude Code €90, Firecrawl €20.
Where I refuse to let the agent decide: anything a user pays for or reads as my judgement. Pricing, what goes in the benchmark, the copy on the site, and any published scoring.
The agent can write the code that runs a scoring pass. It doesn't get to decide what counts as a good page. That taste is the product.
> The agent can write the code that runs a scoring pass. It doesn't get to decide what counts as a good page. That taste is the product.
### The human in the loop
**Your methodology keeps a human in the loop: you review every published analysis rather than fully automating the scoring. Feature or bottleneck?**
I've automated most of it. A script pulls 200 new sections a week from top websites. But I review every one before it imports. That's the step I keep. The quality lives in the database, and that's the whole wedge. The day I stop reviewing and trust it 100%, the product has nothing underneath it that a well-prompted model doesn't.
### What the data showed
**Give me a finding from your data that surprised you.**
AI pages are worse on copy than normal ones. What happens is companies reach for "AI" in the hero as a shortcut for copywriting. It feels like a selling point, so they lead with it instead of doing the harder work of saying what the customer actually gets. And it makes the copy weaker every time.
I looked at 551 screenshots across 13 big, famous homepages over two years, and most of them tried putting "AI" in the hero. Most of them rolled it back. Grammarly, Webflow, Semrush all led with AI and quietly returned to plain benefits. The ones that never blinked, Canva, Ramp, HubSpot, kept the same promise the whole time (you get more done, you win more customers) and let AI make that promise truer underneath.
So the lesson: "AI" is not a value prop. "You get more clients" is. Sell the outcome in the hero and let AI be the reason you can deliver faster and better.
*Gabriel's full write-up of the study is [on his Substack](https://gabrielamzallag815268.substack.com/p/how-to-adapt-your-homepage-with-ai).*
### Whether the moat holds
**You're building a business where the product is partly taste, the curation an AI can't replicate. What do you say to someone who argues a well-prompted model closes that gap in a year?**
You said it in the question: a well-prompted model can do this. That's the catch, "well-prompted." Most people can't give the agent the right context. And left alone, the agent is lazy. It takes the path of least effort, won't go dig for the best answer, and hands you the cheapest generic thing it can produce. The gap isn't the model getting smarter. It's the work of getting the right context, and that's the work I've already done.
### The wrong take
**One popular belief about AI and web building that you think is flat wrong?**
That AI makes SEO an easy game.
I worked on SEO for years. Now AI makes content trivial to produce, which is exactly why it stopped working. Spinning up hundreds of AI-generated pages a month, especially on a new domain, is the fastest way to get penalized.
Publish a few strong pages a week instead, and earn authority first. Taking it slower at first has a greater impact in the medium term.
---
*Gabriel Amzallag builds [Web Anatomy](https://webanatomy.ai), a data-backed library of what converts on landing pages. He was in-house on conversion and SEO at Qonto for five years, posts on X as [@gabrielamzallag](https://x.com/gabrielamzallag), and writes the [Web Anatomy newsletter on Substack](https://gabrielamzallag815268.substack.com/).*
*In August we put Web Anatomy's free tier through a full hands-on test, without Gabriel's involvement: [the Proof verdict is here](/proof/web-anatomy/).*
---
# Studio 01 · Steven Hylands: “Build judgement, not the thing you've already got”
Section: The Studio
URL: https://okaneland.com/studio/steven-hylands/
Stora co-founder Steven Hylands on 10,000 pull requests, a quarter of them in the last six months, and why judgement is the one skill AI can't hand you.
*Studio is Okane Land's founder interview series: builders making real things with AI, and the real numbers behind them.*
Steven Hylands is a designer and co-founder of [Stora](https://stora.co), the self-storage software platform he's spent five years building. He's also one of the sharper voices writing on AI and work, the person behind [“The Death of the Pixel Pusher”](https://shylands.com/writing/the-death-of-the-pixel-pusher/) and the [AI Honesty Badge](https://www.aihonestybadge.com). His codebase just crossed 10,000 pull requests, and nearly a quarter of them landed in the last six months. We asked him what AI actually changed, what it didn't, and what a vibe coder should build first. He didn't hedge.
### The arc
**You call yourself a founder and designer in Belfast writing about AI and work. How did interactive multimedia design lead to running self-storage software, and to some of the sharpest essays going on AI?**
It started long before university. As a teenager I was just making things for fun on the internet, building websites, messing about, working out how it all fit together. Studying interactive multimedia design was really the formal version of that same instinct, a bit of everything, design and code and whatever the thing needed. Then at Stora I ended up doing all of it for real, design, code, sales, marketing, customer success, not by choice but because I had to. Starting a business has a funny way of handing you quick experience across a lot of different mediums. But the thread through all of it isn't any one skill, it's that I tend to be the person who spots when something's misaligned or could be done better, and I've never been able to accept that something's right just because that's how it's always been done. Taking a step back and asking why is a core product design skill, and it's the same instinct behind the writing. I've always enjoyed writing, I just felt for years like I had nothing interesting to say. It's only now, with enough experience behind me and enough trying to do things differently, that I feel I finally do.
### The failure that taught the most
**Give us the one failure that taught you the most, and the specific rule you now follow because of it.**
The lesson that cost me the most: solve a problem painful enough that people will pay to make it go away, and make sure they've actually got a budget to spend on it. Lowdown taught me that. It got into an accelerator and every external signal looked good, and it still didn't work, because the problem simply wasn't painful enough for anyone to prioritise paying for. So now that's the first thing I pressure-test on anything: is the pain real, and is there money already assigned to fixing it? If both aren't true, you're pushing uphill no matter how good the thing you've built is.
### The workflow
**In “The Death of the Pixel Pusher” you wrote that after twenty years you barely open Figma and shipped a whole Stora onboarding flow straight in the codebase. Walk us through the workflow: what tools, in what order, and where a reader should start.**
Honestly the order of tools is the least interesting part, and I'd push back on the question a bit. The thing that actually mattered was five years of running Stora, talking to hundreds of customers, knowing what they care about, understanding what sells the product and not just what to worry about during onboarding. Even having the idea to build it the way I did came from that context. The tools only work because of what's underneath them.
The AI side came from pushing myself to explore these tools relentlessly and never stopping shipping pull requests in the app, even when I was doing things I technically didn't understand. Probing the limits, working out what my engineering team would accept and what they wouldn't.
For tooling it's mostly Claude Code, and [the Claude Code Mac app has become my favourite way to work](/primer/how-to-use-claude-code/) with it. I still drop into Cursor when I need to dig into the code, but I need that less and less as the tools get better at the abstract, chat level and hands-on digging matters less. Most of my time actually goes on building the plan, getting things to the point where Claude Code is ready to run. Once it produces something, it's back to judgement: looking at the execution, judging it, iterating. One habit I've picked up: whenever something repetitive is worth reusing, I turn it into a skill and keep it updated for the wider team.
Where should a reader start? Not with the tools. Start with the context and the judgement, the part AI can't hand you, then get your hands dirty and don't stop shipping even when you don't fully understand yet.
### Which to build first
**Your trifecta is thinking, judgment, and implementation. For a vibe coder who isn't a twenty-year design veteran, which do they build first, and how, this month?**
A vibe coder already has implementation. So don't build the thing you've already got. Build judgement: the ability to look at what you shipped and know whether it's actually any good, not just whether it runs. That's the scarce one, and it's what stops you flooding the world with plausible rubbish. There's no real shortcut. You build it by shaping and learning, and this month that looks like shipping one real thing to real people and studying the best work in that space until you can see the choices behind it. It also helps to have experience across different domains, because they collide in useful ways and let you judge things from angles other people miss.
> Don't build the thing you've already got. Build judgement.
### Building taste in 2026
**You argue taste is what separates people who use AI well from people who just use AI. Give a reader three things they can do to build taste in 2026, when AI is removing the reps that used to build it.**
Study great work like a mechanic, not a fan, take the things you admire apart until you can name the exact choices that make them good.
Ship real things to real people and watch what actually lands, not what you hoped would.
Find one or two people whose judgement you trust and let them tell you fast when your work isn't good enough.
The catch in 2026 is that AI removes the reps that used to build all this, so you have to manufacture them deliberately. Do the hard version on purpose.
> Study great work like a mechanic, not a fan.
### Disclosing AI use
**You built the AI Honesty Badge, and your blog is the featured site on the wall. What's the case for a builder disclosing their AI use, and what would you tell someone who thinks staying quiet is smarter?**
The case is trust. We're already in a world drowning in AI output. Most of us are using AI to write these days whether we say so or not. A lot of the time it's obvious, especially when someone hasn't put much effort in. I've had plenty of moments where someone on my team handed me something that immediately felt off, AI output passed along without the domain knowledge to judge it first, and it made me think less of the work, not more. You can't really hide it, so you may as well be honest about it. That's what I built the AI Honesty Badge for, a simple way to say how much AI was actually involved. And to anyone who thinks staying quiet is smarter: being caught pretending you did it all by hand is a worse look than just owning the tools.
The more interesting question underneath is how much of your brain went into it. The words on the screen are mostly AI's now, for most of us, most of the time, so what actually matters is the thinking that drove them. You're really vouching for the brain behind the words, not the typing, and that's what a reader is deciding whether to value. The label is a start. You earn the rest of that credibility in other ways.
### The first task to automate
**“Someone is going to automate your job, make sure it's you.” Name the first task a reader should automate this week, how you'd build it, and how to find the time when the day job is always louder.**
The first task is likely different for everyone. It might even be that you don't have a task worth automating right now, and that's fine too. But if you find yourself doing the same repetitive thing every day or every week, that's where to start. For us at Stora the first real move was [putting an AI support agent, Fin, onto front-line support](/study/do-ai-agents-work-yet/). It showed how much AI can handle when it's armed with the right knowledge, and it quietly flipped the job: support stops being about answering the same question for the hundredth time and becomes about the systems and documentation that feed good answers. That's the pattern to look for, automate the repetitive answer, then move up to owning the system behind it. Start rough, one task and one hour, aiming for good enough to save you the next ten times. The point isn't automation for its own sake, it's freeing up time for the deep work, and the time is the hard part, because the day job is always louder and nobody hands you the hour. So you steal it.
### The Stora number
**Stora is in a boring, real-money industry. What has AI actually changed about the economics, and what's one number that's measurably different than two years ago?**
It's really only since the start of this year that we properly moved to an AI-native way of engineering across the whole org, so this is still early. The number I find striking is the shape of it. We've crossed 10,000 pull requests in the Stora codebase over the life of the product, and roughly 23% of them, nearly a quarter, landed in just the last six months. That recent spike is the AI part. But it hasn't been a free win. When AI writes far more of the code, the bottleneck shifts to review, so we now spend a lot more time on the spec and the thinking up front, and a lot more on reviewing what comes out. The cost didn't disappear, it moved onto judgement and review, which is exactly where you want your most experienced people. It helps enormously that we've got a lot of senior engineers who understand what they're trying to do. Try this with a less experienced team and I don't think it goes nearly as well.
> The cost didn't disappear, it moved onto judgement and review, which is exactly where you want your most experienced people.
### Do the side projects earn?
**Your side projects are out in the open: the AI band, the Honesty Badge, the blog. Do any of them make money, and should a builder expect projects like these to earn, or is the point something else?**
None of them earn, and honestly none even have a mechanism to earn. Here's the funny part: my number one rule is to validate that a problem is painful enough, and funded, before you build anything, and with these I break that rule completely, on purpose. They're not businesses, they're creative exploration, following my curiosity, keeping my skills sharp, having fun seeing what's possible. If I were freelancing or out of work I'd snap straight back to the rule and obsess over proving someone would pay before I built a thing. But my money-earning time already goes to Stora, so these get to just be fun. I know the trap, that building is enjoyable enough to let you dodge the hard question of whether anyone actually wants it. With a side project, that's allowed. That's the whole point of it.
The more interesting thing I've noticed is with the tools I build just for myself and never publish. I'll start out thinking maybe this could be a product, and then as I keep tailoring it to exactly how I work it becomes hyper-personalised, useless to anyone but me and perfect for me. I've got several little Mac apps like that. I think personalised software is in its infancy, and once you get in the habit of building your own tools it genuinely changes how you think about build versus buy. I still buy plenty of software, but for some things a tailored alternative I've built myself is just better. I'm curious how that shifts over the next few years.
### A wrong take on AI
**What's a popular take on AI right now that you think is flat wrong, and what should people do instead?**
That AI levels the playing field, that now anyone can build or write or design and expertise doesn't matter any more. It's backwards. AI makes taste and deep domain knowledge more valuable, not less, because it'll happily hand you something plausible and confidently wrong, and only experience can tell the difference. Give these tools to someone without the foundations and they don't produce great work faster, they produce work slop faster, and everyone around them can tell. AI is going to make people who aren't great at their work still look not great at their work, just faster. Use it to go deeper in the thing you actually know, and treat judgement as the skill worth protecting. It's the one thing the model can't hand you.
> AI is going to make people who aren't great at their work still look not great at their work, just faster.
---
*Steven Hylands co-founded [Stora](https://stora.co). He writes about AI and the future of work at [shylands.com](https://shylands.com), built the [AI Honesty Badge](https://www.aihonestybadge.com), and posts on X as [@shylands](https://x.com/shylands).*
---
# Rank Prompt on the free plan: it scored our AI visibility at zero, and by hand we found citations on two of eight questions
Section: The Proof
URL: https://okaneland.com/proof/rank-prompt/
Before we opened an account we asked Perplexity and Google AI Mode eight questions our readers ask, and wrote down every source they cited. Then we let Rank Prompt run its free report on the same site. It said zero percent, on nine questions it wrote itself. Both results are correct, and the gap between them is the whole product: an AI visibility tool measures the questions it chooses, and the free plan chooses questions a small site cannot win.
## How we tested
An AI visibility tool sells a number. The only way to test the number is to know the answer first. So before the account existed we measured our own site by hand.
We wrote eight questions our readers ask, each one with a page on this site that could answer it, and typed them fresh into Perplexity, signed out, and Google AI Mode, signed in. For every answer we read the engine's own source list and wrote down every domain. That is the ground truth in the kit: 8 questions, 2 engines, 16 answers, every cited domain named. ChatGPT was meant to be the third engine and never rendered a search answer signed out on two tries, so it is not in the baseline.
Then we gave Rank Prompt the bare domain and let it do what it does. The gates were fixed with the fixture: a live report at $0 with no card, what the report contains and how its questions are chosen, precision and recall against the baseline where the credits allowed, whether the competitors it names are plausible peers, whether its action plan repeats the schema myths we have already researched and dropped, where the trial wall sits, the price and refund terms, and what the policies say about your data.
## The door
Sign-in is a Google account. Onboarding is a chat with an assistant: who are you, what is your website, then "reading your site now." Its read of okaneland.com was accurate to a degree we did not expect. It listed the six sections by name, quoted the editorial standard, identified the author as a pen name, described the newsletter, and proposed ten categories. Nine minutes after the homepage, we were looking at nine questions it had written.
That is where the test really begins, because the questions decide the number.
## The nine questions it wrote
Every one of the nine is a request for a recommendation. "What are the most recommended independent publications for hands-on AI tool reviews and cost comparisons?" "Which independent publications offer practical vibe coding guides for building products with AI?" "Can you recommend research publications that examine the real costs, workflows, and business results of AI for solo founders?"
These are the questions a brand-tracking product has to ask, because its headline metric is whether an assistant names your brand. They are also questions no assistant answers with a nine-month-old independent site. It ran them on ChatGPT, Claude and Google's AI Mode, 27 answers in about four minutes, and reported the result with a label: Emerging. Visibility 0 percent. Citations 0 percent. "AI named Okaneland in 0 of 9 questions on at least one platform. 0 of 218 sources it cited were your site."
Set that beside the baseline. On the questions readers ask, both engines cited okaneland.com for two of eight: the Perplexity Pro limits study, and the study on what a ChatGPT citation is worth, where Perplexity listed our page first. On the other six, neither engine cited us and the tool would have been right to say so. Two measurements of the same site on the same afternoon, zero and two of eight, and neither is wrong. They are answers to different questions.
The words matter here. In Rank Prompt's vocabulary, visibility is your brand named in the prose of an answer, and citations are your pages in the answer's sources. A small site earns the second long before the first. The free report's questions are built to measure the first.
## The same question, both ways
The free account arrives with ten credits. The first report spends nine. We spent the tenth on one of our own questions, the Perplexity limits one, across the four engines the standard bundle covers.
The result page said visibility 0 percent, citations 7 percent, and the citations tab explained it: two of 29 citations across the four answers were our study, labelled "Your Site," with the Reddit thread that links to it cited twice more. Claude and Perplexity Sonar had both cited the page. ChatGPT had cited only Perplexity's own help center. AI Mode's five sources included the Reddit thread and not our page, while our own AI Mode run minutes earlier had our page among eight sources. Engines vary between runs, which is a reason to track over time and a reason to distrust any single reading, including ours.
So on the one question we could afford, the tool found what we found. That is the product working. It is also the product you cannot use on the free plan, because the credit that bought it was the last one.
## What stands behind the engine names
The create-report form is the most useful page in the app, because it says what "ChatGPT" means. The standard bundle, one credit per prompt, is ChatGPT 5.6 Luna, Perplexity Sonar, AI Mode and Claude Haiku 4.5. The premium tier, an extra credit each and locked on the free plan, is ChatGPT 5.6 Terra, Grok 4.20, Gemini 3.7 Flash and Claude Sonnet 5.
Read that as a buyer. A report that says you are invisible on ChatGPT has asked the cheapest model on OpenAI's API, which is not the model a person gets in the ChatGPT app. It is a reasonable engineering choice at a credit a prompt. It is not the same thing as your visibility in ChatGPT, and the report page does not say so.
## Competitors, sources and the plan
The competitors tab lists 129 "businesses" named across the 27 answers. The top of the list is real: Indie Hackers, One Useful Thing, The Gradient, There's An AI For That, Artificial Analysis, TechRadar Pro. It also contains an entry called "AI Is Enabling More Entrepreneurship," which is a headline the parser mistook for a company. The citations tab is cleaner, 208 unique sources with paths, and it is the part of the report we would read first, because it shows that small sites do get cited for these questions: a Substack vibe-coding guide, a one-person blog post on solo-founder AI stacks, a personal site's tool roundup.
The free action plan, nine tasks written from the site, is better than the genre. It wants a methodology block on every review, a plain-language summary on the homepage, the Study and Ledger sections linked as a cluster, an Indie Hackers contribution, and internal links from reviews to research. It hedges its schema advice with "only where the page content supports it." It does slip once: "Add ItemList and Review schema" to the reviews index, and ItemList is on the list of recommendations we have researched and dropped. No FAQ schema, no question-shaped headings, no keyword stuffing.
## Where it breaks
**The free report asks the wrong question for a small site.** It is built to say whether AI recommends your brand, and for a new independent publication the answer is no on every engine and will be for a long time. The number is true and useless. The useful number is whether your pages get cited for the questions people ask, and the free plan gives you one credit to find out.
**The model behind the name.** Visibility on "ChatGPT" is visibility on GPT-5.6 Luna. The app's model and every premium engine sit behind the trial.
**The parser.** Article titles become competitors. Check the list before you put it in front of a client.
**The trial and the refund.** Seven days, card required, converts to paid on its own. The terms offer a refund "within 24 hours of being charged... at our discretion" and none for forgotten cancellations. Monthly credits do not roll over.
**The policy gap.** The privacy policy, last updated in March, covers your email and usage data and says nothing about the prompts and AI answers the product collects for your brand, or whether they train anything.
## Real cost
**Free is $0 forever** and buys one auto-generated report plus one question of your own. **Starter is $470 a year**, billed annually, which the pricing page presents as $39.17 a month, for 150 credits a month, six engines and up to ten brands. At one credit per bundled prompt, 150 credits is our eight questions on four engines about four times a month, or once a week with a few premium engines added. **Pro is $855 a year** for 500 credits. The trial is seven days with 50 credits and a card.
## The verdict
Situational, and the situation is a paid one. The machinery is sound: it reads a site well, stores every answer with its sources, labels your own pages, and on the one question we could afford it agreed with our hands. The free report is where the trouble is. Its questions produce a zero for any site that is not yet a brand, and the label it puts on that zero, Emerging, is the beginning of a sales conversation rather than a measurement of anything a solo builder can act on.
If you want the number this tool can produce, write your own questions first, the ones your readers type, and count the credits before you start. If you want to know whether your pages are being cited this week, the method in our kit costs nothing: type the question, open the sources, write down the domains. We did it for eight questions in twenty minutes, and it is the baseline every visibility tool should be measured against before you pay for one.
---
# Chatbase on the free plan: we fed it our own site and asked it twenty questions we already knew the answers to
Section: The Proof
URL: https://okaneland.com/proof/chatbase/
A support bot is only as good as what it says when nobody is watching. So we trained Chatbase's $0 tier on okaneland.com, froze twenty factual questions and three traps before the account existed, and graded every answer against the page it came from. Eighteen exact, one partial, one refused, none invented, five seconds a reply. The plan rather than the model is where it breaks: one megabyte of training data that dropped 22 of our pages, including the homepage.
## How we tested
A support bot has one job, and it is easy to fake in a demo. So we did not ask Chatbase to be impressive. We asked it to be right about things we could check.
Before the account existed we froze a fixture: one agent trained on okaneland.com by pointing the crawler at the bare domain, then twenty factual questions whose answers live on specific pages of this site, plus three trap questions about things the site does not cover. Each answer was graded exact, partial, refused or invented against the key. The gates were fixed at the same time: a live agent at $0 with no card, how much of the site the free tier would hold, at least fifteen of twenty exact, whether answers name their source, all traps refused, credits consumed per message against the meter, latency, the free-tier friction, the widget on a page we control, and what the terms say about your data.
Everything ran on the Free plan through the dashboard, on the default Auto model, with the instructions Chatbase wrote for us during onboarding left exactly as written. One disclosure: the site it was trained on is ours, which is the point. We know what every page says, so we can grade to the sentence.
## The door
Signing in takes a Google account. Then six screens of survey, where you heard about Chatbase, company size, your website, what the agent will do, your tech stack, where you will deploy, and a pricing page you leave through a small "Continue for free" link at the top right. The crawler found 107 links on okaneland.com from the domain alone and listed them by section for review. Seven minutes after the dashboard first loaded, the agent was live.
It arrived with a banner: "Limit reached! You're using 1 MB of 1 MB in your plan." The free tier holds one megabyte of training content. The crawler had trained on 80 of the 107 links, failed on five non-page assets, and dropped 22 for size.
Which 22 is the part that matters. The cap does not rank pages. It keeps whatever the crawler reached first and drops the rest, and the rest included the homepage, the subscribe page, the start-here page, four studies and the Open Design review. Two of our twenty questions had their source page in that pile. We graded them anyway, because a reader on this plan would meet the same hole.
The model picker lists 36 models. Three are selectable at $0: Auto, GPT-5.6 Luna and GPT-4o Mini. Every Claude, every Gemini, and the rest of the OpenAI line are greyed with a trial button beside them. Auto costs one credit per message.
## The twenty questions
We asked them one at a time in the playground, timed each reply from send to the moment it stopped changing, and read the usage page after.
Eighteen exact. It knew Codex on Free passed twelve of twelve, picked GPT-5.6 Terra and spent 37 percent of its meter. It knew Cursor Pro and Claude Code tied at eleven and which gate they both failed, and described the double booking correctly. It had the Fable price, the two hardware keys, the 2,122 and the 1,024 posts, the three cuts in eight months, the Clay and Creatify free tiers to the credit, and that Akira Sumi is a pen name. Asked what The Proof is, it said hands-on reviews that show what works, what it costs and where it breaks, which is close enough to the masthead that we would have signed it.
The partial was our fault as much as its own. Asked how many servers the MCP tax study measured, it said eleven. The article says ten in prose and lists eleven rows in its table. The agent counted the table.
The refusal was the plan's fault. Asked what our two-run Open Design session cost, it said the excerpts did not contain that figure, then offered a real but unrelated number from a Studio interview. The page with the answer was one of the 22 the cap dropped. It did not invent the figure, which is the behaviour you want from a bot that cannot see the page.
The traps came out two for three, and the third was ours. It refused to produce a phone number and volunteered the public contact email instead. It refused to name a crypto exchange and explained that Coinbase appears on the site only as a cited source. Then it answered the Windsurf question in detail, and it was right to: the field guide covers Windsurf's fate and Devin Desktop's prices, and we had forgotten. The fixture is published with that error left in.
## The meter
| Measure | Result |
|---|---|
| Messages used | 25 of 50 |
| Credits per message | exactly 1 |
| Median time to a finished answer | 4.8 seconds |
| Slowest answer | 16.1 seconds |
| Dashboard to live agent | 7 minutes |
| Dashboard to graded results | 26 minutes |
The credit meter is the plainest thing about the plan. Twenty-three playground questions, one from the embedded widget, one more for a screenshot: twenty-five messages, twenty-five credits, and the usage page agreed to the unit. Fifty a month is under two a day, which is a number for testing rather than for a site with visitors.
## Where it breaks
**One megabyte is smaller than a small site.** Okane Land is around a hundred pages of text. The cap took 80 of them and left the front door outside. Anything you sell will be documented on more pages than that, and the crawler will not tell you which ones it dropped until you open the fetched-links panel and click the "22 overlimit" tab.
**Visitors do not get the sources.** In the dashboard every answer has a "Show sources" control that opens the page URL and the passage it used, which is how we checked our grades. Switch the channel on and embed the widget, and that control is gone. The visitor gets the answer, a thumbs up, a thumbs down and "Powered by Chatbase."
**The channel is off until you switch it on.** The embed code is withheld behind a "Channel disabled" notice until you enable the chat bubble, which is sensible and undocumented. Once on, the bubble loaded on a local page and answered correctly. We switched it off again afterwards.
**The instructions are written for you, and not obeyed.** Onboarding generated 1,400 characters of instructions from the site, including "Never use em dashes in your replies." The twentieth answer used one. The same instructions tell the agent to refuse anything outside the business, which is why the traps worked; edit them before you trust them.
**Fourteen idle days and the agent is gone.** The pricing page says free agents are deleted after 14 days of inactivity. A test bot you build on a Sunday and forget is not there the Sunday after next.
## Real cost
**Free is $0** and did everything above. **Hobby is $40 a month** for 700 credits, 40 MB of sources, the advanced models, integrations and attachments. **Standard is $150** and adds the API. Chatbase's terms call fees non-refundable except after an uncured breach, and its privacy policy says your data is not used to train AI models, which is the sentence to look for before you upload a knowledge base to anyone.
## The verdict
Situational, and the situation is clear. As a way to find out whether a bot trained on your own writing will answer correctly and shut up when it should, the free plan is the best $0 we have spent on a support tool: eighteen of twenty to the number, both real traps refused, nothing made up, five seconds a reply. As a thing to put in front of customers, the free plan is a demo. One megabyte will not hold your docs, fifty messages will not hold a week, and the visitor never sees where an answer came from.
Two things to do before you pay. Open the fetched-links panel and read the overlimit tab, because that list is what your bot does not know. And rewrite the instructions the onboarding wrote for you, because the agent is following them where it matters and ignoring them where it does not.
---
# Google Antigravity at $0: we gave it the same booking app and it ran out of models by half past four
Section: The Proof
URL: https://okaneland.com/proof/antigravity-free/
Google closed the free door on the Gemini CLI and pointed individuals at Antigravity. So we walked through that door with the same founder pitch, curveballs and frozen gates the other three agents faced. The free tier serves Gemini 3.8 Flash, Claude Opus 4.6 and GPT-OSS, and in one afternoon we hit the weekly wall on all three. Nine of ten reached gates passed. The money curveball was never reached.
## How we got here
This was supposed to be a review of the Gemini CLI on its free tier. Google's own README still promises a personal Google account 60 requests a minute and 1,000 a day. We installed the CLI, signed in, and the server answered before the first prompt went out:
> This client is no longer supported for Gemini Code Assist for individuals. To continue using Gemini, please migrate to the Antigravity suite of products.
The tier named in the refusal is free-tier. The reason code is UNSUPPORTED_CLIENT. So we went where Google pointed, and this is the review of that door instead.
## How we tested
The fixture is the one that now has three scores on the board. In August, [Cursor Pro and Claude Code](/proof/cursor-vs-claude-code/) got the same founder pitch, a booking system for a three-room rehearsal studio in Paris, followed by a messy calendar import and a pricing rule set, then a cold ship check against twelve gates frozen before either tool started. This week, [Codex on the ChatGPT Free plan](/proof/codex-free/) took the same run and passed all twelve. Antigravity is the fourth agent against the same yardstick.
Antigravity is a desktop editor first, but it ships a command-line agent called agy that runs headless with a prompt flag, prints JSON, and continues a conversation across calls. That is how we drove it: the frozen script, a scripted operator who could send the pitch, the two curveballs and pasted error text, and nothing else. Three nudges per phase were available. None were used. The Individual tier's default model, Gemini 3.8 Flash at high effort, did the first phase.
**Two disclosures.** We ran the first attempt inside the CLI's own sandbox and it changed the outcome, so we restarted with the workspace declared and the sandbox off, which matches how the August runs were driven. Both attempts are in the kit. And once the Gemini quota closed, we asked the agent to continue on the other models the same $0 tier serves, and we say which model did which phase everywhere a score appears.
## The door
Signing in takes a Google account and nothing else. No card, no Cloud project. The onboarding asks for a colour scheme, then shows the terms with a checkbox already ticked that lets Google "collect and use my Interactions data." We unticked it. Then it asks whether you trust the folder.
The catalog served to a free account has fourteen entries: Gemini 3.8, 3.7 and 3.6 Flash at three effort levels each, Gemini 3.1 Pro at two, Claude Sonnet 4.6, Claude Opus 4.6 with thinking, and GPT-OSS 120B. Google's pricing page describes the tier's limit as "Basic weekly rate limits" and gives no number. By the end of the afternoon we had one.
## Attempt one: the sandbox and the scratch folder
The first run took 21 minutes, made 41 tool calls, and built a working Python app with five passing tests. It also went wrong in two ways that a reader on this tier will meet.
The agent's very first listing was of the CLI's own scratch directory under the user's home folder, and that is where every file went. The folder we launched it in, the repository holding the calendar file, was never opened. The final message told the user to set the scratch folder as their workspace.
Inside the sandbox, every shell command carried proxy variables pointing at a local proxy on port 58112. When the agent started its server and called it, the proxy answered 400. It tried the request four ways, printed the environment, found the proxy, set no_proxy to everything and carried on. That is good recovery and wasted quota. The run ended with a 503 from Google, "no capacity available" for the model, after the summary was written.
We kept that build as evidence, declared the workspace with the CLI's own flag, turned the sandbox off, and started again.
## Act one: the pitch, on Gemini
Attempt two opened by running git status and listing the right folder. Over the next 36 minutes it wrote a threaded standard-library server, a SQLite layer, a day grid, cancellation with the 24-hour late rule, 20 tests that all passed, and, unprompted, a calendar importer that it ran against the fixture file and checked for the New York conversion and the Thursday series across the clock change. It started the server, booked and cancelled through the API, and cleaned its test databases.
Then, before it could write the summary a founder would read, the tier closed:
> Individual quota reached. Please upgrade your subscription to increase your limits. Resets in 167h0m35s.
That is seven days. We probed every model on the account with a one-word prompt. Gemini 3.8 Flash at high and low effort and Gemini 3.1 Pro all returned the same wall. Claude Sonnet 4.6 and GPT-OSS 120B answered.
## Curveball one: the data, on Opus
We continued the same conversation on Claude Opus 4.6, the most capable model the free tier lists. Phase two took two minutes and fifty-five seconds. Twenty-one events imported as thirty-one sessions, the Jazz Trio expanded into eleven Thursdays that stayed at 20:00 on both sides of October 25, the Atlantic Standard event converted from 14:00 New York to 20:00 Paris, and the four skipped events named with the reason each: the impossible timestamp, the missing end, the duplicate UID, the 23:30 session outside hours.
The report it promised went into the CLI's artifact store, a "brain" folder under the home directory keyed by conversation, rather than into the project. The importer prints the same findings to the terminal, which is what our gate read.
## Curveball two: the money, and the second and third walls
Phase three on Opus read one file, wrote one sentence of plan, and stopped twelve minutes later with the same message. The reset stamp on the Claude wall traces back to our first Claude call at 15:35, so the Claude models share a weekly window that opened with a one-word probe and closed 42 minutes later after one real phase.
We tried the last pool. GPT-OSS 120B, which had answered a probe at 15:39, was walled on arrival: ten minutes of retries, zero tool calls. Its reset stamp matches Claude's to the minute, which suggests the non-Gemini models share one pool. The pricing rules and the demo checkout were never built.
## The ship check
The gates run from a fresh copy of what the agent left, following its own README: no install, run the tests, run the importer, start the server.
Nine of the ten gates it reached passed. The tests are real and green. The day view answers, a booking survives a restart, an overlap is refused with a 409 while a back-to-back booking is accepted, the imported events are on the right days, the weekly slot holds across the clock change, and all four defect UIDs appear in the importer's output. The secrets grep is empty.
The one failure is the one that matters most and the one most agents share. Two simultaneous requests for the same Room B slot both returned 201, and two bookings sat in the day view. The server is threaded, the code checks for a conflict and then inserts, and nothing holds a lock between the two. Cursor and Claude Code failed this exact gate in August. Codex passed it by accident of a single-threaded runtime. Antigravity fails it the ordinary way.
Two gates are dashes rather than crosses. The pricing fixtures and the demo checkout were never attempted, because message three never got a working model.
## The meter
There is no meter to read. The pricing page says weekly, the CLI prints nothing about remaining quota, and the only number you get is the one in the refusal. So here is the afternoon in the tier's own terms.
| Pool | Agent time before the wall | Reset |
|---|---|---|
| Gemini 3.8 Flash | 57 minutes across two attempts | 167 hours |
| Claude Opus 4.6 | about 15 minutes | 167 hours |
| GPT-OSS 120B | none, walled after one probe | 167 hours |
The Gemini attempts consumed 2.3 million fresh input tokens, 3.9 million cache reads and 136,000 output tokens, 42,000 of them thinking. At the introductory API rate Google published for 3.8 Flash, that is somewhere between about $3 and $5 of tokens depending on how cache reads are billed, which Google does not state for this model. The Opus phases added roughly 115,000 fresh input tokens and 690,000 cache reads. For all of it, the tier charged nothing and then charged everything, in the form of a week.
## Where it breaks
**The wall is weekly and it is close.** One build, one afternoon, three pools. A builder who tries Antigravity at $0 on a Monday will meet the Gemini wall before dinner and the Claude wall shortly after, and will have nothing until the following Monday. The paid tiers, Google AI Pro and Ultra, are the answer the message itself gives. We have not tested them.
**The sandbox fights localhost.** If you leave the CLI's sandbox on, your agent's own server is behind a proxy it does not know about. The agent will figure it out. It will spend your quota doing so.
**The workspace is not where you are.** An untrusted folder in headless mode sent the agent to its scratch directory. Declare the workspace, or trust the folder interactively first, before the first real prompt.
**Artifacts leave the repo.** Reports and plans go to the brain folder under your home directory. They are fine there for you. They are invisible to anyone who clones your project.
**The concurrency landmine is still there.** Three of four agents on this fixture ship an app that double-books under load. This one does too.
## Real cost
**Individual is $0** and carried this test to three walls. **Google AI Pro is $19.99 a month** and **Ultra is $99.99 and $199.99** for five and twenty times the allowance, per Google's pricing page, with no numbers attached to any tier. Nothing here needed a card, and there is no refund question because there was no charge.
## The verdict
Situational, and a specific situation. If you want to feel what Opus 4.6 or Gemini 3.8 Flash does inside a capable agent, this is the cheapest seat in the building, and the agent itself is good: nine gates of ten from one pitch, an importer nobody asked for that handled every trap, and a clean model switch mid-conversation. If you want to build something, the week-long wall arrives before the second curveball, and the message that delivers it is a sales pitch.
Keep two things in your pocket. Declare your workspace and turn the sandbox off before the first prompt, because both cost us a run. And add the lock yourself, because the fourth agent in a row did not.
---
# Codex on the ChatGPT Free plan: we gave it $0 and the same booking app
Section: The Proof
URL: https://okaneland.com/proof/codex-free/
We handed the free tier of OpenAI's coding agent the exact founder pitch, curveballs and frozen gates that Cursor Pro and Claude Code faced in August. It cleared all twelve, including the concurrency gate both $20 tools failed, in under ten minutes of agent time. The bill was 37 percent of a 30-day meter, and the model behind the door was not the one in the launch posts.
## How we tested
We did not write a new test for Codex. We reused the one that already has two scores on the board. In August we gave [Cursor Pro and Claude Code](/proof/cursor-vs-claude-code/) the same founder pitch, a booking system for a three-room rehearsal studio in Paris, followed by a messy calendar import and a pricing rule set, then ran a cold ship check against twelve gates frozen before either tool started. They tied at eleven of twelve and failed the same gate. That fixture is now the yardstick, and this is the third tool to stand against it.
The plan was the point. OpenAI's pricing page says the Free tier lets you "Explore Codex capabilities on quick coding tasks" and publishes no number for it. So we signed a Free account into the Codex CLI, updated it to the current release, and drove it the way a subscriber on that tier would: through `codex exec`, on the default model, with a scripted operator who could send the pitch, the two curveballs and pasted error text, and nothing else. Three nudges per phase were available. None were used.
**Two conditions differ from the August runs, and both are disclosed.** First, Codex ran inside its own sandbox: writes confined to the project folder, network on, approvals set to never. The earlier two tools ran with permissions bypassed. We tested the sandbox before starting and confirmed it let the agent bind a local port, reach the package registry and write its files, so it did not cost Codex anything we could measure. Second, the operator is an AI, same as in August, following a frozen script, and the gates are external code run from a fresh copy of the build. Every claim below is checkable against the transcripts and meter reads in the kit.
## The door
Before the first message we dumped the model catalog Codex serves to this account. It lists three models a Free user can pick: GPT-5.6 Terra, GPT-5.6 Luna and GPT-5.5. Astra, the model in this month's launch posts, is absent, and so is Sol. OpenAI's help center says Astra is included with Plus, Pro and Business seats and lists no Free row. The catalog agrees with the help center. Codex chose Terra at medium reasoning without announcing it, the way Cursor chose "auto" in July.
The meter is the other thing to know before you type. Codex reports its limits in every turn, and on Free there is exactly one: a window of 43,200 minutes, which is 30 days, with a reset stamped thirty days after our first call. No five-hour window, no weekly window. That shape matters later.
## Act one: the pitch
Four minutes and eleven seconds after the pitch, Codex declared done. It had read the calendar file it found in the folder, written a server in 112 lines of Node with no third-party packages, a JSON file store, a day grid for the three rooms, weekly bookings stored as local Paris wall-clock times so a 20:00 slot stays 20:00 across daylight saving, and a cancel flow that marks anything inside 24 hours as late. It started the app twice on different ports to probe its own API, created and cancelled a booking, and checked what Paris thinks today's date is.
It also did something nobody asked for. It imported the calendar export during phase one, reporting "the valid bookings" and moving on. We let phase two ask the question that word was hiding.
The meter read 15 percent.
## Curveball one: the data
The import message asks for everything in the file, with a report of anything skipped or changed and why. The calendar carries nineteen clean one-offs, a weekly rule with eleven occurrences, one event in New York time and four planted defects.
Two minutes and three seconds later the report existed as a file the app rewrites on every import, and it named all four defects with a reason each: the malformed timestamp, the event with no end, the duplicate UID, and the 23:30 session outside opening hours. The New York event was converted and the report said so in plain words: from America/New_York 14:00 to Europe/Paris 20:00, on the right day. Twenty-one imports, four skips, twenty-five events accounted for.
The meter read 22 percent.
## Curveball two: the money
Three room rates, a 30 percent off-peak discount on weekday hours before 17:00 that has to split a booking spanning 17:00, a 10 percent member code stacked on top, half-hour billing with a one-hour minimum, a 50 percent deposit through a checkout in demo mode, and money rounded half up to the cent.
Codex priced in integer cents, per half-hour slot, and applied the member code after the off-peak reduction. Its own worked example, a weekday 16:00 to 18:00 in Room A with the code, came to €45.90 total and €22.95 deposit, and that is right: one discounted hour at €21 plus one full hour at €30, less ten percent. The checkout records a demo payment on the booking with no card field anywhere. Two minutes and forty-six seconds.
The meter read 34 percent.
## The ship check
The last message says a clean machine is coming and asks for a README that covers install, test and run from a fresh clone. Codex rewrote the README and added two tests that spin up the server on a spare port and check the pricing rules and the one-hour minimum. Thirty-six seconds.
Then we did what the README said, from a fresh copy with no data folder. Install, test, import, start. Then the gates.
Twelve of twelve. The day view answered, the imported events were on the right days, the weekly 20:00 was still 20:00 on both sides of October 25, all four defect UIDs were in the report, four pricing fixtures matched to the cent on total and deposit, the demo checkout completed and said demo, the booking survived a restart, an overlapping request was refused with a 422 while a back-to-back one was accepted, and the secrets grep came back empty.
Then the gate the other two failed. Two simultaneous requests for the same Room B slot: one 201, one 422, one booking in the day view. We were suspicious enough to run it again with four simultaneous requests across eight fresh slots. Exactly one holder every time.
Here is why, because it matters for what you do with this app. The server is a single Node process. It reads the whole request body, then validates against the file and saves, all in one synchronous stretch with no await between the read and the write. Nothing can interleave. That is a property of the runtime, and the code contains no lock, no transaction and no unique constraint. Run two copies behind a load balancer and the double booking comes back. The August apps were Python servers with threads, which is the kind of detail a founder never sees until it costs a Saturday night in Room B.
## The meter
The full run, four phases and twenty commands, ended at 37 percent of the 30-day window. The token accounting behind that: 1.42 million input tokens, of which 1.35 million were served from cache, and 27,000 output tokens, about 4,400 of them reasoning. Priced at OpenAI's own API list for Terra, $2 per million in, 20 cents cached and $12 out, the same work would have cost about 73 cents.
So the free tier is a good deal per token and a tight deal per month. If every build cost what this one did, you get two of them and change before the meter resets, and this build was ten minutes of agent time on a fixture we designed to be finishable. Real products are not finishable. They are iterated, and every iteration reads the whole conversation again. That cached input count is the shape of the bill: the context grew from 500 thousand tokens in phase one to 1.4 million by phase four, and Free charges the meter for it even at cache rates.
The single window cuts both ways. There is no five-hour wall to bounce off in an evening session, which paid Codex users spend a lot of time discussing. There is also no reset until day thirty.
## Where it breaks
**The model is the one you are not being sold.** Astra is the model in the benchmarks and in our [Signal on the two-tier frontier](/signal/the-frontier-twice/). It is not in this catalog and OpenAI's help center does not list it for Free. What this review measured is GPT-5.6 Terra, chosen silently. That is fine for a booking app. It is worth knowing before you compare notes with someone on Pro.
**Fresh clone means what you committed.** The README's first instruction is to clone the repository. The agent initialised nothing and committed nothing; the only commit in the folder is the one we made to place the calendar file. A collaborator cloning what it left would get the calendar and no app. The instructions are right for a repository that does not yet exist.
**The summary hides the stumbles.** Twice in the run Codex's own patch tool refused a patch it had written, once for targeting the same file twice, once because the lines it expected in the stylesheet were not there. It recovered both times and the final messages mention neither. The transcripts do.
**The import ran before you asked.** Doing phase two's work in phase one is initiative, and the word "valid" in its phase-one summary was doing quiet work until the report existed. If your data has to be imported carefully, say so in the first message, because the agent will get to it on its own.
## Real cost
**Free is $0** and carried the whole test. **Plus is $20** and is the first tier OpenAI lists for Astra, with an estimated five to forty-five Astra messages per five-hour window and weekly limits it does not number. **Pro is $100 or $200** for five and twenty times that. We tested none of the paid doors. The comparison that matters for this piece is the one you can make yourself: sign in, run one build, and read the percentage Codex prints, because on Free it is the only number the plan will ever show you.
## The verdict
Worth it, for the price of an email address. We asked a $0 plan to be a founding engineer for one evening on a test two paid tools already took, and it passed every gate they passed and the one they did not, in less time. The app is small, dependency-free and readable, which is what a founder who has to maintain it should want.
Keep three things in your pocket. The model is Terra rather than Astra, and the plan will not tell you. The month is one meter and a real product will drain it faster than a fixture did. And the concurrency pass is a gift from the runtime, so the day you scale past one process, add the lock yourself. The [field guide](/study/ai-coding-agent-field-guide/) row for Codex on Free now reads tested, at $0, with those caveats attached.
---
# Web Anatomy: the annotations are worth your time, the statistics are not
Section: The Proof
URL: https://okaneland.com/proof/web-anatomy/
A design library of scored, annotated landing-page sections from real companies, plus a free MIT-licensed skill pack for your coding agent. We ran its own audit rubric three times on the same page to test its reproducibility claim, ran the hosted analyzer on our own homepage and timed it, and checked its published analyses against the live sites they describe. The section-level work is better than almost any free CRO content. The scores and leaderboards deserve a more careful read.
## How we tested
Point your AI agent at a page pattern that a real company shipped, rather than at whatever the model averaged out of its training data. That is the pitch, and it is a good one. The site puts it plainly: **"Most AI pages are averaged from training data."**
It ships in two halves. The skills are free, MIT-licensed, install with one command and need no account or token, into the same agents we test elsewhere: [Claude Code](/primer/how-to-use-claude-code/) and [Cursor](/proof/cursor/). The MCP server, which is the live link to the library, comes with the €9/mo Pro plan. The docs are clear that **"The skills work on their own. The MCP adds the live data."**
We did not run the vendor's installer. Skills are markdown instruction files, so we cloned the repository read-only and read all eight of them instead. That is also how we tested the audit rubric: by following it ourselves, exactly as written, which is what an agent does with it.
Everything below was done on 8 and 9 August 2026, spending nothing and entering no payment details. One connection to disclose: Web Anatomy's founder sat for [our Studio interview](/studio/gabriel-amzallag/) in July, and this test was run three weeks later on the public product, without his involvement. Browsing and counting used no account at all; the analyzer run used a free account that already existed on this machine, and we created no new one.
Three independent runs judged the same page, okaneland.com, against all 49 rubric items, with no knowledge of each other's verdicts. Separately we sampled 48 analysed entries across 8 industries and 15 section types in the library, requested all 146 screenshots from seven galleries, and checked a set of the site's published analyses against the live pages they describe. We read an existing analyzer report end to end, then submitted a fresh analysis ourselves and timed it.
Two things we nearly reported and did not, because checking killed them. The score gauge that reads 0 on load is a count-up animation that settles correctly. Sentry traffic we assumed was errors is telemetry, and the console is clean.
## The annotations are the real product
The section-level work is better than the overwhelming majority of free CRO writing, and it is better because it is falsifiable.
The best example in our sample, on a hero scored 91:
> Bolded time claim (in under five minutes) is proven by a deploy log ending at blog live 4m 12s
That names the claim, names the artefact on the page that discharges it, and quotes the number inside the artefact. Anyone can check it, and it teaches a move you can carry to your own page. Compare the usual standard of free CRO advice, which is "add social proof."
They are also demonstrably observational rather than generated from a company description. Web Anatomy's Pumble entry records **361,477 teams**. The live page today reads **363,883**. That is an incrementing counter, which means a real reader took a real number off a real page down to the last digit. On Passbolt it names the vault contents, the compliance row in order, and the fact that "Open source" is literally the first two words of the headline. We checked those against the live site and they are exact.
## The reproducibility test
The rubric makes an unusual claim for an LLM-driven product, and states it in its own documentation: **"You do the judging. A script does the arithmetic."** The point is that the same judgments always produce the same number, so the score cannot drift on the maths.
That is true as far as it goes, and it dodges the harder question, which is whether the judgments themselves are stable. So we ran it three times, blind.
**46 of 49 items were unanimous, an agreement rate of 93.9%.** Final scores landed at 56, 56 and 59. For a rubric applied by a language model to a subjective question, a three-point spread is a genuinely good result, and better than we expected going in.
The three items that disagreed are the diagnosis. They were the five-second test, whether the hero is outcome-focused, and whether the primary call to action repeats often enough. All three are judgment calls, and at least one has a specific, fixable cause that the runs identified independently: **the rubric never states a viewport for "above the fold"**, so the same page passes at 1080px and fails at 720px. Define the viewport and one of the three disagreements disappears.
The runs surfaced other spec problems worth the vendor's attention. The house style file forbids HIGH/MEDIUM/LOW severity labels in an audit while a sibling skill uses them. The rubric scores navigation and footer, but the canonical section taxonomy has no tag for either, so those findings cannot be filed. Output paths disagree between two files describing the same directory. And one rule instructs the agent to mark visual items as not-applicable without a render, while four of those items are pure DOM checks that need no render at all.
One more, which matters because it undercuts the pitch: a later step tells the agent to **"trust the recommendation"** over the computed result, sitting a few paragraphs below the step that sells the score as reproducible.
## The rough edges around the scores
The scored library needs reading with one eye open, because the editorial layer around it is not at the level of the annotations.
A flagship gallery page ships the sentence **"1 hero sections in our library are flagged best-in-class"** and then quotes four percentages about that population. The fintech page's FAQ names five strongest performers, four of whom are absent from the leaderboard directly above it. A customer-analytics company is filed sixth in "6 best cybersecurity homepages" under the invented descriptor "Predictive security", and one Gusto card prints 400,000+ and 300,000+ for the same statistic inches apart, when the live page says 500,000+.
None of that touches the thing the product does well. All of it is what a reader hits when they try to cite the aggregate layer instead of the annotations.
## The claim we would ask them to withdraw
This is the one that matters, because it is load-bearing rather than cosmetic.
On the hero gallery, explaining why the scoring weights what it weights:
> in our dataset, heroes with those two convert better than heroes without them
No conversion data exists anywhere on the site. There is no click-through rate, no A/B test, no outcome linked to any score. What the library actually contains is pattern frequency among pages that a practitioner hand-picked as good, which makes "converts" a description of resemblance rather than of measured performance.
That is a perfectly respectable product. Plenty of useful design references are exactly that. But the sentence above claims a causal finding from data the site does not have, and it is the stated justification for the weighting that produces every number on the site. A nearby line has the same problem: "'No credit card required' outperforms countdown timers in 90% of top scorers" never says outperforms at what.
The methodology page elsewhere is admirably candid, stating that **"Conversion analysis is subjective"**. That is the register the whole site should be in.
## We ran the analyzer
Two runs inform this section: a report on this site's homepage generated 28 July, and a fresh run we submitted ourselves on 9 August on the account's free monthly allowance. The sidebar counter ticked from 3 to 2, which is itself a finding. The pricing page advertises "1 credit", the app runs on a three-preview monthly counter, and nothing public explains the difference.
The flow nearly holds its headline promise. We submitted at 12:07:43 UTC and the executive summary rendered at 12:09:51, which puts "get your conversion audit in 2 minutes" eight seconds over its claim on our run. The report opens with a scope banner that was not there in July and deserves credit: **"our analysis is primarily designed for SaaS landing pages. Results are still useful, but some recommendations may be less applicable to your site type."** Its one-line verdict on our homepage is fair and specific: **"Beautifully curated and credible, but the first screen doesn't quickly tell a new visitor what they'll get, how often, and why subscribing beats just browsing."**
The free boundary, now observed rather than inferred from shipped code: on the preview tier, two of eight scoring categories show their recommendations and six are blurred behind PREMIUM locks, and the section-by-section improvement list shows two readable items followed by five rows reading "Locked recommendation #4" through "#8". That is a legitimate way to run a free tier, and the pricing page should describe it, because "1 credit to analyze your landing page" reads like one full report.
Run against run, the analyzer is steadier at the top than underneath. July scored the page 64; August scored it 66, and the fresh report's verdict quote is the sharper of the two. Under that two-point move, the classification flipped from Homepage in the AI industry to Landing Page in Other, and the category scores swung hard: Value Proposition 56 to 71, Trust 23 to 38, Conversion 74 to 53. Some of that is real, because we shipped new sections onto this homepage between the runs. Some of it is the cohort flip, which is the analyzer's own doing. Cite the headline number if you like; do not build a to-do list on one run's category scores.
The fresh run also re-scopes two defects we found in the July report, one in the vendor's favour. The July report's page-overview screenshot renders blank; the fresh report's renders perfectly, our homepage with numbered section markers on the sections it read. So the defect is screenshot assets going stale within a couple of weeks, not a broken feature. The other two stand as of 9 August: the July report's upsell card still says "Your page 62/100" against its own gauge's 64, and still advertises, in full:
> +0 more opportunities
A conversion-optimization product advertising zero additional value at the exact moment it asks for money remains a ten-minute fix.
One small credit from the plumbing: report URLs are login-gated, and the share link we minted to capture these screenshots is a long random token generated on demand. That is how it should be done.
## What we could not test
The signup flow is untested; our analyzer run used an account that already existed. The dashboard library pages behind the login, the fuller per-criterion view the site advertises, are also untested, so our conclusion that you cannot tell why a given page scored what it did applies to the logged-out library.
We did not pay, so the €9 MCP server and the €149 human report are both untested. Since the MCP is the entire paid proposition, treat this review as covering the free surface and the skills, and nothing else. Selling live data to agents is also exactly the market where [our Study of agent economies](/study/what-agent-economies-charge-for/) found almost nobody clearing money, which makes the €9 MCP one of the more credible entries in that market rather than a red flag.
We also cannot verify the claim that every analysis is reviewed by a human before publication. The duplicated Gusto write-up, which appears in two different versions for the same score on two pages, and the Faraday misfiling, are evidence against uniform review rather than proof of its absence.
## Recommendations
Ordered by what we would fix first.
**1. Fix "+0 more opportunities", the 62-versus-64 mismatch, and the expiring report screenshots.** The first two sit inside the paid conversion moment on a product about conversion. None is more than an afternoon.
**2. Withdraw or substantiate the "convert better" sentence.** Either publish the outcome data, or rewrite it to say what is true: these patterns are frequent among pages we judged strong. The methodology page already sets that tone. This is the single biggest credibility risk in the product, because the whole scoring apparatus rests on it.
**3. Give "above the fold" a viewport in the rubric.** One line in scoring.md removes a measurable share of the score variance we found. While in there, resolve the HIGH/MEDIUM/LOW contradiction, add taxonomy tags for nav and footer, and reconcile the two output paths.
**4. Delete or ship `benchmark-compare` and `improve-page`.** The moodboard skill gives routing rules for two skills that do not exist in the pack. An agent that follows those instructions routes to nothing.
**5. Update the stale onboarding line.** The write-page skill still tells users to "request beta access". The docs and the dashboard both say a subscription unlocks the token automatically with no review queue.
**6. Put the scores on the gallery cards.** The galleries are the advertised front door and the least informative surface on the site: screenshots and a company name, with no score, no analysis, and no visible affordance that the card opens anything. The best thing the product makes is one undiscoverable click deep. This is probably the highest-leverage change on the list.
**7. Split the two bullet families, or fix the weaker one.** The page-level "what makes this page stand out" bullets fail in a diagnosable way: 9 of 30 quote no page copy at all and read as company summaries. A generation rule requiring at least one direct quotation from the page would catch nearly all of them.
**8. Add a "last verified" date to every analysis.** A third of the quoted figures we spot-checked had drifted, which is expected on a three-month re-analysis cycle and invisible to a reader deciding whether to cite one.
**9. Say what "scored" means, once, near every score.** Not measured conversion; conformance to a published rubric. The rubric is already public and that is a strength worth leaning on.
## The verdict
**Situational, and the free tier is the one worth your time.**
Use the section modals and the numbered annotations. That work is specific, checkable, frequently excellent, and free, and there is not much else like it. The skills pack is worth reading whether or not you ever pay, because the rubric is published in full and you can lift it.
Treat the leaderboards, the aggregate percentages, the industry rankings and the page-level bullets as unreviewed. Verify any number you plan to cite against the live page. And read "converts" as "resembles pages a practitioner picked as good", because that is what the data supports.
The gap here is not between a good product and a bad one. It is between a genuinely good core and an editorial layer that runs ahead of it. That gap is closable, and most of the items on our list are afternoons rather than quarters.
---
# Cursor vs Claude Code for vibe coding: a real head-to-head
Section: The Proof
URL: https://okaneland.com/proof/cursor-vs-claude-code/
We gave each $20 agent the same founder pitch and the same pass-or-fail gates, frozen before either run started, then did it again with a completely different product to break the tie. Round one: 11/12 each, same failure. Round two: 12/12 each. Two builds, two ties. Here is what still separates them, receipts and repos included.
## How we tested
We did not read spec sheets and call it a comparison. We handed each agent the same founder-style pitch, at nine at night, and asked for a whole product: a booking system for a three-room rehearsal studio in Paris, runnable tonight. Then we threw two identical curveballs at each, a data one and a money one, and ran a cold ship check at the end. Every claim either agent made was gated by tests and probes we ran ourselves, from a fresh clone, outside the tool.
Both agents run on a $20 subscription and were driven the way a subscriber drives them: through the CLI, on default settings, with a scripted operator who could send the pitch, the two curveballs, and pasted error text, and nothing else. Three nudges per phase were available; neither agent needed one. The models each tool silently chose are part of what we are comparing, not a footnote.
**The build was hard on purpose.** A booking app sounds like a to-do list, so we loaded it with four things agents reliably fumble, each reducible to a yes-or-no check. Time and daylight saving: a weekly 20:00 booking has to stay at 20:00 local when the Paris clocks change on October 25. A nasty real file: the data curveball is a calendar export in ICS format, with recurrence rules, a foreign time zone, and four seeded defects, not a tidy CSV. Concurrency: two people requesting the same slot at once must yield one booking, not two. And money that has to be exact: off-peak discounts and a member code that stack, judged to the cent against totals we precomputed.
**The gates were frozen before either agent started.** Twelve binary checks, written and locked while the fixtures were built, then run identically against both finished apps from a cold clone. No moving goalposts, no scoring by impression.
**One disclosure, because it matters here more than usual.** The operator is the same model family as one of the contestants. That is handled structurally rather than by trust: the operator's messages were scripted and frozen in advance, the gates were pre-registered, the checks are external code, and both repositories and all four transcripts are published with this piece so anyone can re-run them. We also disclose that on this machine Claude Code ran on a Max-tier subscription, not the $20 Pro tier, so read its meter as consumption rather than as a like-for-like price.
**And we caught ourselves three times.** Our own harness was wrong before either app was: it silently followed one app's redirects and misread a rejection as a pass, it demanded a defect be reported by internal ID when the app sensibly reported it by name, and one pricing fixture collided with an imported booking, where one app correctly refused to quote an occupied slot and our check called that a failure. All three were our errors, fixed before scoring, and we mention them because a comparison that never catches its own mistakes has not been checked hard enough.
## What both got right
Start with the tie, because it is the headline. We ran this twice, on two unlike products, and both times the two agents finished level. Round one was a rehearsal-studio booking app, and there **both scored eleven of twelve, and it is the same eleven.**
Both took one paragraph of founder-speak and produced a running app: three rooms, non-overlapping bookings, a day view, cancellation with a late flag, persistence across a restart. Both did it in roughly a quarter of an hour of real work, with no operator help.
Then both cleared the traps that were supposed to hurt. The recurring Thursday-night booking held its 20:00 local time on both sides of the October daylight-saving change, which means each agent understood that a wall-clock time and an absolute instant are different things, and stored the right one. The calendar import is the sharper tell: a rehearsal written in New York time imported to the correct Paris slot, 20:00 not 14:00, on both. Get that wrong and every touring band shows up six hours off; both got it right without being told the file contained a foreign zone.
The messy-file gate asked for something most software skips, which is a straight account of what it could not use. Both agents produced one. Cursor wrote an `IMPORT_REPORT.txt` naming each skipped event by its calendar ID and reason; Claude Code exposed a `/log` page and a console summary naming each by title. Between them they caught the unparseable date, the event with no end time, the duplicate ID, and the booking that ran past midnight, and neither swallowed anything in silence.
And the money was exact. Four fixture bookings, priced with a 30% off-peak discount on weekday daytime hours and a further 10% member code stacking on top, came out to the cent on both: the plain one at forty-two euro, the member-discounted Saturday at 43.20, the four-hour afternoon at 55.08, the one-hour edge case at 22.95. Vibe-coded software has a reputation for money math that is almost right. This was right.
## The one they both failed
Now the gate that turns a tidy tie into the real story.
We fired two identical booking requests at the same open slot at the same moment. A correct system lets exactly one win. **Both apps created two bookings for the same room at the same time.** Cursor's API returned two success codes; Claude Code's database ended with two rows for one slot. Same room, same hour, double-booked, in both builds.
This is not an exotic failure. It is the single most common concurrency bug in booking software, and the reason is visible in both codebases: each checks whether the slot is free and then inserts, with nothing stopping a second request from slipping between the check and the insert. Claude Code even wrote a comment acknowledging that a slot could be "taken between quote and confirm", and still shipped the check-then-insert pattern rather than a database constraint that would make the collision impossible.
Neither agent is worse than the other here. Both are worse than the problem. And this is exactly the class of bug a solo founder ships to production and only discovers when two bands are standing in the same room on a Friday night, because it never shows up in casual testing. It is the strongest argument in this whole piece for reading the diff, or at least knowing the words "race condition" before you point an agent at anything people will book, pay, or queue against.
## The rubber match
One tie is a coin that landed on its edge. So we ran it again, and we changed almost everything to give the tie somewhere to break.
The second build is a command-line tool, not a web app: point it at a folder of nginx access logs and print a summary. It stresses the muscles the booking app did not. There is no database and no server, so nothing to hang on. The hard input is a 304-megabyte log file that has to be read without loading it into memory. The correctness is aggregation at scale: total requests, unique visitors, the top ten pages, the error rate, requests by hour, computed from a messy folder of gzipped and plain files with eight malformed lines seeded in. And there is a `--json` flag, because a real tool has a machine-readable mode.
Both agents scored **twelve out of twelve.**
Both parsed the folder to the exact answer key we had precomputed and verified independently: 1,585 valid requests, 43 unique visitors, the top pages in the right order, a 19.94% error rate, and the eight bad lines skipped and counted rather than swallowed. Both added a clean `--json` mode. And both cleared the gate that was built to hurt: on a 304MB input, each tool held its peak memory to about twelve megabytes, which is the signature of reading the file line by line instead of all at once. Neither slurped.
The second build also settled the hang cleanly. With no server to spawn, Cursor's CLI exited cleanly on all four phases, eight clean exits in a row. That narrows the earlier finding from "Cursor's CLI hangs" to the precise and fairer "Cursor's CLI hangs when the build it runs starts a long-lived server." The rubber match earned Cursor that correction.
So the tie held, on a second product that shares nothing with the first but the discipline we tested it under. Twenty-three of twenty-four gates each, across a booking app and a log pipeline. At that point the fair reading is not that we failed to find a winner. It is that, at $20, on the work a solo builder actually hands an agent, there is no capability winner to find.
## Where they actually differ
If the gates tie twice, the choice comes down to temperament, and the two agents have opposite ones.
**Cursor is the fast, opaque one.** It reached a running build first, and it kept the entire job inside the $20 plan with nothing billed on demand. But its usage ledger records every single run's model as `auto`, so after the fact you cannot tell whether your architecture was decided by a frontier model or a cheap one. We flagged this in July and it is unchanged. It also front-ran the data curveball: the calendar file was sitting in the project folder, and Cursor found it and wired up an importer before we had said a word about it, which is initiative you will sometimes want and sometimes not.
**Claude Code is the legible, tidy one.** It exited cleanly on all four phases, reported its own token use per phase in exact numbers you can audit as it works, and chose a stack with no dependencies at all: one Python file, standard library only, nothing to install. It also showed better judgment on one edge we did not gate for, refusing to price a slot that was already booked rather than quoting into a conflict. Where Cursor acts, Claude Code checks.
The sharpest operational difference is not in either app; it is in the tools, and the rubber match pinned it down. **Cursor's headless CLI hung after it finished, twice, on the first build.** Both times the build had launched its own dev server to check itself, and the print-mode command then could not exit while that child server held the output pipe open, once for over an hour before we killed it. On the second build, which starts no server, Cursor exited cleanly all four times. So the trap is specific and real: if you script Cursor in a pipeline where the thing it builds spins up a server, expect to kill it yourself. The interactive editor sidesteps this, and Claude Code exited on its own in all eight phases across both builds.
## Real cost
Both agents were tested on their $20 tier, and neither cost a cent beyond the subscription.
Cursor Pro ran the whole build inside its included allowance: the dashboard showed 2.4 million tokens for the session and zero on-demand spend. Claude Code, on this machine, was on a Max-tier subscription rather than the $20 Pro plan, which we disclose because it makes the meter a measure of consumption and not of price; across four phases it self-reported roughly ten thousand input, seventy-five thousand output, and 4.2 million cache-read tokens, with nothing billed above the plan. The two meters are not the same unit and we do not pretend they are; each is shown as its own tool reports it.
For a solo builder the practical read is simple. On this build, both plans absorbed a full product build without overage. The Claude Code weekly cap, which we mapped in [our limits study](/study/claude-code-limits/), is the ceiling to watch if you run several of these a day; Cursor's included-token pool is the equivalent number on its side, and its promo-free simplicity is a genuine point in its favor. The subscription-versus-API break-even, and the four moves that actually cut the meter, are in [our cost study](/study/cut-your-ai-coding-bill/).
## What this cannot tell you
This is two builds on one afternoon. They were chosen to be unlike each other, a stateful web app and a one-shot data pipeline, and that widens the finding beyond a single lucky draw. But both still favor backend correctness over front-end polish, both were greenfield rather than a large existing codebase, and both were an evening's work rather than a month's. A third kind of brief could still separate these two where our two tied, and we would rather you knew that than oversold two rounds as the last word.
It also cannot referee the parts of each tool we did not drive. We ran both through their command-line agents, because that is the like-for-like surface and the one an automated builder uses. Cursor's Tab completion and inline edit, and Claude Code's interactive session, are typing-native and outside our harness, exactly as our [Cursor review](/proof/cursor/) said of that tool alone. If your day is mostly in the editor rather than firing off whole tasks, weight this accordingly.
And it is a snapshot. Both tools updated in the weeks before this test and will again; we ran both on the same afternoon on current builds to keep it fair, but a race-condition fix or a ledger change on either side could move a line on the scorecard next month. The repos and transcripts are published so you can re-run the gates against whatever ships next.
## The verdict
**Situational, and closer than the discourse.** Across two unlike builds, at $20, Cursor Pro and Claude Code are the same tool wearing different clothes: both competent enough to ship a real product from a sentence, tied at 23 of 24 gates, with no single decisive edge between them. We ran the second build specifically to crown one of them, and it refused to be crowned.
So choose on the thing that actually differs, which is character. Take Cursor if you want the shortest path to a running build and can live with a meter that will not tell you which model did the work, and you are not scripting it in a pipeline where the CLI can hang. Take Claude Code if you want builds you can read, accounting you can audit, and an agent that checks before it acts, and you have watched the weekly cap. And if the answer might be neither, [the coding-agent field guide](/study/ai-coding-agent-field-guide/) maps the rest of the 2026 field, Codex, Antigravity, Zed, OpenCode, against these two.
But the finding that outlives the matchup is the one they share. On the build that had a concurrency trap, two different frontier agents both shipped software that double-books a room. The gap that matters in vibe coding is not Cursor versus Claude Code, which two rounds could not separate. It is between what either agent hands you and what is actually safe to ship, and closing that gap is still your job.
---
# Cursor Pro: we gave it $20 and a startup idea
Section: The Proof
URL: https://okaneland.com/proof/cursor/
We handed Cursor a founder-style pitch and it shipped a working, named SaaS the same evening: a tracker for the exact unnumbered AI allowances our own reporting keeps exposing. It survived two curveballs and a cold ship check, all on the $20 plan. Worth it, with the two caveats the meter still will not show you.
## How we tested
We stopped treating Cursor like a lab specimen and treated it like a hire. We gave Pro one prompt, the kind a founder types at 9pm, and asked for a whole product: build a SaaS that tracks AI subscriptions and their usage allowances, warns you before you overflow, and watches the tools that publish no ceiling at all. We picked that product on purpose. It is the antidote to the exact problem our own reporting keeps finding, most recently in [Perplexity's shrinking $20 plan](/study/perplexity-pro-limits/) and in Cursor's own meter. Then we threw two curveballs at the agent, a data one and a money one, and ran a cold ship check at the end. Every claim the agent made was gated by builds and tests we ran ourselves, outside Cursor.
One disclosure carries over from [our first Cursor review](/primer/how-to-use-cursor/): most of the driving went through Cursor's own automation, the [cursor-agent CLI](https://cursor.com/docs/cli/overview) and the cloud-agent surface at cursor.com. That is a real way to use the product, and it means two keyboard-native features, Tab and Cmd+K, were never exercised by our hands. Cursor advertises "unlimited Tab completions" on Pro; we report that as their claim and everything below as our own receipts.
## Act one: the pitch, and the name
We asked for the whole thing in one message: the tracker, per-tool cost-per-unit and burn rate, projected overflow, a keep/downgrade/watch verdict, a "watch mode" for tools with no published ceiling, a price-change log, real seed data, plain JavaScript on Node 22, a local JSON store, tests, and, as a throwaway line, "propose five product names, pick the best one, and use it."
It picked **Ceiling**. Its reasoning, unprompted: the name captures both the allowance you are trying to stay under and the watch-mode case where there is no ceiling to name. The runners-up were Burnrate, UnitCost, Allot, and KeepWatch. Then it built the thing: an Express app on port 5599, a JSON file store, eighteen real tests covering the projection and overflow math, and demo data seeded with the three tools most of our readers pay for, including Perplexity's real 2026 price cuts logged as history. It even pinned a fixed "today" so the demo is deterministic. One prompt in, `npm install && npm run dev`, and this was on screen:
Look at what it inferred without being told. Cursor Pro, seeded at 300 requests by day 15, projects to 620 against a 500 allowance and gets tagged **watch, ten days to overflow**. Claude Pro, allowance unknown, shows **no ceiling** and rides watch mode. Perplexity Pro, under-using its 400 searches, gets a **downgrade** nudge. That is the whole product thesis, working, from a paragraph of English.
## The tool page reads the room
Open a subscription and the price-change log is the part that matters, because it is the receipt for why this app should exist. Ceiling seeded Perplexity's real history straight from our reporting: the February 2026 Deep Research cut from about 600 a day to 20 a month, and the May 2026 halving of pro searches to 100 a week. This is the tool built to catch the thing the tools keep doing.
## Curveball one: the data
New request, the kind a real first user makes: "let me import my usage instead of typing every entry." We asked for CSV import that skips bad rows and reports them instead of crashing. It added a `date,amount` importer that applies the good rows, and returns a per-row report of exactly which lines failed and why: wrong column count, bad date, negative or non-numeric amount. It shipped a test that feeds a file mixing good rows with three distinct kinds of bad ones and asserts both halves. The suite went from eighteen to **twenty**, still green. The endpoint recomputes every projection on import. No crash on garbage, which is the entire point of the feature.
## Curveball two: the money
This is the one our readers came for. We asked it to make Ceiling freemium without dark patterns: a three-subscription free cap stated up front, a server-side gate on the fourth, and a demo checkout that is clearly labeled and charges nothing. It delivered all three, and the labeling held up:
The free limit is printed on the add-subscription form, not sprung at submit time. The fourth add is rejected server-side with a clear message and an upgrade link. The checkout page says "DEMO, no real payment" on the banner, in the body, and on the button, with no fake card fields anywhere. Clicking it flips a tier flag in the JSON store and removes the three-tool cap. It even seeded exactly three subscriptions so the paywall shows on the first load. Three more tests, now **twenty-three**, all passing. Ask a coding agent to wire up monetization and the risk is a dark pattern or a fake Stripe form; we got the shape of a business model with the guardrails on.
## The ship check
We copied the source to a clean directory with no dependencies and ran the cold-start a stranger would: `npm install`, then `npm test`. Install pulled 68 packages with **zero vulnerabilities**; the suite came back **23 of 23**. The thing runs from nothing.
Now the founder's-gap list, because "worth it" has to be straight about the ceiling. What Ceiling is not, yet: it is a single-user app on a single JSON file with no accounts, no real authentication, no real payments, and no deployment. Those are not agent failures; they are the four hard problems a $20 prompt does not solve for you. Cursor got us a credible, tested prototype in an evening. Turning it into a company is still the part with your name on it.
## The lab notes
Beyond the build, the fundamentals from our full protocol held. Codebase question-and-answer went **3 for 3** against ground truth we knew cold, with correct file citations. A brownfield agent task on this site's real repo shipped clean: build passing, house conventions kept, existing code extended instead of duplicated. A same-task Composer-versus-Opus run split exactly where the models differ: **Composer 1.8x faster** and spec-correct, Opus slower but catching an edge case Composer missed. Our own MCP server connected and its tools were called correctly off one nudge. A two-line project rule was obeyed in the exact spot models usually break it. And the cloud loop closed itself end to end:
The model roster behind all of it is the real Pro upgrade: three frontier labs plus Cursor's own two, switchable per request.
## Where it leaks
The leaks are informational, and they rhyme with [what we documented on Perplexity Pro](/study/perplexity-pro-limits/), which is why Ceiling exists. First: Pro's included usage still has no published number. The page says "usage limits for everyday use," and the ledger stamps every request "Included" without ever showing what remains. Two full sessions of building cost nothing beyond the subscription, which is genuinely generous, and also unbudgetable. Second: runs on Auto are logged as "auto" forever, so the model that did your work is never disclosed, which matters exactly as much as the Composer-versus-Opus gap says it does. Third, smaller: the speed models' corner-cutting is quiet, and nothing in the UI flags which corners.
## Real cost
**Hobby is free** and capped. **Pro is $20 a month** ($16 annually) and carried everything in both of our reviews: the frontier roster, the agent, the CLI, a cloud agent, a Bugbot review, and now a full SaaS build with two curveballs and a ship check, all with on-demand billing off and $0 charged past the subscription. **Pro+ ($60) and Ultra ($200)** are the same product with 3x and 20x the unnumbered allowance. Because the quota has no published figure, the only budgeting method that works is the one we used: watch your own meter for a week and let it tell you which tier you are. Ours never showed an on-demand charge.
## The verdict
Worth it. We asked a $20 subscription to be a founding engineer for one evening and it was: it named the product, built it, tested it, took two curveballs including the one about money, and survived a cold start. That is a real answer to "can I build with this," and the answer is yes, up to the four hard problems no prompt solves for you.
Keep both caveats in your pocket. You are buying an allowance nobody will quantify, from the same industry that [taught us how quietly allowances shrink](/study/perplexity-pro-limits/), and an Auto mode that will not tell you who answered. Pick named models for the code you care about, glance at the meter weekly, and Cursor Pro is the easiest recommendation in this category right now. The startup it hands you is up to you.
---
# Open Design: the free design studio your coding agent runs
Section: The Proof
URL: https://okaneland.com/proof/open-design/
We installed Open Design, pointed it at our own site, and let Claude Code drive: brand extraction, a component kit, a sponsor media kit, a PDF export. The output is real, and the token meter shows what free costs.
> **Correction, July 14:** This review originally said Open Design invented the tagline "Where AI actually pays" and baked fiction into our identity files. It invented nothing. The line was live on our own media kit page, and it rode in the structured data this site served on every page, including the very page we handed the extractor. The agent found copy we had forgotten we published. The error was ours, and it sharpens the finding rather than killing it: extraction is more thorough than we credited, and if your site carries inconsistent copy, the brand system will inherit whichever version it finds. Check the brand.json against what you mean to say today. We took our own advice and swept the retired line from every page the same day.
## How we tested
Open Design calls itself the open-source, local-first design workspace where the coding agent you already pay for does the design work. That claim has a clean test: install it, point it at a real site, and let it run with no account, no paid tier, and no help. So we did exactly that. The test subject was this site's own dev build, running on localhost, because we can check every extracted color and font against our own CSS.
The install is a 260 MB signed and notarized macOS app (v0.14.1, released the day before our test), also on Windows, with the source on [GitHub under Apache-2.0](https://github.com/nexu-io/open-design) at 77.4k stars. First run asks an optional role survey and an optional newsletter email; we skipped both and hit no account wall at any point. The free tier is not a demo: it is the whole desktop app, and the home screen makes the scope plain, 444 plugins across prototypes, slides, images, video, and audio before you touch anything.
The free tier on first launch: 444 plugins, from landing pages and kanban boards to wireframes and video loops.
The BYOK pitch held up immediately. The agent picker had already found our Claude Code install from PATH, version number and all, next to a built-in "Open Design" agent that defaults to a deepseek-v4-flash model. We selected Claude Code and used it for everything below.
## The extraction test
The marquee flow is "point it at a website, get a design system." We gave it `http://localhost:4323/` and a one-line brand description.
The fast pass failed. The built-in browser saved what it announced as a successful page snapshot, "Saved page snapshot (HTML + CSS)," and the file it wrote was 55 bytes of nothing. The extraction spinner then ran for over two minutes with no error, no timeout, and no hint of what was wrong. Part of the blame was ours, our dev server had died mid-test, but the app never said so. A status pipeline that reports success on an empty file is the kind of thing you only find by checking the files.
What saved the workflow is the product's whole thesis: the agent. Handed the broken state, Claude Code diagnosed it in one turn, told us the server was down, offered two recovery routes, and, once we restarted the server, fetched the page itself and got to work. It measured the CSS variables, caught and corrected its own font misread mid-run, and finalized the system in 2m 48s, writing 44 files. The app's own meter priced the run at $2.51.
The brand card the agent built: logo, tagline, and the three real font families, each candidly marked "proprietary, shown via fallback."
## What it got exactly right
We graded the extraction against our own stylesheet, and the precision is the story. The `brand.json` it wrote has our background as `#fbfbf8`, named "Washi paper," which is the exact token. The coral accent came out `#e0604a`, exact. The fonts are right: Instrument Serif for display, IBM Plex Sans for body, IBM Plex Mono for mono, with the fallback stacks written out. The logo description reads like it interviewed us: a coral rounded-square seal, corner radius 18 on 100, the kanji 金 in Shippori Mincho at 800 weight. Every one of those details is true, and none of them is written down anywhere on the page as text. It measured them.
It also rebuilt our homepage from the extracted tokens as a live HTML artifact, nav, kicker, italic serif headline, coral CTA, close enough that we did a double take. And it generated a working component kit, buttons, forms, navigation, breadcrumbs, all colored by `var(--brand-*)` custom properties, plus poster, email, newsletter, deck, and landing previews. One extraction run, one $2.51 meter reading, and the folder holds a small design department's week of output.
The component kit from the same extraction: every control derives from one seed of brand variables.
## Where it breaks
**The app's own panels can contradict the agent's files.** After the run, the design-system screen displayed the typography as Times New Roman and Segoe UI. Neither font appears anywhere in our stacks; Segoe UI is a Windows face. The agent's `brand.json` had the right families with a candid "shown via fallback" note, so the data was correct and the display layer picked up the rendered fallbacks instead. If you only read the panel, you would ship the wrong fonts.
**Inconsistent site copy gets inherited as brand truth.** The brand card came back with the tagline "Where AI actually pays." We first published this review saying the app invented that line. It did not, and the correction above owns the error: the line is ours, retired from the masthead but, at the time, still live on our media kit and in the structured data every page served, and the extractor inherited the version it met. That is the real caution. The identity files bake in whichever copy your site actually carries, current or not, and every artifact that inherits the system repeats it. The copy it writes fresh has a separate failure mode: the media kit's dek reached for the exact phrases this publication banned from its own pages. The visual system is measured, and so, it turns out, was the tagline. The guessing happens in the new words.
**Failure costs the same as success.** Every run is metered, and a run that dead-ends on a broken snapshot still bills the tokens. Ours were cheap because the agent recovered fast. A less capable agent, or a subtler breakage, would burn more.
## The media kit test
Extraction proves it can copy what exists. The real product question is whether it can make something new that stays on brand. We briefed it on an artifact this site does not have: a one-page sponsor media kit, with a hard rule, no invented numbers, placeholders only, and prices as TBD. (Our live media kit is a press kit, boilerplate and brand assets, and exactly where the old tagline was still sitting when we ran the test. A sponsor kit, with audience stats and pricing, was new ground.)
The media kit it designed from the extracted system: the seal, the serif, the coral italic, and copy that mostly understood the assignment.
The design came back in 2m 46s for $1.58, and it looks like this site. The layout discipline was real: the plan it announced included "coral rationed to the seal, links, and one CTA," which is precisely our rule, inferred from measurement. The copy understood the positioning better than most humans pitching us: "Sponsor an audience that checks the receipts" is a line we would keep, and it wrote sponsorship terms, one advertiser per send, disclosure labels inline, that match our published standard without being told.
And the constraint held everywhere. Four stat cells shipped as `[PLACEHOLDER]` with a footnote saying the numbers get filled from analytics before the kit goes out. Both prices shipped as `[PRICE TBD]`.
The no-fake-numbers rule, obeyed: placeholders in every stat cell, TBD on every price.
The caveats from the extraction followed it here: the retired tagline sits in the header, inherited from our own pages, and the dek needed a voice edit. Treat the copy as a strong first draft from a designer who has never read your style guide.
## The export receipt
Design tools love to trap work in their own format. This one does not. The Download menu offers PDF, image, zip, and standalone HTML, plus save-as-template. We exported the media kit to PDF and got a clean, correctly styled 3-page document, the kind you could send to a sponsor after one copy pass. Every project file, the brand JSON, the HTML artifacts, the downloaded font files, sits on your own disk in plain formats. The "real files you own" claim is simply true.
## What free means here
The app costs nothing, and nothing we touched was gated. The bill arrives through a different door: every design action is an agent run, metered in your tokens. Our two working runs totaled $4.09 at API rates by the app's own meter, drawn from a Claude subscription in our case, so no extra invoice, but real usage against the plan's limits. Price an artifact at a dollar or three of tokens and a few minutes of wall time, and "free" starts to look like a usage-based tool where you already hold the contract. There is an optional paid service, Open Design Cloud, that sells managed access to hosted models per token for people who do not want to bring an agent; we did not need it, and nothing pushed us toward it.
## The verdict
Worth it. Free, local, no account, real files, and the extraction quality on our own site was measurably precise, down to individual hex values and the glyph font of our seal. For a vibe coder already paying for Claude Code, this turns that subscription into a design tool for the cost of tokens, and the failure we hit was recoverable by the very agent the product is built on. Go in knowing its two habits: the status layer can smile through a broken step, so check the files, and the words it writes fresh are still first drafts. It reads your site better than it writes for it: the extraction is measured, even the words. The generation still needs your pass. Keep the split in mind and it earns the download.
---
# Creatify: the product-page ad machine, for the right seller
Section: The Proof
URL: https://okaneland.com/proof/creatify/
We bought the Pro plan and drove every tool in the box: URL-to-Video on a real Amazon listing, three custom avatars, static image ads, the ad-cloning agent, the playable-ad builder, and the credit meter. Turning a product page into a stack of usable ads is the real product. The custom-avatar side dropped a render without a word, and the ad-launch suite wants your live ad accounts before it does anything.
## How we tested
We did not watch a demo reel and call it a verdict. We bought the Pro plan, signed in on the Akira Sumi workspace, and drove every tool in the sidebar: URL-to-Video on a real Amazon listing, three custom avatars, a run of branded spots, static image ads, the ad-cloning agent, the playable-ad builder, the model-picker generation studio, the node canvas, and the competitor tracker, watching the credit meter after every job. Pro comes with 300 credits a month. Everything below is what we saw, and what it cost.
One note on the clips in this review. The people in them are not real. Creatify invented them, which is the whole point of the tool, and we are showing them here as specimens of what it produces; nobody in them endorses anything.
## The one feature that earns the plan: URL-to-Video
Paste a product URL and Creatify does the work that usually takes a creative team a day. We gave it an Amazon listing for a Blue Yeti microphone. It scraped the page, pulled the product details, wrote a script, and came back with a run of ready ad variants: the actual product rendered as b-roll, an avatar presenter dropped into the corner, burned-in captions, and a music bed. From one link.
The flagship feature, unedited: a single Amazon URL turned into a captioned product ad with an avatar presenter and generated b-roll. Notice the caption briefly collides with the on-screen product text on a transition, which is the kind of rough edge you clean up in the editor before you ship.
This is where the tool is genuinely strong. The variants are not all keepers, but several are close enough to run after a light edit, and generating another batch is a few credits. For a solo marketer who needs a dozen angles on a product by lunchtime, this alone can carry the subscription. The one full render we exported ran about 28 seconds on the Aurora model and cost 10 credits.
## Where the scraper breaks
The catch is that URL-to-Video is tuned for retail. The Amazon page came back cleanly fielded: title, price, features, image set. When we pointed it at a SaaS landing page instead, the scrape degraded badly. It returned a single run-on block of the page's navigation and marketing copy, thousands of characters with the words jammed together and no structure to build a script from. The tool did not warn us; it just produced a weaker starting point.
The lesson: feed it a real product listing with structured data; a marketing site starves it. On the right input it is impressive. On the wrong input it quietly gives you less to work with.
## The custom avatars: it will invent a person, but not animate a drawing
Pro includes three custom-avatar slots. Making one from a text description is free, and the results are convincing: we described a presenter and got back a photoreal person who reads as a real UGC creator on camera. Here is one of ours reading an Okane Land line.
A custom avatar built from a text prompt, reading a script we wrote. The face, the voice, and the studio are all generated. This is a re-render: the first pass mispronounced the brand name, so we respelled it phonetically in the script and ran it again.
Two things about that clip are worth the price of the review.
First, pronunciation. The ElevenLabs voice read our brand name wrong on the first pass. The fix was not a setting; it was respelling the word phonetically in the script so the voice would say it correctly, then paying to render again. If your brand, product, or founder has a name the model has never seen, budget a render or two to get it right.
Second, the guardrail. We tried to build an avatar from our own hand-inked house portrait using image-to-avatar. Creatify rejected it: "Not a real human, please check the photo again." So the tool will happily fabricate a photoreal person from a sentence of text, but it refuses to animate a stylized illustration of one. That is a defensible safety line. It is also a limit worth knowing before you plan a campaign around a drawn mascot.
One more trick closes the loop: the avatar can hold the product. The stock b-roll our ads kept generating showed a man's ringed hands on the mic, which clashes with a female presenter. The fix was the New look feature: describe her at the desk with the microphone in her hands, feminine hands, no rings, and it generates that scene for the same avatar. From there the simplest ad of the whole test was one render: her, the product, and the pitch in a single continuous take to camera. No cutaways, no music bed, and nothing to clash, which is closer to what real UGC looks like than the assembled cuts anyway.
The one-take version: the custom avatar delivers the pitch to camera with the product in her own hands, from a single New look render. The lesson that got us here: describe the hands you want, or inherit whichever hands the model dreams up. One caveat for planners, audible at the very end of this clip: the renderer cuts scripts at its 15-second block boundary, so write to the block or budget another block.
## The reliability tax
A methods note first, because it changes the reading. We ran this test two ways: scripted browser sessions doing the heavy repetition, and ordinary by-hand use of the same tools. The two saw different things. In the scripted sessions, text-to-avatar jobs climbed to 99 percent and sat there for minutes, and the URL-to-Video preview step did the same. The identical text-to-avatar job run by hand completed in about a minute. So treat the stalls as something Creatify's queue does under some sessions and loads; our by-hand runs were quick.
One failure was real under any reading, though. We wrote a script, hit generate, and nothing happened: no error, no project in the queue, and no credits deducted. We only caught it because the credit meter had not moved. We reselected the avatar, fired again, and that time it landed. The tell is useful to know: a real submission drops a card into your Projects list immediately and charges you when the job completes. If neither happens, the click did not take.
On the credits themselves, the meter is trustworthy. A 15-second avatar render in the simple tool costs 5 credits; the same job re-rendered on the Aurora model through the editor costs 3; the 28-second URL-to-Video export cost 10. Every one of those showed its price before we committed and only came off the balance when the job finished.
## The statics are the sleeper deal
Image Ad takes the same stored product and returns static ad creatives instead of video. We pointed it at the Blue Yeti product it had already scraped and got four finished statics for 2 credits: a lifestyle desk scene, a spec-callout sheet, a feature infographic, and a clean product hero with a call to action.
The spec sheet is the one that surprised us. It listed all four of the Yeti's pickup patterns, correctly labeled, with matching icons and a sensible one-line benefit under each. No garbled AI text, no invented features, correct brand logo. That is half a credit per usable static, and it is the best value-per-credit in the product.
One of the four statics, unedited, from the 2-credit batch. Every pattern name is right, the icons match, and the text is clean. This is the kind of factual discipline the video side does not always manage.
## Ad Clone: the agent shows its work
Ad Clone is the tool that explains where this product is going. You pick your product, then a reference ad. The reference library is not canned examples: it is live trending ads, and when we selected the Blue Yeti it automatically surfaced competitor microphone ads, including a DJI Mic 3 UGC spot that had been running for 39 days. Clone a competitor's proven winner with your product swapped in. That is the pitch, and it pairs with the competitor tracker as one workflow: find their winner, clone it, run it.
Selecting a reference does not open a form. It drops you into Creatify's chat agent, which then works in the open. Ours analyzed the DJI ad into seven anchor scenes, then wrote out exactly what it would change: the DJI clip mic becomes the Yeti, and because the Yeti is a desk condenser rather than a clip-on, it rewrote the narrative around a desktop setup while keeping the ad's form. It generated a presenter persona to match the reference's casting, composed a 33-second music bed, rendered start frames for every scene, and dispatched the scenes to render in parallel, narrating each step.
It also self-corrects. Its first attempt at one scene drew a small handheld mic that looked suspiciously like the DJI it was cloning; the agent re-shot the frame with the actual Yeti, on its own, before rendering the scene. Watching a tool catch its own product swap failing is more reassuring than any accuracy claim.
And it takes revisions like a colleague. After the clone finished, we sent one follow-up message: make our own custom avatar the on-camera presenter, and re-voice the whole narration to match her. We attached a single 300-pixel photo of her. The agent locked her look from that one image, rebuilt only the talking-head scene around her, swapped the narration to a matching female voice without touching the other video tracks, and reassembled. She came back on camera with the product, indistinguishable from the rest of the ad.
The agent-built clone of a competitor''s live ad, after one revision message: our custom avatar is now the presenter, from a single photo, with the narration re-voiced to match her. The product scenes, captions, music, and end card are untouched from the first pass.
The finished clone is real work. Forty seconds, seven scenes, and the swap held in every one of them: the correct Blackout Yeti in the hands-on shots, the burned captions in the reference's style, the presenter at a desk with the actual product, and a branded end card. We would trim it and run it. The one flaw is the usual one: in tight close-ups the mic's small control labels garble into almost-words, the kind of thing you only catch frame by frame, and the kind of thing that quietly marks a video as AI.
Now the bill. The half-credit lines in the transaction log are just the thinking. The scene renders behind them are full video generations, and by the time the final cut assembled, the run had consumed 173 credits. More than half a month's Pro allowance, close to an hour of wall-clock time, for one 40-second ad. The presenter-swap revision, scoped as tightly as we could ask for, cost another 43. At the Pro rate that is about $57 for the clone and $14 for the revision, which puts Creatify's own Studio tier, humans making your video for $100 to $200, in uncomfortable focus. We ran the per-clip-versus-real-bill numbers separately in [the full economics of AI UGC ads](/study/ai-ugc-ad-economics/). There is no total shown up front; the agent spends as it goes and you find out in the log. The log also leaks something Creatify does not advertise: the line items carry Anthropic tool-call IDs, so the agent doing the cloning is Claude under the hood. Impressive engineering, but budget for it like a small production.
## The rest of the box
Three more tools round out the sweep, fast:
**Asset Generator** is the escape hatch. It is a raw generation studio for video, image, and audio where you pick the model yourself: Kling, Google's Veo, Seedance, Wan, HappyHorse, and Gemini's video model are all in the menu, priced in credits (a 5-second Kling image-to-video runs 14). If you want b-roll no ad template gives you, it is there, but at those prices a dedicated video-gen subscription beats it for volume.
**Ad Flow** is a node-based canvas, closer to n8n than to a video editor: product in, prompt nodes, generation nodes, run all. It ships template pipelines for the formats you see trending (challenge POV clips, product visual effects, UGC showcases). The prompt box names its model too: Claude Sonnet. Between this, the cloning agent, and the media buyer, most of Creatify's intelligence layer is Claude with an ad-ops toolbelt.
**HTML Interactive Ad** builds playable ads: it read our product, pulled brand colors, and produced a phone-framed scratch-to-reveal unit with correct branding, feature chips, and a shop button, editable afterward in plain language. One playable costs 10 credits, the same as our entire 28-second flagship video, so it only makes sense if you are actually buying playable inventory.
And then there is **Studio**, Creatify's done-for-you agency tier: $100 to $200 per video, from $5,000 a month, with, in their own words, human QA on every asset and zero hallucinations. Read that twice. The company selling AI-generated ads prices the removal of AI mistakes as its premium product. That is the clearest statement in the whole app of where the self-serve tier's limits are.
## The suite we did not switch on
Creatify is not only a video generator. It ships an ad-operations layer: a competitor ad tracker, an ad launcher, and an AI media buyer built on Claude. We opened the tracker and it pulled a rival advertiser's entire live library, over a thousand ads, and laid out the hooks and formats they run most. As competitive research, that is a strong tool on its own.
The launcher and the media buyer are a different commitment. They want you to connect live Meta, TikTok, or AppLovin ad accounts so the tool can push creative and spend on your behalf. We did not connect any ad account, so we cannot tell you how well the automated buying works, and we [would not hand an AI agent a spending account without a lot more testing than one review allows](/study/do-ai-agents-work-yet/). Treat that half of the product as unproven here, and go in knowing the powerful parts are the ones that touch your money.
## What it really costs
At the time of testing, the plans ran: a free tier with 10 credits a month and the Creatify logo tiled across every frame; Starter at $39 a month; and Pro at $99 a month for 300 credits, watermark-free, with the ad suite. The credit menu, from our own transaction log: 5 credits per 15 seconds of avatar video in the simple tool, 3 for an Aurora re-render in the editor, 10 for our 28-second URL-to-Video export, 2 for four static image ads, 10 for one playable, 14 for five seconds of Kling through Asset Generator, and 173, spent half a credit at a time plus scene renders, for one agent-built clone. So 300 credits is roughly a few dozen finished spots a month, or one big clone and change, fewer if you iterate a lot. Custom-avatar creation is free, but only three slots are included, and each additional avatar is a paid add-on. Above all of it sits Studio, the human-service tier, from $5,000 a month.
The free tier is a preview. The tiled watermark makes free output unusable for anything real, which is a fair way to gate a paid tool but worth saying plainly: to get a clean frame, you pay.
## The verdict
Creatify is two products in one subscription. The first is the product-page machine: URL-to-Video, the 2-credit statics, the 5-credit avatar spots, and the cloning agent, all built on the same trick of reading a real listing and doing something disciplined with it. That machine is the whole case for buying. We fed it one Amazon listing and a $99 plan, and it gave back a month of creative: thirteen video variants from one URL, four clean statics, a competitor clone we would run after a trim, and a one-take UGC spot fronted by a presenter we invented from a sentence of text.
The scope on that machine is tight, and the tight scope is why the verdict reads situational rather than a clean buy. Creatify pays off for someone selling real products who will feed it real listings and edit what comes back, and for that buyer the cheap tools carry the whole plan. The agent is the luxury option: brilliant to watch, and priced like a small production, so treat it as one. Two groups should hold off entirely: anyone marketing a SaaS or service site, because the scraper that powers everything degrades off retail pages, and anyone counting on the ad-launch suite, which asks for your live ad accounts before it proves anything. And keep the Studio tier in mind as the company's own tell: when the vendor charges $5,000 a month to put humans back in the loop, plan on being your own quality check at $99. Buy it for the product-page machine, watch the meter, and it pays for itself in the first batch.
---
*Editor's note, July 24, 2026: the verdict on this review was revised from worth it to situational. No testing or numbers changed; the rating now matches the scope limits the review already documented, a scraper that degrades off retail pages and an ad-launch suite we left unproven.*
---
# Clay: the best prospecting engine we have tested, and the bill that comes with it
Section: The Proof
URL: https://okaneland.com/proof/clay/
We found 50 real leads, ran the six-provider email waterfall, and drove Clay's AI agent across ten companies on the live tool. The AI is the real thing and the coverage is high. The catch is the price and the learning curve.
## How we tested
We logged into Clay on the Free tier and drove the real product end to end. We built a lead list from scratch, ran the email waterfall on real people, tried the phone waterfall, pushed Clay's AI agent across ten companies, wrote personalized openers, and watched the credit meter the whole way. Everything below is what the tool returned, with the receipts. The whole exercise cost about 30 of the 2,000 monthly credits.
## Claygent is the standout
Clay's AI research agent, Claygent, is the thing that separates it from a database with a spreadsheet bolted on. We gave it a deliberately awkward job: find the current CEO of ten companies, names only. It went ten for ten. It got the easy ones (Tim Cook, Mark Zuckerberg, Andy Jassy) and, more tellingly, the hard ones: Waymo's co-CEOs, and Atlassian's Mike Cannon-Brookes, correct only if you know Scott Farquhar had stepped down.
Claygent on a current-CEO task: ten for ten, and a correct "Unknown" for Activision rather than a guess.
The receipt that mattered was Activision. There is no current CEO; Bobby Kotick left after the Microsoft acquisition. Claygent did not guess. It returned "Unknown," with a written rationale ("the current leadership team identifies Rob Kostich as President, but does not list a Chief Executive Officer"), a confidence rating, and the two pages it had actually visited (the company's About page and the Activision Blizzard newsroom). For a tool whose entire job is to fill cells, refusing to fill one when the answer is "no data" is the behaviour you want and rarely get. It cost about two credits a row, and Clay's own AI wrote the structured prompt and picked the model (clay-neon) without us touching either.
The receipt under the cell: Claygent's reasoning, its confidence, and the exact pages it visited, before returning "Unknown."
The "without us touching either" is worth dwelling on. We typed a plain sentence; Clay's own AI classified it as a web-research task, selected its mid-tier model (clay-neon over the cheaper clay-helium and pricier clay-argon), and wrote a structured prompt that included "do not infer or guess; extract only what is explicitly stated." That is the thing that flattens the learning curve: you describe the outcome, and the tool configures the agent.
The AI configures the AI: from one plain sentence, Clay picked the Claygent use case, the clay-neon model, and wrote the structured prompt itself.
## Finding the leads is the easy part
We typed a plain-English target into Clay's lead finder, Sculptor: "heads of marketing at B2B SaaS companies, 11 to 200 staff, in the US." It built nine structured filters from that sentence, queried a database it reports as 338 million people, and returned 3,063 matches, real working marketers at real small SaaS companies; a demo would have shown famous names. We capped the import at 50 (two per company, for variety) and pulled them into a table. That import was free. In Clay, finding and loading leads costs nothing; the meter only starts on enrichment.
Sculptor turned one sentence into nine filters over a database it reports as 338 million people: 3,063 matching marketers.
## The waterfall is the real product
The headline feature is "waterfall enrichment," and it earns the name. We added a Work Email column, and Clay expanded it into a visible chain of providers: it tries the first, validates the result, and only if that comes back empty does it spend a credit on the next, all the way down. On our 50 real SMB leads it found a valid work email for nine of every ten, and we watched it work: for one lead the first four finders returned nothing and the fifth, Findymail, landed the address. Downstream columns read "Run condition not met," which is the waterfall doing exactly what it claims, stopping the moment it has a match so it does not pay every provider on every row. It ran about a credit a row, and the run dialog quoted the cost ("run 49 rows, 24.5 credits") before we committed to it.
The waterfall, found: nine of ten work emails, with the downstream providers skipped ("run condition not met") once a match was in.
That is the genuine advantage over a single-source tool like Apollo: instead of one provider's coverage, you get the union of many, in priority order, billed only for the ones that run.
One flag on that nine-of-ten, because it matters: these were marketers at real but findable SaaS companies, the friendly end of the distribution. Coverage falls on smaller, older, or non-US firms, and on people who keep a thin web footprint. Treat 90% as the top of the range. The independent test we trust, chaining four providers across 200 harder prospects, [landed between 40% and 78%](https://hackceleration.com/clay-review). The waterfall genuinely beats a single source; it does not repeal the limits of the underlying data.
## Personalization works, with an asterisk
We asked Clay's AI to write a one-line cold-email opener for each lead from their title, company, and LinkedIn headline. It auto-routed the job to a cheaper model than the research agent (one credit a row instead of two) and produced openers that were genuinely specific: "As VP Marketing at 1mind, your AI-native GTM focus and GTM AI Academy work stood out to me." The asterisk is that four of five opened with the same "As [title] at [company]" scaffold. This is real personalization at scale, but it is a draft. The tool will pull the right detail; it will not give you a voice.
Specific, and templated: most openers reach for the same "As [title] at [company], your [X] stood out" scaffold. Real detail, unfinished line.
## Then you act on it
A list you cannot use is just a bill, and this is where Clay stops being a spreadsheet. From the same table you can download a CSV, push to a CRM, send to a sequencer like Smartlead or Instantly, or run an email campaign inside Clay itself. It even exposes its enrichments to ChatGPT and Claude over an MCP server, so you can ask an assistant to enrich a lead and have Clay answer.
Not a dead end: from the table you can push to a CRM, a sequencer, a CSV, or a native Clay campaign.
The other half is Signals: turn any enrichment into a trigger and Clay watches for the moment to reach out, a job change, a new hire, a promotion, a funding round. That is the difference between a static list and timed outbound, and it is the part most single-source tools simply do not have.
Signals: monitor a job change, a new hire, a promotion, or a funding round, and trigger outbound on the moment it happens.
## The money is the catch
Clay's pricing is [a metered credit system, and it is where people get surprised](/study/unit-economics-of-wrapping-an-llm/). Two facts set the frame. First, the good data is the expensive data: a mobile-phone lookup is a fourteen-provider waterfall at about 11 credits a row, roughly ten times the cost of an email, so phoning the same 50 leads would run about 570 credits. Second, the Free tier is a demo: 2,000 credits a month, and phone enrichment is blocked entirely. When we tried to run it, Clay refused with a flat "your subscription does not allow this integration to be added." Email and AI enrichment work on Free; phones and the heavier providers want a paid plan.
Phones are the budget-eater: a fourteen-provider waterfall at about 11 credits a row, much of it tagged "Upgrade" and blocked on the Free tier.
The paid plans are not cheap. Clay [restructured its pricing](https://www.clay.com/pricing) in March 2026 into Launch (about $167 to $185 a month) and Growth (about $446 to $495 a month), plus custom Enterprise. Credits meter from roughly $0.05 each. Used well, on a tight ICP with the right waterfalls, that is a fair price for the coverage. Used carelessly, with broad lists and the expensive enrichments switched on, it is how a $349 plan becomes a $349-plus-overage plan.
The Free tier gives 2,000 credits a month. Our whole test, Claygent and the email waterfall included, spent about 30.
## The real cost per lead
Clay never quotes you a price per lead, so here is the math from our runs, at Clay's own credit prices (data credits start around five cents each). A verified work email ran about a credit, call it a nickel. A Claygent research column, like our CEO lookup, ran about two credits, a dime. A mobile number is the outlier at roughly eleven credits, north of fifty cents, and it is paid-tier only.
Now put it on a real list. Enriching a thousand leads with a work email and one AI research column is around three thousand credits, on the order of $150 of credit value, before you have written a word of outreach, and that sits on top of the monthly plan. Add phone numbers and you can double or triple it. That is the number nobody puts in front of you, and it is the whole reason the meter beats the sticker price as the number to watch.
The flip side is the good news: an email at a nickel, found by the union of six providers, is genuinely cheap per unit. Clay does not get expensive because any one lookup is dear. It gets expensive when you run a lot of them, or reach for the dear ones, without watching the total.
## Where it bites
The learning curve is the real tax. Clay's surface area is enormous: tables, waterfalls, signals (job changes, new hires, funding, hiring), functions, a sandbox mode, and an MCP server that pipes its data into ChatGPT and Claude. The power is the point, but it is a lot, and we fumbled the sandbox toggle ourselves on the first try, which is the single most common complaint in reviews. Plan a week of real use before it pays you back.
Two more cautions. Clay's marketing implies it can triple your match rate; the independent test we trust put the real uplift closer to a doubling, which is still good but not the headline. And, like every tool in this category, it will not fix a bad list or a weak offer. It is a faster way to be right or wrong; the strategy is still on you.
## Clay, or something cheaper?
Clay is not the only way to find an email, and most readers should not start here. The real question is whether the waterfall and Claygent earn the premium over a flat-rate tool.
If you need a few hundred leads a month for a tight, well-known ICP, a single-source tool is cheaper and far simpler. Apollo bundles a contact database and a sequencer for tens of dollars a seat, where Clay runs hundreds; Instantly and Smartlead handle sending and basic enrichment in the same range. None of them match Clay's coverage, but for an obvious ICP, one provider often gets you most of the emails for a fraction of the price and none of the learning curve.
You move to Clay when you hit the ceiling of that: when single-source coverage leaves too many rows blank, when you need research or scoring per lead that no database ships with, or when you want signals-triggered outbound at volume. That is the job the waterfall and Claygent are built for, and nothing flat-rate competes. The order is the whole point: buy the cheap tool first, and graduate to Clay when you have a reason stronger than a hunch.
## The verdict
Clay is the most capable prospecting and enrichment tool we have driven, full stop. [The AI agent is accurate and refuses to hallucinate](/study/do-ai-agents-work-yet/), the email waterfall genuinely beats single-source coverage, and the whole thing is wired to act on what it finds. It earns the verdict.
The scope on that verdict is tight, and it is the whole point. Clay is worth it for someone running real outbound volume who will learn the tool and watch the meter. For that person it is a clear yes. For the solo builder who needs a few dozen leads a month, it is overkill and overpriced, and a $30 Apollo or Instantly plan does the job with a fraction of the learning curve. Buy Clay when the volume demands it, and keep one eye on the credits.
---
# Perplexity Max: the deepest toolset in AI search, and where it still leaks
Section: The Proof
URL: https://okaneland.com/proof/perplexity/
We bought Max, signed in, and drove every tool: nine models, Model Council, Deep Research, the Computer agent, the premium data connectors, Finance and Academic. The advanced tools are genuinely powerful. The everyday search still leans on content mills, and most people do not need the $200 tier.
## How we tested
Our first pass was the free, logged-out version: four queries, a false-premise trap, a stats trap, and a hard signup wall after three searches. It refused to fabricate and got the facts right, but it cited content mills and gated us fast.
So we bought **Max**, the $200-a-month top tier, signed in, and drove every tool in it: the full model picker, the four search modes, Model Council, Deep Research, the Computer agent, Spaces, Connectors, Workflows, Memory, and the Finance and Academic surfaces. Everything below is what those tools actually returned, with the receipts.
## What Max actually unlocks
Two things gate behind Max. First, the **models**. The picker carries nine: Best, Sonar 2, GPT-5.4, GPT-5.5, Gemini 3.1 Pro, Claude Sonnet 4.6, Claude Opus 4.8, Kimi K2.6, and Nemotron 3 Ultra. Two of them, **GPT-5.5 and Claude Opus 4.8**, are Max-only. Second, the **modes**. The search box switches between Search, Deep Research, Learn step by step, and **Model Council**, which is also Max-only.
The roster. Nine models, with GPT-5.5 and Claude Opus 4.8 reserved for Max.
## The everyday answer is genuinely strong
We asked Claude Opus 4.8 to compare a year of running Llama 3.3 70B locally on a Mac Studio against a frontier API, with the math. It did not hand-wave. It separated the two cost structures (local is a fixed cost with near-zero marginal cost; API is pure pay-per-use), priced a Mac Studio M3 Ultra with 192GB at about $5,800 plus roughly $95 a year of power, modelled light, moderate, and heavy API usage in a table, and then added the caveat that mattered: GPT-5.5 outperforms Llama 3.3 70B, so this was never a quality-equal trade. Fifteen sources, sound reasoning.
Opus 4.8 on a cost question: two cost structures, real prices, and the caveat that the two options are not quality-equal.
## Model Council is the standout
This is the feature that justifies the tier for a certain kind of user. Ask a contested question and Model Council convenes three frontier models, here **GPT-5.5, Claude Opus 4.8, and Gemini 3.1 Pro**, each reasoning independently, then synthesizes them. We asked whether a bootstrapped solo founder should build on a frontier API or self-host an open model.
The output is a "Where Models Agree" table (all three converged on starting with an API and deferring self-hosting, with the GPU utilization trap as the key reason), a "Where Models Disagree" table, a "Unique Discoveries" list (Opus flagged that TGI entered maintenance mode in December 2025; Gemini flagged GPT-5.5 cached-input pricing at $0.50 per million), and a synthesis. It even noted that GPT-5.5 "naturally highlights its own model's strengths," a sharp piece of self-awareness most single answers never give you.
Model Council: three frontier models, a checkmark grid of where they agree, plus where they split and what each found alone.
## Deep Research is consultant-grade, with a catch
We asked Deep Research for the real total cost of ownership of a small AI SaaS in 2026. It ran eight steps, fired off three rounds of searches (inference pricing, churn benchmarks, Stripe fees and hidden costs) with "Insights" passes between them, and wrote a structured report: an executive summary, four pillars (model inference, cloud hosting, Stripe fees, churn) each with their own pricing tables, and a synthesized cost-stack model at ~$500K ARR. It is the kind of brief you would otherwise pay a consultant for, and you can export it.
The catch is the sourcing. Deep Research pulled from dozens of low-authority SEO blogs (Groovy Web, Bananalabs, contracollective, zendevy, churntools) alongside the few solid ones, and at one point cited a politics magazine for a claim about Anthropic's agent billing. The structure is excellent. The inputs need a human pass.
Deep Research, "Completed 8 steps": a multi-section TCO report with pricing tables. The structure is consultant-grade; the sources are a mixed bag.
## Computer is an agent that actually ships
Computer is the agent. You describe a job and it plans a task list, researches, builds an artifact, and shares it. We asked for a spreadsheet comparing six mini PCs for local LLMs, with citations per row. It wrote a four-step plan, researched across **47 sources**, and [produced a real Excel file](/study/do-ai-agents-work-yet/) (Mac Studio M3 Ultra: 512GB, $9,499, ~14-16 tok/s; Mac mini M4 Pro: 64GB, $2,299, ~10-15 tok/s, and so on) in **1 minute 21 seconds**, then offered follow-ups including a monthly price monitor. The same engine builds slide decks, websites, and reports.
The Computer agent: a four-step plan, 47 sources, and a finished Excel spreadsheet in under 90 seconds.
## Academic fixes the thing that was broken
The source-quality problem has one clean fix: **Academic** mode. We asked whether peer-reviewed studies show AI coding assistants improve productivity. The sources shifted to arxiv, SSRN, Reuters, and InfoQ, and the answer was rigorous: the Microsoft and Accenture randomized trials (4,867 developers, +26% tasks), the METR slowdown (experienced developers took 19% longer while believing they were 20% faster), and a 37-study systematic review, laid out in a comparison table. That is the same evidence our own [Study on AI coding speed](/study/does-ai-coding-make-you-faster/) is built on, sourced properly.
Academic mode: the same question, but sourced to arxiv, SSRN, and Reuters instead of content mills.
The other half of the data story is **Connectors**. From the Pro tier up, Perplexity includes premium research data that normally costs a fortune on its own (PitchBook, CB Insights, Statista, Wiley journals, and a US case-law library), and connects to your Google Drive, Gmail, and Dropbox so it can answer over, and act on, your own files. Worth being precise: this is a Pro feature, which is part of why Pro is enough for most people.
Premium data, included: PitchBook, CB Insights, Statista, Wiley, and a legal library, plus your own cloud drives.
## Finance is a terminal in the chat
The Finance surface is a Bloomberg-lite: live futures and the VIX, real-time quotes, market-news summaries, a screener, earnings, congressional-trade tracking, a watchlist, and a portfolio you can sync through Plaid. You can ask plain-English questions about any of it.
Finance: live quotes, charts, market news, a screener, and Plaid portfolio sync, all queryable.
There is more we drove and will not belabor: Spaces (custom collections with their own instructions and files), Workflows (pre-built agent recipes for financial models, clinical briefs, store optimization), Memory (a persistent, structured store of what you have worked on), Skills, and the Health and Patents surfaces.
## Where it still leaks
The one finding from the free-tier review survives Max intact: the everyday search and Deep Research over-trust the open web. Perplexity sells "the most trusted sources," but in practice the default sourcing skews toward SEO content farms, and the deeper the research, the more of them it rakes in. Academic mode and the premium connectors are the antidote, but they are opt-in. If you run a default query and act on the headline number, you are trusting whatever blog Perplexity happened to find. Cited is not the same as sourced.
## Real cost
The free tier exists but gates after a few anonymous searches. **Pro is $20 a month** ($17 when [billed annually](https://www.perplexity.ai/pro)) and already includes the Computer agent, the premium data connectors, and most of the models, which is the core of what most people need. One caution before you prepay anything: Pro's usage allowances have been cut repeatedly since this review ran, and [our study of 1,024 subscriber posts](/study/perplexity-pro-limits/) maps each cut and what to verify before you buy. **Max is $200 a month** ($167 annually), ten times the monthly Pro price, and the extra is narrow but real: the frontier reasoning models (GPT-5.5 and Claude Opus 4.8), Model Council, and much higher limits for running Deep Research and the agent at scale. The gap is not the quality of an ordinary answer, or even the premium data. It is the top models, the council, and the ceiling on heavy use.
## The verdict
Situational, and that is not a knock. Perplexity Max is the deepest toolset in consumer AI right now: Model Council, Deep Research, and the Computer agent each did real, useful work in our tests, and the included premium data is a genuine edge for anyone who needs it. If you are a founder, analyst, or researcher who will run deep reports, convene the model council on hard calls, and let the agent build things most weeks, the $200 pays for itself.
If you are not, you will spend $200 to use a $20 product. Buy Pro, turn on Academic mode for anything that matters, and keep clicking through to the sources. The tools are extraordinary. Most people just do not need this many of them.
---
# Surfer SEO: a strong scoring engine wrapped in a paywall maze
Section: The Proof
URL: https://okaneland.com/proof/surfer-seo/
We ran Surfer end to end on a live site with Search Console connected, then checked our verdict against what real users report. The dual SEO and AI-Search scoring is real and ahead of older tools. The AI writer inventing a "we tested it" claim is not.
## How we tested
We did not read other people's reviews and call it a verdict. We ran Surfer ourselves, on a live site, with Google Search Console connected, and drove every tool in the sidebar. The test workspace was a real publication (vettedconsumer.com), and the keyword we built a brief for was "best mini pc for local llm," a genuine buyer-intent query in that site's niche. Everything below is what we saw, with the screenshots to prove it. Then we checked our verdict against what other users report, and re-fetched every outside quote from its source.
The actual test: a real buyer-intent query in a real workspace.
## What is genuinely good
**The dual Content Score is the real product.** When you build a brief, Surfer runs a "Deep Research" step that does two things at once: it crawls the live Google SERP (ten ranking pages) and it scrapes [the answers that ChatGPT, Gemini, Perplexity, AI Mode, and Google's AI Overviews give](/proof/perplexity/) for your query. From that it builds two separate guideline sets and scores your draft on both SEO and AI Search. That AEO/GEO angle is where the market is heading, and Surfer is further along than the older keyword-density tools.
Deep Research running live: it scrapes ChatGPT, AI Overviews, Gemini, AI Mode and Perplexity for the AI-Search guidelines, and crawls all 10 Google results for the SEO ones. That is the dual scrape, in motion.
The scoring engine itself is mature. We let Surfer generate a full listicle, and it came back at **90 overall, 79 on SEO and 100 on AI Search**, with 81 entities to cover, recommended headings, and a one-click Auto-Optimize. Green means you have used a term enough, red means add more. It is the most complete on-page guidance we tested.
The dual score: 90 overall, 79 on SEO and 100 on AI Search, with the entities to cover down the side.
**The Search Console connection is the standout for an existing site.** The Content Audit and Recommendations pulled our real ranking pages and flagged real opportunities: a post sitting at position 41 with a low SEO score, another ranking position 3, a third at position 6. That is concrete, do-this-next guidance.
Real pages, real positions. The DGX Spark post is stuck at 41 with a score of 33; two others sit at 3 and 6.The connected Performance view: 319 impressions, 2.2% average CTR, average position 12.8.
## Where it breaks
**The AI writer invents authority.** This is the one that matters most. In the draft it generated, unprompted, Surfer wrote: "We tested each against real-world inference workloads using popular frameworks and quantization formats." Nobody tested anything. The model fabricated a testing claim to sound credible. For any publisher whose whole value is receipts, that is a line you would have to hunt down and delete in every single draft, and one slip publishes a lie.
The receipt, straight from the editor: "We tested each against real-world inference workloads using popular frameworks and quantization formats." Nothing was tested. It scored 90 all the same.
The rest of the writing is competent but generic, and it ignored the voice instruction we gave it ("skeptical, no hype, real RAM and VRAM numbers"). Generation was also slow, two to three minutes for one listicle. Treat the output as a scored first draft to rewrite, never as something to ship.
The full listicle in the editor: competent structure, generic prose, and it ignored the voice we asked for.
## The paywall maze
Here is the part the pricing page does not make obvious. On the plan we tested, most of the headline tools were locked, each behind a different upgrade:
| Tool | What it costs to unlock |
|---|---|
| Keyword Research | Upgrade to Standard |
| AI Visibility / AI Tracker | Upgrade to Standard |
| Topical Map | Upgrade to Pro |
| Topic Research | Upgrade to Pro |
| Audit | Upgrade to Pro |
| SERP Analyzer | Upgrade to Peace of Mind (the top tier) |
So the marquee "be the brand AI talks about" pitch, and the core SEO research tools, are not in the entry plan. What you can actually use at the bottom is the Content Editor plus the Search-Console-fed views. The SERP Analyzer, oddly, is reserved for the most expensive plan of all.
The SERP Analyzer sits behind the top Peace of Mind tier. Each major tool had its own upgrade wall.
## What the upgrade actually buys
After the first pass, Surfer's support team switched on a Pro trial, so we went back and drove every tool the entry plan had walled off. Most of them are the reason to pay.
**Keyword Research** clustered our seed "mini pc for local llm" into eleven keyword groups, each tagged by search intent and carrying a search volume and difficulty score, and it exports to CSV. The clustering drifted toward "small llm" over the "mini pc" hardware angle, but the data is real and usable.
Keyword Research, unlocked: eleven clusters, each tagged by intent and carrying a search volume and difficulty score, exportable to CSV.
**Topical Map** built a 101-topic content plan across clusters, every topic carrying difficulty, search volume, intent, and a one-click "Create" that opens a brief in the editor. This is the planning layer the cheap plan is missing.
The Topical Map: 101 topics across clusters, each with difficulty, volume, intent, and a Create button.
**Audit** is the one we would actually keep. Pointed at a live page (our own RTX 3090 review), it returned a Content Score of 30 and asked for at least 38 more, flagged that 75 of 95 important terms were missing, and cleared internal links and word count. That is a concrete punch list for an existing page.
The Audit on a live page: Content Score 30 with 38 to go, 75 of 95 important terms missing, internal links and word count cleared.
**Topic Research** and **AI Tracker** unlocked too. AI Tracker is the "be the brand AI talks about" feature: you add up to 50 prompts and it tracks where your brand turns up in AI answers. That is the AEO play, and it needs Pro.
**The one that stays locked is SERP Analyzer.** Even on Pro it is gone: not in the sidebar, and its page loads blank, because it lives on the top "Peace of Mind" tier above Pro. So the single most expensive tool is still out of reach unless you buy the most expensive plan.
The takeaway: the entry plan is the Content Editor and little else, and Pro is where Surfer turns into a real research suite. If you are going to pay for Surfer at all, Pro is the floor that makes it worth the money. Just know the SERP Analyzer is not included even then.
## Does this hold up for other people?
We did not want the verdict to rest on a single test, so we read what other users report and re-fetched every quote from its source. Two things to know first. Surfer's headline ratings are rosy and partly managed: Capterra sits at 4.9 out of 5, G2 at 4.8, and TrustRadius openly tags some of its reviews "Incentivized." So we weighted candid forum threads and the low-star first-party reviews over the near-perfect averages.
On the fabrication, we are not alone. A Capterra reviewer describes double-checking the AI's statistics and references, only to find them ["either inaccurate or completely fabricated"](https://www.capterra.com/p/218703/Surfer/reviews/). That is the same failure we hit, reported by someone with no reason to invent it.
The generic-output complaint is the most repeated thing across independent reviewers. One writes that the drafts ["sound like every other AI-generated article"](https://konabayev.com/blog/surfer-seo-review/); an owner-operator who dropped the tool says it was ["adding words just to add words, inserting paragraphs just to fill space"](https://zzzcode.ai/blog/en/9/surfer-seo-review-2025-why-it-didnt-work-for-me).
The paywall friction we hit is the single loudest billing complaint. Paying users report that ["even if you pay a subscription, you're still limited with credits"](https://www.capterra.com/p/218703/Surfer/reviews/), and the tier trap is exact: one reviewer needs ["more than the 30 available with the $99 plan, but with the more expensive plan, I don't use all of them"](https://www.capterra.com/p/218703/Surfer/reviews/). On the candid BlackHatWorld forum, cost is the top reason high-volume publishers leave; one writing about 100 articles a month found it ["too expensive"](https://www.blackhatworld.com/seo/surfer-seo-alternatives.1516745/) and moved to cheaper tools like NeuronWriter and SurgeGraph.
One place our test was too kind. We rated the AI-Search scoring highly; people who build in that space are more skeptical. A reviewer calls it ["an SEO tool with an AEO feature bolted on, not a purpose-built AI visibility platform"](https://www.tryprofound.com/blog/surfer-seo-review) that cannot tell you whether AI models actually cite your pages. That critic sells a competing product, so weigh it accordingly, but the gap is real: a high score is not proof of a citation. A long-time practitioner puts the score in its place: ["I treat content score as a guardrail, not a law"](https://www.kristian-larsen.com/reviews/surferseo-review/).
For balance, the praise is real too. Plenty of reviewers call Surfer a ["comprehensive SEO tool for half or one third of the price of competition"](https://www.capterra.com/p/218703/Surfer/reviews/). The pattern that holds up across all of it: people keep Surfer for the optimization, and grumble about the credits and the writer.
## Real cost
Standard is $119, Pro is $219, and Peace of Mind is $359 per month, billed yearly. There is a 7-day money-back window rather than a true free trial. Budget for the tier that actually contains the tools you came for, which for most people is not the cheapest one.
## The verdict
Situational. If you run a content operation and will lean on the SEO plus AI-Search scoring and the Search Console audit every week, Surfer earns its place, and the AEO scoring is a real edge right now. If you are a small team hoping the AI writer will produce publish-ready posts, it will not, and it will quietly try to put fabricated testing claims in your mouth. Buy it for the score alone, and price in the tier you will actually need.
