Does Proxying Cursor's Private API Violate Terms of Service? A Compliance Boundary Analysis

A Developer's Compliance Dilemma

Recently on Reddit, a developer raised a highly representative question: does using Oh My Pi's (omp) built-in Cursor provider, or setting up an OpenAI-compatible proxy that calls the same Cursor private API, violate Cursor's Terms of Service (ToS)?

This question may seem niche, but it touches on a widely existing gray area in today's AI programming tool ecosystem — where exactly are the boundaries for calling subscription-based AI models? As more developers seek to integrate their paid subscription model capabilities into their preferred clients (like LibreChat) or workflows, the line between "official APIs" and "private APIs" has become an unavoidable compliance topic.

How Oh My Pi and Cursor's Private API Work

According to the original poster, Oh My Pi provides a "first-class citizen" level Cursor provider. Here's how it works:

• Authentication via OAuth / access token (corresponding to the cursor provider and CURSOR_ACCESS_TOKEN environment variable);
• Direct communication with Cursor's private agent API, using the Connect-RPC/protobuf protocol used by the IDE/CLI client;
• It does NOT call Cursor's public Cloud Agents REST API.

Let me explain the background of the Connect-RPC/protobuf technology stack. Connect-RPC is a lightweight RPC framework developed by Buf, based on Google's open-source Protocol Buffers binary serialization format. Compared to JSON, protobuf offers smaller payload sizes and faster parsing speeds, and is widely used for inter-service communication. Connect-RPC's distinguishing feature is its simultaneous compatibility with gRPC, gRPC-Web, and its own protocol, supporting calls via standard HTTP. Cursor chose this protocol stack because it efficiently handles streaming output scenarios — both code completion and chat responses require token-by-token transmission. However, this protocol is not a public REST API; its .proto definition files are typically not published externally, and third parties need to reproduce the call logic through packet capture or reverse engineering.

On the authentication front, OAuth (Open Authorization) is an open standard that allows third-party applications to obtain limited resource access without exposing user passwords. Cursor's access token is a credential obtained after user authentication, which the IDE uses to identify identity and access subscription benefits. When omp requires users to provide CURSOR_ACCESS_TOKEN, it's essentially reusing Cursor IDE's internal authentication credentials. The risk of this approach is that the token's authorization scope is designed for specific official clients. Using it with unofficial tools may violate the token's intended use case, and once Cursor detects abnormal call patterns, it may directly revoke the token or even ban the associated account.

In other words, omp reuses the communication protocol used internally by Cursor's official IDE, bringing the subscription's chat models (including streaming output) into its own framework. And omp's documentation introduces this as a regular feature, without marking any ToS warnings.

The poster also envisioned a more "DIY" approach: setting up a local OpenAI-compatible proxy that translates standard POST /v1/chat/completions requests into Cursor's private protobuf backend calls, allowing any OpenAI client to use subscription models. This is essentially the same approach as omp.

It's worth noting that OpenAI's /v1/chat/completions endpoint has become the de facto standard for LLM calls. Almost all major LLM providers offer or support OpenAI-compatible formats, enabling client tools to implement a single interface to connect to multiple model backends. This standardization has spawned numerous middleware and proxy tools — developers set up local proxies to translate private protocols into OpenAI format precisely so that frontends like LibreChat, Open WebUI, and LobeChat can seamlessly use models from different sources. While this "protocol translation" is technically elegant, when the source is an undocumented private API, it touches the compliance boundaries of reverse engineering.

Cursor's Official Stance: Drawing a Clear Red Line

The poster did something commendable — instead of blindly using the tool, they first consulted Cursor's official terms and forum statements.

Usage Restrictions in the Terms of Service

Section 1.5 "Usage Restrictions" of Cursor's Terms of Service explicitly lists several prohibited behaviors:

• Reverse engineering: Do not reverse-engineer the underlying structure of the service;
• Probing the service: Do not probe the service;
• Data scraping: Do not collect or extract data from the service.

Reverse engineering is a highly sensitive term in software contract law. In the United States, the DMCA (Digital Millennium Copyright Act) strictly limits circumvention of technical protection measures, and the CFAA (Computer Fraud and Abuse Act) may classify unauthorized system access as illegal. While some jurisdictions have exemptions for reverse engineering for interoperability purposes, reverse engineering prohibitions in SaaS terms of service are generally considered contractual constraints that users have agreed to upon registration. This means that even if the technical reverse analysis itself isn't illegal, calling private APIs based on the analysis results still constitutes breach of contract and may lead to account termination or even legal risk.

Calling private protobuf APIs and reusing non-public client protocols can easily be classified under "reverse engineering" and "probing the service."

Official Forum Responses

More critically, Cursor employees have previously addressed similar questions on the official forum (about using Cursor's frontier models like Composer 2.5 in external tools like Codex). The core points were:

1. Unofficial proxies that call private, non-public client APIs violate the above usage restrictions;
2. The official supported path outside the IDE is Cursor CLI / Agent SDK, not self-built OpenAI-compatible bridges.

This effectively places omp-style approaches on the wrong side of the policy line.

Compliance Judgments on Three Core Questions

Combining the official terms and employee statements, the three questions raised by the poster can all be answered clearly.

Is omp's Provider Equivalent to an "Unofficial Proxy"?

From a technical essence perspective, omp's Cursor provider is no different from an "unofficial proxy" — both call private client APIs. Just because omp makes it a first-class feature doesn't mean it complies with Cursor's ToS. A third-party tool's implementation approach cannot change the binding force of the other party's terms of service. This is worth noting for all developers relying on third-party integrations: a tool's "support" does not equal the called party's "authorization."

Does Building a Local Private Proxy Also Count as a Violation?

The answer also leans toward "yes." Even for a purely local, personal-use-only OpenAI-compatible proxy, as long as it calls the same private endpoints, the nature of the behavior hasn't changed. The ToS focuses on "whether you called non-public APIs and reused the protocol," not "whether it's for personal or commercial use." Personal use may have lower enforcement risk in practice, but from a terms perspective, it doesn't become compliant because of that.

The Only Compliant Path: Cursor CLI / Agent SDK

If both of the above approaches are out, then the only officially supported way to use Cursor models outside the IDE is Cursor CLI / Agent SDK.

Cursor CLI and Agent SDK are official compliant interfaces provided for use cases outside the IDE. CLI mode allows users to launch Cursor's AI agent in the terminal to execute code tasks, similar to how Claude Code or OpenAI Codex CLI are used. Agent SDK provides a programming interface that enables developers to embed Cursor's agent capabilities into automation pipelines. However, these official paths are designed for "agent-style interaction" — meaning the model doesn't just do chat completions, but also goes through tool calls, file read/write, context management, and other agent harness layer processing.

The trade-off is: you need to accept the latency and behavioral differences introduced by the agent harness, and cannot get the "raw" low-latency chat experience of connecting directly to the model. For developers pursuing ultimate response speed, this is indeed a compromise, but it's currently the only safe choice within the policy framework.

Deeper Implications for the AI Subscription Era

This case reflects a recurring tension in the AI subscription service era:

Subscribers want "free flow of model capabilities," while service providers want "tightly controlled entry points."

For companies like Cursor whose core competitive advantage is the IDE experience, private APIs are not just technical implementations but also business moats. Cursor employs a typical SaaS subscription model, with its Pro plan charging monthly and including a certain quota of model calls (e.g., 500 premium requests per month). The fundamental assumption of this pricing model is that users interact through the official IDE interface, where the cost of each interaction can be indirectly controlled through UI design (such as conversation turn limits, context window restrictions). Once users bypass the IDE and connect directly to the backend, they could consume massive amounts of model compute through automated scripts, rapidly exhausting the API quotas that Cursor purchases from upstream model providers (like Anthropic, OpenAI). This explains why Cursor is so sensitive about private API calls — it's not just an intellectual property issue but directly threatens the sustainability of their unit economics model.

Once arbitrary proxies are allowed to directly connect to subscription models, the pricing system, usage controls, and even model differentiation advantages could all be diluted. Therefore, it will inevitably draw clear boundaries through ToS and proactively provide CLI/SDK as "compliant exits."

For developers, here are some practical recommendations:

• Don't assume something is compliant just because a third-party tool makes it a default feature. The tool author's and service provider's interests are not aligned.
• The official SDK may offer a slightly inferior experience, but it's the only risk-free path, especially when account ban risks are involved.
• Authentication methods are an important signal: If an integration requires you to input an access token extracted from the official client to call non-public APIs, it's most likely in a gray area.

Conclusion

Returning to the original question: does using omp's Cursor provider or building a self-hosted OpenAI-compatible proxy violate Cursor's ToS? Based on official terms and employee statements, the answer is most likely yes. This is not a technical question of "can it work" but a policy question of "whether it's authorized." In an era of rapidly iterating AI tools and blurring ecosystem boundaries, understanding and respecting service providers' API boundaries is both protection for your account security and respect for a sustainable ecosystem.