GPT-5.5 low vs medium vs high vs xhigh: đường cong suy luận qua 26 tác vụ thực tế trên kho mã nguồn mở

 (reddit.com)
5 điểm bởi GN⁺ 8 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi chạy GPT-5.5 Codex trên 26 tác vụ thực tế của GraphQL-go-tools với các mức low, medium, high, xhigh, chênh lệch về mức độ nỗ lực suy luận bộc lộ rõ hơn ở độ tương đương ngữ nghĩa với bản vá của con người và tỷ lệ vượt qua code review, thay vì chỉ ở việc qua test
  • Tỷ lệ qua test là low 21/26, medium 21/26, high 25/26, xhigh 24/26, nhưng độ tương đương ngữ nghĩa tăng từ 4/26 → 11/26 → 18/26 → 23/26, còn tỷ lệ vượt qua code review cũng tăng từ 3/26 → 5/26 → 10/26 → 18/26
  • high cải thiện cả tỷ lệ qua test, độ tương đương và khả năng vượt qua review so với medium, trong khi chi phí trung bình tăng từ $3.13 lên $4.49, tức 1.43 lần, nên có vẻ là thiết lập mặc định thực dụng nhất trên bộ dữ liệu này
  • xhigh nâng mạnh độ tương đương và chất lượng review so với high, nhưng chi phí trung bình tăng lên $9.77, thời gian chạy trung bình lên 753.3 giây, đồng thời tạo thêm nhiều thay đổi ở test, fixture và expected output, làm tăng cả rủi ro về footprint
  • Hiệu quả của mức nỗ lực suy luận không đơn điệu theo từng tác vụ: có trường hợp high tốt hơn xhigh, hoặc mức cao hơn tạo ra triển khai trông có vẻ hợp lý nhưng lại sai; vì vậy các nhóm nên đo trên harness và tác vụ riêng của mình thay vì dựa vào benchmark toàn cục

Mục tiêu thí nghiệm và cách đánh giá

  • GPT-5.5 Codex được chạy trên cùng 26 tác vụ của một kho mã nguồn mở với các mức nỗ lực suy luận low, medium, high, xhigh, để so sánh không chỉ khả năng qua test mà còn cả độ tương đương ngữ nghĩa với PR do con người merge và khả năng được review chấp nhận
  • Kho mục tiêu là GraphQL-go-tools viết bằng Go, và mỗi tác vụ được rút ra từ một PR hoặc commit đã được merge ngoài thực tế
  • Mỗi tác vụ gồm một snapshot cố định của kho, một prompt yêu cầu thay đổi và một lần thử duy nhất để tạo bản vá trong container Docker
  • Stet áp dụng bản vá đã tạo và chạy bộ test theo từng tác vụ trong container cô lập để xác nhận có qua hay không
  • Sau test, thí nghiệm tiếp tục đánh giá theo các tiêu chí sau
    • Tương đương: bản vá ứng viên có đạt được thay đổi hành vi giống với bản vá gốc do con người tạo ra hay không
    • Vượt qua code review: xét về độ đúng, rủi ro đưa lỗi vào, khả năng bảo trì và các edge case, reviewer có chấp nhận hay không
    • Rủi ro footprint: so với bản vá của con người, agent chạm thêm bao nhiêu mã
    • Rubric về chất lượng tạo tác/kỷ luật: đánh giá độ rõ ràng, đơn giản, nhất quán, có chủ đích, vững chắc, tuân thủ chỉ dẫn, kỷ luật về phạm vi và mức tối thiểu của diff
  • Tất cả mô hình chỉ được chạy một lần cho mỗi tác vụ, với một seed duy nhất
  • Mô hình LLM dùng để chấm là GPT-5.4, và bộ chấm chỉ nhìn thấy bản vá cùng tác vụ, không thấy mô hình hay mức suy luận nào đã tạo ra bản vá đó
  • Một số ví dụ tiêu biểu cũng được kiểm tra thủ công, nhưng không có hiệu chuẩn riêng bằng con người cho tập tác vụ này, nên nên tin tưởng xu hướng tăng giảm hơn là điểm tuyệt đối đơn lẻ
  • Chi tiết thực thi
    • Mô hình: GPT-5.5
    • Harness: Codex 0.128.0
    • Bộ dữ liệu: 26 tác vụ thực tế của GraphQL-go-tools
    • Chỉ số chính: qua test, tương đương ngữ nghĩa, vượt qua code review, rủi ro footprint, đánh giá tùy chỉnh về chất lượng tạo tác/kỷ luật, chi phí và thời gian chạy
  • Biểu đồ tương tác và phân tích chi tiết theo từng tác vụ có tại https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve
  • Cùng một cách đánh giá này cũng được dùng cho vòng lặp nghiên cứu tự động nhằm cải thiện AGENTS.md
    • Agent tạo đề xuất cải thiện AGENTS.md cho kho, chạy các tác vụ quá khứ bằng Stet, sau đó tìm ra chỗ nào tốt hơn hoặc tệ đi để lặp tiếp

Chỉ số tổng thể và cách diễn giải

  • Các chỉ số tổng thể cho thấy khi tăng mức nỗ lực suy luận, chênh lệch lớn hơn xuất hiện ở độ tương đương ngữ nghĩa và tỷ lệ vượt qua review hơn là ở khả năng qua test
  • Kết quả chính
    • Qua test: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • Tương đương với bản vá của con người: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • Vượt qua code review: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • Điểm chất lượng tạo tác/kỷ luật trung bình: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • Chi phí trung bình mỗi tác vụ: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • Thời gian chạy agent trung bình: low 286.9 giây, medium 411.0 giây, high 579.0 giây, xhigh 753.3 giây
  • low và medium cùng đạt 21/26 về qua test, nhưng độ tương đương tăng từ 4/26 lên 11/26, còn tỷ lệ vượt qua review tăng từ 3/26 lên 5/26
  • So với medium, high tăng +15.4 điểm phần trăm ở qua test, +26.9 điểm phần trăm ở độ tương đương và +19.2 điểm phần trăm ở tỷ lệ vượt qua review, cho thấy mức cải thiện thực dụng rõ rệt nhất
  • So với high, xhigh thấp hơn -3.8 điểm phần trăm về qua test, nhưng tăng +19.2 điểm phần trăm về độ tương đương và +30.8 điểm phần trăm về tỷ lệ vượt qua review
  • Mức nỗ lực suy luận dường như không chỉ thay đổi tỷ lệ qua test, mà còn thay đổi loại bản vá mà Codex tạo ra
  • Các benchmark công khai thường trả lời việc tác vụ có thành công hay không theo kiểu nhị phân, nhưng trong kỹ nghệ phần mềm thực tế, việc bản vá có thể được merge và được bảo trì về sau cũng quan trọng
  • Terminal-Bench chủ yếu xoay quanh các bài toán lập trình khó nhằn, SWE-bench verified có khả năng mô hình đã từng thấy sẵn đáp án, còn SWE-bench Pro hữu ích nhưng mang tính tổng quát cao
  • Mối quan tâm của thí nghiệm này là “agent có tạo ra loại thay đổi giống với thứ con người đã merge trong codebase của tôi hay không” và “tôi có muốn sở hữu bản vá này về sau hay không”

Từ low lên medium: chuyển từ heuristic sang mô hình hóa miền

  • low và medium đều đạt 21/26 ở chỉ số qua test, nên nếu chỉ nhìn test thì có vẻ hòa nhau
  • Tuy nhiên, medium nâng độ tương đương ngữ nghĩa từ 4/26 lên 11/26, và điểm chất lượng tạo tác/kỷ luật trung bình cũng tăng từ 2.311 lên 2.604
  • Ở khoảng này, nếu chỉ đo qua test thì sẽ bỏ lỡ phần lớn khác biệt do mức nỗ lực suy luận tạo ra
  • low, ngay cả ở các bản vá qua test, vẫn có lúc chỉ dừng ở heuristic hoặc triển khai một phần; còn medium chuyển sang hướng mô hình hóa tốt hơn kho mã và ngữ nghĩa của miền bài toán
  • Ví dụ PR #1297
    • Đây là tác vụ xác thực dependency nullable external @requires trong GraphQL Federation
    • Nếu một trường required nhưng nullable trả về null kèm lỗi, thì thực thể đã bị ô nhiễm đó không được truyền sang downstream fetch phụ thuộc vào nó
    • Bản chất của tác vụ không phải chỉ là thêm một nhánh validation đơn giản, mà là mô hình hóa một quy tắc phụ thuộc dữ liệu tinh vi trong federation
    • low đã qua test, nhưng xử lý việc ghép cặp required-field/error theo heuristic và bỏ lỡ metadata nullable @requires có cấu trúc, nên không tương đương và cũng không vượt qua review
    • medium theo dõi đối tượng bị ô nhiễm và lọc đầu vào cho downstream fetch, nên đạt cả tương đương lẫn vượt qua review, đồng thời chất lượng tạo tác/kỷ luật tăng từ 1.350 lên 3.225
    • high và xhigh cũng giữ ở cùng dải chất lượng đó, nên tác vụ này chủ yếu cho thấy mức cải thiện khi chuyển từ low sang medium

high: điểm gần với mặc định thực dụng

  • high cải thiện cả tỷ lệ vượt qua bài kiểm thử, tương đương ngữ nghĩa và vượt qua review so với medium, trong khi mức tăng chi phí lớn nhưng vẫn không quá mức
  • So sánh high và medium
    • Vượt qua bài kiểm thử: tăng từ 21/26 lên 25/26
    • Tương đương: tăng từ 11/26 lên 18/26
    • Vượt qua review mã: tăng từ 5/26 lên 10/26
    • Rủi ro footprint trung bình: tăng từ 0.268 lên 0.314
    • Điểm chế tác/kỷ luật trung bình: tăng từ 2.604 lên 2.736
    • Chi phí tác vụ trung bình: tăng từ $3.13 lên $4.49, gấp 1.43 lần
    • Thời gian thực thi trung bình: tăng từ 411.0 giây lên 579.0 giây
  • high trông như điểm mà token bổ sung được chuyển hóa thành lợi ích thực sự, với tỷ lệ xử lý đúng các chi tiết tích hợp cao hơn
  • Ví dụ PR #1209
    • Đây là tác vụ yêu cầu gRPC datasource tôn trọng GraphQL alias trong JSON phản hồi, xác thực trước referenced protobuf message type, và cập nhật độ bao phủ ánh xạ cho đường mutation union/interface
    • low và medium đều vượt qua bài kiểm thử nhưng không tương đương và cũng trượt review
    • medium xử lý phần lớn việc tuần tự hóa alias và xác thực message bị thiếu, nhưng bỏ sót cập nhật ánh xạ mutation createUser và gán quá nhiều ngữ nghĩa response-key cho JSONPath
    • high đưa vào xử lý response-key/alias tường minh và truyền alias xuyên suốt planning lẫn JSON marshaling, nhờ đó trở thành lần vượt qua nghiêm ngặt đầu tiên
    • Chất lượng tùy chỉnh của high tăng lên 3.625, cho thấy không chỉ đơn giản là thêm nhiều mã hơn mà là đáp ứng chính xác các nghĩa vụ tích hợp
    • xhigh cũng vượt qua nhưng không cải thiện cách diễn giải ở cấp độ tác vụ, và thời gian chạy agent theo tiêu chí tóm tắt được tái tạo của nó là 790.7s, dài hơn 314.0s của high
  • Ví dụ PR #1155
    • Đây là tác vụ hardening cho gRPC datasource, bao gồm hỗ trợ repeated scalar field, tránh panic với null/invalid message, truyền gRPC status code, vô hiệu hóa datasource và hỗ trợ dynamic client
    • low và medium vượt qua bài kiểm thử nhưng không tương đương
    • medium cải thiện độ vững chắc nhưng tuần tự hóa invalid repeated field thành empty array, bỏ sót hành vi planning của aliased-root, và vẫn còn rủi ro với vòng đời dynamic-client
    • high vượt qua cả tương đương lẫn review nhờ xử lý nil/invalid an toàn hơn, truyền status-code, hành vi disabled-datasource và độ bao phủ cho dynamic client-provider
    • Ở tác vụ này đã xuất hiện trường hợp đảo ngược khi xhigh vượt qua bài kiểm thử nhưng xử lý sai ngữ nghĩa disabled datasource và hành vi invalid-list, nên không tương đương và cũng trượt review

xhigh: gần với chế độ chất lượng hơn là mặc định

  • xhigh nâng chất lượng ngữ nghĩa và review lên cao hơn high, nhưng không phải kiểu cứ tăng cấu hình là mọi thứ đều tốt hơn
  • So sánh xhigh và high
    • Vượt qua bài kiểm thử: giảm từ 25/26 xuống 24/26
    • Tương đương: tăng từ 18/26 lên 23/26
    • Vượt qua review mã: tăng từ 10/26 lên 18/26
    • Rủi ro footprint trung bình: tăng từ 0.314 lên 0.365
    • Điểm chế tác/kỷ luật trung bình: tăng từ 2.736 lên 3.071
    • Chi phí tác vụ trung bình: tăng từ $4.49 lên $9.77, gấp 2.18 lần
    • Thời gian thực thi trung bình: tăng từ 579.0 giây lên 753.3 giây
  • xhigh có xu hướng bao phủ nhiều nền tảng hơn, khớp tốt hơn với ý định của con người và tạo ra các thay đổi hoàn chỉnh hơn, nhưng dùng nhiều token hơn đáng kể
  • Theo rubric review, xhigh có trung bình 3.365, trung vị 3.500, cao hơn mức trung bình 2.817 và trung vị 2.750 của high
  • Trung vị cũng cao hơn trung bình, nên có vẻ mức cải thiện của xhigh không phải là kết quả của chỉ một hai bản vá xuất sắc kéo trung bình đi lên
  • xhigh hoàn chỉnh hơn về ngữ nghĩa, nhưng so với các bản vá do con người tạo ra thì cũng chạm vào nhiều mã hơn, nên rủi ro footprint tăng lên
  • Trong 26 tác vụ, tổng số dòng mà xhigh thêm vào là 13,144 dòng, gồm 5,918 dòng mã triển khai và 7,226 dòng test·fixture·expected-output
  • So với high, xhigh thêm nhiều hơn 2,631 dòng, trong đó 2,436 dòng nằm trong các tệp test·fixture·expected-output
  • Mức tăng footprint không chỉ vì nó viết ra lượng lớn production code, mà còn vì xhigh tạo thêm nhiều lớp xác thực và độ bao phủ fixture hơn
  • Tuy nhiên, các thay đổi ở test, fixture và expected-output cũng là bề mặt thực tế cần được review và bảo trì
  • Ví dụ PR #1076
    • Đây là tác vụ tái cấu trúc xử lý subscription để tránh shared mutex race condition
    • Các yêu cầu bao gồm ghi tuần tự theo từng subscription, điều khiển heartbeat theo từng subscription, độ bao phủ từ race detector, và sửa WebSocket close semantics
    • medium vượt qua bài kiểm thử nhưng không tương đương và cũng trượt review
    • high đạt tương đương và tuân thủ chỉ thị, nhưng worker queue mới có thể chặn global subscription event loop, shutdown có thể bị dừng sau worker bị kẹt, hung update là vô hạn, và unsubscribe ở cấp client vẫn bỏ qua internal subscription nên trượt review
    • xhigh là lần vượt qua nghiêm ngặt đầu tiên và nâng chất lượng tùy chỉnh lên 3.475
    • Đây là ví dụ tốt nhất cho việc xhigh hoạt động như một chế độ chất lượng, đáng bỏ thêm chi phí để dọn rủi ro review trong các tác vụ nặng về concurrency
  • Ví dụ PR #1308
    • Đây là tác vụ triển khai GraphQL @oneOf input object
    • Cần bổ sung built-in directive, phơi bày qua introspection, xác thực operation literal và runtime variable, cùng cải thiện source location của undefined-variable
    • medium và high vượt qua bài kiểm thử nhưng bỏ sót các ngữ nghĩa @oneOf quan trọng liên quan đến runtime variable, nullable variable, provided-null payload và hình dạng introspection, nên không tương đương và cũng trượt review
    • xhigh là lần vượt qua nghiêm ngặt đầu tiên và ghi nhận độ vững chắc 3.7, tuân thủ chỉ thị 4.0, chất lượng tùy chỉnh 3.525
    • Khác biệt không nằm ở lớp polish bề mặt mà ở độ bao phủ edge case trải trên nhiều phần của hệ thống
  • Ví dụ PR #1240
    • Đây là tác vụ hợp nhất GraphQL AST field-selection merging và inline-fragment selection merging vào một normalization walk duy nhất
    • low và high đều vượt qua nghiêm ngặt
    • xhigh tương đương theo tiêu chí đánh giá ngữ nghĩa, nhưng vẫn giữ prioritized subpass, thay đổi thứ tự của AbstractFieldNormalizer, và để lại đăng ký field-merge cũ nên trượt review
    • Ngay cả cấu hình suy luận cao hơn cũng có thể tạo ra những đợt refactor tinh vi và có vẻ hợp lý hơn, nhưng lại bỏ lỡ hành vi thực thi chính xác mà bài kiểm thử và reviewer coi trọng

Chế tác·kỷ luật, chi phí, giới hạn và kết luận

  • Đánh giá tùy chỉnh về chế tác·kỷ luật cũng nhìn chung tăng lên khi mức nỗ lực suy luận tăng, tương tự rubric review
  • Điểm all-custom có trung bình 3.071, trung vị 3.087 ở xhigh, cao hơn mức trung bình 2.736, trung vị 2.688 của high
  • Cả chế tác và kỷ luật đều có trung vị cao hơn, nên có thể hiểu rằng xhigh không chỉ tạo ra một vài ví dụ nổi bật mà đã nâng chất lượng patch trên diện rộng
  • Chỉ số trung bình/trung vị
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • Diễn giải chi tiết
    • low yếu về độ vững chắc và khả năng tuân thủ chỉ dẫn
    • medium cải thiện phần này một cách đáng kể mà không làm tăng tổng lượng test pass
    • high cải thiện độ chính xác và độ vững chắc trên thực tế
    • xhigh cải thiện gần như mọi chiều cạnh, bao gồm phạm vi và kỷ luật về diff
  • Chi phí và thời gian
    • low: chi phí trung bình $2.65, trung vị $1.91, thời gian chạy trung bình 286.9s, trung vị 294.6s
    • medium: chi phí trung bình $3.13, trung vị $2.87, thời gian chạy trung bình 411.0s, trung vị 371.8s
    • high: chi phí trung bình $4.49, trung vị $3.99, thời gian chạy trung bình 579.0s, trung vị 572.9s
    • xhigh: chi phí trung bình $9.77, trung vị $6.39, thời gian chạy trung bình 753.3s, trung vị 732.7s
  • Chi phí có độ lệch ở low và đặc biệt là xhigh, và chi phí trung bình của xhigh bị ảnh hưởng bởi một vài tác vụ đắt đỏ
  • Xhigh vẫn đắt hơn và chậm hơn high ngay cả khi xét theo trung vị
  • High tốn chi phí khoảng 1,43 lần mỗi tác vụ so với medium, còn xhigh tốn khoảng 2,18 lần so với high
  • Giới hạn
    • Chỉ dùng một seed duy nhất cho mỗi tác vụ
    • Chỉ bao gồm 26 tác vụ thực tế của GraphQL-go-tools
    • Giám khảo LLM là GPT-5.4, có xem patch·tác vụ nhưng không xem label
    • Không có calibration cho grader trên tập tác vụ này
    • Không thể xem đây là kết quả phổ quát có ý nghĩa thống kê, hay kết quả có thể chuyển nguyên trạng sang các kho khác
  • So sánh liên quan
    • leaderboard tác vụ thực tế của Voratiq cũng cho thấy xu hướng tương tự dù phương pháp khác nhau
    • Trên Voratiq, GPT-5.5 xhigh đạt 1994, GPT-5.5 high đạt 1807, tăng +187 điểm, tương đương +10.3%
    • Chi phí là $4.23 so với $2.52, tức +67.9%, còn thời gian là 11.9m so với 7.8m, tức +52.6%
    • Trong thí nghiệm Stet, high → xhigh cho mức tăng lớn hơn: tính tương đương +19.2%p, tương đối +27.8%, pass review code +30.8%p, tương đối +80.0%, còn aggregate chế tác/kỷ luật là +12.2%, khá tương đồng
    • Voratiq là leaderboard kiểu preference/selection cho ongoing work, còn thí nghiệm này là một lát cắt kho gồm 26 tác vụ, nên không thể so sánh trực tiếp
  • Kết luận thực tiễn
    • xhigh phù hợp với các tác vụ mơ hồ, trải rộng nhiều khu vực, thiên về đồng thời, hoặc có rủi ro review cao
    • high có vẻ là thiết lập thực dụng nhất làm daily driver mặc định trong bộ dữ liệu này
    • Các thiết lập từ medium trở xuống phù hợp khi chi phí quan trọng hơn và tác vụ mang tính thường nhật hoặc được định nghĩa rõ ràng
    • Hiệu quả của nỗ lực suy luận không mượt hay đơn điệu theo từng tác vụ; cũng có trường hợp high thắng xhigh, hoặc mức cao hơn tạo ra cách triển khai có vẻ hợp lý nhưng lại sai
    • Thay vì sao chép mặc định từ benchmark toàn cục, các đội nên tự đo trên harness và tác vụ của chính mình
  • Công bố
    • Nhóm đang xây dựng Stet.sh và đã chạy thí nghiệm bằng công cụ đánh giá cục bộ này
    • Ở phiên bản sản phẩm, coding agent sẽ tạo các thay đổi ứng viên như cải thiện AGENTS.md, rồi dùng Stet để đánh giá trên các tác vụ lịch sử của kho
    • Nếu đội ngũ dùng nhiều coding agent đang đứng trước các quyết định cụ thể như high vs xhigh, Codex vs Claude Code, cập nhật AGENTS.md, hay xác định tác vụ nào an toàn để giao phó, thì nhóm đang tìm các đội để cùng chạy thử nghiệm theo từng kho
    • Stet chạy hoàn toàn cục bộ bằng thuê bao LLM, và danh sách chờ ở https://www.stet.sh/private

Bài viết liên quan

1 bình luận

 
GN⁺ 8 giờ trước
Ý kiến trên Hacker News
  • So sánh này rất hay và tôi cũng muốn xem so sánh với 5.4
    Theo cảm nhận cho đến lúc này thì 5.5 không đáng với phần chi phí tăng thêm. 5.4-high làm tốt hơn phần lớn các mức suy luận của 5.5, trong khi chi phí chỉ bằng một nửa và thời gian thực tế ngắn hơn rất nhiều. 5.5-medium đã không thể hoàn thành công việc đến cùng, còn 5.5-high thì thiết kế quá mức, tạo ra bug và regression
  • Với đa số công việc nghiêm túc thì high có vẻ là mức phù hợp
    Những cải thiện đạt được ở các mức cao hơn gần như là lợi ích giảm dần so với chi phí
  • Trên tài khoản Pro, tôi chạy 5.5 xHigh Codex Terminal CLI làm lead chính, còn Codex Desktop App 5.5 xhigh làm lead phụ
    Tôi cấp cho cả hai toàn quyền truy cập kiểu nguy hiểm và để chúng làm việc trên cùng một project. Mỗi bên trung bình gắn 6 sub-agent của 5.5, còn CLI hay app sẽ tự quyết định dùng sub-agent ở mức nào. Có lẫn lộn nhiều mức, nhưng CLI nhìn chung hay gắn 5.5 Medium
    CLI có quyền admin và chỉ CLI mới xử lý các việc như GitHub, Supabase, Vercel, Clerk, Linear, Symphony, cũng như push, merge, PR, deploy. Tôi không phải làm gì trực tiếp, cũng không có issue P0/P1/P2 nào. GitHub, Vercel, Supabase đều xanh, không có issue, code và sản phẩm gọn gàng, và chỉ với một ảnh tham chiếu mà frontend ra cực kỳ ấn tượng
    Nhược điểm là nó có thể đốt tới 30% hạn mức tuần chỉ trong một ngày
    • Sau khi xem thử nghiệm này, tôi đã dùng xhigh cho một vài tác vụ và thấy khá hiệu quả, nhưng nó ngốn token như điên
      Giờ tôi lại quay về high
  • Phàn nàn lớn nhất của tôi về 5.5 xhigh là nó cứ tự mình làm tiếp mà không hỏi gì cả
    Nhờ vậy mà tôi có cảm giác đã tiết kiệm được vài năm tuổi thọ và một lượng token đáng kể
    • Tôi chủ yếu dùng high và nó cũng hành xử y hệt
      Tôi vẫn đang tìm xem nên viết câu gì trong agents.md để nó đừng tự tiện giả định nữa. Có lúc nó cần biết thêm thông tin trước khi tôi ra chỉ thị coding cho một việc nào đó nên nó hỏi, nhưng thay vì chờ câu trả lời thì lại bắt đầu code luôn. Sau khi xong nó vẫn trả lời cả câu hỏi trong response, nên có vẻ nó có chú ý đến điều tôi nói, nhưng không hiểu rằng nếu có câu hỏi thì nghĩa là chưa nên code ngay
  • Tôi muốn biết liệu bạn đã chạy nhiều lần trên cùng một PR chưa
    Tôi muốn hiểu mức độ biến động giữa các lần chạy của model. Trong ví dụ trên, dù high có thể code tốt hơn, nhưng nếu độ biến động giữa các lần chạy lớn thì dùng xhigh có khi lại tốt hơn
    Ngoài ra, như một thử nghiệm khác, sẽ hay nếu sau khi chạy xong, bạn phản hồi về kết quả công việc, cho nó cập nhật AGENTS.md, skills, rules... bằng cách so sánh với phần chỉnh sửa do con người thực hiện, rồi chạy lại high/xhigh trong một fresh session. Sau vài vòng lặp để cải thiện, nếu thử lại ở mọi mức effort thì có thể việc siết chặt AGENTS.md và skills/rules sẽ nâng chất lượng đầu ra tổng thể lên
    • Tôi chưa chạy mỗi biến thể nhiều lần. Lý do chính là chi phí và giới hạn token. Ví tiền của tôi không vô hạn, nhưng đó là một ý tưởng rất hay cho nghiên cứu tiếp theo
      Tôi thực sự thích ý tưởng tối ưu hóa AGENTS.md, và thực tế tôi đã để Stet — thứ tôi tạo ra để chạy thí nghiệm — làm việc này. Tôi cho Codex chạy trên một số tác vụ, xem điểm số và kiểu thất bại, rồi để nó chỉnh AGENTS.md và chạy lại, tất cả đều hoàn toàn tự động. Nó hoạt động như một dạng nghiên cứu tự động cho AGENTS.md, và khá thú vị khi thấy nó quay lại với những cải tiến dựa trên dữ liệu được áp dụng vào AGENTS.md
  • Giờ chắc còn cần cả chỉ số CPI cho lạm phát giá nữa. CPI hằng tháng cảm giác gần như 100%