genex-desktop: a chat driven game studio that mixes Claude and GPT models

A studio where the main agent, workers and reviewers can use different models

Genex is described as a desktop app for game dev with AI, for macOS, Windows and Linux. The project name in the package manifest is ai-game-studio and the product name is Genex, and the package is marked private, so this is an application rather than a library.

What it does is listed as a chain of capabilities. You use your Claude Code or ChatGPT subscription, or you run local models. It is multi agent, letting you mix Opus and GPT models across the main agent, workers and reviewers. It makes 3D assets locally through the Blender plugin, reaches Meshy, Tripo, ElevenLabs and more through the Genex tools router, exports anywhere or publishes to the web, and builds in Unreal or Godot on your Mac with their plugins. Native C++ games are listed as soon.

The model mixing is the part worth pausing on. Most assistants give you one model for everything. Here the split is by role, so the planner, the workers doing the work and the reviewers checking it can be on different models, which is a reasonable way to spend a subscription quota. Running local models is offered as the alternative to a hosted subscription, which matters for anyone who does not want game design and code flowing to a hosted provider.

The project is candid about its maturity. The download section says Genex is early, that you should expect rough edges, and that issues are the way to report them. The version in the manifest is 0.1.13.

Apple Silicon first, system packages on Linux, unsigned preview on Windows

The download table is the clearest statement of priorities. macOS on Apple Silicon has a Genex.dmg. Linux x64 gets a.deb, an.rpm or a.zip from the latest release, and the.deb and.rpm add the Genex package repository, so the system's own updater, whether Software Updater, apt or dnf, brings every later version. That is a small detail with a large effect on how the application stays current on a machine you do not want to babysit.

Windows x64 is labelled preview. The installer is Genex-Setup.exe, and the documentation is explicit that it is not signed yet: if Windows warns, choose More info and then Run anyway.

That warning is the practical cost of the signing setup described further down, and it is the kind of thing that ends a rollout inside a company with endpoint management. For a developer downloading a build to try, it is a mild friction. For a studio, it is a blocker until the signing path described below is in place.

Every release also lists the SHA-256 of each file in a SHA256SUMS file, which at least lets you verify what you downloaded. The repository is not archived, the last push was on 2026-10-22, and three releases landed within two days: v0.1.10 and v0.1.11 on 2026-10-19, then v0.1.12 on 2026-10-20. That cadence is a fact about a pre-1.0 project, and it cuts both ways: fixes arrive quickly, and the changelog will not be a stable contract.

Running the studio locally with the scripted first-run fixture

Contributing requires macOS on Apple Silicon, Git and Node 24. The manifest pins the engine to node 24.x and the repository carries a .nvmrc, so the Node version is a project decision rather than a preference. The setup sequence is five commands:

git clone https://github.com/genex-games/genex-desktop.git
cd genex-desktop
nvm install && nvm use   # Node 24, from .nvmrc
npm ci
npm run studio:dev -- start --profile first-run --fixture app-basics

The last command is the interesting one. The fixture runs the app with scripted models and sample games, which means it needs no account and no provider subscription. That is the fastest way to see whether the studio is worth setting up, and it is also how a new contributor works without spending tokens.

The scripts behind it are visible in the manifest. The build is node scripts/build.mjs, with a watch variant, and start runs the build and then electron ., so the shell is Electron. The main entry point is dist/main/main.mjs and the module type is ESM. Linting and formatting go through biome, with a check script that runs the linter at diagnostic level error.

The project also asks contributors to read CONTRIBUTING.md before opening a pull request, and it points coding agents at AGENTS.md first.

Plugins are the extension path, and the app ships its own as plugins

The extension model is plugins, and the documentation says so directly: plugins give the Genex agents new tools, an asset generator, an engine bridge, or a service your game talks to. The Blender integration and the Genex tools that ship with the application are plugins too, which is a good sign, because it means the internal and external extension paths are the same mechanism.

Scaffolding and checking happen from the command line:

npm run plugin:new -- my-plugin --out ~/studio-plugins   # scaffold it from the example
npm run plugin:doctor -- ~/studio-plugins/my-plugin      # check it the way Genex will

The doctor command is the piece to know about, because it checks a plugin the way Genex will, on your machine, before the app ever loads it. Then there are three distribution steps. You try it locally through Plugins, Add, Load local plugin and pick the folder. You share it by pushing to a public GitHub repository and publishing a release for each version, and anyone can install it from there through Plugins, Add, Install from GitHub. And you list it by opening a pull request against the genex-plugins repository, where a maintainer reviews it and it appears in the Marketplace of every Genex app.

The plugin guide covers tools, panels, settings and accounts, so a plugin is more than a script, it is a surface inside the application.

Signing is manual until the GitHub Actions path is switched on

The code signing policy is spelled out rather than implied. Free code signing is provided by SignPath.io, with the certificate from the SignPath Foundation. The condition is specific: Windows builds are signed only when GitHub Actions builds them from this repository's source, and a maintainer approves each release before it is signed. Committers and reviewers are the members of the genex-games organisation, and approvers are its owners.

Until that path is in place, Windows builds ship unsigned as a preview. That is a specific, dated commitment rather than a vague plan, and it is the reason the download instructions include the Run anyway step.

The alternative for a user who cares about provenance is the SHA256SUMS file published with every release, which lets you verify the bytes you downloaded against the published list. That is weaker than a signature, because it only proves the file matches what the release published, not that the build was produced from the audited source tree.

The repository also carries SECURITY.md, PRIVACY.md and THIRD-PARTY-NOTICES.md, with the privacy policy covering what Genex stores and sends, and connected providers, plugins and services keeping their own policies. That last point matters more than it looks, because the tools router sends requests to third party asset and voice services.

The check suite is unusual for a desktop app

The scripts section shows a project that spends real effort on static verification, and it is the most distinctive part of the repository layout. The check:static script chains a node version check, a context verification, an architecture verification, a TypeScript compile with an incremental build info file, affected test syntax checks, linting of affected files, a test style check, a vocabulary check, a plugin version check, and an eval isolation check. The check script then runs the affected test tier L1.

Some of those deserve a comment. A vocabulary check on source files is a content lint, which fits a product where the app generates text for users. A plugin version check implies the app and its plugins are versioned against each other, which is exactly the failure you would expect in a plugin architecture. An eval isolation check under evals/ suggests the evaluation runs are checked for leaking state between cases.

The test tooling is layered rather than monolithic. There is a plain test script, an affected tests script that works out what changed, a tiered runner, an area flag, and a fast subset. That is a build system for tests, and it is what you would expect from a repository with a tests/ directory, an evals/ directory and a research/ directory, plus a forge.config.cjs for packaging.

The flip side is that the check chain is long. A contributor who only wants to change a prompt or a panel has to get a large pipeline green, and the affected-tests machinery exists precisely to keep that from being a full run every time.

Where Genex is the wrong tool

Three limits are visible in the documentation itself.

The first is the platform. Contributing requires macOS on Apple Silicon, and the app description leads with macOS. Linux and Windows builds exist, but the development story is Mac only, so a team on Windows or Linux is working against the toolchain.

The second is the deliverable. Native C++ games are on the list as soon, which means a project whose end state is a native C++ title cannot be built in Genex yet. The path that works today is the one that exports into Unreal or Godot, and the project says so as build in Unreal or Godot on your Mac with their plugins. If your plan is to stay inside the engine's own workflow and its own scripting, Genex adds a chat surface and an asset router on top of that, which is a different product decision rather than a strict improvement.

The third is dependence on other people's services. The tools router reaches Meshy, Tripo and ElevenLabs, and connected providers and plugins have their own privacy policies. If your data policy forbids sending assets or voice to third party services, the router is not usable and the local Blender path becomes the only one left.

On maturity, the 0.1.x version line, the daily releases, the rough edges warning and the unsigned Windows build together say this is a tool to evaluate, not a tool to standardise on. The MIT licence removes one objection, since the code can be forked and modified without obligations beyond attribution.

Editorial conclusion

Adopt genex-desktop if you are prototyping a game with AI assistance, want Claude and GPT models mixed across one main agent, workers and reviewers, and are willing to run an early 0.1.x application on Apple Silicon. Do not adopt it if the deliverable is a native C++ game, since that is still listed as soon, or if you need signed Windows installers today, because the Windows build is a preview and unsigned until GitHub Actions builds it from source with maintainer approval. Verify first that your provider subscription or local model setup works, and that the plugin you depend on passes npm run plugin:doctor before you load it into the app.

Frequently asked questions

Official sources

1. genex-games/genex-desktop on GitHub
2. License: MIT
3. Project website
4. README
5. Releases