CraftStation: a desktop workbench for composing model and harness pairs

Native by default, so the provider keeps its own agent loop

CraftStation describes itself as an agent runtime composition system with the slogan that your model, your harness and your agent are yours to choose. The default behaviour is the part that matters most for anyone worried about a wrapper degrading their tooling. The README says CraftStation defaults to a model's native Harness to bring out its full capabilities, preserving the official runtime's agent loop, context management and tools. In Auto mode the mapping is explicit: GPT to Codex, Kimi to Kimi Code, Gemini to Antigravity. The official runtime retains ownership of its agent loop, context management, tool execution, MCP and Skills. So the application is a workbench and a launcher rather than a reimplementation of the agent. That is the design choice that makes it usable with harnesses it did not write, and also the reason the harness still has to be installed on your machine.

A Recipe is a saved model and harness pair

The naming borrows from Minecraft, and the README leans into it. You select items, form a recipe, let the crafter compile a plan, and spawn an entity that works inside a continuous session. In practice a Recipe is a saved combination of a model and a harness. The README describes the workbench as making Model times Harness composition visible: you pick your ingredients, inspect compatibility, and save the result. The screenshot examples given are combinations like Gemini 3.8 Flash with the Codex Native Harness and K3-256k with the Codex Native Harness. Cross-vendor combinations use a compatibility bridge where needed, with CLIProxyAPI handling provider and API compatibility while the selected Harness continues to run the agent. Saved Recipes appear next to plain models in the same picker, so a combination you set up once becomes an everyday choice rather than a configuration you rebuild each time.

One model menu spanning several agent runtimes

The model picker is where the workspace idea shows up. The README lists models across Codex, Grok Build, Kimi Code, Antigravity, OpenCode, Devin, Step Code and other integrated harnesses. The stated benefit is that you can stay inside your project while switching agents, following their output and inspecting tool activity, so the workspace around the agent stays familiar as you change the runtime doing the work. The Harness overview adds a layer of visibility that most agent tools do not have: it connects channel to model to final harness or CLI, and shows whether that runtime is ready or still needs installation. That readiness state is the practical piece, because a saved Recipe pointing at a harness you have not installed is a broken entry in a menu, and the overview is where you would catch it.

Account pools with visible quota and failover between your own accounts

The Channels and quotas page manages multiple accounts in supported provider pools, with Grok, Kimi Code and ChatGPT named. You can view session or weekly usage, reset times, account priorities, and enable and disable controls together, and you can see which accounts still have capacity before starting the next task. New sessions follow the pool's scheduling rules, and accounts can be ordered by priority, with pool failover selecting another eligible account when quota or availability stops the current one from continuing. Read that carefully before configuring it, because automatic failover between accounts is exactly the behaviour that will surprise you if you expected a specific account to be used. The pool here is a set of accounts you already hold, and the README frames the feature as putting your accounts and quotas to work.

MCP servers, Skills, scheduled threads and cross-thread handoff

The features beyond the composer are what make this an orchestrator rather than a launcher. Agents can hand tasks to other sessions or create a new one through built-in MCP tools, which the README calls cross-thread collaboration. A Schedule feature wakes a thread at a scheduled time or interval so it continues working unattended. Browser and Computer Use gives compatible harnesses browser tools and Windows desktop actions, including clicks, typing and screenshots. Skills, MCP and Git worktrees are managed from the same desktop, with project bindings and compatible tool injection, and there is a Manage CLI updates feature in the titlebar that can check and update installed CLIs, controlled by an auto-update setting under Settings, Agents, General, with managed account-profile copies updated too. The worktree and Git mention matters for coding agents, since parallel agents editing the same checkout is a common source of trouble.

An Electron app with a renderer, a main process and native module plumbing

The package manifest shows a private package named craftstation at version 1.11.7, Apache-2.0, with the description describing it as a universal desktop orchestrator for AI agents that runs terminal-native and structured chat agents side by side. The main entry is dist/main/main.cjs and the package is an ES module. The dev scripts are worth reading because they show the process structure, with a Vite renderer, an Electron main process built by tsdown in watch mode, and an app step that waits for several built artifacts before launching.

    "postinstall": "node scripts/ensure-native-deps.mjs --electron-native && pnpm run codex-protocol:gen",
    "setup:native": "node scripts/ensure-native-deps.mjs --electron-native",
    "devtools": "node scripts/dev-react-devtools.mjs",
    "dev:renderer": "node scripts/free-port.mjs && vite",
    "dev:mobile": "node scripts/free-port.mjs 3100 && cross-env CRAFTSTATION_BUILD_TARGET=mobile vite",
    "dev:electron": "tsdown --watch",

The app script waits on dist/main/main.cjs, an MCP probe worker and a cursor SDK worker, then prepares WSL helpers and agent plugins before launching. The repository layout backs that up with a native directory, an android and ios directory, a chrome-extension directory, a packages directory and a pnpm workspace file, plus a capacitor.config.json, a lingui.config.ts for translations and a mobile.html entry point.

A headless remote server and telemetry you can turn off

The .env.example file is unusually informative about what the application sends out. Crash and error reporting through Sentry is optional and controlled by SENTRY_DSN, with a separate SENTRY_DEBUG flag and a SENTRY_AUTH_TOKEN for uploading source maps during release builds. Product analytics through PostHog is optional and gated by POSTHOG_ENABLED, and the file explains that PostHog keys are browser and client keys rather than secrets, and that they may be visible to a local user in renderer process arguments or bundled JavaScript. That is a candid admission about where a client-side key ends up. The same file documents a standalone headless remote server started with a pnpm run server, which boots the same remote-access server the desktop exposes without Electron, with a bind host and port, an advertised host for pairing URLs, and a secret key that can be injected from a real secret manager rather than generated on disk.

Editorial conclusion

CraftStation fits an individual developer on Windows who runs more than one AI agent, wants to compare harnesses on the same task, and likes keeping account quota and MCP server setup in a single window rather than in shell profiles. It does not fit a team that needs a shared, audited setup, since the configuration lives in a desktop app, and the README does not describe multi-user accounts for the workspace itself. Verify first that the harness for your chosen model is already installed on your machine or that you are willing to install it, read the account pool scheduling rules before adding several provider accounts, and check the telemetry settings in the .env.example before enabling product analytics.

Frequently asked questions

Official sources

1. HernanJiang/CraftStation on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases