一個 API Key 搞定 Codex CLI、Claude Code 和 Cursor：2026 配置指南

同時配置 Codex CLI、Claude Code、Cursor 和一個終端助手，往往意味著要管理四套整合：建立四個金鑰、在四個地方貼上端點、維護四份逐漸彼此偏離的設定。而用一個 API key 服務多個 AI 模型、由同一個 OpenAI 相容端點提供，可以把其中大部分工作省掉。每個工具仍保留自己的配置檔案，但各項取值不再因工具而異：OpenAI 風格客戶端共用一個 base URL，Claude Code 用一個入口，金鑰也只需輪換一個。

本文以 String AI 的端點為例，逐一梳理四個配置介面：端點契約、最常讓配置失敗的三類錯誤，以及在把任何 agent 指向你的程式碼之前應當執行的驗證流程。

為什麼四個工具會變成四套整合

這種摩擦很少體現在模型跑分上，而是體現在上手文件裡：註冊賬號、生成金鑰、找到設定介面、貼上地址、重啟客戶端，然後指望模型名稱正好對得上。等到金鑰需要輪換時，要更新的清單又變長了。想試另一個模型時，又得逐個工具確認它是否跟得上。

每個程式設計工具都自帶一套認證流程，以及對模型位於何處的預設。有一段時間，這些預設都指向廠商自己的賬號。如今情況變了：Codex CLI 支援自定義 model provider，Claude Code 把閘道器配置視為一等公民式的工作流，Cursor 提供了 base URL 覆蓋選項，而 CC Switch 這類工具負責協調由此產生的各項設定。共享的訪問層如今已是常規配置，真正的功夫在於弄清楚每個工具會讀取哪些欄位。

一個 API key 服務多個 AI 模型背後的契約

工具與 OpenAI 相容端點通訊時，依賴的是一份不大的契約：

• 認證。每個請求都在 Authorization 頭裡攜帶 bearer token。只要工具能出示它，一個金鑰就能覆蓋該工具。
• /v1 下的路由。Chat completions 負責對話，/v1/models 處的模型列表則報告該金鑰能訪問什麼。這個路由同時也可用作連線性檢查。
• 流式輸出。當 stream 設為 true 時，端點返回 server-sent events，請求應攜帶 Accept: text/event-stream。CLI 工具藉此在答案到達時逐段顯示。
• 工具呼叫。Agent 風格的客戶端會發送工具定義，並對響應中的結構化呼叫採取動作。缺少工具呼叫支援時，agent 可以聊天，但無法可靠地編輯檔案或執行命令。

有一個細節決定了後文的一切：客戶端說的並不都是這份契約的同一方言。有些期望經典的 chat completions 形式；Codex CLI 則圍繞 Responses API 構建，並用 wire_api = "responses" 宣告這一點。端點必須提供客戶端所傳送的那種方言，所以“相容所有工具”這句話值得從兩個方向分別審視。

String AI 的文件給出兩種入口形式：面向 OpenAI 風格客戶端的 OpenAI 相容 base URL https://www.string.ink/v1，以及面向 Claude Code 閘道器變數的站點根地址 https://www.string.ink（不帶 /v1 字尾）。除對話之外，文件列出的介面還包括文本與視覺輸入、影像生成與編輯，以及模型列表，因此一個金鑰的適用範圍超出本文這四個工具。

Codex CLI：在 config.toml 中配置自定義 model provider

Codex CLI 與 VS Code 的 Codex 擴充套件讀取的是同一個檔案：~/.codex/config.toml。配置分兩部分：描述端點的 provider 塊，以及選定 provider 與 model 的若干行。

model_provider = "OpenAI"
model = "gpt-6-astra"

[model_providers.OpenAI]
name = "OpenAI"
base_url = "https://www.string.ink/v1"
wire_api = "responses"
requires_openai_auth = true

model_provider 指定 Codex 應使用哪個 provider。在 provider 塊內，base_url 是端點，wire_api = "responses" 宣告協議，requires_openai_auth = true 表示該 provider 使用 OpenAI 風格的憑據認證。兩處的 provider 名稱要保持一致；Codex 保留了幾個內建 ID，其中包含小寫的 openai，這正是該塊使用 OpenAI 的原因。 Codex 配置參考文件記錄了此處展示的每一個欄位。

憑據與配置檔案放在一起，位於 ~/.codex/auth.json：

{
  "OPENAI_API_KEY": "YOUR_STRING_AI_KEY"
}

儲存後重啟 Codex 或你的編輯器。平臺文件列出這條路徑上可用的 model ID 為 gpt-6-astra、gpt-5.6-sol 和 gpt-5.6-luna，並提供一個用於 Windows PowerShell 的一鍵指令碼，替你寫好這兩個檔案。還有一條遷移提示：如果你此前通過 OAuth 會話登入，舊對話可能不會出現在新 provider 下，直到你執行隨附的遷移指令碼為止，該指令碼支援先做 dry run。

自定義 provider 的逐欄位參考（包括 wire_api 規則和重試預設值）見自定義 provider 指南。

Claude Code：ANTHROPIC_BASE_URL 與一對憑據變數

Claude Code 說的是 Anthropic 的協議而非 OpenAI 的協議，因此讀取的是另一組變數：

export ANTHROPIC_BASE_URL="https://www.string.ink"
export ANTHROPIC_AUTH_TOKEN="YOUR_STRING_AI_KEY"

注意缺了什麼：/v1 字尾。本文中每個 OpenAI 風格的欄位都以 /v1 結尾；這個欄位止於根地址，因為 Claude Code 會在你宣告的 base URL 之後自行追加路徑。

憑據變數同樣需要謹慎對待。 Anthropic 的閘道器文件區分了 ANTHROPIC_AUTH_TOKEN 與 ANTHROPIC_API_KEY：前者把金鑰作為 bearer token 放在 Authorization 頭中傳送，後者則放在 x-api-key 頭中。用錯變數會把憑據送到對方並不讀取的頭裡，表現出來的症狀就是 401。String AI 的文件指引 Claude Code 使用者使用 ANTHROPIC_AUTH_TOKEN。

平臺文件中有兩點實用提示。生成金鑰時要在 Claude API 分組中建立；其他分組的金鑰無法通過 Claude API 通道連線。另外，當這些變數由 CC Switch 管理時，同一頁面還會把 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 設為 1，把 CLAUDE_CODE_ATTRIBUTION_HEADER 設為 0。

啟動後，在 Claude Code 內執行 /status。設定閘道器地址後，狀態檢視會顯示 Anthropic base URL，並給出當前生效的憑據來源。如果顯示的是 ANTHROPIC_AUTH_TOKEN，說明起作用的是閘道器憑據，而不是殘留的登入狀態。

CC Switch：為整個工具箱配置一個 Universal Provider

CC Switch 是一個桌面應用，可在一處集中管理 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw、Hermes 等工具的 provider 設定與會話。端點只需配置一次，之後把工具切換過去即可。

相關部分是 Universal Provider 標籤頁。新增 provider 需要填四項：

• Name：String AI，或任何你日後能認出的名字
• Base URL：https://www.string.ink/v1
• API Key：你的 String AI 金鑰
• Default model：gpt-6-astra

執行內建的 Health Check，只有通過之後再遷移你的工具。不需要手工編輯任何檔案，這是四個配置介面中最不容易出錯的一個。有一條注意事項全程適用：大多數工具在啟動時讀取 provider 設定，因此切換後要重啟終端或 CLI。

Cursor：開啟 OpenAI base URL 覆蓋開關

在 Cursor 中開啟設定介面（齒輪圖示），選擇 Models，展開 API Keys 部分。把金鑰貼上到 OpenAI API Key 欄位，開啟 Override OpenAI Base URL，並填入 https://www.string.ink/v1。這個覆蓋開關正是常被跳過的一步；不開啟它，金鑰只是躺在設定裡，Cursor 仍舊呼叫它的預設端點。 Cursor 的文件描述了這些相同的欄位。

model ID 必須與平臺列出的寫法完全一致：請求帶著你輸入的字串離開你的機器，對不上就返回 model-not-found，而不會給出有用的提示。

三個會讓配置失效的錯誤

大多數配置失敗都能追溯到下列之一。

1. /v1 約定並非通用。 OpenAI 風格的欄位（Codex 的 provider 塊、CC Switch 的 Universal Provider、Cursor 的覆蓋項）使用 https://www.string.ink/v1。Claude Code 的 ANTHROPIC_BASE_URL 使用不帶字尾的站點根地址。客戶端會在你給出的地址後自行追加路徑段，所以用錯約定的表現是 404，或者是一個讓你跑去排查金鑰而非 URL 的認證錯誤。記住這一對就夠了：OpenAI 形狀的欄位用 /v1，Claude Code 用裸根地址。

2. 憑據變數不能互換。 API key 與 auth token 在 Claude Code 裡是兩個不同的變數，而 Codex 從 auth.json 而不是 config.toml 讀取金鑰。存在多個來源時，要清楚哪一個優先。Anthropic 的文件指出，當 shell 匯出與設定檔案中的 env 塊設定同一變數時，以設定檔案中的值為準；並且閘道器憑據優先於已儲存的登入。平臺文件提供的 Codex 安裝指令碼給出了更友好的承諾：若存在 STRING_AI_API_KEY 變數則優先使用，並有意忽略其他工具遺留的 OPENAI_API_KEY，這樣過期的金鑰不會悄悄接管。一次只改一個來源，並重啟客戶端。如果你為其他軟體保留了 OPENAI_API_KEY 匯出，不要以為 Codex 會採用它；在這套配置裡，金鑰位於 auth.json。

3. model ID 是精確字串。平臺文件使用的識別符號形如 gpt-6-astra、gpt-5.6-luna 和 claude-opus-4-8。你配置的內容必須與平臺當前的列表完全一致。一個筆誤，或從其他 provider 借來的名字，都會返回 model-not-found，那是字串不匹配，而不是端點壞了。

從小處驗證，再把故障分成兩類

在任何 agent 觸碰你的程式碼庫之前，先在 HTTP 層發現問題。平臺文件建議從 models 路由開始：

curl https://www.string.ink/v1/models \
  -H "Authorization: Bearer YOUR_STRING_AI_KEY"

返回 object: "list" 和 data 陣列的響應一次說明三件事：金鑰有效、base URL 正確、網路通路暢通。此時關於你的編輯器還什麼都沒被證明，這正是重點；一旦這一層通過，後續的失敗幾乎必定屬於客戶端配置。再做一次最小的 chat completion 是合理的第二步。

對 Claude Code 而言，對應的做法是前面說過的 /status 檢視，外加一次測試 prompt；Anthropic 的文件裡包含一個針對閘道器的單 token 請求，用於相同目的。

如果仍然失敗，先分類，再動手：

• 401：憑據被拒絕。檢查客戶端傳送的是哪個變數、金鑰所屬分組、是否有設定檔案覆蓋了你的 shell 匯出，以及客戶端是否重啟過。
• model-not-found：認證通過了，ID 沒通過。對照模型列表，而不是猜拼寫。
• 協議類錯誤，例如流始終不開始、工具呼叫始終不到達：客戶端與端點對前文所述的方言理解不一致。先檢查客戶端的協議設定，再看平臺文件中該工具的頁面。

這樣分類之後，配置問題留在客戶端一側，契約問題則歸端點運營方。

共享端點方案的邊界

兩條邊界讓這套說法站得住。第一，相容性是客戶端與端點合在一起的屬性，不是一句口號。一個說端點並不提供的協議的工具，不會因為填了 base URL 欄位就得救，這正是 Claude Code 有獨立入口、Codex 要宣告 wire protocol 的原因。在加第五個工具之前，先確認它的協議出現在平臺的工具列表中。

第二，客戶端配置是會隨版本變化的軟體。欄位名會挪位置，介面會改版，所以要把平臺文件與各工具的官方文件當作即時參考；本文只用來把握配置的整體形狀：一個金鑰、兩套 URL 約定、一個驗證閉環。

先從一個金鑰開始，再逐個遷移工具

避免返工的次序是：建立金鑰，如果清單上有 Claude Code，記得選 Claude API 分組。先跑一次模型檢查。配置你最常用的那個工具，用真實任務驗證，再按同樣順序處理其餘工具。在團隊 wiki 裡留一段簡短記錄，寫明兩套 URL 約定以及金鑰存放的位置；這些細節否則會讓下一個人搭進去一個下午。

相關閱讀

• 別再讓每個 AI 模型什麼都做：把調研、寫作和審閱分派給不同模型，而不額外增加協調工作。
• 開發者文章：該平臺的配置指南與整合說明。
• 下載：桌面應用與啟動器的安裝包。
• 常見問題：賬號層面的問題，包括金鑰分組。