Paying a subscription for a project you no longer use: dormant applications

Five unpublished applications, four untouched for weeks, and a counter still running. What an unopened project costs, what that spending buys, and when it stops buying anything.

Paying a subscription for an unused project has a measurable cost. A Lovable user reports on Reddit (r/lovable, June 2026) that five never-published applications, four untouched for one to two months, consume 2.67 credits daily, a projected 80 monthly out of a 100-credit Pro allocation.

A sleeping application still runs

A project hosted by its publisher stays on. Its address responds, its database awaits a query, its preview wakes with every visit. The same user asked whether inactive projects could be suspended: support answered no; they must accept consumption or delete projects, discarding invested time and credits. No button existed between those options.

The counter advances without explaining why

Another user of the platform calculated three months of usage (r/lovable, September 2026): 1,364 credits over the last 30 days versus 2,389 over 90, placing 57% of quarterly consumption in the last month. Reviewing 20 exchanges individually gave 14.07 credits per message, ranging from 8.9 to 21.1, which they translate as 70.4% of a 400-credit monthly allocation for twenty interactions. They write: 'Why are we so much in the dark?' Dormant projects ask from the other end the question we explored in what an agent consumes: how to stop spending you cannot see.

The trap lies in how we test ideas. Trying three and keeping one is healthy, except the two abandoned ones remain switched on and billed alongside the successful one. No statement line says 'project abandoned in March'. You see a stable monthly total, slightly higher each quarter, and need an afternoon of accounting to discover half pays for applications nobody opens.

What hosting gives in exchange

That expenditure buys something: an application online during holidays, an address clients can find, backups, security fixes applied without asking. For a shop or tool teams open daily, the service is real and charging for it defensible. The calculation reverses on projects untouched for two months: you pay a server to await a visit that never comes, and cannot take it away without losing everything.

A closed project consuming nothing

Maestro approaches from the other end: project code and documents live on your Mac. Closing a project leaves it on disk without a server running for it or credits trickling away, and nothing needs deleting to stop spending. Agent work is paid according to the assistant's plan: a subscription may remain payable while you are idle, whereas an API bills usage. AI spending from our tests is not a total budget; add approval, maintenance and the published product's services or hosting, which may continue to be billed when a project is closed in Maestro. Reopen in six months and the project waits in the same place with its specification and version history.

In exchange, Maestro stops at code on your machine. When the application must answer customers from a public address, you need a host charging like any other. That is the dividing line: experiments and drafts cost nothing while sleeping; what you publish costs what it costs. Tools adding a spending cap address the other half, work in progress. This difference has a downside we accept: nothing runs while you are away, so nothing updates itself or monitors the application for you. A project sleeping locally truly sleeps, security updates included, and you must reopen it before returning it to service.

Do the sums tonight

Open your project list and note when each was last opened. Those beyond two months form your dormant bill. Ask the publisher in writing what an inactive project consumes daily and whether suspension exists: a legitimate question whose written answer will help. Multiply by twelve, compare with keeping everything, and for projects you will never reopen, retrieve the code locally before closing the subscription line.