#together.ai API calls and model listing won't stick

1 messages · Page 1 of 1 (latest)

hollow breach
#

OpenClaw says "HTTP 403 Forbidden from https://api.together.xyz/v1/models
And OpenClaw still marks all together/... entries (including together/zai-org/GLM-5) as configured,missing.
That means this isn’t an OpenClaw config typo anymore — it’s that Together is refusing the API request with that key."

grave escarpBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

amber ironBOT
#

Yep — a 403 from https://api.together.xyz/v1/models means OpenClaw is reaching Together, but Together is refusing that request for the key/account, so OpenClaw can’t verify availability and will keep showing those together/... entries as “configured but missing”.

Things that commonly cause this on Together’s side:

  • Account tier / billing not unlocked yet. Together’s own docs note that some API access is gated by “Build Tier”, and that after buying credits there can be a ~15 minute propagation delay where calls (they explicitly mention re-querying /v1/models) keep returning 403 until the tier update finishes.
  • Key not actually usable for API (wrong key, revoked key, key from a different org/project, etc.).

Quick isolation test (outside OpenClaw)

Run this on the gateway host (or anywhere) with the same key:

curl -i https://api.together.xyz/v1/models \
  -H "Authorization: Bearer $TOGETHER_API_KEY"
  • If that’s also 403, it’s not an OpenClaw config typo — you’ll need to fix it in Together (tier/billing/permissions, or regenerate the key; and if you just upgraded, wait ~15 min and retry).
  • If that’s 200 but OpenClaw still shows 403, then the gateway process probably isn’t seeing the same key (common when running as a daemon).
#

OpenClaw-side checks

  1. Make sure the key is available to the Gateway service process (not just your interactive shell). Easiest: put it in $OPENCLAW_STATE_DIR/.env (default ~/.openclaw/.env) and restart the gateway.

  2. Then re-check:

openclaw models status
openclaw status --deep

If you paste openclaw --version + the relevant section of openclaw models status (redact the key), we can tell whether it’s a Together-side block vs “daemon didn’t load env”.

hollow breach
amber ironBOT
#

I pulled the text out of your cl1p. Key detail: on OpenClaw 2026.2.24, the Gateway is definitely seeing your Together key:

  • together effective=... | env=tgp_v1_... | source=env: TOGETHER_API_KEY
  • so this is not a “daemon didn’t load env vars” situation.

That means the remaining problem really is: Together is returning HTTP 403 to GET https://api.together.xyz/v1/models for that key/account.

Together actually documents this exact symptom: during Build Tier / billing access restrictions (or right after buying credits), API calls can keep returning 403 until tier propagation finishes, and they explicitly say to re-query /v1/models after ~15 minutes:
https://docs.together.ai/docs/billing-usage-limits

Do this quick isolation test (outside OpenClaw)

On the same machine:

curl -i https://api.together.xyz/v1/models \
  -H "Authorization: Bearer $TOGETHER_API_KEY"
#
  • If still 403 → you’ll need to fix it in Together (tier/billing/permissions). Common fix is: make sure you’ve done the minimum real spend for API access (not just free credits), or wait ~15 min after purchase.
  • If 200 → then OpenClaw’s request path is different (proxy/header/etc). In that case, paste the HTTP status + response body (but redact the token).

About “configured,missing” for together/...

Your openclaw models status shows you’ve configured a bunch of together/... model IDs manually via aliases. OpenClaw marks them “missing” when it can’t confirm them against a provider catalog — and with /v1/models currently blocked (403), it can’t verify anything from Together.

Once /v1/models works, double-check those model IDs against what Together actually returns from that endpoint.

hollow breach
amber ironBOT
#

That 200 is the key clue: Together is fine with your real tgp_… key, so the earlier OpenClaw “403 from /v1/models” is almost certainly because OpenClaw is not sending the same token.

In your openclaw models status paste, this line jumps out:

  • together:default=TOGETHER_API_KEY … | env=tgp_v1_…

That means your stored Together auth profile is literally the string TOGETHER_API_KEY, not the actual tgp_v1_… secret. When OpenClaw/pi’s model registry tries GET https://api.together.xyz/v1/models, it uses that stored value → Together correctly rejects it → “configured,missing”.

Fix (recommended)

Overwrite the Together profile with the actual key:

openclaw models auth paste-token --provider together --profile-id together:default

…and paste the real tgp_v1_... value.

#

Then re-run:

openclaw models list --provider together

If some models are still “missing”

That’s then just model-id mismatch. From the /v1/models blob you pasted, I can see ids like google/veo-3.0, but I did not find zai-org/GLM-5 / cartesia/sonic-3 in that response — so those aliases will stay missing until you switch them to an id that actually appears in /v1/models.

hollow breach
# amber iron Then re-run: ```bash openclaw models list --provider together ``` ### If some ...

semperis@semperis-ThinkPad-P14s-Gen-4:~$ openclaw models list --provider together

🦞 OpenClaw 2026.2.24 (df9a474) — Hot reload for config, cold sweat for deploys.

Model Input Ctx Local Auth Tags
together/zai-org/GLM-5 text 198k no no default,configured,alias:glm5
together/Qwen/Qwen3-Coder-480B-A35B-Ins... text 256k no no configured,alias:qwen3coder-480b
together/togethercomputer/deepcogito-co... text 198k no no configured,alias:moe109b
together/google/veo-3.0 text 198k no no configured,alias:veo3-video
together/cartesia/sonic-3 text 198k no no configured,alias:sonic3-voice
together/NousResearch/Nous-Hermes-2-Mix... text 198k no no configured,alias:nous-hermes-mixtral
together/deepseek-ai/DeepSeek-V3.1 text 128k no no configured,alias:deepseek-v3.1

amber ironBOT
#

That openclaw models list --provider together output is actually super informative:

  • âś… OpenClaw knows the model IDs (so you’re no longer in the configured,missing state)
  • ❌ but it thinks they’re not available (Auth = no), i.e. the Together “availability” check isn’t seeing any Together models as usable.

Given your curl https://api.together.xyz/v1/models returns 200, the most common cause is:

You have a bad Together auth profile taking precedence

From your earlier openclaw models status, you had:

effective=profiles … together:default=TOGETHER_API_KEY … | env=tgp_v1_…

That means OpenClaw is using the profile value first, and that profile is literally the string TOGETHER_API_KEY (not the real tgp_v1_… key). So OpenClaw’s internal model registry calls end up unauthorized / empty → everything shows Auth no.

Fix (cleanest): re-run the Together auth choice so it overwrites the profile

Run:

# 
openclaw onboard --auth-choice together-api-key

When it asks to use the existing TOGETHER_API_KEY, say yes (it should then store the actual key value into together:default).

Then verify:

openclaw models status
openclaw models list --provider together

In models status, the Together line should no longer show together:default=TOGETHER_API_KEY as the credential; it should preview the real key (masked) instead.

If after that you still see Auth no, then the next step is to confirm whether Together is returning those exact IDs for your account (you can grep the /v1/models response for the specific id strings).

hollow breach
#

that worked

amber ironBOT
#

Nice — that lines up perfectly with the “profile contained the literal string TOGETHER_API_KEY” theory.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

(And for future: openclaw models status is the fastest way to spot these “env var name accidentally stored as the secret” situations, because it shows the effective credential source/profile.)