GitHub tung bản cập nhật Visual Studio ngày 28 tháng 8 âm thầm thay đổi cách team nên nghĩ về chi phí AI coding assistant. Tính năng nổi bật: điều khiển thinking-effort Low/Medium/High cho model được hỗ trợ, một view quản lý model hiển thị kích thước context window và chi phí mỗi model, khả năng ghim model yêu thích và thu gọn model ít dùng, cùng custom agent cấp tổ chức tự động xuất hiện trên mọi repo.

Núm effort là cái tôi quan tâm nhất. Đó là một bổ sung UI nhỏ nhưng mang hàm ý kiến trúc thật: tinh chỉnh effort cuối cùng cũng được phơi bày như một quyết định theo từng task, thay vì chính sách model theo từng team.

Vì sao chuyện này quan trọng: cái bẫy chọn model

Hầu hết team tôi từng làm việc xử lý chi phí model theo cách thô: chọn một tier model cho cả tổ chức (gpt-5.x cho mọi người, hoặc model rẻ hơn cho “junior”), set trong policy, xong. Đó là sai trục. Tradeoff cost/quality thực sự quan trọng không phải model nào, mà là call cụ thể này nên “nghĩ” nặng đến đâu.

Tôi từng viết đúng failure mode này vài tuần trước khi phân tích setting reasoning-effort của GLM-4.6/Qwen3.8 — team vặn reasoning effort lên “high” mặc định vì nghe có vẻ như một cần gạt chất lượng, rồi trả giá latency và token cost gấp 3-5 lần cho request không cần đến nó (đổi tên một dòng code không cần extended reasoning; refactor xuyên nhiều file với intent mơ hồ thì cần). Bài học ở đó là: reasoning effort là núm theo từng request, không phải default toàn cục, và mặc định để high thường chỉ là đốt ngân sách.

Điều khiển Low/Medium/High theo từng model mới của Copilot chính là GitHub cuối cùng phơi bày cùng núm vặn đó vào trong workflow IDE, thay vì để nó chôn trong tham số API mà chỉ power user mới đụng tới. Cụ thể, trước bản cập nhật này, nếu tổ chức bạn chuẩn hóa trên một model có khả năng reasoning, mọi request Copilot — từ autocomplete đơn giản đến refactor phức tạp — đều trả cùng một “thuế” reasoning. Giờ một developer (hoặc quan trọng hơn, một chính sách tổ chức) có thể set effort theo task:

Gợi ý inline nhanh, boilerplate, sửa một file  → Low
Refactor nhiều file, yêu cầu mơ hồ              → Medium
Thay đổi cấp kiến trúc, code path nhạy cảm bảo mật → High

Tôi sẽ cấu hình gì thực sự

Nếu tôi triển khai cho một team tuần này, đây là policy tôi sẽ viết, map trực tiếp lên cùng framework effort-tiering từ bài reasoning-effort trước:

# .github/copilot-effort-policy.yml (minh họa — kiểm tra schema policy hiện tại của org)
default_effort: low
overrides:
  - path_glob: "src/auth/**"
    effort: high
  - path_glob: "src/payments/**"
    effort: high
  - task_type: "multi_file_refactor"
    effort: medium
  - task_type: "inline_completion"
    effort: low

Bản năng cần cưỡng lại: đừng set default tổ chức là high “cho an toàn”. Đó là sai lầm giống hệt việc mặc định reasoning effort ở mức max trên open model — bạn trả giá cho nó trên mọi completion vặt vãnh, cả ngày, trên mọi developer, trong khi lợi ích chất lượng biên trên một thay đổi một dòng gần như bằng không. Dành high cho những path mà câu trả lời sai tốn kém: auth, payments, migration, bất cứ gì chạm vào tính toàn vẹn dữ liệu.

View quản lý model quan trọng hơn vẻ ngoài

Tính năng thứ hai — view quản lý hiển thị kích thước context window và chi phí mỗi model, với điều khiển ghim/thu gọn — là phần “nhàm chán nhưng cần thiết” đi kèm tinh chỉnh effort. Điều khiển effort chỉ có lợi nếu developer thực sự thấy được họ đang đánh đổi gì. Một toggle Low/Medium/High không có ngữ cảnh chi phí hiển thị chỉ là cảm tính. Ghép nó với một bảng cost/context hiển thị rõ là thứ biến “cứ để high, ai quan tâm” thành một lựa chọn có thông tin ngay tại điểm sử dụng — chính xác nơi các cuộc trò chuyện FinOps-cho-AI đang hướng tới năm nay: đẩy khả năng nhìn thấy chi phí đến điểm ra quyết định, không phải đến một dashboard billing hàng tháng không ai đọc cho tới khi đã muộn.

Chỗ vẫn còn thiếu

Hai khoảng trống tôi muốn nêu trước khi gọi đây là “đã giải quyết”:

  1. Chưa có telemetry chi phí theo từng effort tier, ít nhất theo changelog. Bạn có thể set núm vặn, nhưng tôi không thấy đề cập báo cáo theo developer hay theo repo về việc setting effort thực sự ảnh hưởng chi tiêu ra sao. Thiếu vòng phản hồi đó, team sẽ set policy một lần rồi không bao giờ xem lại — cùng failure mode như default reasoning-effort tĩnh.
  2. Effort vẫn thủ công, chưa adaptive. Phiên bản lý tưởng của tính năng này tự suy ra effort từ độ phức tạp task (kích thước diff, số file chạm vào, có chạm path nhạy cảm được đánh dấu hay không) và chỉ hỏi developer khi cần override, không phải chọn từ đầu mỗi lần. Hiện tại nó là núm vặn thủ công, nghĩa là việc áp dụng phụ thuộc vào kỷ luật developer — về mặt lịch sử luôn là mắt xích yếu nhất trong bất kỳ chính sách kiểm soát chi phí nào.

Tóm lại: đây là tính năng tốt, đến muộn. Nó không tự sửa hóa đơn Copilot của bạn, nhưng cho bạn cái cần gạt để thực sự thực thi kỷ luật effort-tiering mà trước đây chỉ có sẵn nếu bạn gọi model API trực tiếp.

Nguồn: GitHub Changelog: GitHub Copilot in Visual Studio — August update

Xuất nội dung

Bình luận