把 Cursor 指向你自己的 OpenAI-compatible 端點，歸結為三件必須對齊的事：端點地址（包括/v1路徑）；端點接受的 key；以及該端點上確實存在的 model ID。配置本身很小，之後幾乎每一次失敗都是這三者之一對不上。本指南覆蓋 Cursor 特有的配置、與訂閱並用時實際會改變什麼、常見錯誤的排查表，以及一輪五項驗證，能在你提任何工單之前解決大部分疑問。
三件必須對齊的事
先把這三個值寫下來，因為本文大部分內容都在講它們如何彼此漂移。
端點。對 String AI 來說是https://www.string.ink/v1。/v1字尾是地址的一部分，在不該加的地方加上它、或在該保留的地方丟掉它，都是經典的 404 製造方式。出現 404 時，第一件事就是把這個字串和設定欄位裡的值逐字元念出來對照。
Key。從你賬號頁面獲取的平臺 key。所有 key 材料都不要進截圖和聊天；本指南唯一使用的佔位符是你本地替換掉的YOUR_API_KEY風格文本。
Model ID。你輸入的任何模型名，都必須在端點上此刻真實存在，而不是存在於你對它的記憶裡。平臺的模型列表端點GET /v1/models，是即時的清單，文件示例裡包含像gpt-6-astra、gpt-5.6-luna和claude-opus-4-8這樣的 ID。
Cursor 是需要同樣處理方式的工具之一；如果你想先看多工具總覽，用一個 key 打通編碼工具指南覆蓋了共同的部分，本文只談 Cursor。
Cursor 配置：API key 設定與 Override OpenAI Base URL
Cursor 把憑據儲存在編輯器的模型設定裡。平臺的文件按欄位級別走了一遍 Cursor 的流程：點左下角的設定圖示，選擇Models側邊欄項，展開API Keys區域，把你的 key 填進OpenAI API Key欄位。然後開啟Override OpenAI Base URL開關，並輸入https://www.string.ink/v1到它下面的欄位裡。儲存之後，端點的模型就在 Cursor 裡可用了。
如果這是你第一次在 Cursor 裡配置自定義 API key，Cursor 自己的Bring your own API key頁面上有幾條機制值得在判斷結果之前先了解。自定義 key 只作用於 chat 模型；Tab 補全無論如何都繼續使用 Cursor 內建的模型。如果 key 無效或被廠商拒絕，使用該廠商的請求會一直失敗，直到你更新或移除這個 key，所以一次失敗的測試本身就是一個數據點。key 也不儲存在 Cursor 的伺服器上：請求會經過 Cursor 的基礎設施做 prompt 構建，key 隨每次請求傳輸。這種路由模型有一個實際後果值得早點記住，因為它能解釋好幾個令人困惑的症狀：你的端點必須能從公網訪問，而不只是從你的機器訪問。像 String AI 這樣的託管平臺端點天然滿足這一點；本地筆記本上的伺服器則不行，除非你做隧道。
儲存之後，在新的對話裡測試，而不是複用舊對話；如果第一次嘗試仍然表現得像之前的配置，先重啟一次編輯器，再開始改值。全新會話讀取配置最可靠；這個習慣只花幾秒鐘，卻能省掉一整輪方向錯誤的除錯。
與 Cursor 訂閱並用
自帶端點並不要求放棄 Cursor 的訂閱，兩者可以共存，但有一些約束你應當理解，而不是撞上才知道。
訂閱這一側繼續提供產品層體驗和 Cursor 自己的模型目錄。端點這一側提供目錄之外的模型選擇、落在你自己平臺賬號上的用量，以及可以在整個團隊裡保持一致的配置。實際變化是：只有 chat 模型使用你的 key，Tab 仍用內建模型，而且某些套餐級別的計量可能仍會識別用你自己 key 發出的請求（取決於套餐），所以要查官方頁面，確認你的套餐裡自定義 key 與包含額度之間的關係。那一頁還明確寫了另一個邊界：使用自己的 key 時，Cursor 的零資料留存策略不適用；資料處理遵循你所配置的廠商。企業團隊還可以在團隊看板上完全禁止個人 API key，所以在一個賬號上可用的設定，在另一個賬號上可能被管理策略隱藏掉。
要留意的摩擦不在任何一方有錯，而在於多種配置共存時的優先順序混亂：訂閱登入、廠商 key、端點覆蓋同時存在。把這種共存當成一組需要追蹤的開關，而不是一場比賽；每個開關各有職責，你的職責是知道哪個是開啟的。每臺機器保持一個事實來源，記錄哪個在哪裡生效，當你之後輪換 key 或把整套配置搬到別處時，把廠商切換演示和本文放在一起看。
錯誤排查：從 401 到 model not found
下面的錯誤覆蓋了幾乎所有的第一天失敗。讀症狀、查層級、應用修復。
| 症狀 | 層級 | 修復 |
| --- | --- | --- |
| 401 unauthorized | Key | 從賬號頁面重新完整複製 key 到 OpenAI API Key 欄位；確認你改的是你以為的那個欄位；被吊銷或被截斷的 key 正是這樣失敗的 |
| 每個請求都 404 not found | 路徑 | base URL 必須是https://www.string.ink/v1，並保留/v1路徑；在動任何別的地方之前，先核對你貼上的確切字串 |
| Cursor 報告 model was not found | 模型 | 你的模型名與端點上即時的 ID 不匹配；執行GET /v1/models並精確複製名稱；Cursor 自己的可用模型頁面也定義了在其目錄裡“模型不可用”意味著什麼 |
| Connection refused 或超時 | 網路 | 端點必須能從 Cursor 的伺服器公網訪問；檢查公司出網規則和代理，並注意即使 key 有效，廠商也可能封鎖某些地區，正如 Cursor 的地區參考所描述的那樣 |
| 請求能用但某些行為不同 | 協議 | 客戶端與端點之間在 streaming 和 tool calling 上的差異是一類已知的不匹配；在怪 Cursor 之前，先對端點跑一遍相容性清單 |
所有行之上有一條元規則：一次只改一個欄位。這張表之所以有用，是因為每個層級失敗時都有獨特的簽名，而只有在你自上次測試以來沒有改過三樣東西時，這個簽名才保持可讀。寫下你改了哪個欄位、症狀是什麼；改過 base URL 之後的 404 和近期沒做任何改動的 404 是兩個不同的故事，即使它們看起來一模一樣。
一輪五項驗證
任何改動之後，按順序做這些。每一項隔離一個層級，所以失敗會告訴你該往哪裡看。
- 列出模型。在終端裡用你的 key 呼叫
GET /v1/models，確認你打算用的 ID 存在，且拼寫與端點報告完全一致。 - 發一次最小呼叫。從終端發一個小的 chat completion，和五步快速上手一樣的紀律，確認用你的 key 和端點是能拿回響應的。
- 回到 Cursor。開一個新對話，選擇模型，發一個真實請求。如果第二步成功而這一步失敗，問題在編輯器配置，不在端點；如果兩者都失敗，問題在端點或 key。
- 檢查用量落在哪裡。確認請求出現在你平臺賬號和你這個 key 名下的用量記錄裡，這樣你就知道沒有任何東西在悄悄用別人的憑據。
- 給配置拍個快照。記錄你改了哪些欄位、它們現在是什麼值（去掉金鑰本身）。有這份快照，下一次改動才是回滾，而不是重建。
先終端、後編輯器，這個順序能把除錯時間減半：它在你花任何力氣之前，就把每次失敗分成“編輯器之前”和“編輯器之內”。
接下來看什麼
- 選擇在這套配置背後放什麼。 按約束選模型是上面模型名那一步的決策框架。
- 已經連上了？上面連結的支柱指南、快速上手和清單，覆蓋了從第一次呼叫到驗證完成的完整路徑。
先讓三個值對齊，在終端裡驗證，讓編輯器做最後一公里，而不是第一個嫌疑人。