Generic OpenAI-compatible provider — works with any API that implements the OpenAI chat completions format. One C bridge, configurable base URL, Bearer auth, thinking and tool use support.
The OpenAI provider in scorpiox code is a generic bridge that speaks the OpenAI chat completions protocol.
Unlike the dedicated Anthropic or Gemini providers, this one has no hardcoded base URL —
you point OPENAI_BASE_URL at any compatible endpoint and it just works.
The C implementation lives in sx_provider_openai.c inside libsxnet.
It handles request construction, Bearer token auth, response parsing, thinking blocks,
tool-use function calls, and optional traffic logging — all in pure C with zero dependencies.
A standalone translation proxy binary (scorpiox-openai) is also provided. It accepts
Anthropic Messages API requests on stdin, translates them to OpenAI format, sends the request,
and translates the response back — useful for integrating any OpenAI-compatible backend into
the scorpiox pipeline without modifying the core.
When PROVIDER=openai (or API_BACKEND=openai), the runtime loads
the OpenAI provider bridge. Here's the request flow:
The provider translates the internal Anthropic Messages format to the OpenAI chat completions schema:
# The provider constructs a standard OpenAI-format request: POST $OPENAI_BASE_URL/chat/completions Authorization: Bearer $OPENAI_API_KEY Content-Type: application/json { "model": "$OPENAI_MODEL", "messages": [ {"role": "system", "content": "..."}, {"role": "user", "content": "..."} ], "tools": [...], # if TOOLS enabled "stream": false }
Response parsing extracts choices[0].message.content for text,
choices[0].message.tool_calls for function invocations, and
thinking blocks from extended response fields where supported by the upstream model.
All keys are set in scorpiox-env.txt or as environment variables.
| Key | Type | Description |
|---|---|---|
| OPENAI_API_KEY | string |
API key for the OpenAI-compatible service. Sent as
Bearer token in the Authorization header. Optional for local servers (Ollama, llama.cpp).default: (empty)
|
| OPENAI_BASE_URL | string |
Base URL for the API endpoint. Must include the version path (e.g.
/v1). The provider appends /chat/completions.default: (empty — must be set)
|
| OPENAI_API_BASE | string |
Fallback base URL. Checked if
OPENAI_BASE_URL is not set. Provides compatibility with the Python OpenAI SDK naming convention.default: (empty)
|
| OPENAI_MODEL | string |
Model identifier passed directly to the upstream API. Can be any string the target server accepts (e.g.
gpt-4o, llama3.1, mistral-large).default: (empty — must be set)
|
| OPENAI_TIMEOUT | integer |
Request timeout in seconds for API calls. Applied to both the scorpiox-openai proxy and the in-process provider.
default: 120
|
| OPENAI_TRAFFIC_DIR | path |
Directory to write traffic log files. When set, every request/response pair is saved as sequenced JSON files for debugging and auditing.
default: (empty — disabled)
|
| OPENAI_TRAFFIC_SEQ | integer |
Starting sequence number for traffic log files. Auto-increments per request within a session.
default: 0
|
Authentication is simple: if OPENAI_API_KEY is set, the provider sends it as a
Bearer token in the Authorization header. If not set, no auth header is sent —
which is correct for local servers like Ollama and llama.cpp that don't require authentication.
# Auth header construction (from sx_provider_openai.c): if (config->openai_api_key[0] != '\0') { // Authorization: Bearer sk-proj-abc123... snprintf(auth_header, sizeof(auth_header), "Authorization: Bearer %s", config->openai_api_key); } // If no key is set, header is omitted entirely.
For Azure OpenAI, set your Azure API key in OPENAI_API_KEY and point
OPENAI_BASE_URL to your deployment endpoint. The same Bearer token mechanism works.
Extended thinking blocks parsed from model responses when supported by the upstream API. Maps to scorpiox internal thinking format.
OpenAI function calling / tool_calls are translated to the Anthropic tool-use format used internally by scorpiox code. Full round-trip support.
Every request/response pair saved as numbered JSON files. Set OPENAI_TRAFFIC_DIR to enable. Great for debugging and audit trails.
Automatic retry on transient failures (429, 500, 502, 503) with exponential backoff. Prevents thundering herd on rate-limited endpoints.
Can operate through the scorpiox-openai standalone binary as an HTTP translation relay — Anthropic in, OpenAI out, response translated back.
The scorpiox-openai binary (built from scorpiox/scorpiox-openai.c) acts as a
standalone translation proxy. It reads an Anthropic Messages API request from stdin, converts it to
OpenAI chat completions format, sends it to the configured endpoint, and writes the translated
Anthropic-format response to stdout.
# Use scorpiox-openai as a standalone proxy: $ echo '{ "model": "gpt-4o", "max_tokens": 1024, "messages": [{"role": "user", "content": "Hello"}] }' | OPENAI_API_KEY=sk-... OPENAI_BASE_URL=https://api.openai.com/v1 scorpiox-openai # Output: Anthropic Messages API format response # { # "content": [{"type": "text", "text": "Hello! ..."}], # "role": "assistant", # "stop_reason": "end_turn" # }
This relay mode is used internally when the provider is loaded as a subprocess rather than linked directly. It also enables shell-level piping and scripting with any OpenAI-compatible API.
The OpenAI provider includes built-in traffic logging — useful for debugging, auditing,
or replaying API interactions. Set OPENAI_TRAFFIC_DIR to enable.
# Enable traffic logging in scorpiox-env.txt: OPENAI_TRAFFIC_DIR=/tmp/sx-openai-traffic OPENAI_TRAFFIC_SEQ=0 # Each request/response pair is saved as: # /tmp/sx-openai-traffic/000001_request.json # /tmp/sx-openai-traffic/000001_response.json # Sequence auto-increments per session. # Inspect a captured request: $ cat /tmp/sx-openai-traffic/000001_request.json | python3 -m json.tool # Shows the exact OpenAI-format payload sent to the upstream API
# scorpiox-env.txt — Use OpenAI directly PROVIDER=openai OPENAI_API_KEY=sk-proj-abc123... OPENAI_BASE_URL=https://api.openai.com/v1 OPENAI_MODEL=gpt-4o
# scorpiox-env.txt — Azure OpenAI endpoint PROVIDER=openai OPENAI_API_KEY=your-azure-api-key OPENAI_BASE_URL=https://your-resource.openai.azure.com/openai/deployments/gpt-4o/v1 OPENAI_MODEL=gpt-4o
# scorpiox-env.txt — Local Ollama instance PROVIDER=openai OPENAI_API_KEY=xxx OPENAI_BASE_URL=http://localhost:11434/v1 OPENAI_MODEL=llama3.1
# scorpiox-env.txt — LM Studio local server PROVIDER=openai OPENAI_BASE_URL=http://localhost:1234/v1 OPENAI_MODEL=local-model # No API key needed for LM Studio
# scorpiox-env.txt — Together AI hosted models PROVIDER=openai OPENAI_API_KEY=your-together-key OPENAI_BASE_URL=https://api.together.xyz/v1 OPENAI_MODEL=meta-llama/Llama-3-70b-chat-hf
# scorpiox-env.txt — vLLM serving on local GPU PROVIDER=openai OPENAI_BASE_URL=http://localhost:8000/v1 OPENAI_MODEL=mistralai/Mistral-7B-Instruct-v0.3 OPENAI_TIMEOUT=300
# scorpiox-env.txt — Debug with full traffic capture PROVIDER=openai OPENAI_API_KEY=sk-proj-abc123... OPENAI_BASE_URL=https://api.openai.com/v1 OPENAI_MODEL=gpt-4o OPENAI_TRAFFIC_DIR=/tmp/sx-traffic OPENAI_TRAFFIC_SEQ=0
The scorpiox-openai binary is compiled from scorpiox/scorpiox-openai.c and
serves as the standalone translation layer. It can be used independently of the full scorpiox runtime:
# Build the standalone proxy: $ cd scorpiox && make scorpiox-openai # Run with environment variables: $ OPENAI_API_KEY=sk-... \ OPENAI_BASE_URL=https://api.openai.com/v1 \ OPENAI_MODEL=gpt-4o \ ./scorpiox-openai < request.json > response.json # Or pipe from scorpiox-env.txt config: $ scorpiox-openai # reads OPENAI_* from scorpiox-env.txt automatically
The proxy reads config from scorpiox-env.txt in the current directory (or parent directories)
and from environment variables. Environment variables take precedence.
Any service that implements the OpenAI /v1/chat/completions endpoint works with this provider.