Vibe coding credits incentive. The pricing model that fights the loop it sells.
Vibe coding only works if you iterate. The platform that charges you per iteration is selling you the loop and a tax on the loop at the same time. The rational user one-shots to save credits, and one-shotting kills the loop. There is an architecture choice underneath the pricing that decides whether your tool encourages the iteration it advertises or quietly trains you out of it.
Per-credit pricing in vibe coding tools trains users to one-shot prompts to save credits, which fights the iterate, watch, iterate loop that makes the product work at all. The misalignment is architectural: when the platform owns a credit pool, it profits from heavier iteration while the user is incentivized to ration it. mk0r's alternative is at src/app/api/chat/route.ts:217-228: 6 free anonymous turns on a shared key, then the route reads your own Claude OAuth tokens first so iterations bill against your Claude plan with no platform markup tier in the middle.
Verified against the appmaker source at src/app/api/chat/route.ts:23, :48-68, :217-228, and src/components/claude-connect-modal.tsx:124-130.
The thesis: credits and iteration are pulling in opposite directions
The pitch for every vibe coding tool is the same: describe what you want, watch the preview, change a sentence, watch it redraw. The loop is what makes the tool feel alive. The loop is also what makes the output land, because a single prompt is almost never the right shape on the first pass. You need the small corrections.
The pricing for most of those tools is also the same: per-iteration credits. Buy 100 a month on a Pro plan. Buy 200 a month on Premium. Daily message caps on the free tier. Each prompt debits the pool. The platform's incentive is to maximize iterations sold per user. The user's incentive, once they see the meter ticking, is to minimize iterations spent per output. The two incentives are exactly opposite.
The user wins the local battle. They start writing one large prompt that tries to anticipate every refinement ahead of time. The model is worse at large speculative prompts than at small iterative turns, so the output is worse, so the user concludes the model is the bottleneck. The bottleneck is actually the pricing structure that punished the iteration loop the tool was built around.
The architecture choice underneath the price
A platform-owned credit pool only exists because the platform owns the API key. When the platform is the only party that can talk to Claude, every turn is a debit on the platform's bill, which means every turn has to be metered on the platform's side. The credit pool is the natural shape of that meter. Subscriptions get tied to credit counts, and the user's iteration ceiling lives in the platform's accounting database.
The alternative is to put the user's own Claude account in the middle. The platform holds a shared key for the trial, and once the user signs in and connects Claude, the chat route prefers the user's OAuth tokens. The platform stops being a middleman on iteration. It is now a workshop around a model the user already pays for, instead of a reseller of access to a model the platform pays for.
In mk0r, that choice lives at lines 217 to 228 of src/app/api/chat/route.ts. The comment above it is short: "Try user's own Claude OAuth tokens first; fall back to shared API key." loadAndRefreshTokens runs against users/{uid}, returns the user's stored credentials if present, and only the absence of those credentials hands the request back to the hosted key.
“Use your own Claude subscription to power the AI agent. Your credentials are encrypted and never shared.”
What "ran out of credits" means in each model
A platform-owned pool defines exhaustion on the platform's terms. You hit a soft cap on the trial, a daily cap on the free plan, a monthly cap on the paid plan. The number is the platform's choice. It can be raised, lowered, or repackaged for a tier upsell, and the user has no way to tell whether their next prompt will burn one credit or three.
When the credits being spent are Anthropic's, the exhaustion signal is Anthropic's too. classifyPromptError at src/app/api/chat/route.ts:50 reads the structured error from the SDK. If errorType is billing_error or rate_limit, or the HTTP status is 402 or 429, or the message text matches a list of billing phrases ("credit balance is too low", "out of extra usage", "hit your limit"), the error is classified as credit_exhausted and forwarded to the UI with the resetsAt timestamp the SDK provides. The user sees the same signal they would see in claude.ai directly.
Two consequences. First, the meter cannot be quietly adjusted by the platform, because the platform is not the one running it. Second, the user's mental model of their cap stays consistent across tools: their Claude plan resets at the same time whether they hit the cap inside mk0r, inside Claude Code on their laptop, or inside the web UI. One pool, one schedule, one reset event.
The two pricing shapes, side by side
The comparison below holds the question constant ("what happens when I iterate?") and varies the architecture. Specific competitor plan prices change quarterly; the shape of the incentive is what is durable.
| Feature | Per-credit tool | mk0r |
|---|---|---|
| Who sits between you and Claude | Platform owns the API key, meters every prompt as a platform credit | Platform fronts a shared key for 6 turns, then defers to your own Claude OAuth |
| Source of the spending signal | Invented credit pool: 100 a month, 200 a month, X messages per day | Upstream Claude billing surfaces credit_exhausted (route.ts:48-68) directly to the UI |
| Incentive when you want to iterate | Each turn debits the pool, so you start writing megaprompts to save a credit | Anonymous loop is free for 6 turns; signed-in loop bills your Claude plan, not a markup |
| What the platform earns on a heavier user | More credits sold, often at a markup over the model provider's pass-through cost | No per-iteration cut; the in-app subscription is for the workshop, not the meter |
| What "run out of credits" actually means | Platform-defined cap on a platform-owned credit pool | Anthropic's structured rate_limit_event or billing_error, classified by classifyPromptError(route.ts:50) |
| How a power user benchmarks Sonnet vs Haiku | Pay for a tier, get a model picker, lose credits faster on the bigger model | Sign in, connect your Claude OAuth (claude-connect-modal.tsx:124), pick on your own plan |
What the user actually feels
The thing that gets lost in the architecture talk is the moment-to-moment experience. On a per-credit tool, you finish your second turn and notice the credit counter ticked from 47 to 45. The next prompt is now negotiated against that counter, not against your taste. You write more, edit less, ship rougher.
On the architecture that puts your Claude account in the middle, the counter is somewhere else: it is the same Claude 5-hour window you already know from claude.ai, or the same weekly cap on Claude Code that your engineering brain has already metabolized. You are not learning a new meter to ration, you are using a meter you already understood before you opened the tool. That changes the iteration speed. The small turn happens because it does not feel like a separate ledger.
The trace: where the credit signal actually flows
Read the diagram top to bottom. It shows where the credit signal originates and where it ends up, with no markup tier in between. The labels point at real symbols in the open source repo.
Credit signal path on a connected Claude account
The platform never owns a credit pool of its own on this path. The pool the user is spending against is the one tied to their Claude account. The classifier's only job is to translate the upstream signal into a typed event the UI can render.
The honest counterargument
Platform-owned credit pools are not built out of malice. They exist because they solve real problems. The platform can offer an experience that does not require the user to already have a Claude account, which lowers the on-ramp. The platform can bundle other costs (sandboxes, image generation, deploys) behind a single meter. The platform can offer one bill for an organization. None of those are illegitimate. They are reasons the model exists.
The honest version of this page is not "platform-owned credit pools are wrong." It is "platform-owned credit pools have an incentive geometry that fights iteration, and if iteration is the loop you are selling, the geometry shows up in your retention numbers." The architecture mk0r picked avoids the geometry by giving up the ability to be the sole middleman on the API key. That is a real tradeoff. It means a user with no Claude account ever has to either sign up for one or accept the 6 turn shared trial. The benefit is that everyone who does sign up gets an iteration loop the platform is not quietly taxing.
The resolution
If you are evaluating a vibe coding tool and the pitch leans heavily on iteration speed, look at the pricing page before you look at the demo. If the answer to "what happens when I iterate" is "you spend a credit," the tool is quietly betting that you will not iterate as much as the demo suggests. The credit pool is where the bet lives.
The cleaner test is to ask where the credit signal originates. If it originates inside the platform, the platform owns the meter and the meter is part of how it gets paid. If it originates inside your own Claude account, the platform is on the outside of the loop, and so is its commercial interest in how often you iterate. mk0r's answer to that test lives at src/app/api/chat/route.ts:217. It is a small block of code that decides a big thing about the tool around it.
Want to see where your iteration loop is actually being taxed?
Bring a build idea and your current vibe coding tool. We will open both, watch the credit counters, and trace where each iteration costs you something.
Frequently asked questions
What is the credits incentive problem in vibe coding?
Vibe coding only works if you iterate. Describe, watch the preview, change a sentence, watch the preview again. The loop is the product. Per-credit pricing on top of that loop creates a meter you cannot ignore: each iteration is a debit on a pool the platform owns. The rational user starts trying to one-shot the prompt so they do not burn the pool. One-shotting kills the loop. The platform is selling iteration and selling a tax on it at the same time.
How does mk0r handle credits differently?
It does not run a platform-owned credit pool. The first 6 anonymous turns share a hosted Claude key (ANON_TURN_LIMIT in src/app/api/chat/route.ts:23). After that the chat route at lines 217 to 228 tries the user's own Claude OAuth tokens first, and only falls back to the shared key if the user has not connected an account. When you connect Claude, every turn bills against your plan with no platform markup tier in the middle. When credits do run out, the classifier at route.ts:48-68 reads the upstream signal (billing_error, rate_limit, HTTP 402, HTTP 429) and surfaces it to the UI as credit_exhausted. That signal comes from Anthropic, not from a meter the product invented.
Why does per-credit pricing fight iteration?
Because iteration is small. A good vibe coding turn changes one sentence in the prompt, watches the preview redraw, and decides whether the change helped. If every small turn debits a credit, the cost-per-decision climbs faster than the value of each decision. Users compensate by writing one large prompt that tries to anticipate every change ahead of time. The model is worse at large prompts than at small turns, so the output is worse, so the user blames the model. The actual cause is the pricing structure that pushed the user away from the loop the tool was supposed to enable.
Is the 6 turn anonymous cap also a credit incentive?
Honestly, yes, with a different shape. ANON_TURN_LIMIT = 6 (route.ts:23) is the cost of having no signup at all. Without an account there is no identity to throttle, so the only abuse gate is the turn counter. Six is the smallest number where the visitor can close a real iteration loop (seed, refine, undo, retry). After that the route returns 403 sign_in_required and the UI shows a one-tap sign in. The honest framing is that the 6 turns are a free trial of the loop. Once you sign in and connect your Claude account, the incentive flips: every iteration bills against your Claude plan, which means the platform no longer profits when you iterate more.
What about the in-app Pro plan, isn't that also a meter?
It is a subscription, not a per-iteration meter. The distinction matters. A meter charges you per turn, which gives the platform an interest in your iteration count. A flat subscription does not. The Pro plan unlocks the workshop surfaces (the dashboard, multiple ongoing projects, model picker, longer sandbox lifespan), and the AI calls inside it run on either the hosted shared key or, preferably, your connected Claude account. The pricing page is intentionally not 'buy 100 credits.' It is 'buy access to the workshop, then connect a Claude account if you want to scale your iteration ceiling.' The architecture choice avoids the iteration-versus-credit conflict at the design level.
What happens when a connected Claude account runs out of credits mid-build?
The chat stream surfaces a credit_exhausted event. The classifier in route.ts at lines 48 to 68 triggers on Anthropic's structured signals (errorType billing_error or rate_limit, HTTP 402 or 429) and on a regex fallback that matches messages like 'credit balance is too low' or 'out of extra usage.' The PostHog server logs the event (acp-chat-store.ts:971), the UI shows the resetsAt timestamp that the SDK forwards, and the user knows their next turn will work once their Claude plan resets. Critically, the project itself does not die: the sandbox keeps the code, the chat history keeps the turns, and the next attempt picks up where the cap interrupted.
Does this mean mk0r is cheaper to use than a credit-based tool?
Depends entirely on how much you iterate, and on what you already pay Anthropic. If you iterate a lot and you already have a Claude subscription, the no-markup pass-through is cheaper because there is no platform tax on each turn. If you barely iterate, a small credit pack on a competitor may be cheaper because you never hit the ceiling. The point of the page is not 'mk0r wins on price,' it is 'the incentive structure under the price determines whether the tool encourages or punishes the iteration loop you came for.' Price comparison is downstream of that.
Where exactly does this live in the code?
Four files. ANON_TURN_LIMIT and the anonymous gate at src/app/api/chat/route.ts:23 and :193-209. The OAuth-first credential resolution at src/app/api/chat/route.ts:217-228 (loadAndRefreshTokens runs before any shared-key fallback). The credit_exhausted classifier at src/app/api/chat/route.ts:48-68. The user-facing modal copy at src/components/claude-connect-modal.tsx:124-130 ('Use your own Claude subscription to power the AI agent. Your credentials are encrypted and never shared.'). The repository is open source at github.com/m13v/appmaker; you can grep any of these symbols and they appear exactly once each.
More on the architecture choices under vibe coding
Keep reading
Vibe Coding Friction Tradeoffs: Four Costs Nobody Names
Every removed friction has a hidden cost. 6 turn cap. One model. One device. One hour. Each one lives at a specific line of source.
Claude Weekly Cap Workflow
A practical workflow for Claude's rolling 7-day weekly cap. Batch heavy turns, connect a builder via OAuth, read the resetsAt epoch.
Vibe Coding Iteration Over One-Shot
The loop is the product. Why iteration beats one-shot generation, and what shapes the loop wants from the tool around it.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.