Why Starko Bills per Merged Pull Request, Not per Seat or per Resolution
Starko bills for merged pull requests. Collecting feedback, answering questions from your knowledge base and generating recommendations are free. Each run shows a credit cap before you accept it, and a pull request that is closed without merging costs nothing. This post explains why we chose that unit, what the alternatives would have charged you for, and how the cap keeps the bill predictable.
The short version: charge for the outcome, cap the effort
Every pricing model is a statement about what the vendor thinks you are buying. Per seat says you are buying access for people. Per resolution says you are buying closed conversations. Per token says you are buying compute. Per merged pull request says you are buying a change to your product that your own engineers accepted.
We chose the last one because it is the only unit in the loop that a customer can point to and say "that is what I wanted". It is also the only one the customer controls: nothing merges without a person pressing the button.
What per seat would have charged you for
Seat pricing made sense when the value of software scaled with the number of people using it. A factory inverts that. The point is to need fewer hands per change, so charging per hand penalises exactly the thing the product is for.
There is also a practical problem. Who holds the seat for a coding agent? The support lead who accepted the recommendation, the engineer who merged the pull request, or the agent itself? Each answer is arguable, and a billing unit that needs arguing is a bad foundation for a product that depends on knowing who approved what.
What per resolution would have charged you for
Several AI support products, including , charge per resolution. You pay each time the AI closes a conversation without a human. It is a fair unit for a support bot, and it is the wrong unit for a factory, for two reasons.
First, a resolution is the beginning of the loop, not the end. A customer whose question was answered from the knowledge base is a customer who still has the bug. Charging at that moment charges before anything was fixed.
Second, it creates the wrong incentive for the vendor. If the AI is paid to close conversations, it will close conversations. Starko's support side, including AI answers across every channel, is free precisely so that there is no reason to resolve a conversation that should have become a ticket.
What per token would have charged you for
Token pricing charges for effort, and effort is the thing a coding agent is worst at predicting. A run that explores the wrong part of the codebase for ten minutes costs the same tokens as a run that finds the fix in one. Neither of those is what you are paying for.
The cost is also hard to read. Enterprise buyers already say so. In a16z's 2025 survey of 100 enterprise chief information officers across 15 industries, most said they still prefer paying by usage for AI applications, and their top concerns with outcome-based pricing were unclear outcomes, unpredictable costs and attribution (). All three concerns are solvable, but only if the outcome is concrete and the cost is capped before the work starts.
How the credit cap makes an outcome price predictable
The usual objection to outcome pricing is that the buyer cannot forecast it. The usual objection to usage pricing is that the buyer cannot control it. The credit cap is the answer to both.
Every recommendation comes with a size, Small, Medium or Large, and a credit cap derived from it. The cap is the most a run can cost. You see it before you accept. If the run reaches it, the run stops and asks for guidance rather than overspending. Revisions after a review or a red CI are part of the same run, so you are billed once, on merge, for what the run used. If it does not merge, the bill is zero.
An example ledger, with illustrative credit amounts:
The Starko AI settings page shows what each merged pull request bills at list price next to its platform cost, so there is no hidden margin to reverse-engineer.
Why "closed without merging" is free
This is the rule that keeps the model honest. If a run produces a pull request your engineers reject, that is a run that failed. Charging for it would mean charging for the agent's mistakes.
It also keeps us pointed in the right direction. The only way for Starko to earn more is for more pull requests to merge. The only way for more pull requests to merge is for them to be correct, small enough to review, and backed by evidence. Every feature on the build and verify side, from the reviewer agent to the independent test run to the evidence panel, exists because the merge rate is the business.
The industry data says this alignment is needed. Teams with high AI adoption merged 98% more pull requests but saw review time rise 91% and pull request size grow 154%, according to Faros AI's 2025 analysis of 10,000 developers (). A vendor paid per token or per seat is indifferent to that review cost. A vendor paid per merge is not.
What is free, and why
The whole support side is free: every channel, the website widget, AI answers from your knowledge base, ticketing, the CRM, procedures and session replay. Recommendations are free too, including the triage and sizing that produce them.
The reason is simple. Those stages are inputs. A factory with no feedback coming in has nothing to build. Charging for the inputs would give you a reason to connect fewer channels and record fewer sessions, and a factory with fewer inputs has less to build.
It also means a team can run Starko as a support platform indefinitely without paying, and switch on the factory for one project when a recommendation is worth it.
How this compares to the alternatives
When this model is not the right fit
Two cases. If you want a support bot and never intend to connect a repository, Starko is free for you and the billing question does not arise. If you need self-hosted models, dedicated runners, SSO, an audit log or data residency, Enterprise plans keep the same unit of billing and add those on custom terms agreed in advance.
For the full tier breakdown, see the . For what happens inside a run, read .
Frequently Asked Questions
What does Starko charge for?
Merged pull requests. Feedback intake, AI answers from your knowledge base, ticketing, every channel and recommendations are free. A run is billed only when its pull request merges, up to the credit cap you saw before accepting it.
What happens if a pull request is closed without merging?
Nothing is billed. A run that produced a pull request your team rejected is treated as a failed run, and the cost of it stays with Starko.
How do I know what a run will cost before I accept it?
Every recommendation shows a size and a credit cap. The cap is the maximum. If a run reaches it, the run stops and asks whether to continue. The ledger shows what each merged pull request actually used next to its list price.
Why not per seat?
A factory is designed to need fewer people per change. Charging per person penalises the outcome the product exists to create, and it is unclear who should hold a seat for a coding agent.
Why not per resolution?
A resolved conversation is the start of the loop, not the end. Charging at that point bills before anything has been fixed and gives the vendor an incentive to close conversations that should have become tickets.
