Founder of Goodspeed
Codex agency pricing confuses a lot of buyers, and understandably so. Different teams quote in completely different ways, the same project can attract wildly different numbers, and the language around it is often deliberately vague. When you are comparing proposals that are structured differently, it is genuinely hard to tell which one is the better deal.
The confusion is not an accident. A pricing model is a way of allocating risk between you and the agency, and each model suits a different kind of project. Understanding what you are actually paying for, and which structure fits your situation, is what lets you compare quotes fairly instead of just picking the lowest headline number.
This guide breaks down the common ways agencies charge for building software with OpenAI Codex, what each model is good and bad at, and how to compare quotes that look nothing alike. The goal is to make you a confident buyer who understands the trade offs behind every price.
Pricing is really about risk
Every pricing model is a way of deciding who carries the risk when a project turns out harder than expected. In a fixed price, the agency carries it. In a time based model, you carry it. Everything else sits somewhere between. Once you see pricing this way, the models stop being arbitrary and start making sense.
This matters because the cheapest looking structure often just shifts risk onto you in ways that are not obvious upfront. Understanding where the risk sits in each model lets you choose deliberately rather than being surprised later. The right question is not only how much, but who pays when reality diverges from the plan, because on real projects it always does.
Fixed price for defined scope
A fixed price gives you a single number for a defined piece of work. Its great strength is certainty: you know what you will pay before you start. It works best when the scope is genuinely clear and stable, because the agency can estimate confidently and price the risk of overruns into the number.
The weakness is rigidity. If your requirements change, and on software projects they usually do, every change becomes a negotiation. Fixed price can also tempt a team to cut corners if the work runs longer than they quoted, since their margin is now at stake. It suits well understood projects, and fits poorly with anything exploratory or likely to evolve.
Time and materials
A time and materials model charges for the actual effort spent, usually at a daily or hourly rate. It is honest and flexible: you pay for what is done, and the scope can adapt freely as you learn. This suits projects where the requirements are not fully known at the start, which describes a great deal of real software work.
The cost of that flexibility is that you carry the risk of overruns, so trust and transparency matter enormously. You need a partner who reports clearly on where time goes and does not let the meter run without accountability. With a disciplined, honest team this model is fair and efficient. With a weak one it can drift, so the relationship is doing a lot of the work.
Retainers for ongoing work
A retainer buys a continuing relationship, typically a set amount of capacity each month. It fits software that keeps evolving rather than a one off build, which is most production software once it is live. You get a team that stays close to the system, understands its history, and can respond quickly as needs change.
Retainers reward continuity. The team retains context that a project based partner would lose between engagements, which makes each new piece of work faster and safer. The thing to watch is that you are actually getting value for the ongoing spend, so clear reporting on what the retainer delivers each month is essential. Used well, it is the natural model for software that needs to live and grow.
Embedded teams
An embedded arrangement places an agency's engineers to work alongside your people as an extension of your team. It suits deep, sustained work where the software is central to your business and you want the capability close, without the slower path of building an in house team from scratch.
The advantage is integration: the engineers absorb your context, your priorities and your ways of working, and you get senior AI engineering capacity without a long hiring process. It is a bigger commitment than a project or a retainer, and it works best when the work is ongoing and strategically important. For a critical, long lived system, embedding often delivers the most value per pound.
Value based pricing
Some engagements are priced against the value created rather than the time spent. If software will unlock significant revenue or savings, a price tied to that outcome can align both sides around results. Done honestly, it focuses everyone on the thing that actually matters, which is the impact of the software rather than the hours behind it.
In practice value based pricing is harder to structure and requires real trust, because the value has to be defined and measured in a way both sides accept. It is less common for that reason, but worth understanding. When it appears, judge whether the value being priced is real and measurable, or whether it is a way to justify a premium without accountability.
What you are actually paying for
Whatever the model, it helps to know what the price covers. You are paying for engineering judgement, for evaluation that proves the software works, for security and reliability, and for the process that keeps the whole thing trustworthy. The AI coding agent writes code quickly, but the value is in everything wrapped around that code.
This is why two quotes for the same project can differ so much. A higher price often buys evaluation, guardrails and proper process that a cheaper one has quietly dropped. When you compare quotes, look past the number to what each includes. A price is only meaningful once you know what work sits behind it.
Running costs sit outside the fee
For software that uses AI at runtime, there is a cost beyond the agency's fee: the model usage that scales with how much your users do. This is a separate line from the build price, and it needs to be understood upfront so it does not surprise you once the system is live and busy.
A good agency is transparent about these running costs and helps you estimate them at your expected scale. When comparing quotes, make sure you are comparing total cost of ownership, not just build fees. A cheap build that is expensive to run can easily cost more over its life than a pricier build engineered to keep running costs down.
How to compare unlike quotes
Comparing a fixed price against a retainer against a day rate feels like comparing apples to oranges, but you can make them comparable. Normalise them to the same thing: what does each deliver, over what period, including what work, at what total cost. Once you strip the packaging away, the real differences become visible.
Ask every agency the same questions about scope, evaluation, security, ownership and running costs, then line up the answers. The point is not to find the cheapest label but to see which proposal actually delivers the software you need at a fair price. A structured comparison protects you from being swayed by whichever team packaged their number most attractively.
Beware the suspiciously cheap
A quote far below the others is a warning, not a bargain. Cheap prices usually mean something has been left out: no evaluation, thin security, no process, or a single operator with no backup. Those omissions do not remove cost, they defer it to production, where fixing the problem is far more expensive and far more visible.
When a price looks too good, ask what is missing to make it so. A confident agency can explain exactly what their number includes and why. A team that has hit a low price by silently dropping the parts that keep software reliable is not saving you money, it is selling you a problem that will arrive later with interest.
Transparency is the real signal
Whatever model an agency uses, the quality that matters most is transparency. A good partner explains clearly what you are paying for, how the model allocates risk, what is included and what is not, and what the software will cost to run. That openness is itself a signal of a team confident in the value they provide.
Vagueness is the opposite signal. If you cannot get a straight answer about what a price covers or how it might change, that opacity will not improve once the contract is signed. Choose the partner who makes their pricing legible, because the way a team talks about money is a reliable preview of how they will behave throughout the engagement.
Choosing the right model for you
The right pricing model follows from your project. Clear, stable scope favours fixed price. Ongoing evolution favours a retainer. Deep, strategic work favours an embedded team. Exploration favours a flexible, time based arrangement. Match the structure to your reality rather than forcing your reality into whichever model an agency prefers to sell.
Above all, compare on substance and insist on transparency. When you understand what each model asks of you and what each price includes, you can choose with confidence instead of guessing. That understanding turns pricing from a source of anxiety into just another decision you are equipped to make well.
Conclusion
There is no single best pricing model, only the model that fits your project and your appetite for risk. Fixed price suits clear scope, retainers suit ongoing evolution, and embedded arrangements suit deep, sustained work. What matters is understanding what each structure asks of you and what it is really charging for.
Compare quotes on what they include, not just what they cost, and be most wary of the prices that look suspiciously low. When you understand the trade offs behind every model, you stop being at the mercy of clever packaging and start buying software on your own terms.
If you want a team that ships production software with AI coding agents, see our AI work, or book a free call with our AI engineering team.
Written By
Founder of Goodspeed