Attaching a key you already have

Last updated: 2026-09-22

The goal: you hold keys elsewhere and want them to go through the same entry point as the platform's own credit — one address, one key in your code.

The whole job is filling three fields. What actually takes time is "why isn't it working" afterwards. So this is split in two: fill it in, then check it.

First, confirm the key itself is good

This step gets skipped, and then half an hour disappears. Before touching the platform's settings, call the upstream directly with that key:

curl -s https://upstream-host/v1/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"some-model","messages":[{"role":"user","content":"hi"}],"max_tokens":16}'

A reply means the key and the model name are both fine — so the problem is on the platform side. An error here means fix it there first; don't debug around it.

Fill in three fields

Open the settings for that tool in the console (one card per tool, gear icon). Three fields:

Then click apply. The platform writes all three into that tool's own config and into its own, and uses them the next time the tool starts.

Now actually check it — "no error" proves nothing

Clicking apply does not send a request, so at that moment "no error" is meaningless. Send a minimal call:

curl -s GATEWAY/chat/completions \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model","messages":[{"role":"user","content":"hi"}],"max_tokens":16}'

A reply means it works. If you get an error, work out which kind — the four below cover almost all of them.

Failure 1: the key never left

Many tools read the key from an environment variable, not from the field you just filled in. If your machine already had one with that name, the key you typed may never have been used at all.

The symptom is "authentication failed", and you will assume the key is wrong.

How to confirm:

This one hides well, because the interface shows your value while the process runs on a different one. A real case: a machine had an old variable left over, and several freshly entered keys never took effect — the stale one was winning every time.

Failure 2: right address, model not on that side

A platform often exposes more than one entry point, each backed by a different model pool. The familiar-looking name is not necessarily the one you think.

The symptom is "model unavailable" when the model is perfectly fine — it just isn't behind the entry point you called.

How to confirm: list what that entry point actually serves and look for your model.

curl -s GATEWAY/models | grep your-model

Not there? Switch to the entry point that carries it. This single step removes most of the guessing, because it separates "the model doesn't exist" from "you called the wrong place".

Failure 3: the model name is misspelled

Model names are case-sensitive; one wrong character is a model that does not exist. Copy from the docs rather than typing it.

Some platforms expose aliases (tier names, for example). An alias is only valid on the entry point that provides it.

Failure 4: the tool is installed but exits immediately

Some command-line tools require a particular runtime version. If you have several installed and switched between them (with nvm, say), moving to an older one makes the tool refuse to start.

Usually it tells you itself — "requires Node version X, current is Y". Switch to a version that satisfies it. Check which version is actually in use at the moment you launch the tool, not the one you think is default.

One general rule for debugging this

The four failures look different but come down to two directions:

Decide which one you're in before digging. Most "my settings don't work" confusion is the second kind being investigated as the first — changing keys for twenty minutes while the problem was the model name.

Next