Migrate to the Sail API

Drop-in migration from OpenAI and Anthropic-compatible providers to Sail.

Sail is a drop-in replacement for OpenAI and Anthropic-compatible inference providers, supporting the OpenAI Responses (/v1/responses), OpenAI Chat Completions (/v1/chat/completions), and Anthropic Messages (/v1/messages) APIs. Switching from OpenAI, Anthropic, or any compatible provider is just a configuration change.

Want an agent to do it?

Copy a migration prompt, paste it into your coding agent, and then use the guide below to review the changes.

Copy migration prompt

Using Claude Code or Codex? Install the Sail skills instead and ask your agent to “Migrate this app to Sail”. The sail-migrate skill guides the full migration, including moving sandboxed execution to Sail.

Migration prompt

Migrate this project's LLM inference to Sail (https://sailresearch.com).

Sail docs to consult as you work:
- MCP server: https://docs.sailresearch.com/mcp (connect to it if you support MCP)
- Full docs as plain text: https://docs.sailresearch.com/llms-full.txt
- Key pages: https://docs.sailresearch.com/models (catalog),
  https://docs.sailresearch.com/pricing (per-window rates),
  https://docs.sailresearch.com/completion-windows,
  https://docs.sailresearch.com/support (API feature matrix)

Sail is drop-in compatible with the OpenAI Responses and Chat Completions
APIs and the Anthropic Messages API, all served from
https://api.sailresearch.com. Keep whichever request shape this code
already uses. Sail's Messages API supports system prompts, tool calling, and
streaming for agentic use. Prompt caching is automatic on every Sail API, so
`cache_control` breakpoints are accepted and have no effect; Messages reports
cache hits in `usage.cache_read_input_tokens` (see /support). The exact base
URL differs by SDK (see step 4).

If you can ask the user questions, ask whenever a step below is ambiguous
instead of guessing. If you can't, make the best-supported choice and flag
it in your final report.

1. Survey the current setup. Find every place this project calls an LLM:
   SDK clients, raw HTTP calls, framework configs, env vars, and docs. For
   each call site record the provider, API shape, model, and features used
   (streaming, tool calls, structured outputs, images).

2. Choose replacement model(s). For each model currently in use, pick the
   closest match from https://docs.sailresearch.com/models, comparing
   capability tags, context window, and what the model is known to be good
   at. If a current model is not one Sail serves, research it (web search
   if available) to understand its strengths before choosing. If multiple
   Sail models are plausible, ask the user. Otherwise pick the best fit
   and explain the choice in your report. Check the /support page for any
   features this code uses that Sail doesn't serve, and flag them.

3. Choose a completion window per call site. Omitting completion_window gives
   low-latency inference by default, at lower prices than traditional inference
   providers for many models. Workloads that can wait save more with balanced
   or flex. The live
   https://docs.sailresearch.com/completion-windows and
   https://docs.sailresearch.com/pricing pages are the source of truth for
   public windows, token prices, and scheduling behavior. If you can't fetch
   them, use this summary and decide how long each workload can wait:
   - asap: low-latency serving that is cheaper than traditional inference
     providers
   - balanced: more tokens per dollar for autonomous agents and pipelines;
     use it for workloads that can tolerate more latency
   - flex: the lowest prices for batch jobs, evals, and offline processing; it
     has no latency target; send it with background=True on the Responses API
     or through the Batch API
   If the workload's latency tolerance isn't obvious from the code, ask
   the user. Omit metadata.completion_window when the default low-latency
   behavior is acceptable. Set it explicitly for balanced or flex, or pin asap
   when the request must fail instead of using a fallback window.
   Confirm the chosen window is available for the chosen model on
   https://docs.sailresearch.com/pricing. Some models are flex-only.

4. Make the changes wherever the client is configured or called:
   - base URL: use https://api.sailresearch.com/v1 for OpenAI-compatible
     clients (Responses and Chat Completions). For the Anthropic SDK, use
     the bare host https://api.sailresearch.com (e.g. set
     ANTHROPIC_BASE_URL=https://api.sailresearch.com). The SDK appends
     /v1/messages itself, so a /v1 base URL would resolve to /v1/v1/messages
     and 404
   - API key: read from the SAIL_API_KEY environment variable. Never hardcode
     a key or paste a literal key value into the code
     (the Anthropic SDK can pass it as `api_key`; `auth_token` also works)
   - model: the Sail model(s) chosen in step 2
   - metadata.completion_window: the window(s) chosen in step 3
   - add background=True for flex or very long-running requests
   Update env var names, .env.example files, config templates, and any
   README/docs references. Do not change prompts, tools, or business logic.

5. Estimate the savings. Compare the published per-1M-token list prices
   (input, cached input, and output) of the previous model(s) against the
   chosen Sail model(s) at the chosen completion window(s) from
   https://docs.sailresearch.com/pricing. Research current provider list
   prices if you don't know them. State the comparison as a simple table
   and an approximate overall multiplier (e.g. "roughly 6x cheaper per
   token"). Do not present this as a precise bill forecast.

6. Verify. Run the project's tests. Then make one real smoke request through
   the new configuration: if SAIL_API_KEY is already set, use it; if not,
   walk the user through creating a key at
   https://app.sailresearch.com/api-keys and setting SAIL_API_KEY, then run
   the smoke request once they have. Don't ask them to paste the key to you.
   Have them export it in their own shell.

Finish with a short migration report: call sites changed; model mapping
with rationale; completion window(s) with rationale; the price comparison
from step 5; and anything that needs human follow-up (unsupported
features, ambiguous choices, untested paths). Close by telling the user
exactly where to set SAIL_API_KEY for their setup (locally and in their
production/deployment environment) so the migrated code can authenticate.

1. Get your API key

Sign up at the Sail dashboard and create an API key. Export it where your agent and app can read it:

export SAIL_API_KEY="YOUR_SAIL_API_KEY"

2. See what changes

Already calling the OpenAI Responses API? The request and response are identical:

Sail Responses API

import os

from openai import OpenAI

client = OpenAI(
    base_url="https://api.your-provider.com/v1",  
    base_url="https://api.sailresearch.com/v1",  
    api_key=os.environ["PROVIDER_API_KEY"],  
    api_key=os.environ["SAIL_API_KEY"],  
)

response = client.responses.create(
    model="<your-current-model>",  
    model="<sail-model>",  
    input="Explain the key ideas behind transformers.",
)
print(response.output_text)

Already calling the Anthropic Messages API? Keep the Anthropic SDK and point it at the bare Sail host. The SDK appends /v1/messages itself:

Sail Messages API

import os

from anthropic import Anthropic

client = Anthropic(
    base_url="https://api.sailresearch.com",  
    api_key=os.environ["ANTHROPIC_API_KEY"],  
    api_key=os.environ["SAIL_API_KEY"],  
)

message = client.messages.create(
    model="<your-current-model>",  
    model="<sail-model>",  
    max_tokens=1024,
    messages=[{"role": "user", "content": "Explain the key ideas behind transformers."}],
)

Notes

• Synchronous by default. responses.create blocks and returns the completed response, exactly like OpenAI. For long-running work, pass background=True to get an ID back immediately, then poll. This avoids HTTP timeouts. See the Quickstart.
• Pick a completion window for each call site. Omit completion_window for the default low-latency behavior, which pairs low latency with Sail’s cost efficiency. balanced gives you more tokens per dollar for autonomous work, and flex offers the lowest prices for background batches. See Completion windows.
• Prompt caching is automatic. Sail caches repeated prompt prefixes on every API, so you don’t need cache_control breakpoints; they are accepted and have no effect. On the Messages API, cache hits are reported in usage.cache_read_input_tokens and billed at the cached input rate. See the API support matrix.

Next steps

AI Quickstart

Set your coding agent up with Sail’s docs and skills.

Quickstart

Make your first request against Sail.

Models

Browse supported models and pick a replacement.

Completion windows

How the latency-for-price tradeoff works.

Pricing

Per-token rates by model and completion window.

Cost calculator

Estimate the cost of running your agent on Sail vs traditional inference providers.

Support

Email us if you hit anything unexpected.