Cursor is getting acquired by SpaceX. Here's a Cursor to Kilo Code migration guide.

Summary

Cursor has announced it will use xAI infrastructure for model training — a deal that gives SpaceX the right to acquire Cursor. It creates tighter alignment between the coding tool and a vertically integrated model and infrastructure stack, and even if privacy controls stay in place, this increases lock-in around defaults, pricing, availability, cloud execution, and future interoperability.

If you want to reduce that concentration risk, the cleanest path is a full-stack exit from Cursor's editor and agent layer: move to a neutral IDE like VS Code or VSCodium, install Kilo Code there, keep project instructions in AGENTS.md, and move operational settings into kilo.jsonc. Kilo is open-source, works across IDE and CLI, keeps config in portable files rather than editor-embedded state, and gives you access to 500+ models through Kilo Gateway at zero markup — with optional BYOK if you prefer to bill through your own provider credentials.

This is not an easy one-click migration if you rely on Cursor's Cloud Agents API. Cursor exposes an agent-lifecycle API under /v0/agents. Kilo's public API is an OpenAI-compatible gateway for model access — Cloud Agent, Code Reviews, and IDE/CLI features are product workflows, not a drop-in REST API. Editor-only users will find the migration straightforward. Teams with automation around Cursor's cloud agents should plan for an integration rewrite.

Before you start

Two things to know up front. The goal here isn't to run Kilo inside Cursor — it's to reduce your dependence on Cursor as a host tool. Kilo can run inside Cursor and other VS Code forks, which makes that a valid interim step, but it doesn't fully address the concentration risk. Also, there's no official importer for Cursor chat history into Kilo. If preservation matters, export-and-archive is the right approach, not migration.

If you use a JetBrains IDE, this guide doesn't fully apply yet — follow the existing Cursor migration guide for now. A native JetBrains plugin using the new Kilo core is in active development; once it ships, this guide will apply there too.

This isn't about privacy

Cursor documents strong controls in Enterprise Privacy Mode, including zero-data-retention arrangements with several model providers, and it separates that from Cloud Agents — the one feature that stores your code over time. The real risk is governance: default model routing, compute dependency, cloud-agent execution, pricing leverage, and roadmap control all concentrate when the coding tool, model training path, and affiliated infrastructure sit under a tighter strategic umbrella.

Three ways to reduce the risk

A full host migration is the strongest move. Install Kilo in VS Code or VSCodium and stop using Cursor as your daily editor. Installing Kilo inside Cursor is acceptable as a temporary bridge, but it leaves the host editor, local storage model, update channel, and any non-Kilo editor services under Cursor's control. That's a partial mitigation, not a full one.

Provider and model flexibility is next. Kilo supports a wide range of providers and models out of the box: 500+ models through the managed Kilo Gateway at zero markup (with optional Kilo Pass credits on top), direct connections to existing coding-plan subscriptions like ChatGPT Plus/Pro (which exposes OpenAI's Codex catalog in Kilo), and BYOK with your own provider API keys. BYOK traffic doesn't silently fall back to Kilo's keys if your credentials fail — governance failures stay explicit rather than opaque.

A cloud-minimisation policy rounds it out. For any remote agent platform, not just Cursor, treat cloud execution as a separate trust boundary. Cursor Cloud Agents require stored code; Kilo Cloud Agent requires repository access and environment variables. Scope repo access tightly, use non-production secrets wherever possible, and keep credentials out of version-controlled config files.

Cursor and Kilo feature mapping

Here's how Cursor features map to Kilo Code equivalents. Use this table as a checklist when you migrate.

The migration, step by step

Work in this order to minimise irreversible changes: archive first, install second, move policy files third, migrate integrations fourth, then validate and cut over.

Inventory current Cursor usage
  ↓
Export chats and back up .cursor state
  ↓
Install VS Code or VSCodium plus Kilo
  ↓
Set up auth with /connect or kilo auth login
  ↓
Migrate AGENTS.md rules and Kilo config
  ↓
Migrate MCP servers and provider env vars
  ↓
Smoke-test prompts, edits, reviews, autocomplete
  ↓
Cut over daily workflow
  ↓
Keep Cursor read-only during burn-in

Freeze and archive Cursor state

Start by exporting anything you might regret losing. Cursor documents chat export to Markdown from the chat view, and its Cloud Agents API exposes conversation history as JSON. That's two sanctioned formats: Markdown for IDE chats, JSON for cloud-agent runs.

Baseline archive checklist:

• Export high-value Cursor chats to Markdown.
• If you used Cloud Agents, export agent lists and per-agent conversations via the API.
• Back up .cursor/, AGENTS.md, .cursor/mcp.json, .cursor/environment.json, ~/.cursor/mcp.json, and ~/.cursor/cli-config.json.
• If exact local history matters, optionally back up Cursor app-data folders as a community-documented contingency rather than an official workflow. Cursor's forum documents workspaceStorage and full app-data copies for migration scenarios, but this isn't an official bulk export/import contract.

Backup commands:

mkdir -p migration-backup

cp -R .cursor migration-backup/project-cursor 2>/dev/null || true
cp AGENTS.md migration-backup/AGENTS.md 2>/dev/null || true
cp ~/.cursor/cli-config.json migration-backup/cli-config.json 2>/dev/null || true
cp ~/.cursor/mcp.json migration-backup/global-mcp.json 2>/dev/null || true

# Optional: archive cloud agent metadata if you use the API
curl -u "$CURSOR_API_KEY:" https://api.cursor.com/v0/agents > migration-backup/cursor-agents.json

Choose the target operating model

If de-risking is the goal, the target is VS Code or VSCodium + Kilo Code extension + Kilo CLI. Kilo works across IDE, CLI, and cloud, and the current extension is the pre-release channel built on the Kilo CLI core. Kilo runs inside Cursor and other VS Code forks too, which makes "Kilo-inside-Cursor" a valid interim move — just not the cleanest governance outcome.

For users:

• Preferred: install Kilo in VS Code/VSCodium and disable Cursor as your daily editor.
• Interim bridge: install Kilo inside Cursor, switch active workflows to Kilo, then move the host editor after validation.
• Avoid: keeping Cursor as the default AI/editor stack and only using Kilo occasionally — that doesn't materially reduce concentration risk.

Install Kilo and authenticate

Install Kilo's extension from the VS Code Marketplace as the pre-release version. Install the CLI separately and verify with kilo --version. For first-time provider setup, use /connect; the CLI also supports kilo auth login, kilo auth list, and kilo config check.

Installation:

# IDE extension
code --install-extension kilocode.kilo-code --pre-release

# CLI
npm install -g @kilocode/cli
kilo --version

# Auth and config validation
kilo auth login
kilo config check

One credential rule: don't transplant Cursor credentials into Kilo. Cursor CLI uses browser auth or CURSOR_API_KEY. Kilo uses Kilo Gateway auth and/or provider credentials managed through /connect, kilo auth, environment variables, or BYOK. Kilo warns against committing provider API keys into kilo.jsonc.

Migrate instructions, rules, and agent behaviour

This is the most important structural migration.

Cursor supports both .cursor/rules and AGENTS.md, including nested AGENTS.md. Kilo treats AGENTS.md as the portable baseline and adds two more layers on the current platform: instructions in kilo.jsonc and custom agents in .kilo/agents/*.md.

The transformation:

• Move stable project policy into AGENTS.md.
• Move operational defaults into kilo.jsonc.
• Move specialised personas into .kilo/agents/*.md.

Anything you want to survive future tool changes lives in AGENTS.md. Anything Kilo-specific lives in kilo.jsonc or .kilo/agents.

Target layout:

repo/
├── AGENTS.md
├── kilo.jsonc
└── .kilo/
    ├── agents/
    │   ├── review.md
    │   └── docs-writer.md
    └── rules/
        ├── testing.md
        └── docs.md

Both ./kilo.jsonc at the repo root and .kilo/kilo.jsonc are supported. Root placement is the idiomatic default shown throughout Kilo's docs; keep it there unless you have a reason to scope it inside .kilo/.

A minimal kilo.jsonc starter:

{
  "instructions": [".kilo/rules/*.md"],
  "permission": {
    "bash": "ask",
    "read": "allow",
    "edit": "allow",
    "webfetch": "ask"
  }
}

A custom read-mostly review agent:

---
description: Review code without editing source files by default
mode: primary
permission:
  edit: deny
  bash: ask
---

You are a code review specialist.
Focus on correctness, tests, security, and maintainability.
Prefer actionable review comments over rewrites.

Migrate MCP, integrations, and environment references

Cursor MCP configuration lives in .cursor/mcp.json or ~/.cursor/mcp.json and supports ${env:NAME} interpolation. Kilo's MCP configuration lives in kilo.jsonc, uses mcp entries, and supports {env:VARIABLE_NAME} interpolation. Kilo deprecates SSE in favour of Streamable HTTP; Cursor still documents SSE support.

MCP migration is mostly mechanical:

• copy server definitions;
• change config container shape if needed;
• convert ${env:FOO} to {env:FOO};
• prefer HTTP/Streamable HTTP over SSE for new remote servers.

Example:

// Cursor
{
  "mcpServers": {
    "github": {
      "url": "https://example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${env:GITHUB_TOKEN}"
      }
    }
  }
}

// Kilo
{
  "mcp": {
    "github": {
      "type": "remote",
      "url": "https://example.com/mcp",
      "headers": {
        "Authorization": "Bearer {env:GITHUB_TOKEN}"
      },
      "enabled": true
    }
  }
}

If you rely on repository integrations with GitHub or GitLab, re-authorise them natively in Kilo instead of bridging credentials. Kilo's Cloud Agent and Code Reviews are integration-based product features; configure Kilo Gateway BYOK separately from repository access.

Rebuild automation and SDK usage

This is where many migrations succeed or fail.

If your automation talks to Cursor's Cloud Agents API, you're dealing with endpoints like GET /v0/agents, POST /v0/agents, GET /v0/agents/{id}/conversation, and GET /v0/models, authenticated with Basic auth using your API key as the username. Kilo's public API is Bearer-authenticated and OpenAI-compatible. Model-centric endpoints live under the gateway base https://api.kilo.ai/api/gateway: POST /chat/completions, GET /models, and GET /providers. FIM (fill-in-the-middle) completions are a sibling endpoint at https://api.kilo.ai/api/fim/completions, not under /api/gateway.

The migration rule:

• if your script is model-call centric, move it to Kilo Gateway;
• if it's agent-lifecycle centric, redesign around Kilo product workflows or CLI orchestration rather than expecting a public /agents clone.

Node example using the Kilo Gateway:

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.KILO_API_KEY,
  baseURL: 'https://api.kilo.ai/api/gateway',
});

const response = await client.chat.completions.create({
  model: 'anthropic/claude-sonnet-4.5',
  messages: [
    { role: 'system', content: 'You are a migration assistant.' },
    { role: 'user', content: 'Generate a release note summary for the current branch.' },
  ],
});

console.log(response.choices[0]?.message?.content);

Python example:

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["KILO_API_KEY"],
    base_url="https://api.kilo.ai/api/gateway",
)

resp = client.chat.completions.create(
    model="anthropic/claude-sonnet-4.5",
    messages=[
        {"role": "system", "content": "You are a migration assistant."},
        {"role": "user", "content": "Review this diff summary and suggest follow-up tests."},
    ],
)

print(resp.choices[0].message.content)

Bash examples:

# List Kilo sessions
kilo session list --format json

# Export a Kilo session as JSON
kilo export "$SESSION_ID" --sanitize > kilo-session.json

# Import a Kilo session from JSON
kilo import kilo-session.json

These commands are documented in the Kilo CLI reference.

Validate, cut over, and plan your rollback

Run this as a short controlled cutover, not a same-day hard stop. Kilo's config is portable plain text, IDE and CLI share settings, and session export/import uses JSON. That makes verification and rollback easier than with tools whose state is buried in app data.

Verification checklist:

• the same repository opens correctly in the target editor;
• AGENTS.md instructions are respected in at least three representative prompts;
• one MCP server works end to end;
• one read-only task and one edit task behave according to your new Kilo permissions;
• autocomplete works and cost/provider behaviour is understood;
• one review workflow runs, either /local-review or hosted Code Reviews;
• one representative automation script succeeds against Kilo Gateway or the Kilo CLI.

Effort plan:

Rollback plan:

• keep the Cursor backup directory and exported chats for at least one burn-in cycle;
• keep a cursor-archive Git branch containing .cursor/ metadata and any historical docs;
• don't delete Cursor accounts, API keys, or local state until Kilo has passed smoke tests for the workflows you actually use;
• if Kilo fails in production use, revert the editor default, restore .cursor/ files, and continue from the archived Markdown/JSON exports while you correct the Kilo config.

Cutover timeline:

Day 0: Back up Cursor state
  ↓
Day 0: Install Kilo and re-auth
  ↓
Day 1: Migrate AGENTS.md + MCP config
  ↓
Day 1: Smoke-test daily workflows
  ↓
Day 2–5: Use Kilo as default
  ↓
Passes all key workflows?
  ├─ Yes → Make Kilo permanent default
  └─ No  → Rollback to Cursor using saved backups

What this guide doesn't cover

Native history migration. Cursor documents per-chat Markdown export and exposes Cloud Agent conversation JSON; Kilo documents JSON session export/import for its own sessions. There's no official Cursor → Kilo session converter. Treat old Cursor history as an archive and distil only high-value content into AGENTS.md, documentation, skills, or custom agents.

Public API parity for cloud agents. Cursor documents an agent lifecycle API. Kilo documents Cloud Agent as a product capability and Kilo Gateway as a public API, but there's no public agent-lifecycle API equivalent to Cursor's /v0/agents surface. Teams using Cursor's cloud-agent automation should scope this as an integration redesign, not a string-replace migration.