AI app builder pricing depends on what counts as work

The cheapest plan for 100 prompt iterations a week is usually the one that counts the least work around each prompt. The posted monthly price tells you almost nothing until you know whether a retry, a planning pass, a test run, a deployment, and an agent working in the background touch the same meter.

I have seen teams compare plans by dividing a subscription price by 100 prompts. That arithmetic is neat and wrong. A prompt that changes button copy and a prompt that restructures a database both count as one message to the person typing, but they can create very different bills. The honest comparison starts with a workload ledger, then applies each vendor's billing rules to that same ledger.

This article uses a hypothetical price catalog, not the prices of any named vendor. The point is to give you a calculation you can replace with real plan terms before you buy.

The same prompt count can hide three different bills

A count of user messages measures conversation, not compute or completed work. Credit plans tend to meter model activity, task plans meter a vendor defined unit of work, and flat plans sell access within a boundary. Those boundaries produce different totals even when the application and the 100 weekly requests stay identical.

Suppose a founder asks for 70 small interface changes, 20 changes that touch several files, and 10 build or deployment changes each week. The visible count is 100. Behind it, the builder may inspect the repository, create a plan, call a model several times, run tests, repair a failed edit, rebuild the app, and keep an agent running after the chat response appears. One plan may charge for every model call. Another may call the whole sequence one task. A subscription may include it, cap it, or exclude part of it as an overage.

This is the distinction buyers routinely blur: an iteration is a user decision cycle, while a billable event is whatever the seller chose to meter. Treating them as synonyms favors the plan with the vaguest pricing page. It also makes a cheap looking plan expensive after the team has committed its application to the platform.

For comparison, use a monthly factor of 4.33 weeks rather than pretending every month has four weeks. One hundred weekly iterations become 433 monthly iterations. That small correction adds 33 iterations, before a single retry or background job enters the calculation.

A useful quote request asks the vendor to classify the work, not merely to estimate a total. Ask: What starts the meter? When does it stop? Does a failed run count? Does an automatic retry count? Which work continues after the interface says the response is complete? Can unused capacity roll over? The answers determine the bill.

Define one workload before opening the calculator

Build a representative week from work you actually expect, then freeze it before comparing plans. If you change the workload for each price model, you are testing sales copy rather than price.

For the worked comparison, I will use this weekly workload:

• 70 small edits at one credit unit each
• 20 multi file changes at three credit units each
• 10 build or deployment changes at five credit units each
• 25 retry runs at an average of two credit units
• 35 background runs that consume 45 credit units in total

The 100 requested iterations consume 180 hypothetical credit units on their first passes. Retries add 50. Planning, indexing, tests, and deployment work add 45. The weekly total is 275 units, or 1,190.75 units in an average month.

The same activity has a second shape under task billing. It creates 100 user initiated task starts, 25 retry starts, and 35 background task starts each week. That is 160 events weekly and 692.8 events monthly. Whether all 692.8 are billable depends on the contract's definition of a task.

Record successful and failed work separately. A failure rate based only on visible error messages misses silent repairs, automatic model fallbacks, and test reruns. The platform's usage export, if it has one, is better evidence than a chat history because the chat may collapse several agent runs into one response.

Use a week that includes ordinary mess: one unclear prompt, one dependency conflict, a test that fails for an unrelated reason, and a deployment repair. A pristine demo week produces a budget that lasts only until real development begins.

Do not inflate the workload to protect yourself. Add a separate variance allowance after calculating the observed baseline. Keeping baseline and allowance separate lets you see whether a plan is expensive because of normal work or because you bought insurance against a busy month.

Credit packs charge for motion inside the builder

Credit packs cost less when the platform's unit prices are low, unused credits survive long enough to be used, and the builder needs few repair passes. They cost more when a simple request fans out into several model calls that the user cannot see.

A credit is not a standard unit. It may represent tokens, model calls, agent steps, seconds, or a weighted mixture. A vendor can also charge different credit amounts for a fast model and a more capable model. Comparing the number of credits in two packs is meaningless unless both platforms define consumption in the same way, which they rarely do.

Price the hypothetical workload with a pack of 500 units costing $30. Monthly demand is 1,190.75 units. Because packs are indivisible, the buyer needs three packs and pays $90. The account ends the month with 309.25 units left if credits do not expire. The effective cost of consumed work is about 7.56 cents per unit, even though the pack advertises 6 cents, because the buyer had to purchase unused capacity.

Rollover changes the result. If the remaining 309.25 units survive, the next month's purchase may be two packs rather than three. Over several stable months, average cost approaches the advertised rate. If credits expire monthly, the stranded balance is part of the price. Never omit it from the model.

Model selection can change consumption without changing the prompt count. If the platform routes complex edits to a model with a four unit multiplier, the ten hardest requests can dominate the bill. Ask whether routing is automatic, whether you can see it afterward, and whether you can set a ceiling. A cheaper model that fails and retries twice may cost more than a capable model that succeeds once.

Credit packs work well for irregular projects because you pay when work happens, provided the credits have a useful life. They are harder to budget for a team that experiments freely. The meter can change behavior: people combine unrelated requests into oversized prompts, avoid tests, or accept weak output to save credits. Those choices lower the invoice by damaging the application.

The awkward question is whether background work should consume credits. It consumes resources, so charging for it is defensible. The problem arises when the buyer cannot predict or stop it. A fair evaluation checks whether the interface exposes each background charge and whether a spending limit stops new work before the balance reaches zero.

Task billing depends on where a task begins and ends

Task based billing can be the cheapest model when one price covers the whole attempt, including planning, model calls, tests, and repairs. It becomes the most expensive when every internal action becomes a new task.

Apply a hypothetical rate of $0.14 to each started event in the ledger. At 692.8 monthly events, the cost is $96.99 after rounding to cents. That is higher than the $90 credit pack result, even though fourteen cents sounds small on a pricing page.

Now change one contract sentence: charge only for the 433 user requested iterations, while including retries and background work inside each task. The monthly cost falls to $60.62. Nothing about the application changed. The task boundary changed, and that boundary moved $36.37.

Completed task billing needs another definition. If a run changes files but fails deployment, has the platform completed the task? If the user rejects the result and asks for a correction, is that a new task or a continuation? Vendors need rules to prevent unlimited work under one fee, but buyers need rules they can reproduce from an activity log.

The popular recommendation to compare cost per successful prompt is wrong when success is self reported. Users accept partial results, split large requests, and correct output manually. A low cost per recorded success can conceal hours of cleanup. Compare cost per accepted change instead, using the point where the team would merge, deploy, or otherwise keep the result.

Task pricing has a budgeting advantage when the unit maps to something a person recognizes. A team can estimate 400 accepted changes more confidently than millions of tokens. That advantage disappears if the product labels indexing, planning, testing, and deployment as separate tasks. Read the event names in an actual invoice or usage export before treating the unit as stable.

Ask how concurrency works too. Two agents running at once may shorten elapsed time while doubling task starts. A background repair that spawns a test agent might count once, twice, or not at all. The bill follows the meter, not the wall clock.

Flat subscriptions win only inside their included boundary

A flat subscription costs least for this workload when the monthly fee includes all 433 user iterations, 108.25 retry starts, and 151.55 background starts. If any category sits outside the subscription, add it before declaring the flat plan cheaper.

Use a hypothetical $79 monthly plan that includes up to 600 interactive and retry runs plus 200 background runs. The example creates 541.25 interactive and retry runs and 151.55 background runs per month. Both totals fit, so the cost stays $79. Under these assumptions, flat pricing beats the $90 credit packs and the $96.99 started task plan.

The word unlimited deserves no value in a spreadsheet. Replace it with the actual fair use threshold, concurrency limit, model restriction, or slowdown rule. If the vendor will not state a boundary, model a low case and a high case. A plan that only looks cheap under an unbounded interpretation has not given you a reliable price.

Flat plans also create step costs. At 599 included runs, one more run may cost nothing. At 600, the next run may trigger an overage or force a higher tier. Plot at least three workload levels: a quiet month, the expected month, and a release month. The expected case alone hides the point where the subscription jumps.

Seats matter when billing follows users rather than work. A $79 plan for one person is $316 for four required seats, even if the team shares the same 433 iterations. Do not assume account sharing is allowed. Price the people who must review prompts, approve deployments, or inspect usage.

A flat fee can encourage healthy experimentation because each failed idea does not create a visible microcharge. It can also hide waste until the platform throttles the account. Usage visibility still matters. You need to know whether agents are looping and whether a release month will cross the included boundary.

Annual discounts should enter the calculation last. First find the cheapest model at monthly terms. Then apply the discount and the cost of commitment. Paying ten months for a tool abandoned after three months is not a saving.

Retries belong in the baseline, not in a footnote

Retries are normal development work, so a price comparison that assumes perfect first pass output is not fit for purchasing. The useful number is retry amplification: total attempts divided by requested iterations.

The example has 125 interactive attempts for 100 requested iterations, giving a retry amplification of 1.25. That does not mean 25 percent of prompts simply fail. Some requests need clarification, some edits pass code checks but miss the intent, and some failures come from tools or dependencies. The billing effect is the same when the plan meters another attempt.

Measure retries with a rule that two people can apply consistently. Count a retry when the user repeats the same intended outcome after rejecting or repairing the previous output. Do not count a genuinely new requirement as a retry. Tag automatic retries separately because a user may never see them.

A small pilot should include the tasks you expect to be difficult. If you test only landing page copy and color changes, the retry rate says little about database migrations, authentication, state management, or mobile builds. Put at least one risky change through each candidate and inspect the activity record.

Retries affect the models differently:

• Credit billing usually charges the resources consumed by every attempt.
• Started task billing usually charges each attempt if the retry creates an event.
• Completion billing may absorb failed attempts, depending on its completion rule.
• Flat billing absorbs retries until they hit an included limit or fair use control.

Do not accept free retries as a complete answer. Ask whether the retry uses the same model, whether automatic fallback consumes a separate allowance, and how long the free retry window remains open. A correction submitted the next morning may become a new task even if the work is clearly the same.

There is also a human retry cost. A plan can be cheap in dollars and expensive in attention if users must supervise each repair. Track minutes of review per accepted change during the pilot. Do not force that time into the platform bill, but show it beside the bill so a low price cannot hide a bad workflow.

Background agents are the invisible multiplier

Background agent work must appear as its own row because it can continue after the user sees a response. Repository indexing, planning, dependency checks, tests, build monitoring, deployment, and repair agents may all consume budget without adding another chat message.

Our example assigns 35 background runs and 45 credit units each week. Those numbers are deliberately visible assumptions. Replace them with usage records from a pilot. If a vendor exposes only one combined total, run the same prompt once with optional automation disabled and once with it enabled. The difference is an estimate, not proof, but it is better than treating the work as free.

Planning mode deserves special attention. A plan can reduce expensive failed implementation by finding conflicts early, or it can add a paid step before every trivial edit. Test it on small and large changes separately. The right policy may be to use planning for schema changes and multi file work, while skipping it for copy edits.

Indexing has a different cost shape. The first pass over a repository may be expensive, while later incremental updates cost little. A one week pilot can exaggerate steady state cost if it includes initial indexing, or understate it if the production repository is much larger. Separate setup consumption from recurring consumption.

Tests and deployment are not optional waste. Turning them off to fit a credit allowance transfers failure detection to users. Price the safe workflow you intend to run, including the checks that protect it. A comparison based on disabled tests answers the wrong business question.

Koder.ai supports planning mode, deployment and hosting, snapshots and rollback, and source code export, so a pilot can observe these parts of the workflow instead of pricing chat messages alone. The plan names and prices still need to be checked in the current product interface because the site context here establishes tiers, not their present allowances.

Set a background budget if the product allows one, but do not confuse a cap with predictability. A cap prevents excess spend by stopping work. The application may still miss a release while an agent waits for more capacity. Record both the financial limit and the operational consequence.

Run every candidate through the same ledger

A ledger makes the comparison reproducible and exposes contract ambiguity before it becomes an invoice dispute. One row should describe one metered event, with enough context to map it into credits, tasks, and subscription allowances.

Copy this CSV header and use it during a pilot:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Keep event type and outcome separate. A background test can complete successfully while the requested change still fails acceptance. If you collapse those facts into one status, you cannot test a vendor's completed task rule.

At the end of the week, calculate four values:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Then apply plan terms without changing the rows. For the hypothetical catalog, the calculation is:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

A spreadsheet should also expose stranded credits, included capacity left, and the next price boundary. The winning plan in the example has 58.75 interactive runs and 48.45 background runs left. That margin is not large enough for a release week that doubles deployment work, so the team should calculate that case before committing.

Ask the vendor to review one anonymized ledger page. Do not ask which plan is cheapest; ask how each row would be classified. Written classification is more useful than a sales estimate because you can compare it with the first invoice.

Variance matters more than the sticker price

The example result is flat subscription at $79, credit packs at $90, and started task billing at $96.99. That ranking applies only to the stated catalog and workload. A small change in retry treatment or included background work can reverse it.

Calculate a break even point for each pair. The $79 flat plan beats $30 credit packs whenever monthly demand needs three or more packs, assuming unused credits have no future value. If rollover lets the buyer use every unit, $79 equals about 1,316.7 credit units at six cents each. Below that usage, fully used credits cost less.

Against $0.14 started tasks, $79 equals about 564.3 events. The expected 692.8 events exceed that point. If the task plan charges only 433 requested iterations, however, it costs $60.62 and wins. One definition again matters more than the headline rate.

Run sensitivity cases instead of pretending the estimate is exact. For this workload, change retry amplification from 1.10 to 1.50, background work from 20 to 60 weekly events, and complex edit consumption by a reasonable multiplier disclosed by the vendor. You do not need dozens of scenarios. You need the few variables that can change the decision.

Consider cash flow and lock in separately from unit cost. Packs may preserve flexibility. A monthly subscription creates a predictable ceiling while you remain inside its boundary. An annual subscription trades flexibility for a discount. Source code export and snapshots can reduce the cost of leaving a builder, but they do not make migration free; the exported application still needs a working build, infrastructure, and someone able to maintain it.

A founder with uncertain usage should prefer the model whose downside is visible. That may mean packs with long rollover, even when the expected monthly total is slightly higher. A team with steady, measured work can buy a flat plan near the middle of its included range. A task plan suits work that maps cleanly to accepted outcomes and includes repair work inside the task.

Do not choose based on the example winner. Choose after replacing every hypothetical rate and allowance with terms you can point to, and every workload assumption with a pilot observation.

Put the billing model through an acceptance test

A pricing model is ready for a decision when another person can reproduce the monthly total from the ledger and the plan terms. If the calculation depends on a salesperson interpreting an internal task after the fact, the model has failed the test.

Use this compact acceptance checklist:

1. Record 100 representative requested iterations, or a smaller sample that includes every major work type.
2. Tag retries, automatic retries, plans, tests, builds, deployments, and other background runs.
3. Map each event to the vendor's credit, task, or included allowance rule.
4. Calculate expected, quiet, and release month totals with the same 4.33 factor.
5. Save the plan terms and compare the first real invoice with the forecast.

Set a tolerance before the pilot. For example, you might investigate any total more than 10 percent above forecast. The percentage is a management choice, not an industry standard. Its purpose is to force a review while the event history still exists.

If actual usage exceeds the forecast, find the row category responsible. More accepted work is different from more retries. More planned deployment runs are different from an agent loop. The remedy might be a larger plan, a narrower agent policy, clearer prompts, or a billing correction. A single total cannot tell you which.

Keep the ledger beside the invoice for the first three billing cycles, because a quiet pilot can miss batch jobs, release work, and automatic repairs. The cheapest model for 100 weekly iterations is therefore conditional, but the decision does not need to be vague. Under the explicit example, the $79 flat subscription wins. Under success scoped task billing, the same work costs $60.62 and task billing wins. Credit packs win at lower or bursty consumption when rollover prevents waste. Write down what counts, measure the hidden work, and make the invoice prove the promise.