Cấu hình mô hình bên thứ ba cho Codex CLI: kiểm tra API và khởi động Profile

Cấu hình đã được lưu chưa có nghĩa là Codex CLI thật sự gọi đúng mô hình. Cần kiểm tra lần lượt danh mục mô hình, phản hồi API có nội dung nhìn thấy được, Profile được nạp và luồng gọi công cụ đã bắt đầu.

Ngày 13 tháng 11 năm 2026, bài kiểm tra được thực hiện trên Windows PowerShell với Codex CLI 0.168.0, mô hình deepseek-v4.1-flash, Base URL https://api.crazyrouter.com/v1 và biến môi trường CRAZYROUTER_API_KEY.

Kiểm tra phiên bản Codex CLI và danh mục mô hình

Chạy lệnh sau trong PowerShell:

codex --version

Kết quả trong lần kiểm tra này là codex-cli 0.168.0.

Lệnh phiên bản trả về bình thường cho biết Codex CLI đã được cài đặt. Nếu phiên bản cũ hơn đáng kể, nên cập nhật trước khi áp dụng các trường cấu hình mới.

Bước tiếp theo là kiểm tra danh mục mô hình mà tài khoản hiện tại có thể truy cập. Yêu cầu danh mục trả về HTTP 200 và 170 mô hình. Trong 12 ID từ danh sách cũ, chỉ có 7 ID còn khớp:

Năm ID không tìm thấy là doubao-seed-2.1-pro, doubao-seed-2.1-lite, doubao-seed-2.0-mini, doubao-seed-evolving và minimax-m3.

HTTP 200 ở bước này chỉ chứng minh có thể truy cập danh mục. Nó không chứng minh mọi mô hình trong danh sách đều trả lời được yêu cầu suy luận.

Tách cấu hình Provider và Profile

Trong config.toml, cấu hình Provider và cách xác thực bằng các trường sau:

Có thể đối chiếu địa chỉ dịch vụ trong hướng dẫn tích hợp Crazyrouter. Base URL dừng ở /v1; không nối thêm /responses hoặc /chat/completions vào config.toml, vì Codex hoặc chương trình kiểm tra sẽ tự ghép đường dẫn yêu cầu.

Trong cùng thư mục với config.toml, tạo tệp ds41-flash.config.toml chỉ chứa hai giá trị ghi đè:

model = "deepseek-v4.1-flash"
model_provider = "crazyrouter"

config.toml giữ địa chỉ gateway và cách xác thực. Profile chỉ chọn mô hình và Provider. Khi cần đổi mô hình, có thể thêm một Profile nhỏ thay vì sao chép toàn bộ khối Provider.

Lưu API Key bằng biến môi trường

Trong phần biến người dùng của Windows, tạo biến CRAZYROUTER_API_KEY và điền API Key được tạo ở gateway. Sau khi lưu, đóng cửa sổ PowerShell cũ rồi mở cửa sổ mới; tiến trình đang chạy không tự nhận biến người dùng vừa thêm.

Chỉ kiểm tra biến có tồn tại hay không:

if ([string]::IsNullOrWhiteSpace($env:CRAZYROUTER_API_KEY)) { "chưa đặt" } else { "đã đặt" }

Không chạy echo $env:CRAZYROUTER_API_KEY, không đưa khóa đầy đủ vào ảnh chụp hoặc nhật ký lỗi. Kết quả “đã đặt” chỉ cho biết PowerShell đọc được biến; yêu cầu API mới xác minh khóa có hợp lệ hay không.

HTTP 200 chưa đủ, phản hồi phải có nội dung

Prompt kiểm tra chỉ yêu cầu mô hình trả lời OK. Kết quả của deepseek-v4.1-flash như sau:

Hai yêu cầu đều trả về HTTP 200 và có nội dung OK. Trong cấu hình Codex, giá trị dùng cho wire_api vẫn là "responses".

Kết quả với glm-5.3-flash cho thấy không nên chỉ nhìn mã trạng thái. Khi giới hạn đầu ra là 16 token, gần như toàn bộ phần đầu ra bị quá trình suy luận sử dụng và không có OK cuối cùng. Tăng giới hạn lên 64 token vẫn không có câu trả lời nhìn thấy được. Kết luận phù hợp chỉ là xác thực và định tuyến đã hoạt động; tham số được thử chưa tạo ra phần nội dung có thể sử dụng.

Hai yêu cầu DeepSeek ngắn đều dùng 35 token đầu vào. Responses tạo 30 token đầu ra, còn Chat Completions tạo 38 token. Phiên Codex đầy đủ dùng 91.635 token đầu vào và 850 token đầu ra vì phải nạp ngữ cảnh phiên và thử gọi công cụ. Do đó, nên kiểm tra API ngắn trước khi chạy cả phiên Codex.

Khởi động Codex bằng Profile

Trong thư mục dự án, chạy:

codex --profile ds41-flash

Sau khi khởi động, kiểm tra tên mô hình và Provider. --profile giữ cả hai giá trị, trong khi chỉ truyền -m không thay thế đầy đủ lựa chọn Provider.

Tác vụ kiểm tra yêu cầu Codex đọc README.md của dự án hiện tại và trả về mục đích của dự án. Bản ghi phiên thật cho thấy:

1. Profile ds41-flash đã được nạp.
2. Mô hình được chọn là deepseek-v4.1-flash.
3. Codex đã bắt đầu thread và turn.
4. Mô hình lần lượt thử Get-Content -LiteralPath README.md -TotalCount 60, cmd /c dir, echo hi và Get-Content README.md.
5. Chính sách lệnh trên máy đã từ chối cả bốn lệnh nên nội dung tệp chưa được đọc.

Kết quả này chứng minh Profile đã nạp, yêu cầu mô hình đã xảy ra và luồng gọi công cụ đã bắt đầu. Không thể viết rằng Codex đã hoàn thành tác vụ đọc tệp. Điểm lỗi còn lại nằm ở sandbox, quy trình phê duyệt hoặc chính sách lệnh trên máy.

Phiên chạy cũng xuất hiện cảnh báo Model metadata not found; using fallback metadata. Khi mô hình bên thứ ba không có trong danh mục tích hợp của Codex, chương trình có thể dùng metadata dự phòng. Nếu cảnh báo vẫn còn, không nên mặc định cửa sổ ngữ cảnh, cờ tính năng hoặc ước lượng token hoàn toàn trùng với tham số công bố của mô hình.

Xử lý lỗi theo đúng lớp

Kết luận

Lần kiểm tra này xác nhận ba lớp: danh mục mô hình có thể truy cập, deepseek-v4.1-flash trả về nội dung nhìn thấy được qua hai API, và Profile ds41-flash đi vào luồng gọi công cụ của Codex.

Cách cấu hình chính là định nghĩa Provider một lần trong config.toml, giữ tên mô hình trong Profile riêng và khởi động bằng codex --profile ds41-flash. Tác vụ đọc README.md chưa hoàn thành vì bốn lệnh đều bị chính sách trên máy từ chối; cần xử lý lớp quyền này trước khi chạy lại cùng tác vụ.

Tài liệu tham khảo: tài liệu Crazyrouter, tham chiếu cấu hình Codex và tham chiếu lệnh Codex CLI.