Cost-plus
Tokens burned, plus a margin.
Revenue tracks the cost curve, not the value delivered. Every efficiency win cuts your own price, and the model vendor sets your profit.
THE WORK HAS CHANGED. SO SHOULD THE PRICE.
Dynamic pricing for agentic products.
The price of every request follows the value it creates for your user, decided before the run.

01 The opportunity
That is the whole opportunity: price each job on the value it delivers, and collect the spread. One price list for everyone, a different price per job, set before the run and explained by the rule that set it. Today agentic products price one of these four ways instead, and each one caps what the agent can earn.
Cost-plus
Revenue tracks the cost curve, not the value delivered. Every efficiency win cuts your own price, and the model vendor sets your profit.
Flat price
A button tweak and an app that replaces a subscription go out at the same number. Work that differs by orders of magnitude is sold at one price.
Priced by size
Steps, tokens and tiers measure effort, not worth. A run of hundreds of steps that fails is expensive. A one-shot that replaces a SaaS is cheap.
Subscription
A flat fee, blind to how much the agent was used and to what its work was worth. The user who fixed one button and the user who shipped ten apps pay the same.
02 How it works
Before the run starts, Quoted reads the job and returns a value-based price with the rule that set it, in words the user can read.
Your user asks for something. The job and its metadata go to Quoted before the run.
What serving this job will cost you, learned from jobs like it, tail included. This sets the floor.
What the result is worth to this user: the scope of the ask, and the declared attributes of who is asking. This sets the ceiling.
Never below your cost plus your margin. As close to the value as this user will accept, learned from every yes and no before.
A value-based price plus an explanation you can show your user, returned before the run starts.
03 The mechanism
Four parts behind one price. Three of them each answer one question about the job. The fourth picks the number, and says why. One part runs today. Three are in development.
What will the job cost to serve?
Finds the jobs that look like this one and returns what they actually cost, tail included. The tail sets the number, not the average, so the floor holds on the expensive runs too.
What is it worth to the buyer?
Reads the scope of the ask and the declared attributes of who is asking. A whole campaign is worth more than the sum of its images, because the specification is the part they came to buy.
What does the price list allow?
The published price list, as rules the decision has to obey: tiers, volume steps, contracted rates, minimum margin, caps. Nothing it returns falls outside what a customer could read on the pricing page.
Where in the band does it land?
Not the highest price. The highest price times the odds this buyer accepts it, learned from every offer made, including the ones that came back no. Every price comes back with the rule that produced it, in words the product can put in front of the user.
04 Questions
An open task space, where the user asks in free text and the work varies by orders of magnitude. A charge decided in real time, before the run starts. And an agent loop doing the work, not a fixed pipeline.
A closed set of intents, where a fixed price per intent is enough. One clear task per call, where the ask is always the same shape and a formula on the inputs already gets the price right. Enterprise passthrough with caps, where the risk already sits with the customer and there is no pain to solve.
Nobody is priced by identity. The price derives from declared attributes that are printed in the price list (average deal value, vertical, scope, close rate, LTV, sales cycle length) and the buyer classifies itself.
Identity-based pricing dies at the first invoice comparison and the first MFN clause. Attribute-based pricing is the version both customers can read.
The floor, probably. The acceptance curves have no source: a new customer of yours has no history, so the prior has to come from similar sellers, matched on the same declared attributes that set the price.
That is cross-customer data, and it only exists for a party sitting with many customers. Here it is a condition of the thing working, not a nice-to-have.
To split "a campaign for every social network" into 100 image jobs, they have to already know which 100. That knowledge is the thing they came to buy.
The commercial precedent is the partner's hourly rate against the analyst's, same deliverable, published rate card. Volume buyers get a volume tier that prices them directly.
They will not. The band is internal and what surfaces is a credit charge, not a dollar figure. Your users already see a credit count on every run.
Differential pricing starts arguments, and today the vendor rules on its own invoice. Outcome-based billing in support already had this fight: resolutions were counted that the customer would not have called resolutions, and the definition had to be rewritten in public.
Once prices differ per job, a third party that both sides can read is worth more than an in-house dashboard.
05 / LET’S TALK
We go through what you charge now, where in the flow the price is decided, and which jobs you already suspect you are underpricing. You leave with the spread we think is sitting inside your current pricing and what it would take to capture it. No deck.