Add every catalog model to Chatbox with one custom provider.

Quick answer: one dialog in Model Provider settings.

Open Chatbox Settings and switch to the Model Provider tab. Click Add, then Add Custom Provider. Fill the dialog with five values: a Name (APIsRouter), API Mode set to OpenAI API Compatible, your key in API Key, https://api.apisrouter.com/v1 in API Host, and leave API Path on the /chat/completions default that Chatbox fills for a host ending in /v1. Then add models. The Fetch button pulls the endpoint's model list through /v1/models so you can enable ids from the catalog directly, and New lets you type an id by hand if you prefer a short curated picker. Click Check next to the key field and Chatbox runs a live request; a green confirmation means the provider is wired. We validated this exact flow against the current Chatbox web app, and the same dialog ships in the desktop and mobile builds.

How Chatbox talks to a custom provider.

Chatbox (chatboxai on GitHub, roughly 41K stars) is one of the most installed AI chat clients: native apps for Windows, macOS, and Linux, mobile builds for iOS and Android, and a browser version at web.chatboxai.app. It ships with first-party entries for the big vendors, each wanting its own key, and the custom provider dialog is the documented path for everything else. A custom provider in OpenAI API Compatible mode is a plain description of an endpoint: host, path, key, and a list of model ids. Every conversation turn becomes a standard chat-completions request against that host, with the model id from the picker traveling as a string. Chatbox does not care which vendor trained the model behind an id, which is exactly what makes a multi-vendor gateway useful here: one provider entry puts claude-sonnet-4-6, gpt-5.5, gemini-3.5-flash, and deepseek-v4-flash in the same picker, billed through the same key. The practical difference from stacking four first-party providers is not just fewer keys. Chatbox settings sync per device, so every vendor account you add is another key to paste onto your phone, your laptop, and the web app. One custom provider is one paste per device, and switching a conversation from Claude to DeepSeek is a picker change rather than a provider change.

Full setup: every field in the dialog.

Name is only a label; APIsRouter keeps the picker readable. API Mode must be OpenAI API Compatible, which tells Chatbox to speak standard chat completions; the other mode in the dropdown is for Gemini-native endpoints and is not what a gateway wants. API Host and API Path compose into the request URL, and this pair is where setups go wrong. With the host set to https://api.apisrouter.com/v1, the path is /chat/completions, and Chatbox fills exactly that when it recognizes a /v1 host. The Chatbox docs also describe the bare-host convention, where the host omits /v1 and the path defaults to /v1/chat/completions; both compose to the same URL, so pick one shape and leave the other field at its default. What breaks is mixing them, a /v1 host with a /v1/chat/completions path, which produces a doubled /v1/v1 URL that 404s. Field labels and autofill behavior shift a little between Chatbox releases, so trust the composed URL over memory. For models, Fetch is the low-effort path: Chatbox lists everything the endpoint serves and you toggle on what you want. New is the curated path: type ids by hand and the picker stays short. Each model row has capability switches (vision, tool use); leave them off unless you know the model supports the capability, since an unconfigured model is treated as plain text and that is the safe default. Finish with Check, then start a conversation and pick a model under your new provider name.

Name:      APIsRouter
API Mode:  OpenAI API Compatible
API Key:   sk-YOUR-APISROUTER-KEY
API Host:  https://api.apisrouter.com/v1
API Path:  /chat/completions   (autofilled)

Models: Fetch (pull the catalog) or New (type ids)
Then:   Check → green confirmation

Choosing models for a daily chat client.

Because every enabled model bills through one key, comparing two ids is a picker switch rather than an account decision. Run the same kind of conversations on both for a few days, then read the per-model spend in the APIsRouter console and keep what earned its place.

• Everyday questions and quick rewrites are burst work. claude-haiku-4-5-20251001 and gemini-3.5-flash answer fast enough that the app feels instant, and they carry most day-to-day traffic well.
• Long drafting, careful reasoning, and code discussions earn claude-sonnet-4-6 or gpt-5.5. Keep one of each tier enabled and switch per conversation instead of per provider.
• deepseek-v4-flash is the volume pick if Chatbox is your always-open sidebar; constant small conversations add up and the fast tier keeps the balance moving slowly.
• Image-input conversations need a vision-capable id with the vision switch enabled on that model row; confirm capability against the model documentation before flipping the switch.
• Enable few models deliberately rather than fetching everything: each toggle is a picker row, and adding another id later is a ten-second edit.

Pay-as-you-go · transparent per-model pricing

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Failure modes specific to Chatbox.

The doubled path is the classic. A 404 on every message means API Host and API Path both carry a /v1 or the path repeats what the host already ends with; open the provider entry and read the two fields as one URL. An empty result from Fetch usually means the key is wrong or missing, since the model listing is itself an authenticated request. Check the API Key field and use the Check button, which surfaces authentication errors directly. A model that errors only in some conversations is usually a capability switch: vision enabled on a model that lacks image input, or a tool-dependent flow hitting a model with tools switched off. Reset the model row to defaults and re-enable capabilities one at a time. And remember the provider entry lives per installation. Adding APIsRouter on your desktop does not configure your phone; repeat the dialog there, or use Chatbox's own config sharing if your version offers it. The one thing that never needs repeating is vendor sign-ups, since one key covers every model on every device.

Who routes Chatbox through a gateway.

• People who want Claude, GPT, Gemini, and DeepSeek in one picker without maintaining four vendor accounts and four keys across three devices.
• Users in regions where some vendor sign-ups are painful; top-up based access with no card requirement removes the per-provider dependency.
• Developers who already route their editor and terminal tools through a gateway and want their chat client on the same key and the same usage log.
• Model shoppers who compare ids on real conversations before committing a project to one; every candidate is a picker row, not an account.
• Households and small teams standardizing on one endpoint, one balance, and per-key usage visibility instead of scattered subscriptions.

Verify the endpoint and debug the first message.

Prove the gateway half outside Chatbox first: list models with your key, then run one chat completion against an id you plan to enable. If both pass, everything that remains is in the provider dialog. Inside Chatbox, the Check button is the fastest signal. Authentication errors are the key field. Not-found errors on send are an id mismatch, which mostly happens with hand-typed New entries; copy ids from the /v1/models output instead of memory. 404s on every request are the host/path composition covered above. Once messages flow, the APIsRouter console shows per-request model, token counts, and spend. A chat client generates many small requests across the day, and the usage log is where that habit becomes a per-model, per-day number you can actually read.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

FAQ