gidila91 Spending Lovable credits deliberately
Credits are the real budget of a Lovable project. The difference between a balance lasting a week and lasting a month is almost never the size of the app. It is how many times the agent is asked to do something it was never given enough information to get right.
Know what is actually free
Not everything that touches the project costs credits. Before spending one, check whether a free tool answers the question.
Free, and underused:
- Querying the database. Reading and writing rows through the database tool costs nothing. Enormous amounts of what people ask the agent to do is really data work: fixing a bad row, checking whether a column is populated, backfilling a field, inspecting a constraint. Do it directly.
- Reading the code. Listing and reading files costs nothing. You can confirm exactly what a function does before asking for a change to it.
- Reading the project's own history. Past messages and diffs are free, and they often already contain the answer to "did we ever fix this".
Costs credits:
- Sending the agent a message, including a one-line correction.
- Creating a project.
The asymmetry is the whole lesson: investigation is free, instruction is not. Almost every wasted credit is an instruction sent before the free investigation was done.
Never send a message you have not earned
The expensive pattern is a vague request, a wrong result, a correction, another wrong result. Three messages for one change, and the third is usually worse than the first because the agent is now reconciling contradictory instructions.
Before sending anything:
- Reproduce the problem and find it in the code yourself. Name the file and the function.
- Decide what the fixed behaviour is, precisely, including the edge case.
- Write the request so it cannot be misread. What is wrong, where, what it should do instead, and what must not change.
- Say what to leave alone. The agent will happily "improve" adjacent code. In a file full of hard-won calculations, that is how a fix becomes a regression.
A request prepared this way usually lands in one message. That is the entire saving.
Batch, but do not blur
Several related changes in one message cost one message. Several unrelated changes in one message cost one message and produce a diff you cannot review, which costs more later.
The test: could you verify all of it in a single pass? If yes, batch it. If a failure in one part would leave you unable to tell whether the others worked, split it.
Work in ordered steps and finish one before starting the next. Two overlapping instruction threads on the same project is the most reliable way to get half of each.
Use plan mode as a cheap dry run
Discussing the approach before the agent writes code catches the misunderstanding while it is still words. A plan you disagree with costs you one message. A build you disagree with costs the build, the revert and the rebuild.
Use it whenever the change touches more than one file, involves a schema change, or you are not certain the agent has understood the goal.
Text and data are not code
Sort the work by how expensive the tool has to be:
- Content, copy, config, static text: edit directly. No agent needed.
- Data problems: a database query. No agent needed.
- Schema changes: a migration you write. Then re-query the live catalog to confirm it persisted — a migration can be reported as applied and be gone.
- Real code changes: the agent.
A surprising share of "the app is wrong" turns out to be one of the first two.
Verify independently, always
The agent will report that it fixed something. That report is a claim, not evidence.
Check the actual code or the actual data before believing it, and check the deployed environment rather than the preview, since those diverge. Accepting a false "done" costs the credits already spent plus every credit spent on the work built on top of it.
Whose credits are these
In a studio, this is a real question with a real answer per project.
Client projects often live in the client's own workspace, where you are a member. Then agent work on that project spends their credits, not yours. Your own products live in your own workspace and spend yours.
Two consequences worth internalising:
- Waiting for an agent on a client project costs you time, not money. Model subscriptions you pay for personally are the expense that is genuinely yours, spread across everything.
- A client's credit balance is a delivery constraint on your work. If it runs out mid-task you stop, whatever your own balance says. Know it before planning a heavy session.
Know when not to spend at all
Some work should wait for the next billing cycle rather than being done badly now on a thin balance. A scoped-down version of a feature, built under credit pressure, is often worse than the manual workaround it replaces, and you pay twice: once to build it and once to fix it.
Write the manual workaround down as a recurring task with a date, so the gap is visible rather than forgotten, and build the real thing when the balance supports it.
The habits, in short
- Investigate free, instruct once.
- Never send a correction you could have prevented with a read.
- Name the file, name the behaviour, name what not to touch.
- One ordered step at a time.
- Plan mode before anything multi-file.
- Verify in the code and the live data, not in the agent's summary.
- Know whose workspace you are spending in before you start.