Guides
OpenAI compatibility
What is identical, what differs, and how to migrate an existing OpenAI integration.
Stac implements the OpenAI chat completions surface. Most integrations migrate by changing the base URL and the key.
const client = new OpenAI({
- baseURL: "https://api.openai.com/v1",
- apiKey: process.env.OPENAI_API_KEY,
+ baseURL: "https://api.trystac.com/v1",
+ apiKey: process.env.STAC_API_KEY,
});Using an Anthropic-shaped client instead (Claude Code, the anthropic SDK)?
See Anthropic compatibility — the
request/response shapes differ enough to warrant their own page.
Supported
| Feature | Status |
|---|---|
POST /v1/chat/completions | Full |
POST /v1/completions | Full |
POST /v1/embeddings | Full |
POST /v1/responses | Full |
GET /v1/models | Full |
| Streaming (SSE) | Full |
temperature, top_p, max_tokens, stop | Full |
| Function / tool calling | Full |
JSON mode (response_format) | Full |
| Vision inputs | Model-dependent — check capabilities on GET /v1/models |
| Assistants, threads, files | Not supported |
Differences that matter
modelis always ignored. Your stack has exactly one model assigned; any value you send is replaced with it.GET /v1/modelsreports the real id, mostly for logging.nis capped at 1. Multiple completions per request would multiply capacity use without a per-token meter to price it.max_tokenshas a floor. Requests are clamped to at least 8000 and at most 16000 — see Chat completions.logit_biasis dropped, and message roles outsidesystem,user,assistant,toolare discarded rather than rejected.- Rate limiting is per key, not per tier. See Errors & rate limits.
Unknown parameters are ignored rather than rejected, so an SDK that sends a field Stac does not implement still works. Check the response, not just the status code, when a feature seems to have no effect.
CLI tools
Codex CLI
Codex reads your key from whatever environment variable env_key names in
its config — set that variable, then point Codex at Stac in
~/.codex/config.toml:
export STAC_API_KEY="your-stac-api-key"
codexcurl "https://api.trystac.com/v1/chat/completions" \
-H "Authorization: Bearer $STAC_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"messages": [{ "role": "user", "content": "Hello" }]
}'model_provider = "stac"
model = "your-stack-model"
model_auto_compact_token_limit = 104000
[model_providers.stac]
name = "stac"
base_url = "https://api.trystac.com/v1"
env_key = "STAC_API_KEY"
wire_api = "responses"The TOML file is required either way — it's how Codex learns about the
stac provider. Bash sets the STAC_API_KEY variable that env_key
points at; Curl is just a quick way to confirm the key and base URL
work before wiring up Codex.
Don't set model_context_window — a known Codex bug
(openai/codex#16068) makes
that key break auto-compaction permanently after the first overflow. Use only
model_auto_compact_token_limit.
Cursor, Cline, Continue, and other OpenAI-compatible tools
Any tool with an "OpenAI compatible" provider setting works the same way:
- Base URL:
https://api.trystac.com/v1 - API key: your Stac API key
- Model: any value — it's ignored
Exporting these as global shell variables repoints every tool on the
machine at your stack. Scope them to a project shell, a .envrc, or the
tool's own config file instead.