Skip to main content
This page covers the errors and symptoms most commonly reported by OpenOpen8 administrators and users. Work through the relevant section for your issue, and check the FAQ if you do not find your answer here.
A 401 response means OpenOpen8 could not authenticate your request. The most common causes are:Missing or malformed Authorization header. OpenOpen8 expects the header in this exact format:
Authorization: Bearer your-token-here
A bare token without the Bearer prefix will be rejected.Token is expired or disabled. Log in to the dashboard, go to Tokens, and confirm the token is active and has not passed its expiry date. Administrators can check any user’s tokens from User Management.Token has no remaining quota. A token with a quota of 0 returns 401 rather than a quota-specific error. Check the token’s remaining balance in Tokens.Wrong instance URL. Confirm that your client is pointed at the correct host and port. A request reaching a different service will naturally return 401.
A 404 on the chat completions endpoint almost always means a duplicated /v1 path segment in the URL. This happens when the client SDK appends /v1 automatically and the base URL you configured already includes it.Do this:
base_url = "https://openopen8.ai"
Not this:
base_url = "https://openopen8.ai/v1"   # results in /v1/v1/chat/completions
The OpenAI Python and JavaScript SDKs both append /v1 automatically, so the base URL you pass should be the root of OpenOpen8 with no path suffix.
A 429 response means a rate limit has been reached. OpenOpen8 applies rate limits at three levels:
  1. Token-level limits — configured per-token in Tokens
  2. User-level limits — configured per-user in User Management or Settings → Operation Settings
  3. Upstream provider limits — the provider’s own API returned a 429, which OpenOpen8 passes through
What to do:
  • Wait and retry with exponential backoff. Most rate limits reset within seconds to minutes.
  • If you are an end user, contact your administrator to request a higher limit.
  • If you are an administrator, open Settings → Operation Settings and review the rate limit settings. You can also check the Logs page to see which token or model is hitting its ceiling.
  • If the 429 is coming from the upstream provider, either reduce your request rate or add additional channels for that provider to distribute load.
A 503 with a message about no available channels means every configured channel that supports the requested model is currently marked as unavailable.Steps to diagnose:
  1. Open the Channels page in the admin dashboard.
  2. Look for channels in an error state (shown in red or with an error icon).
  3. Click on the failing channel and review the error message. Common causes:
    • Incorrect API key
    • Wrong base URL
    • The upstream provider is experiencing an outage
    • The model name in the channel does not match what the provider expects
  4. Use the Test button on the channel to trigger an immediate health check and see the raw error response.
If the channel test passes but requests still fail, check whether the channel is enabled and whether the model requested by the client exactly matches a model in that channel’s model list.
If streaming responses stop mid-generation without an error, the most likely cause is the STREAMING_TIMEOUT limit being reached.Increase the timeout by setting the environment variable and restarting the container:
STREAMING_TIMEOUT=600   # 10 minutes; adjust as needed
The default is 300 seconds (5 minutes). For very long reasoning or generation tasks, you may need to increase this significantly.If the response cuts off at a consistent point or in an inconsistent pattern, also check whether the upstream provider itself is terminating the connection. Look at the Logs page for error details on the affected requests.
If responses from vision or image-generation models are cut off — particularly when the model returns large base64-encoded image data inside a streaming response — the per-line buffer for the stream scanner is too small.Increase it by setting:
STREAM_SCANNER_MAX_BUFFER_MB=128   # default is 64; double if you see truncation
Restart the container after making this change. If truncation persists, keep doubling the value until responses are complete. Each MB you add is memory that the container may use per active streaming connection, so do not set this higher than necessary.
If users report being logged out unpredictably, or have to log in again when their request is routed to a different instance, you have not set a shared SESSION_SECRET.By default, each OpenOpen8 container generates its own random session signing key at startup. Session cookies signed by one instance are rejected by all others. To fix this, set the same secret on every instance:
SESSION_SECRET=a-long-random-string-the-same-on-every-instance
Restart all containers after setting the variable. Existing sessions will be invalidated — users will need to log in once more, after which logins will persist correctly across instances.
Choose a strong random value (at least 32 characters) and store it securely. Treat it like a password — anyone with this value can forge valid session cookies.
When the Test button on a channel returns an error, work through these checks in order:
  1. API key — paste the key into the channel editor and confirm there are no leading or trailing spaces. Some providers issue keys with invisible characters when copied from their dashboard.
  2. Base URL — verify the URL is correct for the provider type. For standard OpenAI-compatible providers it should end without a trailing slash and without /v1 (OpenOpen8 appends the path itself). For Azure, confirm the endpoint matches the format: https://your-resource.openai.azure.com.
  3. Model name — the model name configured in the channel must match exactly what the provider expects. For example, Anthropic requires claude-3-5-sonnet-20241022, not a shortened alias. Check the provider’s documentation for the exact identifier.
  4. Network reachability — ensure outbound HTTPS is allowed to openopen8.ai.
  5. TLS issues — if the channel target uses a self-signed certificate (for example, a local Ollama instance behind a reverse proxy), you can set TLS_INSECURE_SKIP_VERIFY=true temporarily to test. Do not leave this enabled in production.
After each change, save the channel and run the test again. The test response is displayed inline and usually contains enough detail to identify the root cause.