DTDeepSeek TUI GuideTerminal setup and usage hub
Home/Config/Provider Setup
Provider Setup

Provider setup is where CodeWhale stops being a binary on disk and starts becoming a real working agent

Once installation is complete, provider setup becomes the real activation step. The important part is not only entering credentials, but making sure the selected backend, auth values, and expected models all belong to the same path.

Site detail pageCodeWhale Provider Setup (DeepSeek TUI Guide)Config

Questions this page should answer fast

  • Which provider path is actually active in the current config?
  • How do auth, model defaults, and runtime expectations have to line up?
  • Which failures should send you back to API key, env vars, or config file location?

What to verify next

  • Confirm the provider named in config matches the key or token you supplied.
  • Check whether stale env vars are silently overriding the intended provider block.
  • If auth is valid but behavior still looks wrong, inspect model defaults and mode assumptions next.

Common mistakes

  • Keeping one provider in config and another in environment variables.
  • Testing with advanced workflows before the simplest provider call is stable.
  • Changing several provider-related defaults at once and losing a clean baseline.

Recommended reading order

Move through the page by workflow need first, then branch into adjacent detail pages or hubs.

Step 1

Choose the provider explicitly

Do not let the provider remain an implicit assumption. Name the active backend first.

Step 2

Align auth and config in one place

Make sure the credential source and provider block describe the same backend instead of mixing two routes.

Step 3

Validate with a minimal live request

Test the smallest successful provider call before you tune models, modes, or MCP.

Use-it-now examples

Start from working examples first, then adjust the details.

Provider-first setup order

Do not configure auth, model defaults, and advanced features all at once. Lock the provider path first, then verify one minimal request.

codewhale --version
# then start one minimal session after auth is set

One-source-of-truth pass

Keep provider choice, auth source, and model assumptions aligned in one pass before you add MCP or more advanced runtime behavior.

export DEEPSEEK_API_KEY="your-key-here"
# keep env and config pointing at the same provider

Verify the credential layer before tuning models

A working provider path is worth more than any model tweak. First prove the key and provider route agree, then change model defaults later.

echo "$DEEPSEEK_API_KEY"
# confirm the intended provider block
# run one minimal request before touching model defaults

Common failure branches

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

Provider is selected but auth still fails

That usually means the provider name and credential source disagree. Check API key setup and env overrides before changing models.

Auth works but responses feel wrong

This is often a model-default or mode-assumption problem, not a credential problem. Move into config and mode pages next.

You are changing provider, env vars, and model defaults in one pass

Stop and split the work. Lock the provider and auth layer first, or you will not know which change fixed or broke the session.

When to leave this page

Once the route is clear, leave this page quickly. Install pages should hand you into config, config pages should send you into provider or troubleshooting, and MCP or mode pages should send you back into live workflow decisions. A detail page is valuable because it narrows the problem, not because you stay on it forever.