The /v1 suffix rule changes by client and it is easy to get wrong

One of the easiest ways to misconfigure an OpenAI-compatible gateway is to treat every Base URL field as if it meant the same thing. I made a small reference table after seeing the same duplicated path error turn up in several setup questions.

Some clients expect a versioned API root and append /chat/completions. Some expect an unversioned origin and append /v1/messages. A raw HTTP client appends nothing. If you paste a full endpoint into a field that expects a base, the final request can quietly become /v1/chat/completions/chat/completions. If you add /v1 to Claude Code, it can become /v1/v1/messages.

These are the current values for TokenRouter clients covered by the official docs.

The underlying principle is simple. Find out whether the field is asking for an origin, a versioned API root, or a complete endpoint. The label Base URL alone does not answer that question.

For a raw OpenAI-compatible smoke test, use a complete endpoint.

export TOKENROUTER_API_KEY="<YOUR_API_KEY>" curl -sS https://api.tokenrouter.com/v1/chat/completions \ -H "Authorization: Bearer $TOKENROUTER_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "<MODEL_ID_FROM_THE_CONSOLE>", "messages": [ {"role": "user", "content": "Reply with OK"} ], "max_tokens": 16 }' 

Do this before putting the gateway behind an agent framework. It separates four variables that are otherwise hard to distinguish during debugging.

• DNS and TLS reachability
• The TokenRouter key
• The model ID
• The endpoint path

If that request succeeds and the framework still fails, the problem is probably in the framework configuration, request format, streaming parser, or tool-call handling. If the raw request fails, adding LangChain, an agent loop, or an IDE on top only gives you a longer stack trace.

For the OpenAI Python client, the versioned API root belongs in base_url.

import os from openai import OpenAI client = OpenAI( api_key=os.environ["TOKENROUTER_API_KEY"], base_url="https://api.tokenrouter.com/v1", ) response = client.chat.completions.create( model=os.environ["TOKENROUTER_MODEL_ID"], messages=[{"role": "user", "content": "Reply with OK"}], max_tokens=16, ) print(response.choices[0].message.content) 

Keep the full model identifier from the Models page. Provider prefixes are part of the ID. A short display name that looks right in a dropdown may still be invalid in an API request.

There are two checks worth adding after the first successful response.

First, inspect the returned usage fields and confirm the request appears under Usage Logs. This proves that the key and model are visible in the control plane you will later use for cost review.

Second, run one streaming request and one tool-calling request if your application depends on them. A successful plain-text completion proves very little about an agent integration. Streaming event boundaries, tool-call ordering, finish reasons, and usage reporting are the parts most likely to expose compatibility assumptions in a client library.

Also create separate API keys by environment or workload. A key called prod-support-agent is much easier to trace and disable than a single key shared by a laptop, CI, staging, and production. The console supports named keys, restrictions, and usage logs, so use those boundaries early.

Official feature guide
https://www.tokenrouter.com/docs/tokenrouter-feature-guide/

Check the final wire URL once before debugging the rest of the stack. A duplicated path segment is dull, but it can look remarkably similar to a bad key or an unsupported model from inside an agent framework.