Editor-Only AI Tooling in UE5: Why UncookedOnly Modules Add Zero Shipping Cost

The real question: will this plugin bloat my packaged game?

Every UE5 developer who installs an AI-assist or developer-tools plugin asks the same thing before shipping: does this end up in my cooked build? It is a fair worry. A plugin that helps you author content has no business sitting inside the executable a player downloads, dragging in dependencies, growing the binary, and widening your attack surface. The good news is that Unreal already has a precise mechanism to keep editor-side tooling out of cooked builds, and it hinges on one field in the plugin's module descriptor: the module Type.

If you are weighing UncookedOnly vs an Editor module and wondering whether a tool will bloat your packaged game, the short answer is that both are stripped from cooked shipping builds. Where they differ is when they load and what they are allowed to touch. Understanding that distinction lets you read any plugin's .uplugin file and know, before you ever click Package, exactly what will and will not travel with your game.

This article walks through the three module types that matter for this decision, explains why UncookedOnly is excluded from cooked builds, and shows how MythicDevAssist applies the rule across its three modules so the bridge that drives your AI agent leaves nothing behind in the shipped product.

The three UE5 module types that matter here

A UE5 plugin is a collection of modules, and each module declares a Type in the .uplugin descriptor. Three of those types decide whether code reaches a cooked build. Runtime modules are compiled into every target, including the shipping build the player runs, so anything you place in a Runtime module is code you are shipping. Editor modules compile only for editor targets; the cooker never includes them in a packaged game. UncookedOnly modules compile for tools and editor contexts but are explicitly excluded from cooked builds, which is the type you want for code that supports authoring without ever needing to run at game time.

Alongside Type, a module also declares a LoadingPhase that controls when in engine startup it initialises. A phase such as PostEngineInit means the module comes up after the core engine has finished booting, which is the right moment for editor tooling that depends on the engine and editor subsystems already existing. The Default phase loads earlier in the normal sequence. These two fields, Type and LoadingPhase, together tell you both whether a module ships and when it wakes up.

The practical takeaway is simple. When you evaluate a developer-tools plugin, open its .uplugin and look at the module list. If a module that does authoring or observation work is marked Runtime, treat it as something you are shipping and scrutinise it. If it is marked Editor or UncookedOnly, the cooker leaves it behind.

Why UncookedOnly is excluded from cooked builds

The cook step is where Unreal converts your editor-friendly project into the lean, platform-specific data and code a packaged game actually uses. Part of that conversion is deciding which module binaries to include. UncookedOnly is, by definition, the category for code that is only ever relevant before or during cooking and authoring, never in the cooked output, so the build pipeline drops it. That is not a configuration you have to remember to set on your side; it is the contract the module type carries.

This is what 'zero runtime cost' means in concrete terms. A module marked UncookedOnly is not linked into a cooked shipping build at all. There is no dormant subsystem ticking away, no extra DLL alongside your executable, no symbols to strip. The code simply is not present in what you ship, so it cannot cost frame time, memory, or download size in the player's hands.

Editor modules earn the same exclusion through a different door: they only ever compile for editor targets, so the cooker has nothing of theirs to include either. The reason a plugin author reaches for UncookedOnly rather than Editor for some code is loading semantics and what the code is allowed to depend on. UncookedOnly suits engine-level support code that should be available in tool and commandlet contexts as well as the full editor, while Editor suits code that genuinely belongs to the editor application. Either way, your packaged game is untouched.

How MDA splits MythicDevAssist, MythicDevAssistEditor and MDAFeedback

MythicDevAssist (MDA) is an agent-native editor bridge: it lets external AI coding agents such as Claude Code, Cursor, or Codex CLI actually drive and observe the UE5 editor instead of guessing at outcomes. It runs an in-editor HTTP server and exposes structured read-backs so a stateless agent stays grounded. That is exactly the kind of capability you want available while you build and never present in what you ship, and its module layout reflects that.

The .uplugin declares three code modules, each chosen for the job it does. MythicDevAssist is the core module, typed UncookedOnly with the Default loading phase, so the bridge layer is excluded from cooked builds. MythicDevAssistEditor is typed Editor with a PostEngineInit loading phase, so its editor-facing pieces come up after the engine has finished booting and, being an Editor module, never reach a packaged game. MDAFeedback is also an Editor module on the Default phase. There are zero Runtime modules in the descriptor, which is the structural reason MDA adds no shipping cost.

Because none of these modules are Runtime, the whole plugin sits on the editor side of the cook boundary. The plugin is categorised under Developer Tools, contains no content (CanContainContent is false) and ships zero Blueprints, so there is no stray asset or runtime class to leak into a build either. Its core subsystem loads on editor startup and does its work entirely within the editor process. When you cook and package, all three modules are left behind by design.

Local-first: nothing leaves 127.0.0.1

Keeping tooling out of the shipped build addresses the runtime-cost worry; the other half of the trust question is what the tool does while it is running in your editor. MDA's bridge binds to 127.0.0.1 only, the loopback address, and will auto-cycle through ports 7779 to 7788 if the default is busy. Loopback-only binding means traffic never leaves the machine, so no inbound firewall rules are required and there is no externally reachable service.

There is no cloud account and no external network dependency in the bridge itself. The design is local-first: the editor hosts the HTTP server, your AI client connects to it over loopback, and the observability data it gathers is written to a per-session SQLite database under your project's Saved folder. You bring your own agent; MDA is the bridge layer, not an AI service phoning home.

Every module also carries a PlatformAllowList of Win64, so the plugin targets a Windows 64-bit editor host. That platform scoping, combined with the UncookedOnly and Editor module types, draws a tight box around where this code can run: a Windows editor, on loopback, never in a cooked build. To verify the boundary yourself, open the plugin's .uplugin and confirm the three modules and their types, then check the MDA dashboard in the editor, which shows the live loopback endpoint and the session database path so you can see exactly what is listening and where data lands.

If you want the same editor-only discipline elsewhere in your toolbox, the sibling MythicLemon tools follow the pattern: AI Flipbook Generator does its generation work in the editor and bakes finished assets you choose to keep, Easy Kanban Board is an editor-only single-module plugin with zero runtime overhead, and Lumen Meter measures scene brightness while you author. Each keeps the heavy lifting on the authoring side of the cook boundary.

MythicDevAssist modules and the cook boundary

Type and LoadingPhase as declared in the .uplugin. No module is typed Runtime, so none is linked into a cooked shipping build.

FAQ