Every AI-driven change on Plemo consumes credits. Credits are the unit of AI usage on the platform, and each plan, Starter, Professional or Enterprise, comes with a monthly allowance. That part is easy to understand. The question teams ask after their first month is less obvious: why did one customization consume so much more than another that looked, from the outside, about the same size?
The short answer is that consumption tracks how much work the AI has to do to understand and build the change, not how many lines of code end up in the result. A three-line change to a report can cost more than a whole new screen if those three lines sit inside a sales flow that five years of customization have made unrecognizable. Here is what actually drives that, and what you can do about it.
What consumes credits
- Reading your system. Before anything gets written, the AI has to understand the models, fields and existing customizations in your instance. A request that touches a heavily customized area requires more reading than one that touches a stock Odoo module.
- Clarifying the request. The chat-driven request flow asks questions when a request is ambiguous, and it pushes back when a request is too broad. Those exchanges are useful and they are also work. A vague opening message means more rounds before there is a spec.
- Writing the change. The development itself, which is the part everyone expects to pay for.
- Iterating after the preview. If the sandbox does not match what you had in mind, the correction is another development cycle. Not a catastrophic one, but not free.
Scope is the biggest lever
The most expensive habit is bundling. "Redesign our sales process" is not one request. It is a dozen requests, and the first thing that has to happen is working out which dozen. The chat flow will try to bound a request that broad, which is the correct behavior, but you will have spent something getting there.
Break work into changes that can be described in one or two sentences and verified independently in the sandbox. Add a field to the quotation line and show it on the printed quote. Block confirmation when a customer is over their credit limit. Require an approval above a threshold. Each of those is checkable on its own, and when one turns out to be wrong you re-run one small thing instead of one large one.
Specificity is the second lever
Name the screen. Name the model if you know it. Say what happens today, then what should happen instead. Compare these two requests:
- "Add approvals to purchasing."
- "Purchase orders above 50,000 SAR should require finance manager approval before they can be confirmed. Today anyone in the purchasing team can confirm any amount."
The second one is almost a spec already. The first one is the opening line of a conversation that has to arrive at the second one before any work can start, and you pay for that conversation.
Treat spec approval as a checkpoint, not a formality
Nothing is developed until you approve a written spec. That gate exists for correctness, and it also happens to be the cheapest place in the whole cycle to catch a misunderstanding. A spec that says "add a field to the sales order" when you meant the sales order line costs one sentence to correct at that stage. The same misunderstanding caught after the sandbox is built costs a full development cycle.
So read it the way you would read a scope document from an external developer, because functionally that is what it is. If a sentence reads as vague to you, it will be at least as vague to whatever implements it, and sending it back is the cheapest action available to you at that moment.
The trade-off nobody mentions
Splitting everything into tiny requests is not free either. Five separate requests that all touch the same custom sales flow each pay the cost of understanding that flow. There is a real middle ground here, and the rule is about shared context rather than shared size: group changes that touch the same screen or the same document, separate changes that touch different modules. Two tweaks to the delivery note belong in one request. A delivery note tweak and a payroll rule do not.
When a customization is the wrong tool
A surprising share of what teams request in their first months is not customization at all. It is configuration: a setting, a pricelist rule, an access right, a report filter that already ships with Odoo. Asking for configuration as a customization spends credits on discovering that no code was needed. If you are not sure which side of the line a request sits on, the setting is worth checking first.
At the other end, some work is genuinely bigger than a request-and-preview cycle. A new business process, an integration with an external system, a data migration: these need a designed solution and a person accountable for it, which is what a custom development engagement is for. Spending an allowance in small pieces on something that needed a design is the most common way a month ends with the question of where the credits went.
A first-month checklist
- Make your first two or three requests small and deliberately boring. You are calibrating, not delivering.
- Write down everything you want changed, then sort and group the list before you ask for any of it.
- Check whether each item is a setting before it becomes a request.
- Read every spec before approving it, and send back the ones that read as vague.
- Test the sandbox against the exact case you had in mind, including the awkward one, not only the happy path.
None of this is about rationing. It is about the fact that clarity is cheaper than iteration, in AI-assisted development exactly as in the human kind. You can see how the request, spec and sandbox cycle fits together at plemo.ai.