AI Agent Platform Comparison

First-class native MCP via `.mcp.json` supporting STDIO and HTTP servers; MCP tools are treated identically to built-in tools in hooks, permissions, and the subagent system, including full `mcp__<server>__<tool>` matcher syntax. MCP servers can also be bundled directly inside plugins.

14 distinct lifecycle events (SessionStart through SessionEnd, including SubagentStart, TeammateIdle, PreCompact, and more) with handlers that can be shell commands, LLM evaluations, or full agent-based hooks. PreToolUse hooks can block, allow, or modify tool inputs before execution — the most mature and capable hooks system in this comparison.

Custom subagents in `.claude/agents/` each have a dedicated markdown file with YAML frontmatter for system prompt, tool allowlist/denylist, model selection, permission mode, MCP server list, hooks, skills, and persistent memory scope — fully declarative, per-agent configuration with no equivalent in other tools.

Skills in `.claude/skills/<name>/SKILL.md` create invocable `/name` slash commands with `$ARGUMENTS` placeholders, per-index argument substitution, and shell preprocessing; scoped to user, project, or plugin levels. Solid and flexible, though the system shares the same `agentskills.io` open standard as Codex.

Glob for file pattern discovery, ripgrep-backed Grep for cross-repo content search, Read with offset/limit for large files, and Explore subagents optimized for read-only codebase traversal. CLAUDE.md files load hierarchically and auto-memory persists codebase learnings, but lacks the semantic vector indexing that Cursor or VS Code Copilot provide.

Task tool spawns foreground or background subagents within a session; experimental Agent Teams (opt-in via env flag) run fully independent Claude Code sessions coordinated by a team lead with shared task lists and inter-agent messaging via tmux/iTerm2. Powerful but the Agent Teams feature is still experimental.

Auto-memory at `~/.claude/projects/<project>/memory/MEMORY.md` is written by Claude and loaded into context at each session start (first 200 lines); subagents can be configured with their own persistent memory at user, project, or local scope. More capable than most competitors, though the 200-line load limit and lack of semantic retrieval leave room for improvement.

Officially supports Anthropic Claude models via Anthropic API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry. Third-party routing via `ANTHROPIC_BASE_URL` to OpenRouter or local proxies is unsupported and can degrade with non-Claude models — functional but constrained compared to model-agnostic tools.

Runs locally as a CLI/IDE extension but requires a live cloud API connection; fully offline operation is not supported. Pointing `ANTHROPIC_BASE_URL` at a local Ollama proxy is technically possible but explicitly unsupported and unreliable.

Seamlessly cloud-native with first-class Anthropic API integration plus Amazon Bedrock, Google Vertex AI, and Microsoft Foundry support. Immediate setup with no infrastructure to manage — the only officially supported deployment model.

Native MCP in CLI and IDE extension; servers configured in `~/.codex/config.toml` or project `.codex/config.toml` and launched automatically at session start. Codex can itself run as an MCP server, enabling orchestration by external agents — a notable differentiator, though integration depth is slightly less deep than Claude Code's hook/permission integration.

No hooks system has shipped as of February 2026. A community PR (#11067) proposing PreToolUse/PostToolUse/SessionStart events was closed without merging when OpenAI restricted unsolicited contributions. OpenAI confirmed active work on the feature but it is not available.

No native concept of individually-configured named agents with dedicated instruction files. Instructions are project/user-scoped via `AGENTS.md`. Per-agent prompts in multi-agent Agents SDK workflows are programmatic code, not declarative config files accessible to end users.

Agent Skills system uses a `SKILL.md` file per skill directory with name, description, and instructions; skills invoke explicitly via `$skill-name` or auto-selected when a task matches the description. Follows the open `agentskills.io` standard but lacks argument placeholders and shell preprocessing found in Claude Code's skills.

Designed for repository-scale operation — reads full working directory, navigates file trees, edits across multiple files, and runs shell commands for search. The cloud platform runs each task in an isolated sandbox preloaded with the full repo, but there is no semantic indexing or ripgrep-specific tooling; file search is shell-command-driven.

The Codex cloud app natively supports parallel agents in isolated sandboxes with git worktree support. The CLI itself has no built-in parallel sub-agent spawning within a session; that requires the cloud interface or programmatic Agents SDK orchestration.

Session transcripts persist in `~/.codex/history.jsonl` and are resumable via `codex resume`. Memory infrastructure (`/m_update`, `/m_drop`) was added in early 2026 as described 'initial plumbing' — not a mature automatic cross-session memory system, with no equivalent to Claude Code's auto-summarizing MEMORY.md.

The `--model` flag or `config.toml` profiles allow switching between OpenAI models; the `--oss` flag enables first-party local inference via Ollama, LM Studio, or MLX; mid-session model switching is available via `/model`; and custom provider configurations support Mistral, Azure, and custom proxy endpoints.

Official `--oss` flag routes inference to Ollama, LM Studio, or MLX with no cloud dependency — a first-party supported, documented capability, not a workaround. Cloud mode remains the recommended primary path and some features degrade locally.

Cloud-native Codex App provides isolated sandboxes per task, built-in parallel agent support, and git worktree integration. The cloud platform is the richest feature tier and the primary recommended deployment model.

Native MCP support via project-level and global `mcp.json` files, covering stdio and HTTP transports with a growing ecosystem of pre-built integrations. Does not yet ship a built-in MCP marketplace or implement the 2025-11-25 spec revision that VS Code supports.

Cursor 1.7 introduced hooks at 7 lifecycle events with allow/deny/ask return semantics, but the feature is in beta with noted documentation gaps. The event set (7 events) is narrower than VS Code's 8 and Claude Code's 14, and production stability is not confirmed.

Glob-scoped `.mdc` rule files approximate per-context instructions but there is no native concept of a named agent instance with a dedicated instruction file or tool allowlist. The closest analog, `.cursor/skills/`, provides instruction bundles but not true agent-scoped configuration.

Markdown files in `.cursor/commands/` (project) and `~/.cursor/commands/` (global) are surfaced as `/` dropdown commands that inject full prompt content with project context attached. No parameterization or templating system is documented, which limits composability.

AST-aware chunking via tree-sitter, server-side embeddings stored in Turbopuffer, and nearest-neighbor retrieval combine to produce one of the most technically sophisticated codebase indexing pipelines among IDE agents. The `@codebase` reference and semantic search work across the full project without manual context selection.

Cursor 2.0 supports up to 8 simultaneous agents in isolated git worktrees or remote machines with automatic CPU/memory balancing across sub-tasks. The 8-agent ceiling and worktree isolation model are well-implemented, though orchestration is manual rather than automated.

No native cross-session memory; context resets completely at session end. Persistence requires workarounds: encoding context in `.cursor/rules/` files, using third-party MCP servers like Basic Memory, or community-built Memory Bank markdown patterns. None of these are first-party or automatic.

Supports Anthropic, OpenAI, Google, DeepSeek, and Cursor's own Composer model with a per-conversation model picker and an Auto mode. Local models via Ollama require an ngrok or Cloudflare tunnel workaround, and Cursor Tab autocomplete is cloud-only regardless of model selection.

Self-hosted machines (Cursor changelog) allow tool execution to remain entirely within the user's own network without the ngrok or Cloudflare tunnel workarounds previously required for any local operation. The flagship Tab autocomplete feature remains cloud-only, and full offline inference is not supported — self-hosted machines address network boundary concerns rather than eliminating cloud model dependency.

Fully cloud-native with server-side semantic indexing, Cursor's custom models, and embedded browser automation in Cursor 2.0 — all cloud-only. Immediate frictionless setup with the complete feature set available out of the box.

First-class MCP support with a built-in marketplace for browsing and installing servers from the GitHub MCP Registry, support for stdio and HTTP transports, and implementation of the 2025-11-25 MCP spec including URL mode elicitation and long-running task support. Most complete MCP integration among IDE agents reviewed.

VS Code 1.109.3 introduced 8 lifecycle hook events (PreToolUse, PostToolUse, SessionStart, Stop, SubagentStart, SubagentStop, and others) in Preview, using the same format as Claude Code for cross-tool compatibility. The feature is still Preview-stage and not yet generally available.

VS Code 1.108 Agent Skills load `SKILL.md` instruction bundles contextually when requests match skill descriptions. Custom agents in `.vscode/agents/` carry their own system prompts and tool configurations, providing true per-agent scoped instructions—a capability Cursor lacks natively.

Prompt files (`.prompt.md`) in `.github/prompts/` are invokable as `/filename` slash commands. Built-in commands (`/fix`, `/explain`, `/tests`, `/new`, `/init`) augment the system. No Handlebars-style parameterization like Continue.dev, limiting dynamic reuse.

Three-tier indexing—remote GitHub index, local semantic embedding index, and keyword fallback—provides robust repo-wide retrieval. Agent mode autonomously reads, searches, and edits across files. Slightly less transparent than Cursor's pipeline in terms of tuning controls.

VS Code 1.107 'Agent HQ' enabled parallel agent sessions in isolated git worktrees; VS Code 1.109 added orchestrator-spawned parallel subagents for research and coding subtasks. The orchestrator model with automated subagent spawning and result merging is more sophisticated than Cursor's manual 8-agent approach.

No native cross-session memory; each session starts fresh. 'Copilot Memories' is rolling out (currently more mature in Visual Studio than VS Code) and will auto-populate `copilot-instructions.md`, but is not generally available. Current persistence relies entirely on instruction files or external MCP memory servers.

Supports OpenAI (GPT-4.1, GPT-5, GPT-5 mini), Anthropic (Claude Sonnet 4.5, Haiku 4.5), and Google (Gemini Pro 2.5) with Auto mode and BYOK for hundreds of additional models. Ollama and LM Studio are natively integrated without tunneling workarounds, though Agent and Plan modes show instability with local models.

Ollama is natively integrated without the tunnel workarounds Cursor requires, and the AI Toolkit extension adds CPU/GPU/NPU local inference paths. However, Agent and Plan modes are unstable with local models, and a GitHub Copilot subscription is mandatory regardless of inference source.

GitHub Copilot is a mature managed cloud service with multi-model support (GPT-4.1, GPT-5, Claude Sonnet, Gemini Pro) available immediately via subscription. Cloud is the foundation of all Agent and Plan mode capabilities.

Native MCP support since IntelliJ 2025.1 with STDIO and Streamable HTTP transports, plus the ability to import server configs directly from a Claude Desktop JSON file. Junie gained MCP support independently, giving two separate agent surfaces native MCP access.

No end-user hook system exists in AI Assistant's standard configuration. The Koog framework SDK provides rich hooks (onBeforeLLMCall, onToolCall, onToolCallResult, onAgentFinished) for developers building ACP-compatible agents, but these are completely inaccessible to everyday AI Assistant users.

Rules can be scoped by file glob or activated by model decision, but there is no first-class mechanism to assign instructions exclusively to one named agent (e.g., Junie vs. Claude Agent). The Agent Skills Manager plugin adds task-specific scripts but does not close this gap.

The Prompt Library stores custom prompts with context macros (`$SELECTION`, `$SELECTION_LANG`) accessible via AI Actions, which covers typical use cases. However, the ability to select a saved prompt directly from the chat input was removed in 2025.1, making discovery less convenient than peers.

JetBrains AI Assistant uses the IDE's native project index — including symbols, type graph, and module structure — giving it structural codebase understanding that text-search-based tools cannot match. The 2025.1.2 Codebase Mode adds RAG-based retrieval on top of this foundation, making it the strongest codebase-awareness implementation.

Multiple distinct agents (Junie, Claude Agent, ACP agents) can be active from the same chat UI, and Junie supports async task delegation via GitHub integration. However, true parallel sub-task execution within a single session is explicitly listed as a future roadmap item and is not shipped as of early 2026.

No built-in cross-session memory; each new chat starts fresh with no auto-summarization or automatic context carry-over. Persistence requires either external MCP memory servers or manually maintained project rules files checked into the repo.

Supports OpenAI (GPT-4o, o1, o3-mini), Anthropic (Claude 3.5/3.7 Sonnet, Haiku), Google (Gemini 1.5/2.5 Pro), and local models via Ollama, LM Studio, or any OpenAI-compatible endpoint. Models can be assigned per feature (e.g., chat vs. code completion), adding meaningful configurability beyond simple model switching.

Full offline mode with local inference via Ollama, LM Studio, or llama.cpp; the 2025 free tier includes unlimited local code completion at no cost. No tunneling workarounds required — the most complete officially supported local story among IDE agents reviewed.

JetBrains AI subscription provides polished cloud access to OpenAI, Anthropic, and Google models with remote IDE analysis. Solid managed cloud service, though local-first operation is the platform's defining differentiator.

Native MCP support via YAML files in `.continue/mcpServers/` or inline in `config.yaml`, with STDIO, SSE, and Streamable HTTP transports including OAuth-authenticated servers. There is a known compatibility gap with the 2025-06-18 MCP spec revision in the VS Code extension, but standard servers work correctly.

Continue has no lifecycle hook system whatsoever — no pre/post tool-use events, no session start/end hooks, and no mechanism for programmable behavior injection. Tool approval is handled via static policies (Ask First/Automatic/Excluded), not hooks; implementing hook-level behavior requires contributing to the core codebase.

The IDE extension has no first-class per-agent instruction scoping; all rules apply broadly across chat, agent, and edit modes. Agent-level configs (models, rules, tools) exist for Cloud Agents on Continue Hub, but that is a separate cloud product and not available locally in the IDE.

Prompt files in `.continue/prompts/` with `invokable: true` create slash commands directly in the IDE, supporting Handlebars templating with `{{input}}` and arbitrary TypeScript logic via `config.ts`. This programmable approach goes beyond static text templates and enables genuinely dynamic prompt workflows.

Multi-tier retrieval combining embeddings-based vector search, AST parsing via tree-sitter, and ripgrep text search, with tunable retrieval parameters (result count, re-ranking) in `config.yaml`. Agent mode uses built-in glob and ripgrep tools for autonomous repo navigation without a separate indexing product.

Frontier models can issue multiple parallel tool calls within a single agent session, but this is model-level parallelism rather than native multi-agent orchestration. Running multiple simultaneous agents requires manually running multiple `cn` CLI processes via shell scripting, with no IDE-native coordination.

No native cross-session memory; context resets completely at the end of each session. Continue Hub publishes a `continuedev/memory-mcp` knowledge-graph server (March 2025) for opt-in persistence via MCP, but this is not bundled or automatic — committing rules files remains the primary recommended pattern.

Supports virtually every major provider including OpenAI, Anthropic, Google Gemini, Mistral, Amazon Bedrock, Azure OpenAI, xAI, Ollama, LM Studio, and any OpenAI-compatible endpoint, with different models assignable to different tasks (e.g., local model for autocomplete, cloud model for agent chat). This is Continue's defining strength and the most comprehensive provider coverage of any tool reviewed.

Fully local operation with Ollama is a first-class, well-documented primary use case with zero data leaving the machine. The entire open-source stack — including the backend — is self-hostable, the strongest data-residency story of any tool reviewed.

Works with all major cloud AI providers (OpenAI, Anthropic, Google, Mistral, Bedrock, Azure) and Continue Hub for team-shared configurations. Cloud is fully functional but secondary to the local-first design philosophy; there is no Continue-managed cloud service.

First-class MCP support with a built-in MCP Marketplace; Cline can install, manage, and scaffold brand-new MCP servers on the user's behalf, and treats MCP as its primary extensibility mechanism for connecting to external APIs and services.

Hooks system (v3.36+) supports PreToolUse (can block or modify), PostToolUse, UserPromptSubmit, and TaskStart events in `.clinerules/hooks/`; hooks receive JSON context via stdin and return JSON to control flow. Currently macOS and Linux only; Windows is not supported.

The Skills system (v3.48+) allows modular instruction sets in `.cline/skills/` (project) or `~/.cline/skills/` (global), each with YAML frontmatter defining name, description, and triggers; a skill activates only when the current request matches its description, avoiding context bloat.

Slash-command workflows are stored as markdown files in `.clinerules/workflows/` or `~/Documents/Cline/Workflows/` and invoked by typing `/workflow-name.md`; Cline can also auto-generate workflow files from completed conversations.

Builds codebase awareness through file-tree reading, AST parsing, and regex search within the agent loop without a separate indexing step; fully supports VS Code multi-root workspaces, reading, editing, and searching across multiple repos simultaneously.

The Cline CLI exposes a gRPC API for managing multiple concurrent Cline instances on different sub-tasks, but within the VS Code extension sub-cline instances currently execute sequentially, waiting for each to complete before starting the next.

No built-in automatic memory layer; each new session starts with a clean context window. 'Memory Bank' is a user-defined convention of structured markdown files committed to the repo that must be manually instructed to load at session start — not an automatic behind-the-scenes system.

Fully model-agnostic with direct connections to major providers (Anthropic, OpenAI, Gemini, xAI), aggregator/proxy services (OpenRouter, Requesty), and local inference engines (Ollama, LM Studio); models are switchable per task with no lock-in to any provider.

Runs entirely locally as a VS Code extension with no data sent to Cline's servers. When paired with Ollama or LM Studio the full stack — extension, inference, and storage — operates fully on-device with zero internet dependency.

Connects seamlessly to all major cloud AI providers (Anthropic, OpenAI, Gemini, xAI, OpenRouter) with no configuration friction. There is no Cline-managed cloud service; cloud access means bringing your own provider API key.

MCP Registry integration allows connecting external tools via MCP. Functional and documented, though MCP is secondary to OpenClaw's native 50+ integration connectors (Gmail, GitHub, Spotify, Obsidian, etc.) which are not MCP-based.

Webhooks, cron jobs, and Pub/Sub integrations (e.g., Gmail Pub/Sub) enable event-driven automation at the session and task level. These are integration-focused trigger hooks rather than a tool-level PreToolUse/PostToolUse system, limiting precision compared to Claude Code or Cline.

Skills system stores modular instruction bundles per skill; multi-agent routing can isolate workspaces and sessions per agent. Individual agents can have dedicated skill sets and memory scopes, though configuration is less declarative than Claude Code's `.claude/agents/` approach.

Skills serve as reusable instruction modules invokable by name or description match. No explicit slash-command system or prompt file convention is documented; cron and webhook triggers handle scheduled invocation rather than user-facing prompt reuse.

File system access is available within the configured workspace (`~/.openclaw/workspace`), and the agent can read and write files. However, OpenClaw is not a coding-specific tool and has no semantic indexing, AST parsing, or codebase-traversal tooling oriented toward software projects.

Multi-agent routing assigns inbound channels or accounts to isolated agents with separate workspaces and session contexts, enabling concurrent independent agents. Within a single session, parallel tool calls rely on model-level parallelism rather than orchestrated sub-agent spawning.

24/7 persistent memory system that learns user preferences across sessions; cross-agent memory sharing allows knowledge accumulated in one agent to be available to others. This is the most capable automatic memory system of any platform in this comparison.

Works with Anthropic Claude, OpenAI models, and locally-running models (Ollama, LM Studio); includes automatic model failover and profile rotation for resilience. Users report running alternative backends including MiniMax. Not locked to any single provider.

Designed to run privately on user infrastructure by default — local device, on-premises server, or remote VM accessible via Tailscale or SSH. No data is sent to OpenClaw's servers unless explicitly configured.

Supports deployment on remote Linux cloud instances via Tailscale or SSH, enabling cloud-hosted self-managed setups. There is no OpenClaw-managed SaaS option; all cloud deployments are self-provisioned and maintained by the user.