kevin9327 24c41d0347 fix(tools): keep result truncation inside its byte budget and terminating
`truncate_text` looks for a fixed point where the kept prefix length equals the
byte count printed in its own truncation notice. Two things go wrong when the
limit is small, and both are reachable because two call sites pass a *remaining*
budget rather than a constant:

* `gate_grep_content` -> `truncate_text("Grep", .., budget.content_bytes)`
* `gate_mcp` -> `truncate_text("MCP text", .., remaining_text)`

1. The loop can spin forever. `notice.len()` grows with the decimal digit count
   of `shown`, so `kept.len()` alternates between two values across a power-of-
   ten boundary and never equals `shown`. With `tool_name = "Grep"` this happens
   at `limit` 78 and 170; with `"MCP text"` at 82 and 174. The conversation task
   then spins at 100% CPU and the turn never completes. `truncate_middle` in
   `model/tool_result_replay.rs` already guards against exactly this.

2. When the notice itself does not fit, `available` saturates to 0 and the
   function returns the ~68 byte notice alone, i.e. *more* than `limit`.
   `gate_grep_content` then evaluates `budget.content_bytes -= <68 bytes>` on a
   budget of at most 68, which panics with "attempt to subtract with overflow"
   in debug/test builds and wraps in release, silently disabling the 32 KiB
   content cap for the rest of the result.

Both are ordinary Grep results away: 16 matches of ~2 KiB leave a two-digit
remainder of the 32 KiB budget, and the next match then hits the small-limit
path.

Fix: return a plain prefix when the notice cannot fit, and stop as soon as the
kept length repeats a previous value. The reported byte count is then off by one
at most in that rare oscillating case, and the result is guaranteed to be at
most `limit` bytes. Every constant-limit call site is unaffected: their notices
always fit and their limits do not oscillate. `budget.content_bytes` now uses
`saturating_sub`, matching every other subtraction in this file.

Verified against the unfixed function:
  cargo test -p cursor-server --lib gate::tests::truncate_text_never_exceeds_its_limit
  -> FAILED: limit 1 produced 67 bytes
  cargo test -p cursor-server --lib gate::tests::grep_content_gate_survives
  -> FAILED: panicked at gate.rs:261: attempt to subtract with overflow
  cargo test -p cursor-server --lib gate::tests::truncate_text_terminates
  -> never returns (killed after 45s)
  cargo test -p cursor-server --lib gate::tests::grep_content_gate_terminates
  -> never returns (killed after 60s)
After: cargo test -p cursor-server --lib tools::tool_call_result::gate -> 4 passed
2026-08-31 19:35:39 +09:00
2026-08-31 15:38:02 +08:00
2026-08-29 22:05:04 +08:00
2026-08-31 15:18:43 +08:00
2026-06-30 10:46:26 +08:00

cursor-byok

cursor-byok is a local implementation of Cursor's backend.

leookun/cursor-byok | Trendshift

User Guide · Download · Report an Issue · 中文版本说明

Release Downloads License Platforms

Connect cursor-byok to a wide range of model APIs

cursor-byok dashboard

About

cursor-byok is an open-source local model gateway for Cursor. It runs a service on your machine that connects Cursor to the model APIs you configure, routes model requests through your own providers, and preserves Cursor Agent capabilities such as tool calling, Skills, and MCP.

You can connect OpenAI- and Anthropic-compatible services, customize endpoints, model IDs, API keys, and request parameters, and use model channels beyond the options built into the platform.

Important

cursor-byok is free and open source, but the model APIs you connect may charge for usage. This is an independent project and is not affiliated with or endorsed by Cursor or its developers.

Features

  • Bring your own model channels: Configure your own API endpoint, credentials, and model IDs.
  • Multiple API protocols: Use OpenAI- and Anthropic-compatible APIs or a custom endpoint.
  • Model management: Add, duplicate, edit, reorder, and batch-test multiple model configurations.
  • Connection benchmarks: Measure time to first token, generation speed, and inspect raw provider responses.
  • Agent workflows: Keep tool calling, Skills, MCP, and multi-turn conversations available.
  • Session metrics: Track token usage, cache hit rate, conversation turns, and estimated value.
  • Cross-platform: Run on macOS, Windows, and Linux.

Quick Start

  1. Download the latest build for your platform from GitHub Releases.
  2. Launch cursor-byok, open Model Settings, and enter the endpoint, API key, and model ID.
  3. Test the model configuration. Once it passes, return to the dashboard and start the service.
  4. Test the model configuration. Once it passes, return to the dashboard and start the service.
  5. After upgrading Cursor or configuring a model for the first time, quit Cursor completely and restart it, then start a new conversation and select the configured model.

For complete installation steps, system configuration, and Frequently Asked Questions, see the User Guide.

Model Management

Model configurations support both OpenAI and Anthropic API protocols. Each model channel can independently define its context window, maximum output tokens, reasoning effort, custom headers, and additional request parameters.

cursor-byok model settings

How It Works

Cursor client
    │
    │ Agent requests and tool results
    ▼
cursor-byok local service
    │
    │ OpenAI- / Anthropic-compatible requests
    ▼
Your model API

cursor-byok handles protocol adaptation, model request forwarding, tool-call coordination, and conversation state on your machine. API keys and application settings are stored locally; requests are still sent to the model provider you configure.

Why This Project

Many Agent products bundle their tool capabilities with a fixed set of models, subscriptions, and billing options, leaving users limited to the channels offered by the platform.

cursor-byok is built to return model choice to the user. Developers can make full use of the APIs and credits they already have, choose the models and providers that fit their needs, and self-host related services when required.

Roadmap

The project will continue to improve model compatibility, Agent tooling, local runtime stability, and the self-hosting experience while exploring support for more IDE, chat, and Agent workflows.

See the release roadmap for plans and progress.

Community and Support

Development and Contributing

Issues and pull requests are welcome. See the Contributing Guide for prerequisites, build commands, project structure, and contribution guidelines.

Contributors

License

This project is open source under the MIT License.

S
Description
No description provided
Readme MIT
27 MiB
Languages
Rust 68.9%
TypeScript 20.6%
Go 5.2%
SCSS 2.5%
JavaScript 1.6%
Other 1.1%