feat: add self-correcting OpenAI sampling-param handling

[thuytx03]

Vấn đề

OpenAI đã tách Chat Completions thành hai thế hệ tham số sampling khác nhau:

• Model cũ (gpt-3.5, gpt-4, gpt-4o, gpt-4.1, …) dùng temperature + max_tokens.
• Model reasoning mới (o1/o3/o4/gpt-5 trở lên) dùng max_completion_tokens và không cho phép override temperature.

Nếu gửi sai bộ tham số cho model, OpenAI sẽ trả về lỗi 400 và request thất bại. Việc cố gắng duy trì một danh sách đầy đủ tất cả model để biết dùng tham số nào là bất khả thi và dễ lỗi thời.

Giải pháp

PR này thêm cơ chế tự đoán rồi tự sửa để tính năng tóm tắt hoạt động ổn định trên cả hai thế hệ model, mà không cần bảo trì danh sách model dài dòng:

1. apply_openai_sampling_params chọn bộ tham số "đoán tốt nhất" dựa trên một allowlist ngắn các dòng model cũ.
2. Nếu OpenAI từ chối một tham số, post_openai_chat sẽ phân tích lỗi trả về — ưu tiên dùng trường có cấu trúc error.param thay vì đọc message dạng text — rồi sửa đúng trường bị lỗi ngay tại chỗ và thử lại.
3. Số lần thử lại được giới hạn bởi MAX_OPENAI_PARAM_ADJUSTMENTS. Hằng số này đếm số lần điều chỉnh (không phải số request); trường hợp xấu nhất là số lần điều chỉnh + 1 request. Mọi lần gửi đều đi qua cùng một nhánh trong vòng lặp để tổng số request luôn rõ ràng.

Lý do thiết kế

• Không hardcode danh sách model đầy đủ: các dòng model cũ về cơ bản đã "đóng băng", còn model mới của OpenAI đều đã thống nhất chuyển sang kiểu tham số mới. Vì vậy chỉ cần một allowlist ngắn cho model cũ, còn lại mặc định coi là model mới.
• Tự sửa dựa trên lỗi thực tế của OpenAI: nếu đoán sai, chi phí chỉ là 1 request thừa rồi hệ thống tự điều chỉnh — an toàn hơn là cố đoán đúng 100%.

Cách kiểm thử

• cargo check chạy sạch
• Các unit test hiện có cho parser tương thích OpenAI vẫn pass
• Thủ công: tóm tắt bằng một model cũ (vd gpt-4o) và một model reasoning (vd o3) để xác nhận cả hai kiểu tham số đều được chấp nhận

🤖 Được tạo với sự hỗ trợ của Claude Code

[vanloctech]

Thanks for the focused fix. The overall direction looks right: centralizing OpenAI sampling-parameter handling and using structured OpenAI error details is a good approach, and I don’t see a security issue in the bounded retry loop.

I’d like to request two small changes before merge:

1. The same parameter mismatch can still happen through the Proxy provider. The app’s Proxy provider is OpenAI-compatible, defaults to https://api.openai.com, and also defaults to a GPT-5 model, but generate_raw_with_proxy() still sends temperature + max_tokens. Since the new helper already accepts a URL, please either reuse the same OpenAI-compatible retry path for Proxy or explicitly narrow the PR so Proxy is handled in a follow-up.

2. Please add unit tests for the new logic. The current test suite still only covers the existing OpenAI-compatible response parser, not apply_openai_sampling_params(), adjust_openai_request(), or the retry adjustment cases. At minimum, I’d like tests for legacy models using temperature + max_tokens, reasoning/new models using max_completion_tokens without temperature, removing rejected temperature, and converting rejected max_tokens to max_completion_tokens.

I verified locally that cargo check, cargo test --lib, and bun run tsc -b pass, so this looks close. After those coverage/scope fixes, I’d be comfortable merging.

[thuytx03]

Cảm ơn phản hồi chi tiết! Mình đã xử lý cả hai điểm trong commit mới:

1. Proxy provider dùng chung retry path OpenAI-compatible

generate_with_proxy và generate_raw_with_proxy giờ đi qua apply_openai_sampling_params + post_openai_chat, thay vì luôn gửi temperature + max_tokens. Vì Proxy mặc định trỏ api.openai.com với model GPT-5, giờ nó cũng chọn đúng bộ tham số và tự sửa khi bị reject.

Ngoài ra mình mở rộng adjust_openai_request để đổi trường token limit theo cả hai chiều:

• max_tokens → max_completion_tokens (model reasoning của OpenAI)
• max_completion_tokens → max_tokens (một số proxy OpenAI-compatible chỉ hiểu trường cũ)

Nhờ vậy vòng retry tự phục hồi dù endpoint từ chối trường nào.

2. Unit tests cho logic mới

Đã thêm test cho:

• apply_openai_sampling_params: model legacy dùng temperature + max_tokens; model reasoning/mới dùng max_completion_tokens không kèm temperature; bỏ token limit khi không set; nhận diện legacy không phân biệt hoa/thường.
• adjust_openai_request: gỡ temperature bị reject; chuyển max_tokens ↔ max_completion_tokens cả hai chiều; fallback theo message khi không có error.param; không đổi gì khi trường đã vắng; điều chỉnh kết hợp nhiều trường.

Đã xác nhận local: cargo check, cargo test --lib (199 pass), và tsc -b đều xanh.