Codex'i Açık Kaynak Modellerle Nasıl Kullanılır (OSS Modu)

OpenAI Codex içinde açık kaynak modelleri çalıştırın. Tam OSS modu rehberi: Ollama ve LM Studio kurulumu, DeepSeek ve Qwen için özel sağlayıcı yapılandırması, artı ödünleşimler.

Ashley Innocent

Ashley Innocent

19 August 2026

Codex'i Açık Kaynak Modellerle Nasıl Kullanılır (OSS Modu)

Kurumsal İçin Apidog

Şirket İçi (On-Premises) Dağıtım

SSO ve RBAC

SOC 2 Uyumlu

Apidog Enterprise'ı Keşfedin

Codex varsayılan olarak OpenAI modelleriyle birlikte gelir, ancak sizi onlara kilitlemez. CLI, Ollama ve LM Studio gibi yerel çalışma zamanları için yerleşik bir OSS moduna sahiptir, ayrıca bir TOML dosyasında tanımladığınız herhangi bir uyumlu uç noktaya aracı işaret eden özel bir sağlayıcı sistemine sahiptir. Bu, dizüstü bilgisayarınızda gpt-oss'u çalıştırabileceğiniz, Codex'i barındırılan bir DeepSeek veya Qwen API'si ile sürebileceğiniz veya proje başına sağlayıcılar arasında geçiş yapabileceğiniz anlamına gelir.

Bu kılavuz, tüm kurulumu adım adım anlatır: OSS modunun ne işe yaradığı, tam yapılandırma anahtarları, modele özel tarifler ve OpenAI modellerini değiştirdiğinizde kabul ettiğiniz ödünleşimler. Buradaki her şey resmi Codex gelişmiş yapılandırma belgelerinden alınmıştır. Belgeler belirsiz olduğunda, tahmin etmek yerine bunu belirtirim.

Başlamadan önce bir not. Modeliniz Codex içinde çalışmaya başladıktan sonra, model iş akışının sadece yarısıdır. Diğer yarısı, aracınızın oluşturduğu ve çağırdığı API'leri doğrulamaktır. İşte Apidog burada devreye girer ve eşleştirmeyi sona doğru ele alacağız.

TL;DR

Codex OSS modu bir CLI özelliğidir. codex --oss komutunu çalıştırdığınızda Codex, OpenAI yerine yerel bir Ollama veya LM Studio sunucusuyla konuşur. Varsayılan yapmak için ~/.codex/config.toml içinde oss_provider = "ollama" ayarını yapın ve hangi yerel modelin çalışacağını seçmek için -m <model> parametresini geçin. Barındırılan açık kaynaklı modeller için (API'leri aracılığıyla DeepSeek, Qwen, GLM), base_url ve env_key içeren bir [model_providers.<id>] bloğu tanımlayın, ardından bunu model_provider ile seçin. Ancak: mevcut yapılandırma referansı, desteklenen tek wire_api değeri olarak responses'ı listeler, bu nedenle uç noktanızın Responses API protokolünü konuşması gerekir.

OSS modu nedir

OSS modu, Codex'in yerel açık kaynak model sunucularına karşı çalıştırma kısayoludur. Belgeler iki desteklenen yerel sağlayıcıyı açıklar:

Bunu --oss bayrağıyla etkinleştirirsiniz. Codex geliştirici komutları referansından:

--oss: Yerel bir açık kaynak model sağlayıcı kullanın. Codex, --local-provider, yapılandırılmış oss_provider'ınızı kullanır veya LM Studio ve Ollama arasında seçim yapmanız istenir.

--local-provider adında eşlik eden bir bayrak da vardır, bu lmstudio veya ollama alır ve tek bir çalıştırma için varsayılanınızı geçersiz kılar. Ne bir bayrak ne de bir yapılandırma varsayılanı ayarlamazsanız, etkileşimli CLI sizden seçim yapmanızı ister. Etkileşimli olmayan codex exec istemez; bir hatayla çıkar. Bu nedenle komut dosyaları ve CI için sağlayıcıyı her zaman açıkça ayarlayın.

Yüzeyler hakkında dürüst bir not: dokümantasyon, OSS modunu ve özel sağlayıcıları CLI'nin config.toml sistemi altında ele alır. IDE uzantısı ve Codex bulutu, yapılandırma belgelerinde hiçbir yerde yerel sağlayıcıları desteklediği belirtilmemiştir. [DOĞRULA: Codex IDE uzantısının model_providers'ı CLI ile aynı şekilde config.toml'dan okuyup okumadığı; belgeler bunu iki şekilde de belirtmez.] OpenAI aksini belgeleyene kadar bunu bir CLI iş akışı olarak değerlendirin.

Neden Codex içinde açık kaynaklı bir model çalıştırılmalı

Adil bir soru, Codex'in OpenAI'nin kendi ajanı olduğu düşünüldüğünde. Birkaç gerçek neden:

Yapılandırma nerede bulunur

Codex, varsayılan olarak ~/.codex olan CODEX_HOME altında durumunu saklar. Kullanıcı düzeyindeki yapılandırmanız ~/.codex/config.toml'dir ve bir depo, proje düzeyinde geçersiz kılmaları .codex/config.toml içinde taşıyabilir. Aşağıdaki her şey bu iki dosyadan birine gider.

Hızlı başlangıç: Ollama ile Codex

Codex'te açık kaynaklı bir modele giden en hızlı yol Ollama'dır.

  1. ollama.com adresinden Ollama'yı yükleyin ve başlatın. 11434 numaralı portta OpenAI uyumlu bir API sunar.
  2. Bir model çekin. OpenAI'nin kendi açık ağırlıklı sürümü doğal bir ilk tercihtir; gpt-oss kütüphane sayfası 20b ve 120b varyantlarına sahiptir. Bağımsız kurulumu Ollama kullanarak gpt-oss nasıl çalıştırılır makalemizde ele aldık.
ollama pull gpt-oss:20b
  1. Codex'i OSS modunda çalıştırın ve modeli adlandırın:
codex --oss -m gpt-oss:20b

-m/--model bayrağı yapılandırılmış modeli geçersiz kılar ve --oss ile birleştirildiğinde hangi yerel modelin çalışacağını seçer. Etkileşimsiz kullanım için:

codex exec --oss --local-provider ollama -m gpt-oss:20b "kayıt rotasına giriş doğrulaması ekle"
  1. Varsayılan yapın, böylece bayrakları bırakabilirsiniz. ~/.codex/config.toml içinde:
# `--oss` ile kullanılan varsayılan yerel sağlayıcı
oss_provider = "ollama" # veya "lmstudio"

Yerel modeller için özellik bu kadardır. API anahtarı yok, özel sağlayıcı bloğu yok. LM Studio da aynı şekilde çalışır: uygulamada bir model yükleyin, yerel sunucusunu başlatın ve codex --oss --local-provider lmstudio komutunu çalıştırın. Sunucu kurulumu için lmstudio.ai adresine bakın.

Özel sağlayıcılar: Codex'i herhangi bir uyumlu uç noktaya yönlendirin

OSS modu Ollama ve LM Studio'yu kapsar. Diğer her şey için, barındırılan DeepSeek veya Qwen API'leri, bir proxy, yerel ağınızdaki bir vLLM sunucusu, Codex'in özel model sağlayıcıları vardır. Belgeler bir sağlayıcıyı "Codex'in bir modele nasıl bağlandığı (temel URL, bağlantı API'si, kimlik doğrulama ve isteğe bağlı HTTP başlıkları)" olarak tanımlar.

Resmi belgelerdeki desen:

model = "gpt-5.6-terra"
model_provider = "proxy"

[model_providers.proxy]
name = "LLM proxy kullanarak OpenAI"
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"

Önemli anahtarlar:

Anahtar Ne işe yarar
model_provider Codex'in kullandığı sağlayıcı kimliği (varsayılan: openai)
model O sağlayıcıya gönderilen model adı
name Sağlayıcının görünen adı
base_url API temel URL'si
env_key API anahtarını tutan ortam değişkeni
wire_api Sağlayıcı tarafından kullanılan protokol
query_params İsteklere eklenen ekstra sorgu parametreleri
http_headers / env_http_headers Statik başlıklar veya ortam değişkenlerinden doldurulan başlıklar

Sağlayıcı başına ağ ayarlaması da mevcuttur: request_max_retries (varsayılan 4), stream_max_retries (varsayılan 5) ve stream_idle_timeout_ms (varsayılan 300000). Yavaş yerel donanım, daha uzun bir boşta kalma süresinden faydalanır, çünkü bir dizüstü bilgisayarda 120b'lik bir model, tokenlar arasında bir süre sessiz kalabilir.

Belgelerin doğrudan belirttiği iki kural. Birincisi, openai, ollama ve lmstudio kimlikleri rezerve edilmiştir; yerleşik sağlayıcıları geçersiz kılamazsınız. Yerleşik OpenAI sağlayıcısının temel URL'sini değiştirmek için [model_providers.openai] oluşturmak yerine openai_base_url'yi ayarlayın. İkincisi, ve bu her şeyi şekillendirir: yapılandırma referansı, wire_api için "responses desteklenen tek değerdir ve atlandığında varsayılan olarak kullanılır" der.

Bu gerçek bir kısıtlamadır. Önceki Codex sürümleri, Sohbet Tamamlama uç noktaları için wire_api = "chat" kabul ediyordu ve modeller genel bakış sayfası hala Codex'i "Sohbet Tamamlama veya Responses API'lerini" destekleyen sağlayıcılara yönlendirebileceğinizi söylüyor. Referans ve genel bakış çelişiyor. [DOĞRULA: wire_api = "chat" mevcut CLI sürümünde hala çalışıyor mu; yapılandırma referansı sadece yanıtları söylüyor, modeller sayfası sohbetin hala çalıştığını ima ediyor. Yayınlamadan önce yalnızca sohbet uç noktasına karşı test edin.] Yalnızca yanıtlar geçerliyse, sağlayıcınızın bir Responses API uç noktasına ihtiyacı vardır, ki çoğu OpenAI uyumlu sunucu bunu şimdi ifşa etse de bazı barındırılan API'ler hala etmiyor.

Modele göre tarifler

Aşağıdaki her tarif, bir yapılandırma bloğu artı çalıştırma komutudur. Başlatmadan önce API anahtarı ortam değişkenini ayarlayın.

DeepSeek (barındırılan API)

DeepSeek, Codex'in bağlantı protokolünün tam olarak istediği V4 Flash beta sürümünün yanında Responses API desteği ekledi. Bu dağıtımı DeepSeek V4 Flash, Responses API ve Codex makalemizde ele aldık.

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

Güncel model kimlikleri için DeepSeek API belgelerini kontrol edin. [DOĞRULA: DeepSeek'in Responses-protokol erişimi için belgelediği tam base_url yolu; /v1 sohbet yolu Responses yolundan farklı olabilir.]

Qwen (Model Studio aracılığıyla barındırılır)

Alibaba'nın Model Studio (DashScope), Qwen 3.8 ailesi için OpenAI uyumlu bir mod sunar. Uyumlu mod uç noktası tarihsel olarak Sohbet Tamamlama biçiminde olmuştur. [DOĞRULA: DashScope'un uyumlu modunun artık Responses protokolünü sunup sunmadığı; eğer sunmuyorsa, bu tarif yukarıdaki wire_api = "chat" sorusuna bağlıdır.]

model = "qwen3.8-max"
model_provider = "qwen"

[model_providers.qwen]
name = "Model Studio aracılığıyla Qwen"
base_url = "https://dashscope-intl.aliyuncs.com/compatible-mode/v1"
env_key = "DASHSCOPE_API_KEY"

Qwen 3.8 API kılavuzumuz, barındırılan yol için anahtarları, model kimliklerini ve fiyatlandırmayı kapsar.

Kimi, GLM ve diğer açık ağırlıklar (Ollama aracılığıyla yerel)

Ollama'ya çekebileceğiniz her şey, sağlayıcı bloğu olmadan basit OSS modu aracılığıyla çalışır:

ollama pull <model>
codex --oss -m <model>

Bu, GLM ve Qwen açık ağırlıklarını ve donanımınız dayanırsa Kimi K3'ü kapsar (K3 ağırlıkları MXFP4'te 594 GB'tır, bu yüzden çoğu kişi denemeden önce yerel olarak Kimi K3 çalıştırma makalesini okumalıdır). Orta büyüklükteki makineler için gpt-oss:20b veya kuantize edilmiş bir Qwen coder derlemesi pratik bir seçimdir.

Kendi kendine barındırılan vLLM veya bir LAN sunucusu

Başka bir makinede bir vLLM veya benzeri OpenAI uyumlu sunucu, OSS modu değil, özel bir sağlayıcıdır:

model_provider = "lan_vllm"

[model_providers.lan_vllm]
name = "İş istasyonunda vLLM"
base_url = "http://192.168.1.50:8000/v1"
env_key = "VLLM_API_KEY"

Profiller: görev başına beyin değiştirin

Tek bir kurulum seçmek zorunda değilsiniz. Codex profilleri, ~/.codex/<profil-adı>.config.toml adresindeki ayrı TOML dosyalarıdır ve --profile parametresini geçirdiğinizde temel yapılandırmanızın üzerine katmanlanır. Yerel model profili şöyle görünür:

# ~/.codex/oss-local.config.toml
oss_provider = "ollama"
model = "gpt-oss:20b"
codex --profile oss-local
codex exec --profile oss-local "utils/dates.ts için birim testleri yaz"

Zorlu yeniden düzenlemeler için varsayılan yapılandırmanızı OpenAI modellerinde tutun ve lint düzeltmeleri, test iskeleleri ve doküman geçişleri için --profile oss-local ile çalıştırın. Tek seferlik geçersiz kılmalar da profil olmadan çalışır: codex -c model='"deepseek-chat"' -c model_provider='"deepseek"'.

OpenAI modellerine karşı ödünleşimler

Neyi feda ettiğiniz konusunda kendinize karşı dürüst olun:

Pragmatik ayrım: Yüksek hacimli, düşük riskli işler için yerel veya ucuz barındırılan modeller; başarısız bir çalıştırmanın size bir öğleden sonraya mal olduğu görevler için öncü modeller.

Aracınızın dokunduğu API'leri doğrulayın

Codex içinde hangi model çalışırsa çalışsın, çıktı genellikle API'leri çağıran veya tanımlayan koddur ve açık kaynaklı modeller, öncü modellere göre uç noktaları ve şemaları daha sık halüsinasyon olarak görür. Bunu üretimde değil, API katmanında yakalayın.

Apidog, iş akışının bu tarafını kapsar. Apidog MCP sunucusunu projenize yönlendirin ve Codex aracınız, alan adlarını uydurmak yerine kod yazarken gerçek API spesifikasyonunu okuyabilir. Ardından, her değişiklikten sonra aracının terminalden test senaryolarınızı çalıştırmasına izin vermek için Codex içinde Apidog CLI'yi kullanın: düzenler, test eder, siz geçen bir farkı gözden geçirirsiniz. Daha küçük bir model kodu yazdığında bu döngü daha da önemlidir. Bağlantı kurmak için Apidog'u indirin; CLI ve MCP sunucusu yapılandırdığınız herhangi bir modelle çalışır.

Sorun giderme

SSS

Codex OSS modu IDE uzantısında veya Codex bulutunda çalışır mı?

Belgeler, OSS modunu ve özel sağlayıcıları CLI'nin yapılandırma sisteminin bir parçası olarak belgeler. IDE veya bulutun yerel sağlayıcılar için desteği belgelenmemiştir, bu nedenle bunu bir CLI özelliği olarak değerlendirin. [IDE desteğine güvenmeden önce DOĞRULA.]

Codex OSS modunda hangi modeller en iyi çalışır?

Donanımınızda Ollama veya LM Studio'nun sunabileceği her şey. gpt-oss:20b, düşük sürtünmeli varsayılandır. Güçlü açık ağırlıklı kodlama seçenekleri arasında Qwen 3.8 ailesi ve GLM bulunur; Kimi K3 gibi devasa modeller için, önce yerel Kimi K3 kılavuzumuzdaki donanım matematiğini kontrol edin.

OpenRouter veya başka bir toplayıcıyı Codex ile kullanabilir miyim?

Uyumlu bir uç nokta sunan herhangi bir toplayıcı, [model_providers.<id>] desenine uyar: base_url ve env_key'i ayarlayın, ardından model_provider ile seçin. Açık soru protokoldür: yapılandırma referansı, desteklenen tek wire_api olarak responses'ı listeler, bu nedenle toplayıcınızın Responses API'sini sunup sunmadığını onaylayın.

Açık kaynaklı bir modelle Codex'i çalıştırmak için bir OpenAI API anahtarına ihtiyacım var mı?

Yerel bir Ollama veya LM Studio sunucusuyla OSS modu için anahtara gerek yoktur. Özel barındırılan sağlayıcılar, kendi anahtarlarını env_key aracılığıyla kullanır. OpenAI hizmetlerine dokunan her şey için yine de Codex'e her zamanki gibi giriş yaparsınız.

Görevinize uygun kurulumu çalıştırın. Ucuz döngüler için yerel bir gpt-oss, daha düşük maliyetle barındırılan hız istediğinizde DeepSeek veya Qwen ve sorun zorsa OpenAI'nin öncü modelleri. Codex'in yapılandırması, üçünü de tek bir bayrakla ayırır ve Apidog API tarafında doğrulamayı hallettiğinde, model bir taahhüt yerine değiştirilebilir bir parça haline gelir.

API Tasarım-Öncelikli Yaklaşımı Apidog'da Uygulayın

API'leri oluşturmanın ve kullanmanın daha kolay yolunu keşfedin