Receiving malformed JSON

[marble bluff]

I'm an AI assistant - my answers may be incorrect and I cannot see screenshots. Please verify information with the OpenRouter docs.

To help debug this issue, I need more information:

1. Can you share the full error response (not just the line/column, but any server response or traceback)?
2. What is the exact model identifier you're passing (e.g., openai/gpt-4o, openai/gpt-4-turbo, openrouter/gpt-5, etc.)?
3. Are you using streaming (stream=True) or non-streaming mode in your API call?

These details will help pinpoint whether the issue is with a specific model, response format, or SDK compatibility.

-# This is an automated response powered by Answer HQ. Use !mute to stop the bot from responding.

[sonic peak]

That's an error with the package you're using, not with OpenRouter itself

[marble bluff]

Thank you for providing additional details.

This error typically means the OpenAI SDK received an HTTP response from OpenRouter that was not valid JSON—often this is an HTML error page (like a 429 Too Many Requests or 5xx error), or a truncated/incomplete response, which the SDK then tries to parse as JSON and fails.

Key points:

• The OpenRouter API is OpenAI-compatible, but the SDK expects all responses to be valid JSON. If the server returns a non-JSON error (like an HTML error page), you'll get a JSONDecodeError.
• This is more likely to happen during rate limits, provider timeouts, or upstream service issues.

How to debug and mitigate:

1. Log the full HTTP response body (not just the error/traceback) when a JSONDecodeError occurs. This will often show the true server-side error (like 429, 502, etc.).
2. Check for rate limiting and upstream errors. If you see HTML with messages like "Too many requests" or "Internal server error," those are often the root cause.
3. Add error handling for non-JSON responses before passing to the OpenAI SDK for parsing.

Reference from docs:
"OpenRouter provides an OpenAI-compatible completion API... In the examples below, the OpenRouter-specific headers are optional."
See more about API usage and supported error handling in the API Reference and about provider routing and error recovery in Provider Routing.

Next steps:

• Try catching the exception and printing/logging the raw response.
• Consider implementing retry logic or handling for HTML/non-JSON error responses.

If you continue experiencing issues or find the problem only occurs with "gpt-5", please confirm the exact model identifier and check if...