Provider troubleshooting gets faster when you separate credentials, endpoints, and backend assumptions

Provider errors look deceptively similar. A key can be valid while the endpoint is wrong. The endpoint can be correct while the provider selection is wrong. Or the whole stack can be fine while your mental model still assumes a different backend path is active.

Site detail pageDeepSeek TUI Provider TroubleshootingTroubleshooting

Questions this page should answer fast

Is the key wrong, the provider wrong, or the endpoint wrong?
Which backend path is actually active in the current config?
Are you debugging auth, routing, or expectation mismatch?

What this page should help you decide

This page should help the reader isolate provider issues into credential, provider-selection, endpoint, and runtime-expectation buckets.

Fast diagnosis

Credential bucket

Check whether the key belongs to the backend you think you are using right now.

Provider bucket

Confirm that the selected provider in config matches the credentials and model path you intend to use.

Endpoint bucket

Verify the base URL and backend routing assumptions before assuming the auth secret itself is invalid.

Expectation bucket

Make sure the current runtime is not still inheriting an older environment variable or shell profile.

Step-by-step workflow

Read the current config first
Look at the active provider, model, and endpoint rather than trusting memory.
Test credentials in the right context
A valid key for one backend does not prove anything about another backend path.
Compare config with environment overrides
Environment variables can silently override the file-based provider route.
Retest only after narrowing the bucket
Change one layer at a time so you know whether the problem was auth, routing, or environment inheritance.

Common mistakes

Rotating keys before confirming the provider and endpoint are even the expected ones.
Assuming the config file wins when environment variables are still active.
Changing credentials, provider, and URL all at once and losing the real signal.

When to leave this page

Leave this page once you know whether the failure lives in credentials, provider selection, endpoint routing, or environment inheritance.

Use-it-now examples

Start from working examples first, then adjust the details.

Read the active provider stack before rotating keys

Check provider name, endpoint, and current env overrides before you change credentials.

# inspect config provider block
# inspect active env overrides
# only then test credentials

Change one provider layer at a time

A stable provider debug path changes auth, endpoint, or provider selection one layer at a time.

# test current key
# then test endpoint
# then test provider selection

Common failure branches

Work out which layer failed first instead of treating every problem as the same.

You changed the key and nothing improved

That often means the provider or endpoint layer was wrong, not the key itself.

The config looks right but behavior still feels inherited

Check environment overrides and old shell exports before you rewrite the config again.