open-cursor: running Cursor subscription models inside OpenCode

A local OpenAI-compatible proxy sits between OpenCode and Cursor

The point of this plugin is that OpenCode speaks to an OpenAI-shaped interface while Cursor expects its own protocol, so something has to translate. open-cursor does that translation locally: the README describes it as connecting OpenCode to the models available through a Cursor subscription, translating prompts, streaming responses, thinking and tool calls between OpenCode and Cursor through a local openai-compatible proxy backed by @cursor/sdk.

The architecture has a clear shape. OpenCode loads the plugin, the plugin starts a local proxy that speaks the OpenAI conventions OpenCode already knows, and the proxy forwards each request to Cursor through the SDK. Because the translation is a local process rather than a hosted service, the plugin can be installed as a bare package name and OpenCode handles the install and the updates. The model list also comes from the plugin itself on OpenCode 2.x, which is why the models appear under a cursor-acp prefix rather than under a provider block you configured by hand.

The interesting design choice sits in the tool loop. A translated tool call has to arrive in OpenCode in a form the agent runtime can execute, and the reasoning content has to survive the trip as a separate channel rather than being flattened into the assistant text. The README lists tool support and thinking as headline capabilities, and the package description in package.json claims no prompt limits, no broken streams and full thinking plus tool support. Whether the proxy keeps those promises under a long agentic session is a question the documentation does not settle, and the project's own test suite is where that behaviour is pinned down.

On OpenCode 2.x the plugin supplies the models itself

Installation differs sharply between the two OpenCode generations, and the difference is more than a config key. On OpenCode 2.x, which the README calls the current default, you add the package to the plugins array in your opencode.json and restart. The bare name is enough, because OpenCode installs and updates the package for you.

{
  "plugins": ["@rama_nigg/open-cursor"]
}

The file lives at ~/.config/opencode/opencode.json. On 2.x the plugin registers the cursor-acp models itself, so there is no separate provider entry to write.

OpenCode 1.x takes the older path, with a global install and a small installer command that adds both the plugin and a cursor-acp provider block to your OpenCode config, backing up the existing file first. Upgrades on that line are a global package update.

npm install -g @rama_nigg/open-cursor
open-cursor install

That is a meaningful difference in ownership. On 1.x the installer mutates your config file and leaves a plugin file behind at ~/.config/opencode/plugin/cursor-acp.js, and the README tells 1.x users to delete that file and the provider.cursor-acp block when they move to 2.x. In other words, migrating between OpenCode majors is a documented cleanup task, not a no-op, and the same opencode.json is read by both versions.

cursor-agent login is the default credential path

The plugin does not ask you to paste a key into OpenCode in the common case. The README states that open-cursor uses your cursor-agent login by default and that you do not need to store anything in OpenCode, and the first installation step is signing in to Cursor with the official CLI.

cursor-agent login

You need OpenCode, a Cursor subscription, the cursor-agent CLI and Node.js 20 or newer for any of this to work. The plugin is a client of Cursor, not a way to obtain a subscription.

There is a second path if you prefer a key. The README lists three options in a table: use your Cursor login as the default, log in from inside OpenCode 2.x through opencode auth login and then Cursor and Log in with cursor-agent (browser), or use an API key instead through the same flow, or by setting CURSOR_API_KEY. Keys come from cursor.com/settings. With a key stored, OpenCode 2.x runs requests through the Cursor SDK.

The failure mode is documented with unusual care, and it is the part worth reading before you file a bug. If Cursor rejects the key and cursor-agent is installed, open-cursor switches to cursor-agent and logs a warning. The exception is a key set in CURSOR_API_KEY, because cursor-agent reads that variable too, so a bad key there has to be unset. The README also warns against entering a placeholder key to get past the login prompt, and points to the browser based cursor-agent option instead.

Model identifiers carry a cursor-acp prefix and an auto mode

Once the plugin is registered, the models show up in OpenCode under a cursor-acp prefix, and there is an auto entry that leaves the model choice to the plugin. The README gives the check command first, and it is worth running exactly as written before debugging anything else, because a missing model here means the plugin never registered.

opencode models | grep cursor-acp
opencode run -m cursor-acp/auto "Reply with PONG"

The first command lists the registered models, the second sends a trivial prompt to the auto model and should return a reply. A prompt that fails is a faster signal than opening the model picker and looking for an entry that was never added.

For actual work, the same flag carries an explicit prompt.

opencode run "Summarise this repository in five bullets." \
  --model cursor-acp/auto

You can also start opencode interactively and pick a cursor-acp model from the model picker. The repository links a separate guide on choosing a model, and the picker route and the flag route are both documented, so the difference is convenience rather than capability. One consequence of the prefix is worth naming: because the models are surfaced by the plugin rather than by a native provider entry, anything that filters models by provider name, such as scripts and dashboards that assume a provider key, will not recognise these.

The 1.x to 2.x migration leaves three pieces of state behind

Because the two OpenCode generations register the plugin differently, moving between them is the most likely source of a broken setup. The README devotes a section to it, and the steps are explicit rather than advisory. OpenCode 2.x reads the same opencode.json, so 1.x entries carry over and the file itself does not need editing beyond the plugin entry.

First, replace the cursor-acp entry, or @rama_nigg/open-cursor, in the 1.x plugin list with the plugins entry that 2.x expects. Second, delete the provider.cursor-acp block, because on 2.x the plugin supplies the models itself and the two paths would otherwise both claim the same models. Third, remove ~/.config/opencode/plugin/cursor-acp.js if the 1.x installer created it. That last file is the kind of artifact that survives a migration and quietly keeps an old code path alive.

There is a fourth item that is a symptom rather than a step. If requests fail with Cursor rejected the API key, the README says to remove the old stored key with opencode auth logout cursor-acp. The stored credential is keyed by the provider name, so a leftover from 1.x will be found by 2.x even after the config has been cleaned, which is why the credential removal is separated from the config cleanup.

TypeScript for the plugin, Go for the terminal side

The repository layout is unusual for a plugin and says something about the project. The package.json names the published artifact @rama_nigg/open-cursor at version 2.5.15, type module, with dist/plugin-entry.js as the main entry and src/plugin-entry.ts as the module entry, so the source is TypeScript and the published build is bundled JavaScript.

The build and test scripts are Bun based. The build bundles six entry points, including src/index.ts, src/plugin-entry.ts, src/plugin-opencode2.ts and three CLI modules under src/cli, targeting node and marking @opencode-ai/plugin and zod as external. There are separate scripts for unit tests, integration tests and a perf suite, and the perf list names individual test files, which hints at where the project concentrates its own checking: prompt building, session resume, incremental prompts, line buffering, the streaming parser, delta tracking, OpenAI SSE output and an SDK demux round trip.

Alongside that sits a go.mod for module github.com/nomadcxx/opencode-cursor requiring go 1.25.6, whose dependency list is almost entirely terminal UI libraries: bubbletea, lipgloss, bubbles, charmbracelet x/ansi and x/term, plus the OSC52 package go-osc52, go-isatty and muesli termenv. The repository footer describes the author as building terminal native tooling for the linux desktop, and the Go side appears to be that terminal tooling rather than part of the proxy path. The top level also carries install.sh, cmd/, scripts/, tests/, docs/ and a docs-site directory, so documentation and the published site are maintained in the same tree.

Three releases in two days, and a permissive licence

The last push was on 2026-10-16 and the release list shows v2.5.13 on 2026-10-15, v2.5.14 and v2.5.15 both on 2026-10-16, which is a fast patch cadence for a project whose published version tracks that closely to the commits. The repository is not archived. A CHANGELOG.md is present at the top level, which is where the detail of those patch releases would live, since the README itself does not break them down.

The licence is BSD-3-Clause, a permissive grant that allows use, modification and redistribution, including in closed source products, provided the copyright notice and the disclaimer of warranty travel with the code. The three clause form requires that the notice not be removed and that derived work not carry a trademark use of the original names, so rebrand a fork rather than shipping it under the same label. This is a description of the grant, not advice on how to apply it in a specific setting.

The upgrade cost on the plugin side is small, a version bump in the plugins array or a global package update, and OpenCode 2.x handles it for you when the bare package name is used. The cost sits on the dependency side, since the plugin depends on the behaviour of @cursor/sdk and on the Cursor agent protocol, and the model list it advertises is only as stable as what Cursor exposes to a subscriber account.

Editorial conclusion

open-cursor suits an individual developer who already pays for Cursor and wants those models inside OpenCode without juggling two clients, and it does not suit a team that needs shared credentials, audited model routing or a stable plugin contract across OpenCode major versions. Before adopting it, run the two check commands after installation and confirm that opencode models lists a cursor-acp model and that opencode run -m cursor-acp/auto returns a reply.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Nomadcxx/opencode-cursor on GitHub
3. Project website
4. README
5. Releases