Codex z lokalnym Qwen3.8-27B przez Responses API

Codex może łączyć się z własnym serwerem modelu przez udokumentowany protokół Responses. W wieczornym eksperymencie użyliśmy tej funkcji, aby skierować klienta Codex do Qwen3.8-27B wystawionego przez zmodyfikowany vLLM. Przesyłanie rozmowy, narzędzia i skracanie kontekstu zadziałały. Zmiana programistyczna dostała 87/100, podczas gdy Qwen Code na tym samym serwerze dostał 100/100.

Codex wspiera konfigurację własnego dostawcy. OpenAI nie certyfikuje przez to Qwena, jego wag ani zmodyfikowanej instancji vLLM. Po aktualizacji klienta lub serwera cały profil trzeba ponownie sprawdzić.

Profil, którego rzeczywiście użyliśmy

Oficjalna dokumentacja Codex opisuje base_url, źródło klucza i protokół. Poniżej jest użyty profil po usunięciu lokalnych ścieżek i nazwy hosta:

# ~/.codex/qwen-vllm.config.toml
model = "qwen3.8-27b"
model_provider = "qwen_vllm"
model_context_window = 150000
model_auto_compact_token_limit = 120000
model_auto_compact_token_limit_scope = "total"
model_reasoning_effort = "medium"
tool_output_token_limit = 6000

[model_providers.qwen_vllm]
name = "Qwen3.8-27B through local vLLM"
base_url = "http://127.0.0.1:18020/v1"
env_key = "QWEN_VLLM_API_KEY"
wire_api = "responses"
request_max_retries = 1
stream_max_retries = 1

Na innym urządzeniu 127.0.0.1 ma wskazywać lokalny tunel do hosta z GPU. Publiczne wystawienie portu byłoby błędem. Klucz trafia wyłącznie do QWEN_VLLM_API_KEY, poza TOML i repozytorium. Profil uruchamialiśmy osobno:

export QWEN_VLLM_API_KEY="$(< ~/.config/qwen-vllm/api-key)"
codex --profile qwen-vllm

Dokumentacja Codex zaznacza też, że ustawienia model_provider i model_providers w projektowym .codex/config.toml są ignorowane. Dostawca musi znaleźć się w konfiguracji użytkownika lub w osobnym pliku profilu. To drobiazg, przez który poprawny TOML umieszczony w złym miejscu wygląda jak niedziałający dostawca.

Pięciominutowy test przed wpuszczeniem agenta do repozytorium

Po uruchomieniu modelu najpierw sprawdź warstwę HTTP:

curl -fsS http://127.0.0.1:18020/health
curl -fsS \
  -H "Authorization: Bearer $QWEN_VLLM_API_KEY" \
  http://127.0.0.1:18020/v1/models

Następnie uruchom profil w pustym, jednorazowym repozytorium i podaj dokładnie takie zadanie:

Utwórz result.json z polami source: "codex-qwen-smoke" i ok: true. Sprawdź plik poleceniem jq -e '.source == "codex-qwen-smoke" and .ok == true' result.json. Nie zmieniaj innych plików.

Ten test sprawdza pięć rzeczy naraz: odpowiedź przez Responses, wywołanie narzędzia, zapis pliku, odczyt wyniku polecenia i poprawne zakończenie. W tej klasie drobnych zadań nasze przebiegi trwały od około 33 do 113 sekund. Jeżeli krótki test podstawowy przekracza pięć minut, przerywamy go i diagnozujemy transport lub pętlę agenta, zamiast udawać, że to normalny czas.

Na koniec w tej samej sesji poproś o zmianę source na codex-qwen-resume i ponowną walidację. Świeży turn może działać, kiedy wznowienie jest zepsute.

Dwie awarie, które naprawdę wystąpiły

Zły klucz. Klucz starego serwera llama.cpp użyty przy vLLM zwracał HTTP 401. Program uruchamiający początkowo potrafił potraktować tekstowy komunikat API jak wynik. Poprawiliśmy program uruchamiający tak, aby taki przebieg miał status awarii dostawcy i nie trafiał do oceny jakości modelu.

Wznowienie sesji. W profilu llama.cpp świeży turn działał, ale wznowiona sesja Codex kończyła się błędem System message must be at the beginning. Codex umieścił późniejszą wiadomość developer w historii, a szablon Qwena dopuszczał systemową treść tylko na początku. Poprawiony szablon zbiera system i developer do początkowego bloku. Osobno sprawdziliśmy świeży turn, historię system,user,assistant,developer,user i wznowienie zwracające resumed-ok.

Te przypadki pokazują, dlaczego sam /health nie jest testem integracji agenta.

Wynik Codex w domowym eksperymencie

Na zmodyfikowanym vLLM, przy 150k i medium, na domowym RTX 3090:

Codex zbudował projekt, przeszedł testy i przygotował dokumentację. Niezależna kontrola znalazła jednak istotny błąd: zachowanie awaryjne opisywane jako deterministyczne mógł wypisać adres pamięci wskaźnika lub kanału. Testy obejmowały łatwiejsze przypadki i nie wykryły tej własności.

W tej komórce Qwen Code był lepszym wyborem. Codex pozostał użytecznym kandydatem: w małym imporcie uzyskał pełne 5/5 kontroli, gdy Qwen Code pominął jedną walidację. O wyborze programu sterującego decydują wyniki konkretnego zestawu. Marka klienta nie jest kryterium odbiorowym.

Odchudzony profil Codex

Pełne środowisko klienta niosło wiele instrukcji i opisów umiejętności. Izolowany codex-qwen-vllm-slim zmniejszył zmierzoną treść wejściową z 19 748 do 10 573 bajtów, czyli o 46,5%.

To miara rozmiaru instrukcji; sama nie mówi nic o jakości. Krótsze instrukcje mogą zmniejszyć koszt i zostawić więcej kontekstu na repozytorium, a jednocześnie usunąć potrzebną procedurę. Słowo „lepszy” ma sens dopiero wtedy, gdy profil ukończy nowe zadanie i przejdzie ukryte kontrole.

Bezpieczne użycie

1. Osobny profil Codex, bez zmiany normalnego dostawcy.
2. Lokalny klucz z prawami 0600.
3. Pierwsza próba w odłączonej kopii repozytorium.
4. Wyłączone polecenia wdrożeniowe i sekrety.
5. Jawny limit kontekstu zgodny z serwerem.
6. Niezależny test formatu narzędzi oraz wznowienia.
7. Rozwiązanie zapasowe na sprawdzony profil lub API.
8. Ponowny krótki test podstawowy po każdej aktualizacji Codex, vLLM lub szablonu czatu.

Domowy RTX 3090 służył tu jako poligon. Oferta Syntalith dotyczy konfiguracji, scenariuszy odbiorowych, kontroli uprawnień, dokumentacji awarii i szkolenia zespołu. Na Kursie AI-Native zespół uczy się rozdzielać klienta, model i protokół. Bezpłatny skan procesu ustala, czy lokalny profil ma sens i jakie kontrole musi przejść.