Locus for Unity: an AI agent that runs beside the editor

Beside the editor rather than inside it

Locus for Unity is an open source AI Agent for Unity projects, and the sentence in the README that explains its design is this one: if Locus were implemented inside the Unity Editor, or designed as an MCP server, most of these capabilities would be difficult to deliver and some would be nearly impossible technically.

That is a strong claim, and the rest of the README explains it. Locus is a standalone Rust plus Tauri plus Vue.js application that runs as an independent process, and the features it lists depend on that separation. It can JIT-compile and execute C# code inside the Unity Editor to make semantic asset edits, which is a different thing from asking an editor extension to compile a script. It can run Roslyn semantic analysis in its own process and see compiler-grade errors the moment it changes code, without waiting for Unity to compile. It can perform highly parallel asset database scans, because the parallel ecosystem in Rust lets it do semantic parsing of large scenes and reference queries for arbitrary assets, which the Unity Editor API does not offer, providing only dependency queries.

So the architecture is the argument. An agent that lives in the editor is bound by the editor's threading model, its compiler pipeline and its serial database API. One that lives beside it can do its own parsing, in parallel, and can drive the editor through a richer channel than a script hook.

The project is written in Rust with a TypeScript and Vue frontend, licensed GPL-3.0-or-later, and its documentation lives at unity.farlocus.com. It is currently in early testing, and the README asks for feedback through issues.

The intermediate representation and the retrieval layer

Two mechanisms do the heavy lifting for the agent, and they are the part of the design that is not visible from the feature list.

The first is a proprietary intermediate representation. The README says it lets agents progressively read large scenes and assets, and it is paired with retrieval tools that help agents quickly locate target objects. Progressive reading is the right idea for a Unity project, where a scene file can be enormous and mostly irrelevant to the change you want. Instead of handing the model the whole scene, the agent pulls in the parts it needs.

The second mechanism is the parallel asset scan. Because Locus maintains its own semantic view of the asset database, it can answer reference questions, such as where a field is referenced from UnityEvents, AnimationEvents and scenes, and it can do it without going through the editor's serial dependency query API.

There is a practical consequence. The agent's model of the project is not the editor's model, and the two can disagree. The README addresses this by noting that the apply state is fully visible to the agent, which can confirm immediately whether a change actually landed. A change that the agent believes it made, but that the editor did not accept, is therefore detectable rather than silent.

The version management on the agent side completes the picture. Locus includes agent-side version management handling so users can review and revert asset and code changes the agent makes during a conversation. That is a meaningful difference from most coding agents, which leave the revert problem to git and to the user.

Roslyn outside the editor, and what that buys

The static analysis story is the most concrete technical claim in the project, and it is worth separating the parts.

Locus runs Roslyn semantic analysis in its own process, which means it has go-to-definition, find-references, hover information and live diagnostics available without involving the editor. The diagnostics are compiler-grade errors and warnings, and the agent sees them the moment it changes code rather than after Unity compiles the assembly.

The README claims the diagnostic coverage is close to Rider's live inspections, including finding where a field is referenced from UnityEvents, AnimationEvents and scenes. That last part is the interesting one, because those references are exactly the ones that are invisible to a compiler and that break a refactor at runtime. A tool that can see them has a much better picture of the project than one that only reads source.

The trade is that this depends on the Windows and Unity specific machinery that the agent side can reach into, and on a Roslyn runtime that Locus ships and keeps in step with itself. The repository layout reflects that: there is a locus_compile_server directory, a locus_hotreload_runtime directory, a locus_native_plugin directory, a locus_unity directory, a locus_json directory, a locus_gpu_transport directory and a locus_unity, alongside src-tauri for the Tauri shell and src for the frontend.

The README also says Locus includes agent-side version management so users can review and revert what the agent changed, which is the difference between a tool that edits your project and a tool that edits your project reversibly.

Hot reload that keeps Play Mode state

Unity's domain reload is the reason iterating on a Unity project feels slow. Change a script, and the editor tears down the running state and rebuilds it, so a play session that took ten minutes to set up is gone.

Locus ships with built-in C# hot reload, described as on par with commercial plugins. The agent's changes take effect without recompiling the assembly and without running a domain reload, so Play Mode state is preserved. The README adds the detail that makes this usable: the apply state is fully visible to the agent, so it can confirm immediately whether a change actually landed rather than assuming it did.

That is the whole value proposition in one feature. An agent that edits code inside Unity without a domain reload can be used in an actual play session, with the actual game running, and it does not destroy the user's setup every time it makes an edit.

The second hot-reload-adjacent capability is the runtime analysis tooling. Locus includes C# state-machine tools so the agent can sample internal state through reflection at specific frames or events during runtime, output frame-by-frame tables, and dynamically debug multi-frame behavior. Combined with the runtime analysis and debugging feature in the overview, that is a debugging story rather than a screenshot story, which is a differentiator from tools that only read logs.

The knowledge system and the Vue-based editor UI

The knowledge system is the feature that addresses a different failure mode. The README says Locus includes an automated knowledge system where the agent summarizes fragmented conversation requests into design documents and saves working understanding into memory, reducing repeated project exploration.

That is a real problem with coding agents on a long project. The user says something vague in one session, the agent explores the project for twenty minutes, and then the next session starts again from zero because nothing was written down. Turning a conversation into a design document makes the intent durable.

The documents support configurable AI maintenance modes and maintenance rules, plus L0, L1 and L2 injection control inside the context. The levels are a budget: the agent decides how much of a document to put into its working context. It also supports native lexical and syntactic retrieval across large document sets, and lets the user choose and download embedding runtimes.

The other user-facing feature is editor UI built with web technology. Through the /view command the agent can build Unity editor interfaces with Vue.js, with full HTML and CSS, free of IMGUI's constraints, with data binding and interpreted C# execution built in. Locus embeds a Vue frontend into the Unity window through Windows APIs, on the argument that the Unity Editor API's own controls are limited.

For a project with its own in-editor tooling, that combination, an agent that can author the editor UI in Vue and execute C# from it, is more than a chat box with a file browser.

Building from source with bun and Tauri 2

The repository uses bun and Tauri 2, with Windows as the primary development and build platform, and the README recommends installing from the Releases build rather than building.

Development mode starts the Vite development server and opens the Tauri desktop app:

bun tauri dev

There is a second command for an isolated test instance:

bun run locus:test:app

That enables WebView2 debugging and Codex MCP, then creates isolated database, configuration, logs, workspace, WebView2 profile and process-temp directories. Startup prints LOCUS_RUNTIME_JSON so the complete test environment can be located reliably. The runtime parent is resolved in a defined order, first --runtime-base, then LOCUS_ISOLATED_RUNTIME_BASE, then the Git-ignored .locus-dev.local.json, and finally the system temp directory. The local config file has this shape:

{
  "isolatedRuntimeBase": "<absolute local directory>"
}

The package manifest shows how large a production build is. The script build:tauri:with_embed_python_git chains unity:bundle, compile-server:bundle, ort:bundle, python:bundle, git:bundle, github-cli:bundle, renderdoc:bundle, licenses:bundle and view-runtime:export before the frontend build. There is a sibling script that skips the embedded Python and Git.

That list is the answer to what the agent actually needs at runtime. It needs a Roslyn-based compile server, ONNX Runtime for the embedding work, a Python runtime, Git for the version management, the GitHub CLI, RenderDoc for graphics debugging, a native plugin and the Unity bridge, all bundled into a Windows installer.

Editorial conclusion

Use Locus if you are working on a Unity project on Windows and you want an agent that can edit C# and assets with compiler-grade feedback and a rollback trail, rather than a chat window that prints code for you to paste. Do not adopt it if you are on macOS or Linux, since Windows is the only supported platform, or if you need something you can drop into an existing pipeline today, because the project says it is in early testing. Before installing, read the compatibility note about Unity 2021 and later, plan for the size of the build, which bundles the Unity bridge, a compile server, ONNX Runtime, Python, Git, the GitHub CLI, RenderDoc and licences, and note that the latest release is v0.9.0 from 2026-10-17 with the last push on the same day.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. r1n7aro/Locus on GitHub
4. README
5. Releases