Claude Code Multi-Provider Setup Guide (GLM 5.2, MiniMax M3 and more)

TL;DR

• Keep provider API keys in the active shell profile, then keep key-free launcher scripts on your path. This removes the need to rewrite one Claude settings file every time you change providers. (source video gG6qY9fnb7w, 02:04; 02:16; 02:50; 02:56)
• Each launcher has three jobs: fail clearly when its key is missing, export that provider’s Claude Code variables, and start Claude Code with that environment. (source video gG6qY9fnb7w, 03:20)
• Separate provider-specific model and endpoint values from shared settings such as theme and verbosity, because the shared settings file applies to every provider. (source video gG6qY9fnb7w, 05:10; 05:37)
• Map Claude Code’s Opus, Sonnet, and Haiku tiers to the models exposed by the selected provider; the video shows GLM and LongCat as examples. (source video gG6qY9fnb7w, 04:15; 04:43)
• Ron prefers a provider’s native coding tool when one exists. Use this setup when you specifically want the Claude Code harness with an Anthropic-compatible endpoint. (source video gG6qY9fnb7w, 06:47; 07:22; 07:57)

Ron’s verdict

This is a clean operator pattern for people who want one familiar harness without manually mutating its settings for every model switch. The launcher boundary makes the active provider explicit and keeps provider-only values out of the shared config. But do not build this just because it is possible: Ron’s own preference is the native coding tool when the provider offers one, especially when its coding plan is the better-value route. He keeps the launcher option for the model-plus-harness combinations he actually wants, and says GLM 5.2 inside Claude Code had been impressive in his use. (source video gG6qY9fnb7w, 06:47; 07:27; 07:37)

Key moments

• 00:00 — The multi-provider problem: different providers need different parameters, so swapping one token and URL is not enough.
• 00:55 — Why the single settings file is risky: Ron points out that the API key sits in plain-text JSON and may be visible to anyone with home-directory read access.
• 02:16 — Choose the active shell profile: the setup starts in the shell’s matching profile rather than assuming every machine uses Bash.
• 03:20 — The three-part launcher pattern: require the key, export provider-specific values, then execute Claude Code.
• 04:27 — Map Claude’s internal model tiers: Opus, Sonnet, and Haiku aliases are redirected to provider models.
• 05:45 — Follow the full startup flow: the shell loads keys and path, the launcher builds the provider environment, and Claude Code also reads shared settings.
• 06:16 — Verify the provider: /status shows the active base URL and model; Ron treats provider billing or usage as the stronger check.
• 06:47 — Native tool or Claude harness?: Ron closes with the decision that determines whether this setup is worth maintaining.

Useful quotes

“the key here is stored in plain text JSON.” — Ron, source video gG6qY9fnb7w, 00:57

“And what each of these launcher does is they perform three steps.” — Ron, source video gG6qY9fnb7w, 03:20

“anything in the settings.json JSON applies to every provider” — Ron, source video gG6qY9fnb7w, 05:39

“if they have a native IDE, I would just go for it.” — Ron, source video gG6qY9fnb7w, 07:22

The setup architecture

A shell profile is the file your shell loads to establish environment variables and command paths. Ron stores the provider keys there and adds the directory containing his launcher scripts to the path. He warns viewers to identify the active shell first: the relevant file may be the Bash profile, the Zsh profile, or another matching profile. (source video gG6qY9fnb7w, 02:09; 02:18; 02:30)

A launcher script is a small provider-specific entry point. Ron’s launchers do not contain the key value. They expect a named environment variable from the shell profile, stop with a clear message when it is missing, export the provider-specific values, and then start Claude Code. This lets him invoke a MiniMax launcher or a GLM launcher by name instead of editing JSON between sessions. (source video gG6qY9fnb7w, 01:15; 02:56; 03:20)

The video describes GLM, MiniMax, LongCat, Qwen, and Kimi endpoints as compatible with the API format Claude Code expects. Claude Code reads the exported values at startup, so the launcher can redirect the harness to the chosen endpoint for that process. (source video gG6qY9fnb7w, 03:46; 04:00)

Configuration layer	Put here	Keep out	Check
Shell profile	Provider API keys and the launcher directory on the path. (source video gG6qY9fnb7w, 02:04; 02:50)	Provider keys should not be copied into each launcher. (source video gG6qY9fnb7w, 02:56)	Confirm the matching profile is the one your shell loads. (source video gG6qY9fnb7w, 02:18)
Provider launcher	Missing-key check, provider endpoint variables, model-tier overrides, and the Claude Code start action. (source video gG6qY9fnb7w, 03:20; 04:15)	Shared preferences that should follow every provider. (source video gG6qY9fnb7w, 05:37)	Run the provider-specific launcher by name. (source video gG6qY9fnb7w, 03:13)
Claude settings	Shared configuration such as theme and verbosity. (source video gG6qY9fnb7w, 05:10; 05:41)	Old provider key, token, and base-URL entries after launchers work. (source video gG6qY9fnb7w, 06:32)	Check that a provider switch does not change the shared preferences. (source video gG6qY9fnb7w, 05:37)

Model-tier mapping without guesswork

Claude Code exposes internal Opus, Sonnet, and Haiku tiers. A third-party launcher needs to map those aliases to models the selected provider exposes. In Ron’s example, GLM’s Opus slot points to GLM 5.2; Sonnet can point to 5.2 or 5.1; and Haiku points to GLM 4.7. For the LongCat setup shown, all three slots point to LongCat 2.0 because Ron says that was the provider’s only model at filming. (source video gG6qY9fnb7w, 04:27; 04:43; 05:02)

Treat those mappings as a dated example, not a permanent compatibility table. The transcript does not preserve the full launcher code, exact environment-variable names, provider base URLs, or API-key variable names. This companion therefore does not manufacture a copy-paste script. Use the provider-specific values visible in the source video and verify them against the documentation available when you configure the machine.

Operator checklist

1. Identify the shell profile your terminal actually loads. Do not assume the Bash file when the machine uses another shell. (source video gG6qY9fnb7w, 02:09; 02:18)
2. Place each provider key in that profile and expose the launcher directory on the path. Keep key values out of the launcher files. (source video gG6qY9fnb7w, 02:30; 02:50; 02:56)
3. Create one launcher per provider. Give each one its own required-key check, provider values, and model-tier mapping. (source video gG6qY9fnb7w, 03:20; 04:15)
4. Leave only genuinely shared preferences in Claude settings. Ron’s rule is simple: anything there applies across providers. (source video gG6qY9fnb7w, 05:10; 05:37)
5. Verify after every launcher change. Inspect /status, then use the provider’s usage or billing view to confirm which model handled inference. (source video gG6qY9fnb7w, 06:16; 06:22)
6. Remove the old provider entries only after the new flow works. The cleanup step comes after the shell profile and launchers are in place. (source video gG6qY9fnb7w, 06:32)

One security boundary matters: this reorganises where the transcript says the keys live; it does not claim to encrypt them or replace a secrets manager. Ron explicitly says the shell profile contains multiple sensitive API keys. The supported conclusion is that the launchers stay key-free and the shared Claude settings stop carrying provider credentials—not that the keys no longer exist in a readable file. (source video gG6qY9fnb7w, 02:30; 02:56)

What changed since this video

The video was published July 3, 2026. This companion was source-checked on July 18, 2026 against the saved full transcript and timestamp segments. No outside Claude Code release note, provider documentation, pricing page, endpoint test, or native-tool availability check was added. The model names, endpoint compatibility, coding-tool availability, and relative-cost comments above are therefore a dated record of Ron’s setup—not confirmation of product state on July 18. Re-check the exact variables, endpoints, model identifiers, and billing terms before using this pattern now.

Related

• Coding with Claude Code: understand the harness and verification loop
• The Anthropic family: how Opus, Sonnet, and Haiku tiers differ
• Cost-efficient models: choose an execution tier by workload
• Performance, model routing, and cost
• Watch the source video on YouTube