Introduction

Cusp is an agentic coding workspace for any model. You point it at a folder, ask for something, and an agent reads the code, edits files, runs commands and checks its own work. It does this with the model you choose: Claude, GPT, Gemini, Grok, DeepSeek, Kimi, GLM, Qwen, MiniMax, Mistral, or anything behind a gateway such as OpenRouter, Vercel AI Gateway or LiteLLM. Local models through Ollama or LM Studio work too.

If you already use a coding agent, bring your setup. Cusp reads AGENTS.md, CLAUDE.md and GEMINI.md, .claude/ settings, skills, subagents, hooks and MCP servers in place, and imports the rest from the agents you already use. See Import your setup.

What makes it differentCopy Anchor Link

Any model, one agent. The same agent loop, tools, permissions and extension points work across providers. Switch models mid-session with /model and keep going.

A harness that adapts to the model. Models are trained on different tool dialects. Cusp gives GPT-family models apply_patch, Claude and Gemini a str_replace-style Edit, and weaker or local models hash-anchored line edits. It replays reasoning state the way each provider expects, so the model keeps its reasoning from turn to turn. The harness post explains why this matters.

Paste a key. Cusp recognizes the provider from the key or base URL, probes which wire protocols answer (without spending tokens), lists the models, and picks a strong main model plus a small fast one for titles and summaries.

Brings your existing setup. Your instructions, skills, subagents, hooks and MCP servers work as they are: AGENTS.md, CLAUDE.md, GEMINI.md, .claude/skills, .claude/agents, hooks with their JSON protocol, and rules like Bash(npm run test:*). See Import your setup.

Careful by default. Every tool call passes through hooks and a permission engine before it runs. Writes to agent configuration, .git and shell startup files need a person's approval in every mode. Shell commands run inside the operating system sandbox (Seatbelt on macOS, bubblewrap on Linux), with no network unless you allow it.

SurfacesCopy Anchor Link

Cusp has one runtime and several ways in.

How it worksCopy Anchor Link

Every surface talks to the same agent runtime, the daemon. The interfaces never call a model themselves.

1. The daemon runs on your machine. The desktop app starts it as a sidecar process; the CLI connects to a running one or starts its own. It listens only on 127.0.0.1, on a random port, and requires a per-launch bearer token on every request.
2. A session is an append-only log of typed events: your messages, the model's output, each tool call and its result, permission prompts and decisions, checkpoints. The UI is a projection of that log, which is why sessions can be resumed, forked and rewound. See Sessions.
3. The harness runs the loop. It builds the context (instructions, memory, tools), streams the model's reply, and executes tool calls. Each call goes through PreToolUse hooks, then the permission engine, then the tool, then PostToolUse hooks. Read-only calls in the same batch run in parallel.
4. The provider layer translates between Cusp's normalized message format and the wire protocol the endpoint speaks: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages or Google Gemini. It handles retries, fallbacks, prompt caching and cost accounting.
5. Your files are snapshotted before every mutating tool runs, so a rewind can restore them.

 Desktop app ─┐
 CLI ─────────┼── REST + WebSocket (127.0.0.1, bearer token) ──► daemon
 Web app ─────┘                                                   │
                                            harness: tools · permissions · hooks · MCP
                                                                  │
                                            providers: OpenAI · Anthropic · Gemini · gateways

Next stepsCopy Anchor Link