AutoDev Xiuper: a Kotlin Multiplatform multi-agent coding platform
🧙‍AutoDev: the Multi-Agent coding development platform built on Kotlin Multiplatform.
At a glance
- What is it?
- AutoDev Xiuper is an alpha, MPP-based agent platform from phodal/auto-dev that ships the same agent runtime to IntelliJ IDEA, VS Code, CLI, web, desktop, Android and iOS. It is broad by design, which is also its main cost.
- Who is it for?
- Adopt AutoDev Xiuper if you need one agent runtime across an IDE, a CLI and a server, and you are willing to track an alpha release line under MPL-2.0. Do not adopt it if you want a single stable agent for one surface, or if you depend on the iOS shell, the VS Code package or the web agent, since the README places mpp-ios, mpp-vscode and mpp-web outside the current root Gradle build graph and marks the web agent experimental.
- Can I use it commercially?
- Yes, with conditions. MPL-2.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 27, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What AutoDev Xiuper is, and the problem it targets
Most coding agents are bound to one surface. A plugin lives in the IDE, a CLI lives in the terminal, and the two do not share an agent loop, tool set or prompt rules. AutoDev Xiuper takes the opposite position. The README describes it as an "AI-native, multi-agent development platform built on Kotlin Multiplatform", and states that it targets IntelliJ IDEA, VS Code, CLI, Desktop JVM, Android, iOS, JS/WASM Web, and Server runtimes from one codebase. The problem it addresses is fragmentation: one agent engine, one tool layer, many front ends.
The intended audience is engineers who work across more than one of those surfaces, or who want to embed an agent runtime in their own product. The module table makes this explicit. mpp-core is the shared agent engine, tools, MCP integration and AGENTS.md loading. mpp-ui is the multiplatform UI surface and app entrypoints. mpp-server is a Ktor-based remote coding agent server. mpp-idea and mpp-vscode are host integrations. If you only ever use one IDE, the platform framing buys you little. If you want the same agent behaviour in an IDE and in a headless server, the shared core is the whole point.
The README is equally clear about maturity. The project is labelled Alpha, the most recent published release is compose-v3.0.0-alpha5 from 2026-02-07, and the last push to the repository was on 2026-08-04. Several capabilities are marked as experimental or outside the default build, which matters more than the feature list when you are deciding whether to depend on it.
The mpp-core agent engine and how tools flow through it
The architecture is a shared runtime with thin host shells. mpp-core holds the agent engine, the tool definitions and the MCP integration. Hosts such as mpp-idea and mpp-vscode do not reimplement agent behaviour; they render it and wire in host-specific services. The README notes that mpp-idea is a composite build with "dedicated renderers and toolwindow integration", and that mpp-vscode is "backed by mpp-core JS bindings". That is the data flow: the same agent decides what to do, the host decides how it looks and what host APIs are reachable.
Tools are the second layer. The README lists built-in file system, grep/glob, shell, web fetch, MCP tools and renderer integration for the CodingAgent. A model turn produces a tool call, the runtime executes it against the workspace, and the result returns to the loop. SubAgents are exposed as tools rather than as separate top-level loops, which the README calls the "agent as tool" pattern. The named SubAgents include a NanoDSL agent for generating UI code, a PlotDSL agent for statistical charts, and a chart agent for ComposeCharts configurations. PlotDSL is listed as JVM Desktop and Android only, so the cross-platform promise has real exceptions.
Project rules come from AGENTS.md. The README states that the runtime performs "automatic AGENTS.md discovery and prompt injection from project hierarchy", and the repository contains both AGENTS.md and AGENTS.md.example at the top level. This is the cheapest way to steer the agents without touching their code. Code intelligence is separate from the agent loop: the README describes Tree-sitter based parsing for Java, Kotlin, Python, JavaScript/TypeScript, Go, Rust and C#.
Installing AutoDev Xiuper and running a first agent task
The README points to five distribution channels rather than a single installer. IntelliJ IDEA users get the plugin from the JetBrains Marketplace. VS Code users get the extension from the Visual Studio Marketplace under the publisher Phodal. The CLI installs from npm. There is a hosted web app at web.xiuper.com, and Desktop and Android builds are attached to GitHub Releases. iOS is explicitly build-from-source.
The CLI is the fastest path to a first run because it needs no IDE restart. The README gives this exact command:
npm install -g @xiuper/cliAfter installation, the CLI is on your PATH. The README does not document the CLI's flags or subcommands, so the first task should be whatever the tool prints when invoked without arguments rather than a command invented from the feature list.
For IDE work, install the plugin from the marketplace listing and open a project that contains an AGENTS.md. The README states that AGENTS.md is discovered automatically from the project hierarchy and injected into prompts, and the repository ships AGENTS.md.example as a starting shape. The README does not give the contents of that example file, so open it in the repository rather than copying a shape from here.
Once an AGENTS.md exists in the project, the CodingAgent picks it up without further configuration. The README also documents that model and tool configuration live in UI surfaces, and that OpenAI, Anthropic, Google, DeepSeek and Ollama are among the supported providers. Ollama is the one that keeps a first experiment entirely local, assuming you already run an Ollama server. The README does not document the provider configuration keys, so read the configuration UI rather than guessing at environment variables.
Where AutoDev Xiuper is the wrong tool
The alpha label is not decorative. The newest release is compose-v3.0.0-alpha5, and the README's own status snapshot separates modules that are in the default root Gradle build from those that are merely present in the repository. mpp-vscode, mpp-ios and mpp-web are maintained in the repo but excluded from the current settings.gradle.kts build graph. If your adoption plan depends on the iOS app or the VS Code extension being built and tested by the same root build as mpp-core, the repository layout says otherwise.
Capability coverage is uneven in a way the feature list hides. The Web Agent and WebEdit flows are marked experimental. Testing capability exists mainly through xiuper-e2e and E2E-oriented tooling, and the README states it is not yet a clearly separated top-level agent. PlotDSL is limited to JVM Desktop and Android. A team looking for a single stable agent for one narrow job, such as reviewing pull requests in IntelliJ IDEA, gets more surface area than it needs and inherits the alpha release cadence.
There is also a documentation gap. The README describes what exists in the codebase but does not document CLI flags, provider configuration keys or upgrade or rollback procedures. For a platform that spans nine or more runtime targets, that is the difference between reading a feature inventory and following an operations manual. Budget time for reading the source, particularly mpp-core, before you commit a workflow to it.
How AutoDev Xiuper differs from single-surface coding agents
The obvious comparison is a single-surface coding agent, such as an IDE plugin that performs edits and reviews inside one editor and nowhere else. The difference is architectural rather than feature-level. A single-surface agent can assume the editor's file model, its diff view and its language services. AutoDev Xiuper cannot, because the same agent loop has to run in a terminal, in a Ktor server and in a browser WASM target. That forces the abstraction into mpp-core and pushes host-specific behaviour into renderers and toolwindow integration.
The trade-off is visible in the module table. The shared core is what makes an IDE plugin and a headless server behave identically, and it is also why platform-specific gaps appear, such as PlotDSL on JVM Desktop and Android only. A single-surface tool would simply not have that gap, because it would never have promised the other platforms.
A second comparison is with a plain MCP client. AutoDev Xiuper speaks MCP as a tool source and also supports A2A agent commands, Claude Skill loading and SpecKit command integration. If your need is only to call a handful of MCP servers from one editor, a thin MCP client is less machinery. AutoDev Xiuper is aimed at the case where the agent itself, with its agents, sub-agents and project rules, has to be the portable part.
Licence, upgrade cost and maintenance signals
The repository is licensed under MPL-2.0. That is a file-level copyleft licence, which means modifications to MPL-covered files carry obligations when distributed, while larger works that combine MPL files with other code can generally be licensed differently. This is a summary of the licence identifier in the repository, not legal advice; if you plan to redistribute a modified mpp-core, read the licence text in the repository and talk to whoever handles licensing for you.
The upgrade cost comes from the release cadence and the version naming. Recent releases are all alpha builds in the compose-v3.0.0 line, published on 2025-12-29 and 2026-02-07. An alpha line means interfaces in mpp-core and the host integrations can move between releases. The README does not document a migration or rollback path, so pinning to a specific release and reading CHANGELOG.md before moving is the practical approach. The repository does carry a CHANGELOG.md at the top level.
On maintenance, the last push to the default branch was on 2026-08-04, and the repository is not archived. That is the evidence available. The README also points at AutoDev 2.0 as the stable branch for users who want the older plugin, which is a useful signal: the project itself treats Xiuper as the moving line and 2.0 as the settled one.
Editorial conclusion
Adopt AutoDev Xiuper if you need one agent runtime across an IDE, a CLI and a server, and you are willing to track an alpha release line under MPL-2.0. Do not adopt it if you want a single stable agent for one surface, or if you depend on the iOS shell, the VS Code package or the web agent, since the README places mpp-ios, mpp-vscode and mpp-web outside the current root Gradle build graph and marks the web agent experimental. Before committing a workflow, verify three things in the source: the CLI's actual subcommands, the provider configuration keys behind the model configuration UI, and which mpp-core interfaces changed between the compose-v3.0.0-alpha3 and alpha5 releases listed in CHANGELOG.md.
Frequently asked questions
What is AutoDev Xiuper?
It is an AI-native, multi-agent development platform built on Kotlin Multiplatform, described in the README as targeting IntelliJ IDEA, VS Code, CLI, Desktop JVM, Android, iOS, JS/WASM Web and Server runtimes from one codebase. Its code-backed agents cover document research, coding, code review, database queries and artifact generation. The current release line is alpha.
How do I install the AutoDev Xiuper CLI?
The README gives the CLI install as a global npm package: npm install -g @xiuper/cli. The same README lists the IntelliJ IDEA plugin on the JetBrains Marketplace, the VS Code extension on the Visual Studio Marketplace, the web app at web.xiuper.com, and Desktop and Android builds on GitHub Releases. iOS is build-from-source.
Which LLM providers does AutoDev Xiuper support?
The README lists OpenAI, Anthropic, Google, DeepSeek, Ollama and more under multi-LLM support. Model and tool configuration are exposed through UI surfaces rather than documented as configuration keys in the README.
How does AutoDev Xiuper pick up project rules?
The runtime performs automatic AGENTS.md discovery and prompt injection from the project hierarchy, and the repository includes an AGENTS.md.example file. Placing an AGENTS.md in your project is enough for the CodingAgent to read it; no extra wiring is described in the README.
Is AutoDev Xiuper stable enough for production use?
The project is labelled Alpha, and the most recent published releases are compose-v3.0.0-alpha builds from 2025-12-29 and 2026-02-07. The README also points to AutoDev 2.0 as the stable branch. The README does not document a rollback or migration procedure between releases.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/phodal-auto-dev)