[Performance] opencode-cursor is ~4x slower than native Cursor CLI

[mohammad154]

Describe the issue

I've been using opencode-cursor to access Cursor Pro models via OpenCode, and while the functionality and setup are great, I'm experiencing a significant performance overhead.

Compared to using the native Cursor CLI directly, opencode-cursor is about 4 times slower in terms of response and processing speed. This latency is highly noticeable and is really bothering my daily workflow.

To Reproduce

Steps to reproduce the behavior:

1. Run a standard prompt/task using the native Cursor CLI and measure the time it takes to generate a response.
2. Run the exact same prompt/task using opencode-cursor via OpenCode.
3. Compare the execution/response times.

Expected behavior

I expected the performance to be relatively close to the native Cursor CLI. I understand there might be a slight overhead due to the HTTP proxy and SSE streaming architecture, but not a massive slowdown.

Actual behavior

The tool takes roughly 4 times longer to process and stream responses compared to the official Cursor CLI.

Environment

• OS: [Ubuntu 22.04]
• opencode-cursor version: [latest]
• OpenCode version: [e.g. v1.17.7]

Additional context

Since this project acts as an HTTP proxy via cursor-agent and relies on SSE streaming, I suspect the bottleneck might be in how the proxy handles the stream or how OpenCode consumes it compared to the native CLI.

Is there any specific configuration, optimization, or architectural change that could help reduce this latency? Any advice on how to debug this further (e.g., specific debug logs to check with CURSOR_ACP_LOG_LEVEL=debug) would be greatly appreciated.

Thanks for your hard work on this project!

[Nomadcxx]

I feel this pain ahah and your intuition is correct here, lag is mostly architectural. Each opencode chat turn spawns a fresh cursor-agent process (or fresh SDK agent) with the full conversation history re-flattened as a text prompt.

Native cursor-agent keeps one process alive and reuses state across turns - we pay the cold-start cost every single turn, and again for every tool call round on top of that. Agent.create alone is 6s on the SDK path before streaming even starts.

There are some streaming pipeline fixes I can make to can speed this up, like getting session continuity (reusing the agent across turns) to work which would actually close most of the gap (have 2 PR's coming up that address this but relatively complex).

but main thing to remember though is current architecture is a bridge at this point, the end state is ACP with MCP at session setup, no proxy, no per-request spawn (architecture doc (https://github.com/Nomadcxx/opencode-cursor/blob/main/docs/architecture/cursor-acp-mcp-future.md)). Blocked on upstream cursor issues for now and some limitations with opencode itself that are the real blockers, otherwise would have built this ages ago.

[Nomadcxx]

Ok guys I've run some benchmarks, following these fixes, looks at least 2x faster depending on the model selected, but please test this out and let me know. As flagged above there's limits to how much performance benefits we can squeeze out here given architecture.

[mohammad154]

Yes, it's faster
Based on my observations, tool calling is fast but output generation is slow