multica/apps/docs/content/docs/providers.mdx

---
title: AI coding tools matrix
description: Multica supports 16 AI coding tools; they implement the same interface, but the capability details diverge significantly.
---

import { Callout } from "fumadocs-ui/components/callout";

Multica ships with built-in support for **16 AI coding tools**. They all implement the same interface — queue, dispatch, execute, return results — so you can drive any of them from the same Multica board. **But the capability details diverge significantly**: whether session resumption actually works, whether MCP is supported, where skill files live, how models are selected. This page is the full matrix.

For guidance on picking a tool when creating an agent, see [Creating and configuring agents](/agents-create).

## Capability matrix

| Tool | Vendor | Session resumption | MCP | Skill injection path | Model selection |
|---|---|---|---|---|---|
| **Antigravity** | Google | ✅ (`--conversation <id>`) | ❌ | `.agents/skills/` | Dynamic discovery (`agy models`) |
| **Claude Code** | Anthropic | ✅ | ✅ | `.claude/skills/` | Static + flag |
| **CodeBuddy** | Tencent | ✅ | ✅ | `.codebuddy/skills/` | Dynamic discovery |
| **Codex** | OpenAI | ✅ | ✅ | `$CODEX_HOME/skills/` | Static |
| **Copilot** | GitHub | ✅ | ❌ | `.github/skills/` | Static (determined by account entitlement) |
| **Cursor** | Anysphere | ✅ | ✅ | `.cursor/skills/` | Dynamic discovery |
| **Hermes** | Nous Research | ✅ | ✅ | `HERMES_HOME/skills/` (per-task home) | Dynamic discovery |
| **Kimi** | Moonshot | ✅ | ✅ | `.kimi/skills/` | Dynamic discovery |
| **Kiro CLI** | Amazon | ✅ | ✅ | `.kiro/skills/` | Dynamic discovery |
| **OpenCode** | SST | ✅ | ✅ | `.opencode/skills/` | Dynamic discovery + variants |
| **DevEco Code** | Huawei | ✅ | ❌ | `.deveco/skills/` | Dynamic discovery (`deveco models`) |
| **OpenClaw** | Open source | ✅ | ✅ | `.agent_context/skills/` (fallback) | Bound to the agent, can't be switched per task |
| **Pi** | Inflection AI | ✅ (session is a file path) | ❌ | `.pi/skills/` | Dynamic discovery |
| **Qoder** | Alibaba | ✅ | ✅ | `.qoder/skills/` | Dynamic discovery |
| **Trae** | ByteDance | ✅ (ACP `session/load`) | ✅ | `.traecli/skills/` | Dynamic discovery |
| **Grok** | xAI | ✅ (ACP `session/load`) | ✅ | `.grok/skills/` | Dynamic discovery (ACP `session/new`) |

## What each tool is for

### Antigravity

From Google. CLI binary name is `agy`. Pairs with Google's Antigravity service and ships with a Gemini-backed default model. Multica launches Antigravity with `agy -p` because that is the daemon-compatible non-interactive mode; `agy -i` needs an attached TTY and is not suitable for background task execution. Current Antigravity CLI releases can still execute tools from this mode, but stdout is plain assistant text rather than a structured event stream, so Multica relays the transcript as text and cannot show per-tool telemetry for Antigravity today. **Session resumption works** via `--conversation <id>`; the daemon captures the conversation UUID from the CLI's log file. **Model selection works** via the `--model` flag (added in agy 1.0.6): the daemon enumerates the catalog with `agy models` and ships the chosen value verbatim. Note these are human display strings such as `Claude Opus 4.6 (Thinking)`, not `provider/model` slugs — and agy silently no-ops on a value it doesn't recognise, so prefer picking from the discovered list over typing a custom one. Skills land in `.agents/skills/` (the CLI inherits Gemini CLI's workspace skill layout — see [Antigravity migration docs](https://antigravity.google/docs/gcli-migration)).

### Claude Code

From Anthropic. **First choice for new users** — the most complete feature set: session resumption actually works, it reads MCP configuration, and it supports fine-tuning flags like `--max-turns` and `--append-system-prompt`. Requires an Anthropic API key.

### CodeBuddy

From Tencent. A Claude Code–compatible CLI agent — Multica drives it with the same stream-json protocol as Claude Code, so session resumption works (via `--resume`) and MCP config is passed through `--mcp-config`. CodeBuddy ships its own native config directory rather than reusing Claude's, so skills land in `.codebuddy/skills/` and the runtime brief is written to `CODEBUDDY.md`. Models are discovered dynamically.

### Codex

From OpenAI. Uses JSON-RPC 2.0, has stronger statefulness, and a finer-grained approve mechanism (manual approval for `exec_command` and `patch_apply`). MCP config is materialized into the per-task `$CODEX_HOME/config.toml`. **Session resumption works** through Codex app-server `thread/resume`; if the saved thread is missing or stale, Multica falls back to a fresh thread so the task can still run.

### Copilot

From GitHub. Model routing goes through your GitHub account entitlement — the tool doesn't select a model itself; GitHub decides which model you get. Placing skills in `.github/skills/` is GitHub CLI's native discovery mechanism.

### Cursor

From Anysphere, the CLI counterpart to the Cursor editor. **Session resumption works** with current Cursor Agent releases: the stream-json event includes a `session_id`, and Multica passes it back with `--resume <id>` on the next run. MCP config is materialized into the task workspace's `.cursor/mcp.json`, with Cursor's project approval file written under a per-task `CURSOR_DATA_DIR` so managed MCP servers do not depend on the user's global Cursor approvals.

### Hermes

From Nous Research. Uses the ACP protocol (shares a transport with Kimi). Session resumption works, and MCP config is passed through ACP `mcpServers`. Hermes discovers skills only from its home directory (`~/.hermes/skills/`, or `%LOCALAPPDATA%\hermes\skills\` on native Windows) and configured `skills.external_dirs` — it has no workspace-relative discovery. So **when an agent has skills assigned**, Multica points `HERMES_HOME` at a per-task overlay of your Hermes home: your real home is mirrored by symlink (auth/secrets included, so token refreshes propagate), a derived `config.yaml` references your existing skills as read-only external roots, and only the assigned skills are written into its `skills/` directory — where they take precedence, so your global skills keep working. A `-p`/`--profile` selection in `custom_args` is honored: the overlay is seeded from that profile's home, and the flag is consumed from the launch command so it can't slip past the overlay. Multica never writes to your shared home directly (it only reads it and links into it), though writes Hermes itself makes through a mirrored symlink — a token refresh, say — do propagate. Task memory is isolated per task: a fresh `memories/` directory, plus the external `memory.provider` backend is disabled in the derived config, so neither on-disk notes nor a shared Supermemory/Hindsight-style bank crosses between tasks (a managed, agent-scoped memory backend is a separate future decision). A Hermes task with no assigned skills runs against your real home unchanged.

**Selecting a Hermes profile.** To launch Hermes under a specific profile, set the agent's `custom_args` to the profile flag and the profile name as two separate entries — for example, for a profile named `research`:

```json
["-p", "research"]
```

Don't combine them into one string like `"-p research"`; Multica passes each array item as a separate argv entry. `custom_args` is configured per agent — see [Creating and configuring agents](/agents-create).

### Kimi

From Moonshot, aimed at the Chinese market. Shares the ACP protocol with Hermes, including MCP config through ACP `mcpServers`, but the skill path `.kimi/skills/` is Kimi CLI's native discovery mechanism — different from Hermes's fallback.

### Kiro CLI

From Amazon. Uses ACP over stdio via `kiro-cli acp`. Session resumption works through ACP `session/load`, MCP config is passed through ACP `mcpServers`, model selection works through `session/set_model`, and skills are copied into `.kiro/skills/` for native project-level discovery.

### OpenCode

From SST, open source. Dynamically discovers available models and model variants (scans the CLI's configuration file). Session resumption works, and it consumes the agent's `mcp_config` field — Multica injects it inline through the `OPENCODE_CONFIG_CONTENT` environment variable, so the agent's MCP servers reach OpenCode without writing anything into the task workdir's `opencode.json` (the agent or the user keep ownership of that file). When a model exposes variants, Multica shows them as the agent thinking selector and passes the selected value through `opencode run --variant`. **Suitable for tinkerers who want to customize their model catalog.**

### DevEco Code

**DevEco Code** is Huawei's independent coding agent for HarmonyOS development (`deveco` CLI, [gitcode.com/openharmony-sig/deveco-code](https://gitcode.com/openharmony-sig/deveco-code)). Built on the OpenCode engine, it ships as a complete product in its own right — its own model catalog and provider (the built-in `deveco/GLM-5.1`), Huawei-account auth, and its own config and skill layout under `~/.config/deveco/` and `.deveco/skills/`. Multica drives it over `deveco run --format json`, parsing the NDJSON event stream. **Session resumption works** (`--session <id>`), models are discovered dynamically (`deveco models`), and system context is delivered through the per-task `AGENTS.md`. MCP servers are configured through DevEco's native `DEVECO_CONFIG_CONTENT` channel; Multica-side `mcp_config` wiring is in progress, so the MCP tab is hidden for DevEco agents for now. Authenticate with `deveco auth login` (Huawei account).

### OpenClaw

Open-source project, a CLI agent orchestrator. MCP config is materialized through Multica's per-task OpenClaw config wrapper. **Model is bound at the agent layer** (`openclaw agents add --model`) — it can't be overridden per task. Configuration is strictly controlled: users can't pass `--model` or `--system-prompt`; the agent-registration config decides.

### Pi

From Inflection AI, minimalist. **Session resumption is unusual** — the session ID is a file path on disk (`~/.pi/...`) rather than a string ID. In other tools, the resume id is a string returned by the CLI; in Pi, the resume id is the session file itself.

### Qoder

From Alibaba. An agentic coding CLI. Uses the ACP protocol over stdio (shares a transport with Hermes, Kimi, and Kiro CLI). Session resumption works through ACP `session/resume`, MCP config is passed through ACP `mcpServers`, model selection is discovered dynamically, and skills are copied into `.qoder/skills/` for native discovery.

### Trae

From ByteDance — the official **TRAE CLI** (`traecli`, documented at [docs.trae.cn/cli](https://docs.trae.cn/cli); this is the product paired with the Trae IDE, **not** the open-source `bytedance/trae-agent`). traecli is ACP-native, so Multica drives it over the standard ACP JSON-RPC transport via `traecli acp serve --yolo`, exactly like Kiro and Qoder — `--yolo` puts it in bypass-permissions mode so headless runs don't block on tool-approval prompts.

- **Session resumption works** through ACP `session/load` (traecli advertises `loadSession: true` from `initialize`).
- **Model selection is dynamic**: the model catalog is discovered from `session/new` (`models.availableModels`) and switched per task via `session/set_model`. Set the daemon-wide default with `MULTICA_TRAECLI_MODEL`.
- **MCP is supported** — config is passed through ACP `mcpServers`; traecli advertises `mcpCapabilities: {http, sse}`, and unsupported transports are filtered out before `session/new`.
- **Authentication** is traecli's own enterprise login: run `traecli` once interactively to complete the browser login (the token persists in `~/.trae` + the OS keyring). The IDE login is separate — logging into the Trae IDE does **not** log in the CLI.
- **Skills** are written to `.traecli/skills/` (project) for native discovery; global skills live in `~/.traecli/skills`.
- The Multica runtime brief is also inlined into the prompt (traecli has no `--system-prompt` flag and reads project rules from `.trae/rules/`, not `AGENTS.md`), so the workflow instructions reach the agent regardless.

> The capabilities above were captured from the real `traecli` v0.120.42 binary: `initialize` → `loadSession:true` + `mcpCapabilities{http,sse}`; `session/new` → `result.sessionId` + `models.availableModels`; `session/prompt` streams `session/update` notifications with `sessionUpdate: agent_message_chunk`.

### Grok

From xAI. CLI binary name is `grok` (Grok Build CLI, often installed to `~/.grok/bin/grok`). Multica drives it over **ACP** via `grok --no-auto-update agent --always-approve stdio`, reusing the same transport as Trae / Kimi / Kiro / Qoder. After `initialize`, Multica chooses only an auth method the CLI advertised (`xai.api_key` when `XAI_API_KEY` is set and offered, otherwise `cached_token`) and waits for `authenticate` to succeed before any session operation; an empty or unsupported method list fails explicitly. **Session resumption works** through ACP `session/load`. **Model selection works** via the catalog returned from `session/new` and `session/set_model`. For `grok-4.5`, **reasoning effort** exposes only xAI's documented `low`, `medium`, and `high` values; unverified models hide the picker. **MCP is supported** — config is passed through ACP `mcpServers` (filtered to transports advertised by `initialize`). Skills land in `.grok/skills/` (project). User skills live under `$GROK_HOME/skills/` (default `~/.grok/skills/`) or the universal user root `~/.agents/skills/`. Tool calls stream as ACP `tool_call` / `tool_call_update` events.

## Session resumption: who really supports it

The session resumption mechanism is covered in [Tasks](/tasks#can-a-task-continue-from-the-previous-context). **Every supported tool resumes sessions** — pass the resume id and the task continues from the previous context. The one quirk is Pi, whose resume id is a session file path on disk rather than a string id (see [Pi](#pi) above).

## MCP configuration: provider-specific support

**Of the 16 tools, twelve consume `mcp_config`: Claude Code, CodeBuddy, Codex, Cursor, Hermes, Kimi, Kiro CLI, OpenCode, OpenClaw, Qoder, Trae, and Grok**. The other four (Antigravity, Copilot, DevEco Code, Pi) accept the field but **ignore it** — no error, no warning, the config just has no effect.

The runtime paths are provider-specific: Claude Code and CodeBuddy receive it through `--mcp-config` paired with `--strict-mcp-config`; Codex writes a daemon-managed `mcp_servers` block into the per-task `$CODEX_HOME/config.toml`; Cursor writes `.cursor/mcp.json` plus per-task project approvals under `CURSOR_DATA_DIR`; Hermes, Kimi, Kiro CLI, Qoder, Trae, and Grok receive ACP `mcpServers`; OpenCode receives inline config through `OPENCODE_CONFIG_CONTENT`; OpenClaw receives `mcp.servers` through Multica's per-task config wrapper. OpenCode's path does **not** rewrite the project's `opencode.json`.

<Callout type="warning">
If you set `mcp_config` in an agent configuration but pick a tool not marked ✅ in the MCP column, your MCP servers have **no effect** on that agent. MCP integration is provider-specific.
</Callout>

## Where skill files go

Each tool uses **its own** skill discovery path. Before a task runs, the Multica daemon copies the workspace's skill files into the corresponding path:

| Tool | Path | Native discovery? |
|---|---|---|
| Claude Code | `.claude/skills/` | ✅ Native |
| CodeBuddy | `.codebuddy/skills/` | ✅ Native |
| Codex | `$CODEX_HOME/skills/` | ✅ Native |
| Copilot | `.github/skills/` | ✅ Native |
| Cursor | `.cursor/skills/` | ✅ Native |
| Kimi | `.kimi/skills/` | ✅ Native |
| Kiro CLI | `.kiro/skills/` | ✅ Native |
| OpenCode | `.opencode/skills/` | ✅ Native |
| DevEco Code | `.deveco/skills/` | ✅ Native |
| Pi | `.pi/skills/` | ✅ Native |
| Qoder | `.qoder/skills/` | ✅ Native |
| Trae | `.traecli/skills/` | ✅ Native |
| Grok | `.grok/skills/` | ✅ Native |
| Antigravity | `.agents/skills/` | ✅ Native (inherits Gemini CLI's workspace layout — see [Antigravity docs](https://antigravity.google/docs/gcli-migration)) |
| Hermes | `HERMES_HOME/skills/` (per-task home) | ✅ Native (seeded per task from `~/.hermes/`) |
| OpenClaw | `.agent_context/skills/` | ⚠️ Generic fallback |

Whether a fallback-path tool actually reads this directory depends on the tool's own documentation — no guarantees. If your skills aren't taking effect for OpenClaw, check this first.

For native project-level paths, repo-scoped discovery is expected: if the checked-out repository already contains a matching directory, the underlying tool can discover those committed skills on its own. You do not need to import those repo skills into Multica just to use them in that repo. Multica keeps the repo files intact. If a workspace skill has the same natural directory name, the daemon writes the workspace copy to a collision-free sibling such as `review-helper-multica`.

For creating and using skills, see [Skills](/skills).

## Next

- [Creating and configuring agents](/agents-create) — pick a tool for your agent
- [Tasks](/tasks) — task lifecycle and session-resumption mechanics
- [Daemon and runtimes](/daemon-runtimes) — where the tools run and how they connect to Multica
- [Install an agent runtime](/install-agent-runtime) — installation and authentication for each of the 16 supported tools