Sol Gateway

An OpenAI-compatible endpoint for the gpt-5.6-sol model.

Sol Gateway accepts the same requests as the OpenAI chat completions API, so any client or SDK that talks to OpenAI works here by changing two settings: the base URL and the API key. Reasoning effort is fixed at high on every call, so you do not need to pass it. If you have been given a key, the examples below are everything you need.

Connection details

Base URL: http://127.0.0.1:8795/v1
Model id: gpt-5.6-sol
Auth header: Authorization: Bearer SK-SOL-...
Chat endpoint: POST /v1/chat/completions
Model list: GET /v1/models
Health check: GET /health

Examples

Replace SK-SOL-your-key with the key you were given. Keep it out of source control and out of anything you share.

curl

curl http://127.0.0.1:8795/v1/chat/completions \
  -H "Authorization: Bearer SK-SOL-your-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6-sol",
    "messages": [
      {"role": "user", "content": "Write one paragraph about tide pools."}
    ]
  }'

Python, openai SDK

Python

from openai import OpenAI

client = OpenAI(
    base_url="http://127.0.0.1:8795/v1",
    api_key="SK-SOL-your-key",
)

response = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[
        {"role": "user", "content": "Write one paragraph about tide pools."}
    ],
)

print(response.choices[0].message.content)

Node, fetch

Node

const response = await fetch("http://127.0.0.1:8795/v1/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": "Bearer SK-SOL-your-key",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "gpt-5.6-sol",
    messages: [
      { role: "user", content: "Write one paragraph about tide pools." },
    ],
  }),
});

const data = await response.json();
console.log(data.choices[0].message.content);

Streaming works if you send "stream": true. The gateway waits for the full answer and then sends it as a single server-sent event, so you get a valid stream but not token-by-token output.

Rate and token limits

Limits are set per key, so yours may differ from the defaults below. The token budget is a daily allowance, not a one-time pot. It resets at the UTC date rollover, every day.

Default limits applied to a new key
Limit	Default	Notes
Requests	30 per minute	Counted over a rolling 60 second window. Going over returns HTTP 429.
Tokens	2,000,000 per day	Prompt plus completion tokens. Resets at 00:00 UTC every day. Going over returns HTTP 429.
Output length	64,000 tokens	Per request default. Ask for more with max_tokens, up to a hard ceiling of 128,000.
Input length	32,000 characters	Measured across the whole message list, before the model sees it.
Request timeout	300 seconds	A call that runs longer returns HTTP 504.

What gets logged

Every call writes one line to a usage log containing the timestamp, the key label, the first characters of the key, the model name, the token counts, and whether the request was blocked by a content rule. Prompt text and response text are not recorded.

Errors you might see

401 the Authorization header is missing, or the key is unknown or revoked.
400 the request or the response hit a content rule, or the input was too long.
429 you passed the per-minute request limit or the daily token limit.
502 the upstream model failed or returned nothing.
504 the call ran past 300 seconds.

How it runs

Requests are handed to the Codex CLI running inside an isolated WSL environment with the shell tool removed, so no local files or configuration from the host reach the model.