Codex มาพร้อมกับโมเดล OpenAI โดยค่าเริ่มต้น แต่ก็ไม่ได้จำกัดคุณอยู่แค่โมเดลเหล่านั้น CLI มีโหมด OSS ในตัวสำหรับรันไทม์ในเครื่อง เช่น Ollama และ LM Studio รวมถึงระบบผู้ให้บริการแบบกำหนดเองที่ชี้ให้เอเจนต์ไปที่ปลายทางที่เข้ากันได้ซึ่งคุณกำหนดไว้ในไฟล์ TOML นั่นหมายความว่าคุณสามารถเรียกใช้ gpt-oss บนแล็ปท็อปของคุณ ขับเคลื่อน Codex ด้วย DeepSeek หรือ Qwen API ที่โฮสต์ไว้ หรือสลับไปมาระหว่างผู้ให้บริการตามแต่ละโปรเจกต์ได้
คู่มือนี้จะอธิบายการตั้งค่าทั้งหมด: โหมด OSS ทำอะไรได้บ้าง คีย์การกำหนดค่าที่แน่นอน สูตรสำหรับแต่ละโมเดล และข้อแลกเปลี่ยนที่คุณยอมรับเมื่อคุณสลับโมเดลของ OpenAI ทุกสิ่งที่นี่มาจาก เอกสารการกำหนดค่าขั้นสูงของ Codex อย่างเป็นทางการ หากเอกสารมีความคลุมเครือ ฉันจะระบุไว้แทนที่จะเดา
ข้อควรทราบก่อนที่เราจะเริ่มต้น เมื่อโมเดลของคุณทำงานอยู่ใน Codex โมเดลนั้นเป็นเพียงครึ่งหนึ่งของขั้นตอนการทำงาน อีกครึ่งหนึ่งคือการตรวจสอบ API ที่เอเจนต์ของคุณสร้างและเรียกใช้ นั่นคือที่มาของ Apidog และเราจะพูดถึงการจับคู่กันใกล้ตอนท้าย
สรุป (TL;DR)
โหมด Codex OSS เป็นฟีเจอร์ของ CLI เรียกใช้ codex --oss และ Codex จะสื่อสารกับเซิร์ฟเวอร์ Ollama หรือ LM Studio ในเครื่องแทน OpenAI ตั้งค่า oss_provider = "ollama" ใน ~/.codex/config.toml เพื่อให้เป็นค่าเริ่มต้น และส่ง -m <model> เพื่อเลือกว่าโมเดลในเครื่องใดจะทำงาน สำหรับโมเดลโอเพนซอร์สที่โฮสต์ไว้ (DeepSeek, Qwen, GLM ผ่าน API ของพวกเขา) ให้กำหนดบล็อก [model_providers.<id>] ที่มี base_url และ env_key จากนั้นเลือกด้วย model_provider ข้อควรจำ: การอ้างอิงการกำหนดค่าปัจจุบันระบุว่า responses เป็นค่า wire_api ที่รองรับเพียงค่าเดียว ดังนั้นปลายทางของคุณจำเป็นต้องรองรับโปรโตคอล Responses API
โหมด OSS คืออะไร
โหมด OSS เป็นทางลัดของ Codex สำหรับการเรียกใช้กับเซิร์ฟเวอร์โมเดลโอเพนซอร์สในเครื่อง เอกสารอธิบายผู้ให้บริการในเครื่องที่รองรับสองราย:
- Ollama, รันไทม์โมเดลในเครื่องยอดนิยม
- LM Studio, แอปเดสก์ท็อปพร้อมเซิร์ฟเวอร์ในเครื่องในตัว
คุณเปิดใช้งานด้วยแฟล็ก --oss จาก การอ้างอิงคำสั่งนักพัฒนาของ Codex:
--oss: ใช้ผู้ให้บริการโมเดลโอเพนซอร์สในเครื่อง Codex ใช้--local-provider,oss_providerที่คุณกำหนดค่าไว้ หรือแจ้งให้คุณเลือกระหว่าง LM Studio และ Ollama
มีแฟล็กคู่หูคือ --local-provider ซึ่งรับค่า lmstudio หรือ ollama และจะแทนที่ค่าเริ่มต้นของคุณสำหรับการรันเพียงครั้งเดียว หากคุณไม่ตั้งค่าแฟล็กหรือค่าเริ่มต้นในการกำหนดค่า CLI แบบโต้ตอบจะแจ้งให้คุณเลือก ส่วน codex exec แบบไม่โต้ตอบจะไม่แจ้ง; มันจะออกพร้อมข้อผิดพลาด ดังนั้นสำหรับสคริปต์และ CI ควรกำหนดผู้ให้บริการอย่างชัดเจนเสมอ
ข้อสังเกตเกี่ยวกับพื้นผิว: เอกสารครอบคลุมโหมด OSS และผู้ให้บริการแบบกำหนดเองภายใต้ระบบ config.toml ของ CLI ส่วนส่วนขยาย IDE และ Codex cloud ไม่ได้กล่าวถึงว่ารองรับผู้ให้บริการในเครื่องในเอกสารการกำหนดค่าใดๆ [ตรวจสอบ: ว่าส่วนขยาย Codex IDE อ่าน model_providers จาก config.toml เหมือนกับที่ CLI ทำหรือไม่; เอกสารไม่ได้ระบุไว้ทั้งสองทาง] ถือว่านี่เป็นขั้นตอนการทำงานของ CLI จนกว่า OpenAI จะระบุเป็นอย่างอื่น
ทำไมต้องเรียกใช้โมเดลโอเพนซอร์สภายใน Codex
คำถามที่สมเหตุสมผล เนื่องจาก Codex เป็นเอเจนต์ของ OpenAI เอง มีเหตุผลที่แท้จริงไม่กี่ข้อ:
- การควบคุมค่าใช้จ่าย การอนุมานในเครื่องผ่าน Ollama ไม่มีค่าใช้จ่ายต่อโทเค็น หากคุณใช้ขีดจำกัดการใช้งานในเซสชันเอเจนต์ที่ยาวนาน โมเดลในเครื่องจะจัดการงานหนักในขณะที่คุณบันทึกการเรียกใช้ที่โฮสต์ไว้สำหรับปัญหาที่ยาก
- ความเป็นส่วนตัวและการทำงานแบบ air-gapped โค้ดเบสบางส่วนไม่สามารถออกจากเครื่องได้ โมเดล Kimi, GLM หรือ gpt-oss ในเครื่องจะเก็บทุกโทเค็นไว้บนฮาร์ดแวร์ของคุณ คู่มือของเราในการ เรียกใช้ Kimi K3 ในเครื่อง ครอบคลุมสิ่งที่ต้องทำในทางปฏิบัติ
- ความชอบในโมเดล โมเดลแบบ open-weight ได้ปิดช่องว่างการเขียนโค้ดส่วนใหญ่ DeepSeek และ Qwen API ที่โฮสต์ไว้มีราคาที่ต่ำกว่า OpenAI ในขณะที่ให้คะแนนใกล้เคียงกันในการทดสอบประสิทธิภาพการเขียนโค้ด และคุณอาจจะชอบวิธีการเขียนโค้ดของโมเดลเฉพาะตัวใดตัวหนึ่ง
- โครงสร้างเอเจนต์เดียว, หลายโมเดล ประสบการณ์ผู้ใช้เทอร์มินัล การแยกแซนด์บ็อกซ์ และขั้นตอนการอนุมัติของ Codex นั้นดี การกำหนดค่าผู้ให้บริการช่วยให้คุณคงโครงสร้างนั้นไว้และสลับสมองได้
ที่อยู่ของการกำหนดค่า
Codex จัดเก็บสถานะภายใต้ CODEX_HOME ซึ่งมีค่าเริ่มต้นเป็น ~/.codex การกำหนดค่าระดับผู้ใช้ของคุณคือ ~/.codex/config.toml และ repo สามารถมีค่าที่ตั้งไว้ล่วงหน้าระดับโปรเจกต์ใน .codex/config.toml ทุกอย่างด้านล่างนี้จะอยู่ในหนึ่งในสองไฟล์นั้น
เริ่มต้นอย่างรวดเร็ว: Codex กับ Ollama
วิธีที่เร็วที่สุดในการใช้โมเดลโอเพนซอร์สใน Codex คือ Ollama
- ติดตั้ง Ollama จาก ollama.com และเริ่มทำงาน มันให้บริการ OpenAI-compatible API บนพอร์ต 11434
- ดึงโมเดล การเผยแพร่แบบ open-weight ของ OpenAI เองเป็นตัวเลือกแรกที่เป็นธรรมชาติ; หน้าไลบรารี gpt-oss มีเวอร์ชัน 20b และ 120b เราได้ครอบคลุมการตั้งค่าแบบสแตนด์อโลนไว้ใน วิธีเรียกใช้ gpt-oss โดยใช้ Ollama
ollama pull gpt-oss:20b
- เรียกใช้ Codex ในโหมด OSS และตั้งชื่อโมเดล:
codex --oss -m gpt-oss:20b
แฟล็ก -m/--model จะแทนที่โมเดลที่กำหนดค่าไว้ และเมื่อรวมกับ --oss จะเลือกโมเดลในเครื่องที่จะทำงาน สำหรับการใช้งานแบบไม่โต้ตอบ:
codex exec --oss --local-provider ollama -m gpt-oss:20b "add input validation to the signup route"
- ทำให้เป็นค่าเริ่มต้นเพื่อให้คุณสามารถละแฟล็กได้ ใน
~/.codex/config.toml:
# Default local provider used with `--oss`
oss_provider = "ollama" # or "lmstudio"
นั่นคือฟีเจอร์ทั้งหมดสำหรับโมเดลในเครื่อง ไม่มีคีย์ API ไม่มีบล็อกผู้ให้บริการแบบกำหนดเอง LM Studio ทำงานในลักษณะเดียวกัน: โหลดโมเดลในแอป เริ่มเซิร์ฟเวอร์ในเครื่อง และเรียกใช้ codex --oss --local-provider lmstudio ดู lmstudio.ai สำหรับการตั้งค่าเซิร์ฟเวอร์
ผู้ให้บริการแบบกำหนดเอง: ชี้ Codex ไปยังปลายทางที่เข้ากันได้
โหมด OSS ครอบคลุม Ollama และ LM Studio สำหรับส่วนที่เหลือ ไม่ว่าจะเป็น DeepSeek หรือ Qwen API ที่โฮสต์ไว้, พร็อกซี, เซิร์ฟเวอร์ vLLM บน LAN ของคุณ Codex ก็มีผู้ให้บริการโมเดลแบบกำหนดเอง เอกสารกำหนดผู้ให้บริการว่าเป็น “วิธีที่ Codex เชื่อมต่อกับโมเดล (URL พื้นฐาน, wire API, การยืนยันตัวตน, และหัวข้อ HTTP ที่เลือกได้)”
รูปแบบจากเอกสารอย่างเป็นทางการ:
model = "gpt-5.6-terra"
model_provider = "proxy"
[model_providers.proxy]
name = "OpenAI using LLM proxy"
base_url = "http://proxy.example.com"
env_key = "OPENAI_API_KEY"
[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"
[model_providers.mistral]
name = "Mistral"
base_url = "https://api.mistral.ai/v1"
env_key = "MISTRAL_API_KEY"
คีย์ที่สำคัญ:
| คีย์ | สิ่งที่ทำ |
|---|---|
model_provider |
ID ผู้ให้บริการที่ Codex ใช้ (ค่าเริ่มต้น: openai) |
model |
ชื่อโมเดลที่ส่งไปยังผู้ให้บริการนั้น |
name |
ชื่อที่แสดงสำหรับผู้ให้บริการ |
base_url |
URL พื้นฐานของ API |
env_key |
ตัวแปรสภาพแวดล้อมที่เก็บคีย์ API |
wire_api |
โปรโตคอลที่ผู้ให้บริการใช้ |
query_params |
พารามิเตอร์การสอบถามเพิ่มเติมที่แนบท้ายคำขอ |
http_headers / env_http_headers |
หัวข้อคงที่ หรือหัวข้อที่เติมจากตัวแปรสภาพแวดล้อม |
การปรับแต่งเครือข่ายต่อผู้ให้บริการก็มีให้ด้วย: request_max_retries (ค่าเริ่มต้น 4), stream_max_retries (ค่าเริ่มต้น 5), และ stream_idle_timeout_ms (ค่าเริ่มต้น 300000) ฮาร์ดแวร์ในเครื่องที่ทำงานช้าจะได้รับประโยชน์จากการตั้งค่า idle timeout ที่นานขึ้น เนื่องจากโมเดล 120b บนแล็ปท็อปสามารถอยู่เฉยๆ ได้นานระหว่างโทเค็น
กฎสองข้อที่เอกสารระบุไว้อย่างชัดเจน ประการแรก ID openai, ollama และ lmstudio เป็นชื่อที่สงวนไว้ คุณไม่สามารถแทนที่ผู้ให้บริการในตัวได้ หากต้องการเปลี่ยน URL พื้นฐานของผู้ให้บริการ OpenAI ในตัว ให้ตั้งค่า openai_base_url แทนการสร้าง [model_providers.openai] ประการที่สอง และข้อนี้มีผลต่อทุกสิ่ง: การอ้างอิงการกำหนดค่า ระบุว่าสำหรับ wire_api, “responses เป็นค่าที่รองรับเพียงค่าเดียว และเป็นค่าเริ่มต้นเมื่อละเว้น”
นั่นเป็นข้อจำกัดที่แท้จริง Codex เวอร์ชันก่อนหน้านี้ยอมรับ wire_api = "chat" สำหรับปลายทาง Chat Completions และหน้าภาพรวมโมเดลยังคงระบุว่าคุณสามารถชี้ Codex ไปยังผู้ให้บริการที่รองรับ “ทั้ง Chat Completions หรือ Responses APIs” การอ้างอิงและภาพรวมไม่สอดคล้องกัน [ตรวจสอบ: ว่า wire_api = "chat" ยังคงใช้งานได้ใน CLI เวอร์ชันปัจจุบันหรือไม่; การอ้างอิงการกำหนดค่าระบุว่ารองรับเฉพาะ responses ส่วนหน้าโมเดลบอกว่า chat ยังใช้งานได้ ทดสอบกับปลายทางที่รองรับเฉพาะ chat ก่อนเผยแพร่] หากรองรับเฉพาะ responses ผู้ให้บริการของคุณจำเป็นต้องมีปลายทาง Responses API ซึ่งเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ส่วนใหญ่ตอนนี้ก็มีให้ แต่ API ที่โฮสต์บางส่วนยังไม่มี
สูตรสำหรับแต่ละโมเดล
แต่ละสูตรด้านล่างคือบล็อกการกำหนดค่าพร้อมคำสั่งในการรัน ตั้งค่าตัวแปรสภาพแวดล้อมคีย์ API ก่อนเริ่มต้น
DeepSeek (API ที่โฮสต์)
DeepSeek ได้เพิ่มการรองรับ Responses API ควบคู่ไปกับ V4 Flash beta ซึ่งเป็นสิ่งที่ wire protocol ของ Codex ต้องการ เราได้ครอบคลุมการเปิดตัวนั้นใน DeepSeek V4 Flash, Responses API, และ Codex
model = "deepseek-chat"
model_provider = "deepseek"
[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"
export DEEPSEEK_API_KEY="sk-..."
codex
ตรวจสอบ เอกสาร DeepSeek API สำหรับ ID โมเดลปัจจุบัน [ตรวจสอบ: เส้นทาง base_url ที่ DeepSeek ระบุสำหรับการเข้าถึงโปรโตคอล Responses; เส้นทาง /v1 chat อาจแตกต่างจากเส้นทาง Responses]
Qwen (โฮสต์ผ่าน Model Studio)
Model Studio (DashScope) ของ Alibaba มีโหมดที่เข้ากันได้กับ OpenAI สำหรับตระกูล Qwen 3.8 ปลายทางในโหมดที่เข้ากันได้เคยมีรูปร่างแบบ Chat Completions มาก่อน [ตรวจสอบ: ว่าโหมดที่เข้ากันได้ของ DashScope ตอนนี้ให้บริการโปรโตคอล Responses หรือไม่; ถ้าไม่ สูตรนี้ขึ้นอยู่กับคำถาม wire_api = "chat" ข้างต้น]
model = "qwen3.8-max"
model_provider = "qwen"
[model_providers.qwen]
name = "Qwen via Model Studio"
base_url = "https://dashscope-intl.aliyuncs.com/compatible-mode/v1"
env_key = "DASHSCOPE_API_KEY"
คู่มือ API ของ Qwen 3.8 ของเราครอบคลุมคีย์ ID โมเดล และราคาสำหรับเส้นทางที่โฮสต์ไว้
Kimi, GLM และโมเดล open weights อื่นๆ (ในเครื่องผ่าน Ollama)
สิ่งใดก็ตามที่คุณสามารถดึงเข้าสู่ Ollama จะทำงานผ่านโหมด OSS ธรรมดา ไม่จำเป็นต้องมีบล็อกผู้ให้บริการ:
ollama pull <model>
codex --oss -m <model>
นั่นครอบคลุม GLM และ Qwen open weights รวมถึง Kimi K3 หากฮาร์ดแวร์ของคุณรองรับ (โมเดล K3 มีขนาด 594 GB ที่ MXFP4 ดังนั้นคนส่วนใหญ่ควรอ่าน เรียกใช้ Kimi K3 ในเครื่อง ก่อนลอง) สำหรับเครื่องขนาดกลาง gpt-oss:20b หรือ Qwen coder build ที่ถูก quantized เป็นทางเลือกที่ใช้งานได้จริง
vLLM ที่โฮสต์เองหรือเซิร์ฟเวอร์ LAN
vLLM หรือเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ที่คล้ายกันบนเครื่องอื่นเป็นผู้ให้บริการแบบกำหนดเอง ไม่ใช่โหมด OSS:
model_provider = "lan_vllm"
[model_providers.lan_vllm]
name = "vLLM on the workstation"
base_url = "http://192.168.1.50:8000/v1"
env_key = "VLLM_API_KEY"
โปรไฟล์: สลับสมองตามงาน
คุณไม่จำเป็นต้องเลือกการตั้งค่าเดียว โปรไฟล์ Codex คือไฟล์ TOML แยกต่างหากที่ ~/.codex/<profile-name>.config.toml ซึ่งซ้อนทับบนการกำหนดค่าพื้นฐานของคุณเมื่อคุณส่ง --profile โปรไฟล์โมเดลในเครื่องมีลักษณะดังนี้:
# ~/.codex/oss-local.config.toml
oss_provider = "ollama"
model = "gpt-oss:20b"
codex --profile oss-local
codex exec --profile oss-local "write unit tests for utils/dates.ts"
เก็บการกำหนดค่าเริ่มต้นของคุณไว้บนโมเดล OpenAI สำหรับการปรับโครงสร้างใหม่ที่ยาก และเรียกใช้ --profile oss-local สำหรับการแก้ไขข้อผิดพลาด การสร้างโครงสร้างการทดสอบ และการผ่านเอกสาร การแทนที่แบบครั้งเดียวก็ทำงานได้โดยไม่ต้องมีโปรไฟล์: codex -c model='"deepseek-chat"' -c model_provider='"deepseek"'
ข้อแลกเปลี่ยนกับโมเดล OpenAI
ซื่อสัตย์กับตัวเองเกี่ยวกับสิ่งที่คุณกำลังแลกเปลี่ยนไป:
- ความสามารถ gpt-oss:20b ไม่ใช่ gpt-5.6-terra โมเดลในเครื่องมักจะล้มเหลวบ่อยกว่าในการแก้ไขไฟล์หลายไฟล์ที่ยาวนาน และลูปเอเจนต์จะขยายจุดอ่อนของโมเดลเนื่องจากทุกขั้นตอนสร้างขึ้นจากขั้นตอนที่แล้ว
- ความเร็ว API ที่โฮสต์สามารถสตรีมได้อย่างรวดเร็ว โมเดลขนาดใหญ่ในเครื่องบนฮาร์ดแวร์ผู้บริโภคอาจช้าพอที่จะเปลี่ยนวิธีการทำงานของคุณ
- ความแม่นยำของเครื่องมือ พรอมต์และการเรียกใช้เครื่องมือของ Codex ได้รับการปรับแต่งมาสำหรับโมเดล OpenAI โมเดลโอเพนซอร์สมีความหลากหลายในความน่าเชื่อถือในการส่งการเรียกใช้เครื่องมือ และโปรโตคอล wire ที่รองรับเฉพาะ responses จะจำกัดปลายทางที่มีคุณสมบัติเหมาะสม
- พื้นที่การสนับสนุน โหมด OSS เป็นเส้นทาง CLI ที่มีเอกสารประกอบ แต่ผู้ให้บริการบุคคลที่สามเป็นความรับผิดชอบของคุณ: ID โมเดล, ขีดจำกัดอัตรา และความแปลกประหลาดของโปรโตคอลเป็นเรื่องระหว่างคุณกับผู้จำหน่าย
การแบ่งที่ใช้ได้จริง: โมเดลในเครื่องหรือโมเดลที่โฮสต์ราคาถูกสำหรับงานที่มีปริมาณมากและมีความเสี่ยงต่ำ โมเดลแนวหน้าสำหรับงานที่การรันที่ล้มเหลวทำให้คุณเสียเวลาช่วงบ่าย
ตรวจสอบ API ที่เอเจนต์ของคุณใช้งาน
ไม่ว่าโมเดลใดจะทำงานภายใน Codex ผลลัพธ์มักจะเป็นโค้ดที่เรียกใช้หรือกำหนด API และโมเดลโอเพนซอร์สจะสร้างข้อมูลที่ผิดพลาดเกี่ยวกับปลายทางและ schema บ่อยกว่าโมเดลแนวหน้า ตรวจจับสิ่งนั้นที่ชั้น API แทนที่จะรอให้เกิดในขั้นตอนการผลิต
Apidog ครอบคลุมด้านนั้นของเวิร์กโฟลว์ ชี้ Apidog MCP server ไปยังโปรเจกต์ของคุณ และเอเจนต์ Codex ของคุณสามารถอ่านข้อมูลจำเพาะ API ที่แท้จริงในขณะที่เขียนโค้ด แทนที่จะสร้างชื่อฟิลด์ขึ้นมาเอง จากนั้นใช้ Apidog CLI ภายใน Codex เพื่อให้เอเจนต์รันสถานการณ์การทดสอบของคุณจากเทอร์มินัลหลังจากการเปลี่ยนแปลงแต่ละครั้ง: มันแก้ไข มันทดสอบ คุณตรวจสอบความแตกต่างที่ผ่าน การวนซ้ำนั้นมีความสำคัญมากขึ้น ไม่ใช่น้อยลง เมื่อโมเดลที่เล็กกว่าเขียนโค้ด ดาวน์โหลด Apidog เพื่อเชื่อมต่อ; CLI และ MCP server ทำงานร่วมกับโมเดลใดๆ ที่คุณกำหนดค่าไว้
การแก้ไขปัญหา
codex execเกิดข้อผิดพลาดทันทีในโหมด OSS คุณไม่ได้ตั้งค่าผู้ให้บริการ การรันแบบไม่โต้ตอบจะไม่มีการแจ้งเตือน ดังนั้นให้ส่ง--local-provider ollamaหรือตั้งค่าoss_providerในการกำหนดค่า- การเชื่อมต่อถูกปฏิเสธบนพอร์ต 11434 Ollama ไม่ได้ทำงาน หรือถูกผูกไว้กับที่อยู่อื่น เริ่มแอปหรือ
ollama serveและยืนยันด้วยcurl http://localhost:11434/v1/models - 404 หรือข้อผิดพลาดโปรโตคอลจากผู้ให้บริการที่โฮสต์ไว้ รูปแบบ
base_urlไม่ถูกต้อง หรือปลายทางไม่รองรับโปรโตคอล Responses ตรวจสอบว่าผู้จำหน่ายมีเอกสารเกี่ยวกับเส้นทางที่เข้ากันได้กับ Responses หรือไม่ - การตรวจสอบสิทธิ์ล้มเหลว
env_keyตั้งชื่อตัวแปรสภาพแวดล้อม; Codex อ่านคีย์จากสภาพแวดล้อมเชลล์ของคุณเมื่อเริ่มต้น Export ในเชลล์เดียวกัน และจำไว้ว่า launchd หรือ CI shells อาจไม่โหลด dotfiles ของคุณ - สตรีมหยุดทำงานกลางคันในโมเดลในเครื่องที่ช้า เพิ่ม
stream_idle_timeout_msและstream_max_retriesในบล็อกผู้ให้บริการ - การแก้ไขการกำหนดค่าถูกละเว้น ตรวจสอบ
.codex/config.tomlระดับโปรเจกต์ที่แทนที่การกำหนดค่าผู้ใช้ของคุณ และจำไว้ว่าโปรไฟล์จะซ้อนทับบนทั้งสอง
คำถามที่พบบ่อย
โหมด Codex OSS ทำงานในส่วนขยาย IDE หรือ Codex cloud หรือไม่?
เอกสารระบุโหมด OSS และผู้ให้บริการแบบกำหนดเองว่าเป็นส่วนหนึ่งของระบบการกำหนดค่าของ CLI ส่วนการรองรับผู้ให้บริการในเครื่องสำหรับ IDE หรือคลาวด์ไม่ได้รับการบันทึกไว้ ดังนั้นให้ถือว่านี่เป็นฟีเจอร์ของ CLI [ตรวจสอบก่อนที่จะพึ่งพาการรองรับ IDE]
โมเดลใดทำงานได้ดีที่สุดกับ Codex ในโหมด OSS?
อะไรก็ตามที่ Ollama หรือ LM Studio สามารถให้บริการได้บนฮาร์ดแวร์ของคุณ gpt-oss:20b เป็นค่าเริ่มต้นที่ใช้งานง่าย ตัวเลือกการเขียนโค้ดแบบ open-weight ที่แข็งแกร่ง ได้แก่ ตระกูล Qwen 3.8 และ GLM; สำหรับโมเดลขนาดใหญ่เช่น Kimi K3 ให้ตรวจสอบการคำนวณฮาร์ดแวร์ใน คู่มือ Kimi K3 ในเครื่อง ของเราก่อน
ฉันสามารถใช้ OpenRouter หรือตัวรวมอื่นๆ กับ Codex ได้หรือไม่?
ตัวรวมใดๆ ที่เปิดเผยปลายทางที่เข้ากันได้จะเข้ากับรูปแบบ [model_providers.<id>]: ตั้งค่า base_url และ env_key จากนั้นเลือกด้วย model_provider คำถามที่เปิดอยู่คือโปรโตคอล: การอ้างอิงการกำหนดค่าระบุว่า responses เป็นค่า wire_api ที่รองรับเพียงค่าเดียว ดังนั้นให้ยืนยันว่าตัวรวมของคุณให้บริการ Responses API
ฉันจำเป็นต้องมีคีย์ OpenAI API เพื่อรัน Codex ด้วยโมเดลโอเพนซอร์สหรือไม่?
ไม่จำเป็นต้องใช้คีย์สำหรับโหมด OSS กับเซิร์ฟเวอร์ Ollama หรือ LM Studio ในเครื่อง ผู้ให้บริการโฮสต์แบบกำหนดเองใช้คีย์ของตนเองผ่าน env_key คุณยังคงต้องลงชื่อเข้าใช้ Codex ตามปกติสำหรับทุกสิ่งที่เกี่ยวข้องกับบริการของ OpenAI
ตั้งค่าที่เหมาะสมกับงาน gpt-oss ในเครื่องสำหรับลูปราคาถูก DeepSeek หรือ Qwen เมื่อคุณต้องการความเร็วที่โฮสต์ในราคาที่ต่ำกว่า และโมเดลแนวหน้าของ OpenAI เมื่อปัญหาซับซ้อน การกำหนดค่าของ Codex ทำให้ทั้งสามอยู่ห่างกันแค่แฟล็กเดียว และด้วย Apidog ที่จัดการการตรวจสอบฝั่ง API โมเดลจะกลายเป็นส่วนที่สลับเปลี่ยนได้แทนที่จะเป็นข้อผูกมัด