Stop looking for the best model

The most useful shift here is small. People arrive expecting to find out which model is best, and there is no answer to that question — not because it is hard, but because it is the wrong shape of question.

OpenRouter is a good starting point precisely because it is not one model. It is a gateway — one key and one endpoint that reach models from many different developers. So the honest starting position is this: you may already have enough. What follows is how to tell when you do not.

Where a single route starts to pinch

These three come from depending on one route, not from anything wrong with OpenRouter itself.

flowchart TD
  A["You send a request"] --> B{"Is your one route
working right now?"}
  B -->|"no"| C["The task stops here"]
  B -->|"yes"| D{"Can the selected model
do this kind of work?"}
  D -->|"no, it cannot read images"| C
  D -->|"yes"| E["You get an answer"]
  E --> F{"Was a premium model
needed for this?"}
  F -->|"no"| G["You paid more than you had to"]
  F -->|"yes"| H["Right tool, right job"]

Most household work fits three roles

Model catalogs are long and the names are meaningless from the outside. It helps to stop reading them as a list of products and start reading them as three jobs. One model can fill more than one role.

Here is the same idea as actual decisions:

Switching between them is a dropdown at the bottom of the message box. It is not a settings change and it does not restart anything.

Switching modelsThe picker sits under the message box. The tick marks the model this conversation is using.

• The tick shows the current model for this conversation.
• Changing it affects the next message, not the ones already sent.
• Beside the picker sit reasoning level and tool preset — covered in Parts 5 and 8.

You can watch the meter run

Providers meter usage in tokens, counted separately for what you send in and what comes back out.

The useful part is that Pi Agent shows you the figure under every answer, so this is not theoretical. Below is a real two-sentence answer from a live workspace:

The meterEvery answer carries its own cost line. This one: 1,094 tokens in, 53 out, $0.0071.Live workspace

• 1,094 in — and the question was one sentence. The rest is the system prompt and tool definitions that go with every request.
• 53 out — the answer itself, which is the small half.
• $0.0071 — under a cent. Now imagine that line on a premium reasoning model, on a question this simple.

That gap is the whole argument for keeping an everyday model around. Not because the expensive one is bad, but because most of what you ask does not need it.

Three ways a provider connects

If you do open the Add provider screen, the catalog is grouped in a way that tells you something useful before you pick anything: a custom endpoint you fill in yourself, a subscription you log into, or a provider you paste a key for.

The provider catalogGrouped by how you connect: a custom endpoint, a subscription you log into, or a provider you paste an API key for.

• Subscriptions connect by logging in — you already pay a monthly fee somewhere, and this reuses it.
• API key providers meter per use, which is the pay-as-you-go model this article has been describing.
• Only the API key cards carry a model count here — the subscription cards just read OAuth, because what you get is whatever your plan includes.

The model counts are worth a second look, because they show why a gateway is a reasonable default.

Breadth in one entryOpenRouter: 366 models behind a single key. Most direct providers list a handful.

That is the case for staying where you are. One entry, one key, hundreds of models — including, usually, one of each of the three roles above. A direct provider is a narrower thing you add for a specific reason.

The honest answer is usually no

A second provider earns its place when it gives you one of these, and you should be able to say which one before you add it:

• Specialization — a native capability the gateway does not expose the way you need it.
• Fallback — an independent route for when the first one is down or rate-limited.
• Comparison — asking two models the same important question. Though note that two models agreeing is not proof either is right.
• Account separation — keeping usage and access controls apart for different purposes.
• Better judgment — learning which characteristics actually matter for your own work, rather than trusting a generic ranking.

If none of those describes a problem you currently have, the right move is to keep one route and get on with using it.

Where to go from here