Add APIsRouter as an OpenCat API provider.

Quick answer: one provider entry in Settings.

Open Settings, go to API Providers, and add a provider (or edit the existing OpenAI one). Four fields do the job: a display name of your choosing, the protocol set to OpenAI, the API Host set to https://api.apisrouter.com/v1 with the /v1 included, and the API key. That is the whole integration; OpenCat speaks standard chat completions to whatever host the provider entry names. Once the provider saves, OpenCat lists the models the endpoint serves. If a model you want does not appear in the auto-populated list, add it manually by its exact id, the app accepts typed ids for precisely this case. From then on, every conversation and assistant in the app can select any catalog id like a native option.

Name:      APIsRouter
Protocol:  OpenAI
API Host:  https://api.apisrouter.com/v1
API Key:   sk-APIsRouter-...

models auto-list from the endpoint;
add ids manually if one is missing

How OpenCat treats providers and assistants.

OpenCat is one of the longest-standing native AI clients in the Apple ecosystem, a Mac, iPhone, and iPad app with a strong following across Asia, built around the bring-your-own-key idea: the app is the interface, your keys are the access, and there is no per-message middleman. Its developer sells the app itself, a free tier plus a one-time Pro purchase listed at 9.99 dollars on opencat.app as of July 2026, which is a different economic shape from subscription chat products and exactly why a metered gateway key pairs well with it. The mechanics that matter: providers and assistants are separate layers. A provider is a protocol, a host, and a key. An assistant is a persona, a system prompt plus a model choice, and OpenCat encourages keeping several. With one gateway provider, that turns into a genuinely useful pattern: a writing assistant on claude-sonnet-4-6, a quick-answers assistant on claude-haiku-4-5-20251001, a bilingual assistant on glm-5.2 or kimi-k2.6, all in one app, switchable per conversation, billed to one key. The app also folds chat, translation, voice conversation, and image discussion into the same interface, and every one of those features rides the model the current assistant selects. Point the provider at a multi-vendor endpoint and each feature quietly gets model choice too.

Full setup: provider, models, assistants.

Add the provider on whichever device is handy; OpenCat syncs conversations and settings across devices through iCloud on its paid tier, so a provider configured on the Mac typically follows you to the iPhone rather than needing re-entry. If you run the free tier per device, enter the same four fields on each. Then build assistants around models rather than treating the model picker as an afterthought. Create an assistant, give it a system prompt, and bind it to a catalog id. The practical division of labor: fast ids for the assistant you talk to all day, a frontier id for the one that drafts things that matter, and a bilingual id for the one handling Chinese, Japanese, or Korean text. Because OpenCat lets several assistants coexist, you get per-task model routing without ever thinking about it mid-conversation. For the translation and voice features, the model behind the current assistant does the language work, which makes the fast tier the right default there: translation turns are short, frequent, and latency-sensitive, the exact profile deepseek-v4-flash and claude-haiku-4-5-20251001 are priced for.

Writer     -> claude-sonnet-4-6        (drafts, long answers)
Quick      -> claude-haiku-4-5-20251001 (default chatter)
Bilingual  -> glm-5.2                   (zh/en mixed threads)
Translate  -> deepseek-v4-flash         (short, frequent turns)

all four assistants -> one provider -> one key

Choosing models for a native client.

The per-assistant binding makes comparison effortless: duplicate an assistant, change only the model, and run both against your real questions for a day. The usage log prices the comparison per id while the conversations tell you which one you kept opening.

• Phone-first usage is latency-first usage. claude-haiku-4-5-20251001 and deepseek-v4-flash answer fast enough that the app feels native rather than networked.
• The one-time-purchase economics reward metered keys: no seat fee means your only recurring cost is tokens, so putting casual traffic on fast ids keeps a heavy month small.
• claude-sonnet-4-6 earns the assistant that writes for you, where per-message price buys visible quality.
• glm-5.2 and kimi-k2.6 are first-class picks for the Chinese-English traffic a large share of OpenCat's user base actually has; through the gateway they sit in the same picker as Claude instead of needing separate vendor accounts.
• Translation and voice turns are short and constant; keep them on the fast tier and the features feel free.

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 OpenCat.

Requests still going to api.openai.com after setup means the conversation is not using your new provider. Providers coexist in OpenCat, and an assistant or conversation created earlier keeps its original provider binding; switch the assistant's provider and model rather than assuming the new entry took over globally. An API Host without the /v1 fails once the app appends request paths; the working shape, as gateway guides for OpenCat consistently show, is the base with /v1 included, https://api.apisrouter.com/v1. An empty or partial model list is not a dead end. The auto-list depends on the endpoint's model listing, and OpenCat accepts manually typed ids for anything missing; the /v1/models output with your key is the authoritative spelling for what you type. Keys are per provider entry, so a key rotated on the gateway must be updated in the provider settings; a suddenly failing app after months of silence is usually an expired or rotated key, not an app problem. And if devices disagree, one working and one failing, the settings sync boundary is the first suspect: confirm the failing device actually has the provider entry and key.

Who routes OpenCat through a gateway.

• BYOK users who bought the app to escape subscriptions and want the key side equally simple: one balance, every model, no card on file.
• Bilingual users across Chinese and English, for whom GLM and Kimi next to Claude in one picker is the actual daily workflow, not a novelty.
• Multi-device people, Mac at the desk and iPhone in transit, who want one provider entry serving both rather than per-vendor apps and logins.
• Heavy translators using OpenCat's translation features, where short frequent turns on fast catalog ids keep the habit inexpensive.
• Developers without access to a given vendor's billing. Top-up based access with no card requirement removes the per-provider sign-up dependency.

Verify the endpoint and debug the first chat.

Confirm the endpoint from a terminal first if you have one handy: list the models with your key and check the ids you plan to use. On iPhone-only setups, skip straight to the in-app path: save the provider, watch whether the model list populates, and send one short message. The failure sort is short. An authentication error is the key field. A connection or not-found error is the API Host, almost always a missing /v1. A model error means the id was typed differently from the endpoint's listing. And a conversation that behaves like the old provider is bound to the old provider; check the assistant's settings, not the provider list. Once messages flow, the APIsRouter console shows per-request model, token counts, and spend. For a bring-your-own-key app, that log is the whole financial picture, every device and every assistant on one page, which is exactly the visibility subscription chat apps never give you.

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

FAQ