Requesty has published documentation for routing Cursor requests through its API gateway, giving teams a way to use supported model IDs while applying centralized routing, policy and usage controls.
Requesty has published instructions for connecting the Cursor AI coding editor to its model gateway through Cursor’s Override OpenAI Base URL setting. According to Requesty’s Cursor documentation, users configure the editor to send requests to https://router.requesty.ai/v1, authenticate with a Requesty API key, and select Requesty-supported model IDs in Cursor.
The setup is designed to let developers continue working in Cursor while routing requests through Requesty’s service. Requesty says its Cursor endpoint is built to accommodate the request format used by the editor, reducing the need for users to alter their normal development workflow.
Requesty says its Cursor integration provides access to more than 300 models. That figure differs from the company’s broader Smart LLM Routing page, which describes a gateway catalogue of more than 600 models. The documentation therefore indicates that the full Requesty catalogue is larger than the set presented for the Cursor connection.
On its routing page, Requesty says its gateway can choose between models using factors including cost, latency and availability. It also describes failover support and policies that can be applied across teams. Those capabilities could allow an organization to set shared model-selection rules rather than requiring individual developers to manage provider and model choices separately.
Requesty further says the gateway includes usage and cost tracking. For teams using several model providers through Cursor, that could provide a consolidated view of traffic and spending at the gateway layer, rather than relying solely on separate provider records.
Cursor’s custom base URL option does not necessarily mean every OpenAI-compatible endpoint will work without adaptation. In a Cursor Community Forum discussion, a Cursor staff member said the setting applies to all models and noted that Cursor can send payloads shaped for OpenAI’s Responses API.
That behavior makes endpoint compatibility important: a service must handle the request structures Cursor actually sends, not merely accept a conventional chat-completions-style request. Requesty’s documentation positions its Cursor endpoint as that compatibility layer, while also exposing the company’s routing and monitoring features.
The integration may be useful for engineering teams that want to keep Cursor as their coding environment while centralizing model access, reliability behavior and spending oversight. The model-count claims should be read in context, however: Requesty cites 300-plus models for Cursor and 600-plus for its wider gateway offering.
Requesty documents a Cursor gateway integration Requesty has published instructions for connecting the Cursor AI coding editor to its model gateway through Cursor’s Override OpenAI Base URL setting.
According to Requesty’s Cursor documentation, users configure the editor to send requests to https://router.requesty.ai/v1 , authenticate with a Requesty API key, and select Requesty supported model IDs in Cursor.
The setup is designed to let developers continue working in Cursor while routing requests through Requesty’s service.
Continue reading