OpenRouter Made Crystal Clear · chapter 2: The Mental Model: One Key, Many Endpoints

One model slug, many provider endpoints

2026-09-08

Each endpoint is a separate provider's copy of the same model, at its own price, precision, and data policy.

Below: the paragraph from the book that builds this idea, then the diagram itself (Figure 2.1), and a recap. About a minute of reading.

This is not a flaw in OpenRouter's design. It is the direct, structural consequence of being an aggregator rather than a host: OpenRouter does not control what happens inside any given provider's infrastructure, only which provider gets your request and what you are billed for it. Chapter 5 is built entirely around the consequences of this fact, because it is also the single loudest source of reader confusion this research found. For now, just hold the shape of it: model slug on top, a set of independent provider endpoints underneath, each one capable of behaving a little differently.

Figure 2.1: One model slug, many provider endpoints. Each endpoint is a separate provider's copy of the same model, at its own price, precision, and data policy.
Figure 2.1: One model slug, many provider endpoints. Each endpoint is a separate provider's copy of the same model, at its own price, precision, and data policy.

Recap

  • The idea: Each endpoint is a separate provider's copy of the same model, at its own price, precision, and data policy.
  • The picture: Figure 2.1, from chapter 2 ("The Mental Model: One Key, Many Endpoints") of OpenRouter Made Crystal Clear.
  • Go deeper: the chapter builds this step by step, with recipes and sources at the end.

This diagram is one of many in OpenRouter Made Crystal Clear.

Every chapter opens with the gist, draws the hard ideas, and ends with recipes and sources.

Get the book

All diagrams