Making games with local LLMs

Cost. A model you host has no per-token bill, and if that is the whole motivation it is worth knowing early that external agent access to Stage Engine is on the paid plans. Indie is $10 a month, Pro is $50. The free plan does not include it. So this route reduces one bill and does not remove the other.

Privacy. What your agent thinks, and the text you type at it, stays on your machine if the model is on your machine. That part is real. What is not private is everything else the app does, which is covered in the next section and is the reason this page exists.

Control. This one holds up best. Your model, your version, no deprecation notice, no rate limit, no change in behaviour on a Tuesday because someone shipped an update. If you have built habits around a specific local setup, keeping it is a legitimate reason to bring your own agent rather than use Director 1.

Stage Engine is online only for building. Asset generation runs over the network. World data comes over the network. Neither of those is the language model, and neither becomes local because your model did.

This is not a limitation waiting to be fixed. It is how the product is built, deliberately, and we do not add offline fallbacks or degraded modes. If your requirement is a genuinely air-gapped game-making setup, Stage Engine is not it and no configuration makes it it. Better to hear that here than three hours in.

The one thing that does run entirely on your machine is the game. Godot ships inside the app, and when you press play it runs locally with your machine's memory and framerate. No streaming, no browser preview, no render queue. A finished game does not need the connection at all.

Most local models are smaller than the hosted frontier ones, and the usual advice is that they therefore cannot do agentic work on a complex codebase. That advice is broadly right when the codebase is a raw game project, because a raw game project asks the model to invent almost all of its own context.

Stage Engine exposes a capability layer instead. Terrain, water, weather, sky, characters and what they do are real operations rather than a hundred property assignments the model has to sequence correctly. Every capability that exists is code the model does not have to produce and a set of mistakes it can no longer make.

The honest version of the claim: this is designed so that reliability comes from the tool surface rather than from model size, which is what makes a self-hosted model worth attempting at all. We have not benchmarked local models here and will not tell you which one to run or which is best. Try yours.

Stage Engine ships two MCP servers inside the desktop app. One exposes the Stage capability layer, one exposes assets. An MCP-capable agent on the same machine can call them. That agent can be backed by whatever model you like, including one you are serving locally.

We have not built anything specific to any local-model runner or any particular client. There is no plugin and no listing. Popular MCP clients should work, behaviour varies between them, and we have not tested every one.

We also do not publish the setup steps here. Command names, flags and config file contents change, and a stale instruction on a page like this is worse than sending you to the app, where the current details live.

You build the world by hand. In the builder, in the app, placing things. That is true with a local model, a hosted model, or Director 1, and it is the deliberate shape of the product rather than a feature that has not arrived.

And you judge the game. You play it, decide whether it is right, and say what is wrong. Handing work back is the normal loop here. Not writing the code has never implied not having an opinion about the result.

If none of the three reasons at the top of this page apply strongly to you, use Director 1. It is in the app, it is aimed at the capability layer already, and there is nothing to connect or maintain.