Does the Lovable MCP still burn Lovable credits?
Yes, using the MCP (Model Context Protocol) to edit your code still consumes Lovable credits because the AI agents are still performing the work. The credits are tied to the agent's compute and token usage, not where the code is stored.
Last updated
Yes, using the MCP to edit your code still consumes Lovable credits because the AI agents are still performing the work. The credits are tied to the agent's compute and token usage, not the location of the files.
Why are credits still being used with MCP?
The MCP allows an AI agent to interact with your local environment or a remote repository, but the "brain" doing the reasoning remains on the provider's servers. Every time the agent reads a file, proposes a change, or runs a command via the MCP, it sends a request to the LLM.
Those tokens are what you are paying for. Whether the agent is writing to a proprietary sandbox or a local Git repo, the cost of the intelligence remains the same. This is why many founders feel they are still locked in even after they move their source code out of the hosted environment.
Is there a way to stop paying per-edit?
To stop paying per-edit, you have to move the agent itself, not just the code. As long as you are using a hosted AI builder's interface to trigger the changes, you are subject to their credit system.
If you have already moved your code to your own repository, you can use local IDE agents or open-source frameworks. However, most people find that moving the code is the easy part. Moving the deployment pipeline and the automated QA is where they hit a wall. If you are currently trying to figure out what happens after your lovable plan, the realization is usually that the "credits" are the leash.
Where does the app actually run if I leave?
When you move away from a hosted AI builder, you are responsible for the runtime. Most founders move their code to Vercel or Railway and their data to Supabase. While this removes the "edit credits," it replaces them with monthly platform fees and the risk of another form of lock-in.
The alternative is owning the infrastructure. Instead of a sandbox, the app runs on K3s in a namespace that belongs to the account, deployed as a Helm release. In this setup, the source is a real repository that can run anywhere Docker runs, meaning you aren't paying a "tax" just to have an agent touch your code.
How do I get to zero running costs?
The only way to truly stop the credit and subscription bleed is to bring your own hardware. By joining a home machine to a K3s cluster over a private network, the pods schedule onto your own hardware.
This changes the economics of the app. The running cost approaches zero because you aren't paying for a managed cloud slice. You keep the ability to use AI agents to deploy and manage the app, but because the cluster is yours, you aren't paying a premium for the privilege of hosting.
my-app.engineer lets you describe an app in chat and deploys it into a Kubernetes cluster you own, so you can join your own hardware as a node and stop paying for hosted sandboxes.