Base URL Guide

OpenAI-Compatible API Base URL Checks

OpenAI-compatible means a provider exposes an API shape that many tools can call. It does not prove model identity, pricing accuracy or Cursor/Codex compatibility. Use this checklist before adding a key, balance or repository context.

What OpenAI-Compatible Really Means

A compatible provider usually accepts OpenAI-style requests, but each tool can depend on a different subset of endpoints, model IDs, streaming events, error formats and auth behavior. Treat compatibility as a starting point, not a guarantee.

OpenAI API Compatible vs AI API Relay

Searches for OpenAI API compatible, OpenAI-compatible API, AI API relay and AI gateway often point to the same practical question: can this endpoint work with an OpenAI-style SDK or coding tool? Use the wording as a discovery clue, then verify the actual API behavior.

  • OpenAI API compatible should mean documented auth, Base URL, model IDs and endpoint behavior, not official OpenAI ownership.
  • AI API relay usually describes a third-party path between your tool and an upstream model provider; that extra hop makes privacy, routing and billing checks more important.
  • AI gateway or model gateway usually adds routing, provider selection, fallback, analytics or governance on top of a compatible API surface.
  • For any label, verify `/v1/models`, chat or responses support, streaming chunks, error formats, pricing and data-handling terms before sending repository context.

Common API Surfaces to Verify

Searches for OpenAI-compatible API often mix several different needs: a drop-in SDK endpoint, an editor Base URL, a model gateway, or a pricing reference. Before comparing providers, identify which surface your workflow actually uses.

  • SDK compatibility: check whether OpenAI SDK clients can call chat, responses, embeddings or image endpoints without custom adapters.
  • Editor compatibility: check the exact Base URL field, model picker behavior and whether custom keys cover only chat or more tool features.
  • Gateway compatibility: check routing rules, provider routes, fallback behavior and whether the gateway exposes a public model list.
  • Pricing compatibility: compare raw API token prices, cache prices, minimum top-up, failed-request billing and refund rules separately.
  • Risk compatibility: verify privacy, terms, support and status pages before using repository context or customer data.

Base URL Checklist

  • Confirm whether the base URL should be the root gateway, `/v1`, or a provider-specific path.
  • Do not paste the full `/chat/completions`, `/responses` or `/models` endpoint into a Base URL field.
  • Check whether the provider supports `/v1/models` so tools can discover available model IDs.
  • Record the exact model ID you tested, not only the marketing model family.
  • Verify streaming, tool-call shape, JSON mode and error response format if your workflow depends on them.

Endpoint Shape Examples

When a tool asks for a Base URL, it usually wants the shared API prefix, not a single endpoint. Save the exact URL shape from the provider docs before testing, because a wrong slash or duplicated `/v1` can look like an auth, model or streaming failure.

  • Root gateway style: the provider tells tools to use `https://gateway.example.com`, then appends endpoint paths internally.
  • `/v1` prefix style: the provider tells OpenAI-compatible tools to use `https://gateway.example.com/v1`.
  • Provider-specific path style: the provider exposes a path such as `https://gateway.example.com/openai/v1` for OpenAI-compatible traffic.
  • Full endpoint paths such as `/v1/chat/completions`, `/v1/responses`, `/v1/embeddings` and `/v1/models` belong in SDK requests or tests, not in most editor Base URL fields.
Good Base URL candidates:
https://gateway.example.com
https://gateway.example.com/v1
https://gateway.example.com/openai/v1

Not a Base URL:
https://gateway.example.com/v1/chat/completions

Tool-Specific Checks

  • Cursor custom keys may only cover some chat workflows; specialized Cursor features can still use built-in model routes.
  • Codex CLI custom providers may need Responses-style behavior, not only Chat Completions-style compatibility.
  • Cline and OpenAI SDK workflows usually care most about `/v1`, model IDs, streaming and retryable error formats.
  • Claude Code normally needs Anthropic-compatible behavior; an OpenAI-compatible endpoint alone is not enough.
  • If a provider publishes a dedicated Cursor, Codex CLI, Cline or SDK guide, prefer that over generic setup snippets.

Pricing and Model Evidence

Gateway prices often vary by provider route, cache reads/writes, context length, image/audio usage and failed requests. Before testing, save the pricing page, model list and any provider route details so later billing differences can be explained.

  • Normalize pricing to 1M input tokens and 1M output tokens.
  • Check cache write/read prices separately when a model supports caching.
  • Look for minimum top-up, refund rules, failed-request billing and rate-limit behavior.
  • If a model has multiple provider routes, record which route the gateway selected.
  • Keep a small test prompt and billing screenshot for future comparison.

How to Compare OpenAI-Compatible Gateways

Use official APIs as the baseline, then compare each gateway against the same evidence fields. A gateway can be useful for testing or routing without being suitable for private code, production traffic or team-wide billing.

  • Start with official OpenAI, Anthropic, Google or cloud-provider APIs when sensitive data, compliance or stable billing matters.
  • Use OpenRouter-style model gateways when model discovery, route choice and public model pricing are more important than one vendor account.
  • Use 302.AI-style app and API platforms only after separating web-app pricing from raw API pricing.
  • Use self-hosted or enterprise gateways when API key governance, audit logs, team budgets and routing control matter most.
  • Treat missing docs, pricing, model lists, privacy policy, terms, status or support as risk signals, not as small footnotes.

Small Test Flow

  1. Open the provider docs, pricing, model list, privacy policy, terms, status page and support page.
  2. Use the public source checker to record missing fields before adding any key.
  3. Run a non-sensitive test with the smallest balance or free credit available.
  4. Test model listing, a short chat, streaming, a small code task and one deliberate error.
  5. Only persist the key in your editor or CLI after the endpoint, model ID and billing behavior match the docs.

When to Avoid a Gateway

Avoid third-party gateways for private repositories, production secrets, customer data or regulated workloads unless the provider gives you a credible data-handling and contract path.

For sensitive work, start with official APIs, cloud-provider channels, enterprise gateways or self-hosted BYOK infrastructure. Use relay providers first for public-code tests and low-risk experiments.

FAQ

Is OpenAI-compatible the same as official OpenAI?

No. It usually means the request shape is similar to OpenAI's API. The upstream model, billing, privacy controls, rate limits and error behavior can still differ.

Is an OpenAI API compatible relay safe to use?

Compatibility alone does not prove safety. Treat it as a technical signal, then check the provider's docs, pricing, model IDs, privacy policy, terms, support path and whether your workflow sends sensitive repository context.

Should a Base URL include /v1?

Sometimes. Some providers ask for the root gateway URL, while others expect `/v1`. The safe rule is to follow the provider's current docs and never paste a full endpoint such as `/v1/chat/completions` into a Base URL field.

Can every OpenAI-compatible provider work in Cursor?

No. Cursor support depends on the current Cursor settings UI, supported model type, Base URL override behavior and whether the workflow uses built-in Cursor model routes.

What should I verify before adding balance?

Verify docs, pricing, model IDs, privacy, terms, status and support first. Then run a small non-sensitive test and compare billing against the published pricing page.