The Current

Willison Highlights Consistency Pitfalls in OpenRouter Provider Routing

A linked post details how OpenRouter's automatic provider selection can produce differing model behavior across backends.

useful howto · for technical · September 12, 2026

In a link post published on 11th September 2026, Simon Willison summarized observations by Mohamed Moustafa about potential problems when using OpenRouter, a service that routes API requests to backend model providers. According to the post, one of OpenRouter's selling points is that it "handles fallbacks automatically and picks the most cost-effective option for each request," allowing users to call a single API endpoint and be routed to the best available backend provider. Moustafa points out that this arrangement can cause problems because different providers run different serving software with different optimizations and settings, meaning the same OpenRouter endpoint can serve requests that behave in different ways. The post notes that some providers even lack vision capability for vision models, and that the way the reasoning effort option is processed can differ between providers. Willison writes that users can control which provider is routed to using the provider.only option, and that the /endpoints method returns the list of available providers for a specific model ID. The post is presented as a link post citing Moustafa's original write-up, with no independent testing described in the excerpt.

  • OpenRouter routes a single API endpoint to different backend providers automatically
  • Different providers use different serving software, which can change model behavior
  • Some providers lack vision support for vision models, and reasoning effort handling can differ
  • The provider.only option lets users pin a specific provider; /endpoints lists available providers per model

What it means for you

OpenRouter lets you send a request to one address and it picks a backend company to actually run the AI model for you. The catch: those backends aren't identical, so the same request can behave differently — and some can't even handle images despite being listed for an image-capable model. If you rely on OpenRouter and expect consistent results, this inconsistency can quietly break things.

Try this

If you use OpenRouter in anything you care about, pin a specific provider using the provider.only option instead of letting it auto-select, and check the /endpoints list to see which backends are available for your model.

Who should care

Developers and technical teams routing production or important workloads through OpenRouter, especially anyone using vision models or relying on reasoning-effort settings.

Skip this if

You don't use OpenRouter, or you only call one model provider's API directly.

Sources: Simon Willisonread the original

← All stories