godot-ai-assistant-hub: an AI assistant inside Godot's code editor
Embed AI assistants in Godot with the ability to read and write code in Godot's Code Editor.
At a glance
- What is it?
- FlamxGames/godot-ai-assistant-hub is a GDScript plugin that connects Godot to a local or remote LLM and lets the assistant read and write code and edit scenes. It is for developers who want AI help without handing over their project.
- Who is it for?
- Adopt godot-ai-assistant-hub if you run a local model such as Ollama and want an assistant that can create scripts, edit nodes and touch resources inside Godot rather than in a separate chat window. Skip it if you need a hosted, zero-setup assistant, or if you expect the plugin to run the model: the README states it acts as an interface between Godot and your provider.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly GDScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What godot-ai-assistant-hub solves, and for whom
The plugin's own framing is a reaction against the idea that you need the largest available model to get useful help. The README asks the reader to "Challenge that idea by creating small LLMs tailored to your game", and the highlights table describes the project as designed for local LLMs first, with remote options available. That places the intended user somewhere specific: a Godot developer who already has, or is willing to install, a program that runs LLMs, and who wants the assistant to act on the open project rather than answer questions in a browser tab.
The second distinguishing choice is the assistant model itself. Rather than one general assistant, the README describes "different assistant types for different tasks", and the repository ships an examples/assistants/ directory alongside examples/quick_prompts_no_tools/, which suggests both patterns are meant to be copied and edited rather than used as-is. If you want a single chat box that knows everything about your project, this is not the shape of the tool.
Ownership is the third theme. The highlights table says the plugin is for developers who "still want to drive their game's creative and development processes", and the security row says it is designed to give you control over what assistants can or cannot do. That control is not decorative: it is implemented as per-tool permissions, described below.
Two workflows: tools that act, and quick prompts that only edit code
The README draws a line between Tools and Quick Prompts, and the distinction matters more than the feature list. A tools request looks like "Make a new enemy that chases the player": the assistant picks from the available tools and performs multi-step work. A quick prompt looks like "Complete code marked with #CODE_HERE#": you select the code, and the assistant fills it in.
The trade-off is stated plainly in the comparison table. Tools give much more capability but carry a risk of mistakes when the assistant uses them, with undo offered as the mitigation. Quick Prompts are described as reliable with less powerful models, but they require you to select code manually and rely on rigid prompt design using keywords. In other words, Quick Prompts trade reach for predictability, and they work with any model, while tools require a model with tooling capabilities.
There is a middle path: the README notes that Quick Prompts can be combined with tools for other things. Where the documentation is thin is in describing what happens when a multi-step tool chain fails halfway. The undo tool exists, and the README says you can undo mistakes, but it does not describe partial rollback semantics for a sequence of edits.
The tool surface: code, scenes, resources, files, project settings
The available tools table is the clearest statement of what an assistant can actually touch. The Code category covers Create Script, Append Code, Replace Code, Delete Code and Show Code. The Scene category is the largest: Create Scene, Add Node From Class, Add Node From Scene, Delete Node, Edit Node Groups, Edit Node Properties, Edit Node Signals, plus read-side counterparts (Get Node Groups, Get Node Properties, Get Node Signals, Scan Scene Node Tree, Show Scene Node). Resource tools cover Create External Resource, Edit Resource Properties and Get Resource Properties. File tools cover Read File, Create Text File, Scan Directory and Create Directory. Project tools cover List Global Groups and Manage Global Groups, and the General category has Save All and Undo.
Every one of these is marked as introduced in 2.0.0 and last updated in 2.0.0 in the table, so the tool surface arrived as a single block rather than accumulating gradually. That is worth knowing if you are reading older tutorials: anything describing a pre-2.0 plugin is describing a different product.
The read tools are as significant as the write tools. Scan Scene Node Tree, Get Node Properties and Get Node Signals are what let an assistant reason about an existing scene instead of guessing at node names. A model that cannot call these will produce edits against a scene it has imagined.
Installing the plugin and running a first assistant
The README does not contain an installation section, so treat the repository itself as the source of truth: the plugin lives under addons/ in the top-level listing, which is the conventional location for a Godot editor plugin, and the README points to a full tutorial video for setup. The project is distributed as source on GitHub, so the practical route is to place the addon in your project and enable it.
What the README does document is the prerequisite. The plugin does not run models; it is an interface between Godot and your LLM provider. So the first real step is having a provider running. For a local setup, that means Ollama, which the README marks as supported by the maintainer.
The plugin's own statement of what it needs is minimal: the highlights table says you only need a program to run LLMs like Ollama, and that the project is designed to have the least amount of dependencies. The provider list is where you choose:
Ollama
llama.cpp
Google Gemini
Jan
Ollama Turbo
OpenRouter
OpenWebUI
xAIOnce a provider is reachable, the workflow splits according to the two-workflow table. For a tools-based assistant, you configure which tools it may use through the three permission levels: Allow, Ask and Hide. Allow grants the assistant permission to use the tool, Ask makes it request permission, and Hide removes the tool from the assistant's view entirely. The README's security framing is that this is how you keep control over what assistants can or cannot do.
For a quick prompt, no tooling-capable model is needed. The README's example instruction is to mark the region you want completed:
#CODE_HERE#You select the code block and send a prompt asking the assistant to complete code marked with that keyword. The README describes this path as reliable with less powerful models, which is the reason to start there if you are running a small local model. The examples/quick_prompts_no_tools/ directory exists for exactly this case.
Where it goes wrong, and when it is the wrong tool
The first limitation is structural, not a bug: the plugin is an interface, not a runtime. If you do not have a provider running, there is nothing to talk to. The README is explicit that it "does not run LLM models directly", so anyone expecting a self-contained assistant after enabling the addon will be disappointed. This is the main reason the local-first pitch is also a barrier: local means you own the setup.
The second limitation is model capability. Tools require models with tooling capabilities, and the README warns that tool use risks mistakes that you then undo. A small model that works well with Quick Prompts may not be able to drive Create Scene, Add Node From Class and Edit Node Properties in the right order. The README's own advice, framed as a challenge to the assumption that you need a super-powerful model, is to build small assistants for specific tasks. That is good advice and also a concession: the plugin does not make a weak model good at multi-step scene editing.
The third limitation is provider parity. The README states that Ollama is supported by the maintainer and sometimes ahead in features, and points to a features-by-LLM-provider section for the details. That section is not reproduced in the README excerpt, which is itself the thing to check: if you plan to use Gemini, OpenRouter or xAI, verify the specific tools you need are supported on that provider before committing.
Finally, the failure mode with the least documentation is a tool chain that partially succeeds. Undo and Save All exist as tools, and the README says mistakes can be undone, but nothing in the README describes what state a scene is left in when the third of five tool calls fails.
How it compares with an external coding assistant
The obvious alternative is an external assistant, a general coding tool or chat interface that you alt-tab to. The difference in approach is not model quality; it is access. An external assistant sees whatever you paste into it. This plugin's tools include Scan Scene Node Tree, Get Node Properties, Get Node Signals, Read File and Scan Directory, which means the assistant can inspect the actual project state before proposing an edit, and then apply that edit through Create Script, Replace Code, Edit Node Properties or Edit Node Signals.
That access is also the cost. An external assistant cannot accidentally delete a node or rewrite a resource property, because it has no hands. Here, Delete Node and Edit Resource Properties are in the tool list, which is why the Allow, Ask and Hide permission levels are the centre of the project's security model rather than a settings afterthought. If your working style is to review every diff before it lands, an external assistant plus copy-paste gives you that review for free, at the price of manual application. If your working style is to describe a change and let it happen, the plugin's tools are the reason to use it.
A second comparison is against running a model through a generic local chat front end. The plugin adds nothing to the model, but it removes the step of describing your scene in prose. Whether that is worth the setup depends on how much of your work is scene and resource editing versus reading and reasoning.
Maintenance, upgrades and the MIT licence
The repository is not archived, and the last push was on 2026-09-01, the same date as the v2.1.0 release. The release history shows v1.8.3 on 2026-04-08, v2.0.0 on 2026-07-12 and v2.1.0 on 2026-09-01, so the project has shipped three releases across roughly five months, with the 2.0 line arriving in July. The README links to a "What's new?" section for the latest version and a separate "Upgrading to a newer version" section, which indicates upgrades are treated as a documented concern rather than an afterthought.
That matters because of the version column in the tools table. Every tool is marked as introduced in 2.0.0. If you are on 1.8.3, you do not have the tool surface at all. The upgrade path from the 1.x line to 2.x is therefore not a patch; it changes what the plugin can do. The README's upgrading section is the place to read before you move, and the README excerpt does not say what that section contains.
The licence is MIT, stated in the repository metadata and present as a LICENSE file at the top level. MIT is permissive: it allows use, modification and redistribution with the licence and copyright notice retained. It does not, on its own, settle anything about the models you connect to. If you point the plugin at a hosted provider such as Gemini, OpenRouter or xAI, the terms of that provider and the licence of the model you choose are separate questions from the plugin's licence, and the repository's LICENSE file does not address them. This is not legal advice; read the provider terms for your own case.
Editorial conclusion
Adopt godot-ai-assistant-hub if you run a local model such as Ollama and want an assistant that can create scripts, edit nodes and touch resources inside Godot rather than in a separate chat window. Skip it if you need a hosted, zero-setup assistant, or if you expect the plugin to run the model: the README states it acts as an interface between Godot and your provider. Before adopting, confirm two things in your own copy of the repository: which tools your assistant is allowed to use under the Allow, Ask and Hide permissions, and whether the provider you plan to use appears in the features-by-LLM-provider table, since the README notes Ollama is supported by the maintainer and is sometimes ahead in features.
Frequently asked questions
Does Godot have a built-in AI assistant?
No. godot-ai-assistant-hub is a third-party plugin, not part of Godot itself, and the README states it does not run LLM models directly but acts as an interface between Godot and your LLM provider.
What is the best AI tool for Godot?
The README does not rank tools or compare godot-ai-assistant-hub against other Godot plugins. It states that the plugin is designed for local LLMs first, with remote providers supported, and that Ollama is supported by the maintainer and sometimes ahead in features.
How does Godot work?
This is outside the scope of the plugin. What is relevant here is that godot-ai-assistant-hub exposes Godot's editor objects through tools, including scene node trees, node properties, node signals, resources and files.
What are the top 3 AI assistants?
The repository does not rank assistants. It describes an assistant model of its own, where different assistant types are used for different tasks, and ships example assistants under examples/assistants/ and examples/quick_prompts_no_tools/.
Community notes