Đã đăng vào khoảng 8 giờ trước 9 phút đọc

Cách dùng Claude Code với nhiều model mà không phải sửa config mỗi lần đổi task

Dùng Claude Code với một model cố định thì đơn giản. Vấn đề chỉ xuất hiện khi workflow bắt đầu có nhiều loại task khác nhau.

Một model có thể đủ tốt để viết nhanh boilerplate, nhưng chưa chắc là lựa chọn tốt nhất cho refactor, review logic hoặc so output. Có những việc chỉ cần model rẻ để test prompt hoặc xử lý tác vụ lặp. Có những việc lại cần model mạnh hơn để giảm sai sót.

Nếu mỗi lần đổi nhu cầu lại phải sửa config, đổi endpoint, thay API key hoặc chỉnh lại từng tool, thì phần tốn thời gian nhất sẽ không còn là code nữa. Nó chuyển thành quản lý cấu hình.

Vấn đề thực tế không nằm ở Claude Code, mà nằm ở phần cấu hình quanh nó

Claude Code bản thân nó không phải vấn đề lớn nếu local environment đã ổn: Git chạy bình thường, Node.js ổn, npm ổn, terminal ổn.

Điểm dễ rối nằm ở đây:

muốn đổi model thì phải sửa config
tool này dùng một endpoint, tool kia dùng cách khác
project tăng lên thì key và base URL bắt đầu khó quản lý
muốn so output của nhiều model nhưng mỗi lần đổi lại phải chỉnh lại từ đầu
task nhẹ không cần model đắt, nhưng vì đổi quá phiền nên cuối cùng vẫn dùng một model cho tất cả

Đây là kiểu ma sát không làm workflow hỏng ngay, nhưng làm nó chậm dần và khó mở rộng dần.

Sai lầm phổ biến là tối ưu model trước khi tối ưu cách chuyển model

Nhiều người dành khá nhiều thời gian để tìm “model tốt nhất”. Cách làm đó không sai, nhưng thường không giải quyết được vấn đề vận hành.

Trong workflow thật, điều quan trọng hơn thường là:

đổi model có nhanh không
đổi model có làm gãy luồng làm việc không
thêm tool mới có phải cấu hình lại từ đầu không
so sánh nhiều model có đủ rẻ và đủ tiện để làm thường xuyên không

Nói cách khác, thứ cần tối ưu trước không phải là một model hoàn hảo, mà là chi phí chuyển đổi giữa các model.

Nếu chi phí chuyển đổi cao, về lâu dài bạn sẽ ít thử hơn, ít so hơn và ít tối ưu hơn. Khi đó việc có nhiều model trên lý thuyết cũng không mang lại nhiều giá trị thực tế.

Cách xử lý gọn nhất là thống nhất lớp cấu hình

Cách mình thấy thực dụng nhất là gom những tool có thể dùng theo kiểu OpenAI-compatible về cùng một lớp cấu hình.

Ý tưởng rất đơn giản:

giữ một OPENAI_BASE_URL thống nhất
giữ một OPENAI_API_KEY thống nhất
để việc đổi model diễn ra ở lớp gateway thay vì sửa từng tool

Ví dụ:

export OPENAI_BASE_URL="https://crazyrouter.com/v1"
export OPENAI_API_KEY="your_key_here"

Điểm mạnh của cách này không nằm ở việc “trông gọn hơn”, mà ở chỗ nó giảm số nơi bạn phải động vào khi workflow thay đổi.

Lợi ích thực tế là:

• giảm số lần phải sửa config thủ công
• dễ đổi model hơn theo từng task
• dễ tái sử dụng khi thêm tool mới
• dễ giữ cùng một cách gọi API cho nhiều workflow khác nhau
• giảm tình trạng mỗi project lại có một kiểu cấu hình riêng

Nếu làm việc với nhiều repo hoặc nhiều loại task, lợi ích này thấy rất rõ.

Khi nào nhiều model thực sự đáng để dùng?

Không phải ai cũng cần nhiều model. Nhưng có ba tình huống mà cách này phát huy giá trị khá rõ.

1. Khi một model không phù hợp cho tất cả các loại task

Một model có thể đủ nhanh để viết nháp hoặc generate phần lặp lại, nhưng chưa chắc tối ưu cho các việc cần độ cẩn thận cao hơn như chỉnh cấu trúc, review logic hoặc cải thiện khả năng đọc.

Nếu việc đổi model đủ nhẹ, bạn sẽ dùng đúng công cụ cho đúng việc. Nếu việc đổi model quá nặng, bạn sẽ có xu hướng dùng một model cho mọi thứ, kể cả khi nó không phù hợp.

2. Khi cần so output trên chính workflow của mình

So sánh model bằng benchmark công khai chỉ có giá trị tham khảo. Cái quan trọng hơn vẫn là
[26/03/2026 12:26] whitemarshall_bot: :

• code của bạn
• prompt của bạn
[26/03/2026 12:26] whitemarshall_bot: • task của bạn
• điều kiện làm việc của bạn

Muốn so đúng thì việc chuyển qua lại giữa các model phải đủ nhanh. Nếu mỗi lần đổi lại phải sửa một loạt cấu hình, phần lớn mọi người sẽ bỏ qua bước so sánh này.

3. Khi cần tối ưu chi phí cho các việc nhẹ

Không phải task nào cũng đáng trả giá cao nhất.

Các việc như:

• format lại nội dung
• viết script nhỏ
• chỉnh câu chữ
• xử lý tác vụ lặp
• test nhanh một flow

thường không cần model mạnh nhất. Nhưng nếu việc chuyển đổi rườm rà, phần tối ưu chi phí này rất khó duy trì đều.

Điều cần tránh là để workflow biến thành “quản lý dây điện”

Đây là điểm mình thấy nhiều nhất khi làm AI workflow lâu hơn một chút.

Ban đầu ai cũng nghĩ mình đang tối ưu model. Nhưng sau một thời gian, cái chiếm thời gian thật ra là:

• endpoint nào đi với tool nào
• key nào đang dùng cho project nào
• config nào đang là config đúng
• đổi model thì phải sửa ở bao nhiêu chỗ

Khi đó công việc không còn giống tối ưu development nữa. Nó giống quản lý dây điện hơn.

Nếu đã xác định dùng Claude Code nghiêm túc, phần cấu hình nên được chuẩn hóa càng sớm càng tốt. Không cần làm quá phức tạp, nhưng nên đủ thống nhất để sau này không phải quay lại dọn một mớ rối lớn hơn.

Không phải ai cũng cần cấu trúc này

Nếu bạn chỉ dùng một model, ít đổi task, ít đổi tool và workflow hiện tại đã đủ ổn, thì chưa cần thêm lớp trung gian.

Nhưng nếu bạn đang gặp một trong các dấu hiệu sau:

• thường xuyên muốn đổi model theo task
• hay so output giữa nhiều model
• dùng nhiều tool trong cùng một workflow
• muốn giảm công sửa config
• không muốn bị phụ thuộc vào một cách kết nối duy nhất

thì việc thống nhất lớp cấu hình là thứ nên làm sớm.

Kết luận

Khi dùng Claude Code trong công việc thật, vấn đề thường không nằm ở việc thiếu model. Vấn đề nằm ở việc đổi model quá tốn công.

Một khi mỗi lần chuyển đổi còn kéo theo sửa endpoint, thay key, chỉnh tool hoặc sửa lại config, thì phần ma sát đó sẽ ăn hết lợi ích của workflow nhiều model.

Cách thực dụng hơn là giữ một interface đủ thống nhất để model có thể thay đổi mà workflow không phải thay đổi theo.

Với mình, giá trị lớn nhất của một lớp OpenAI-compatible như Crazyrouter không chỉ là có nhiều model để chọn. Giá trị lớn hơn là giữ cho việc chuyển model đủ rẻ, đủ nhanh và đủ gọn để workflow không bị đứt nhịp.