OpenAI thu nhỏ kích thước context của mô hình Codex từ 372k xuống 272k

 (github.com/openai)
1 điểm bởi GN⁺ 1 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • OpenAI đã cập nhật metadata mô hình bundled của Codex và backport thay đổi giảm kích thước context của mô hình từ 372k xuống 272k vào nhánh release/0.144
  • PR #33972 chuyển các thay đổi từ nhánh agent/hotfix-0.144-model-metadata sang bản phát hành Codex 0.144
  • Phạm vi thay đổi là 1 tệp JSON, với thống kê diff là thêm 64 dòng và xóa 54 dòng
  • Được merge qua 1 commit và 36 kiểm tra, không có nội dung trao đổi hay review riêng
  • Trên trang được cung cấp, file diff không tải được nên không thể xác nhận các thay đổi metadata cụ thể ngoài việc thu nhỏ context

Mục đích và phạm vi thay đổi

  • Tiêu đề PR là công việc backport metadata mô hình bundled đã được làm mới vào Codex 0.144
  • Theo tiêu đề trên Hacker News, kích thước context của mô hình đã được thu nhỏ từ 372k xuống 272k
  • Nhánh đích là openai:release/0.144, nhánh nguồn là sayan-oai:agent/hotfix-0.144-model-metadata

Kết quả merge

  • PR #33972 gồm 1 commit b06f4fa
  • Tiêu đề commit là Backport refreshed bundled model metadata
  • Được merge vào ngày 18 tháng 7 năm 2026, hiển thị 36 kiểm tra và 1 tệp thay đổi
  • Khối lượng thay đổi là thêm 64 dòng và xóa 54 dòng, định dạng tệp là JSON

Các hạn chế có thể xác nhận

  • Khu vực tệp và bình luận trên trang hiển thị lỗi tải, nên diff JSON thực tế không thể được xác nhận từ nội dung được cung cấp
  • Nội dung không bao gồm quy trình tái hiện, lý do thay đổi, tác động tương thích hay phản hồi review

Bài viết liên quan

1 bình luận

 
GN⁺ 1 ngày trước
Ý kiến trên Hacker News

  • Mọi người nói rằng nén là giải quyết được, nhưng trong công việc của tôi, có quá nhiều chi tiết bị mất do nén
    Nếu kế hoạch đơn giản hoặc không thảo luận quá chi tiết thì có thể ổn, nhưng vì thiếu ngữ cảnh dài nên cuối cùng tôi vẫn tiếp tục dùng Anthropic
    Khi cần ghi nhớ trọn vẹn nhiều bài báo hoặc tài liệu lớn, phức tạp, ngữ cảnh luôn dừng ở mức 16%. Nói chuyện khoảng 5 phút là bị nén, rồi lại phải cho đọc tài liệu để lên tới 16%, và quá trình đó cứ lặp lại
    Ngữ cảnh 372k cũng không hoàn hảo, nhưng nó tăng phần dư vốn chỉ 12–20% lên khoảng 40%, nên giúp ích rất nhiều

    • Không thể tắt tự động nén và cũng không thể quay lại lịch sử hội thoại trước khi nén, nên với codebase hơn 5.000 dòng thì không thể dùng Codex
      Nó chạy ngẫu nhiên khi ngữ cảnh còn lại 10–20%, nên thực tế chỉ dùng được 80% của 272k. Sau khi nén thì ảo giác nghiêm trọng hơn, còn tệ hơn bắt đầu lại từ đầu, rồi lại rơi vào vòng lặp đọc lại codebase và tiếp tục bị nén
    • Quy trình thiết kế của tôi khác. plan.md được sửa nhiều lần chính là bộ nhớ, và khi khởi động lại phiên, đọc lại rồi rà soát kế hoạch thì dễ có được góc nhìn mới
    • Vì nén quá tệ nên tôi đã làm một công cụ cho phép LLM xóa có chọn lọc một phần ngữ cảnh và khôi phục khi cần. Nếu thường xuyên chạm giới hạn tự động nén thì context bonsai đáng để thử
      https://github.com/Vibecodelicious/context-bonsai-agents
    • Mô hình của Anthropic cung cấp ngữ cảnh 1 triệu token. Tôi định chuyển sang OpenAI vào tháng tới, nhưng thấy vẫn còn quanh mức 300k thì có lẽ phải thích nghi với thực tế mới
    • Thường thì người ta khuyên nên để agent thỉnh thoảng tạo hoặc cập nhật file .md để ghi nhớ thông tin quan trọng mới xuất hiện. Nhưng nếu agent thật sự biết chính xác điều gì là quan trọng thì /compact cũng phải hoạt động tốt

  • Vì cửa sổ ngữ cảnh lớn nên người ta không còn chọn lọc những gì đưa vào nữa, còn nén thì áp dụng nén mất dữ liệu lên toàn bộ một lượt, khiến cả những chi tiết cần thiết cũng bị mất
    Tôi cho rằng việc gửi lại toàn bộ hội thoại mỗi lần mới là vấn đề căn bản. Với plugin bộ nhớ/ngữ cảnh do tôi làm, mỗi lần tôi làm trống ngữ cảnh rồi chỉ bơm lại thông tin liên quan, nên mô hình chỉ đọc vài nghìn token trạng thái đã được chọn lọc thay vì lịch sử hội thoại 200 nghìn token; nhờ vậy ngữ cảnh nhỏ không thành vấn đề
    Với coding agent thì tôi vẫn chưa giải quyết được, nhưng tôi nghĩ lời giải thật sự là một chính sách lưu giữ chỉ giữ lại những gì cần cho việc hoàn tất tác vụ hoặc tác vụ tiếp theo, còn lại thì bỏ đi, và có thể triển khai bằng một LLM chuyên dụng

    • Nhiều chuyên gia xử lý ngôn ngữ tự nhiên từng nghiên cứu LSTM, GRU, v.v. cũng xem việc gửi lại toàn bộ hội thoại là vấn đề căn bản, nhưng về mặt thực nghiệm thì Transformer đã thắng
      Sẽ thú vị nếu kiến trúc mô hình tương lai xem xét lại vấn đề này. Nếu lấy con người làm chuẩn, điều còn thiếu là khả năng chuyển thông tin hiệu quả từ trí nhớ ngắn hạn sang trí nhớ dài hạn; fine-tuning về nguyên lý có làm việc tương tự, nhưng không hiệu quả

  • Tôi không biết đây có phải lý do của thay đổi này không, nhưng ngay từ đầu tôi cho rằng dùng ngữ cảnh lớn hơn mức này nhìn chung là sai lầm
    Người ta đánh giá thấp mức độ hiệu năng của mô hình giảm đi và chi phí token tăng lên khi ngữ cảnh lớn hơn. Claude không dùng quá 300k mà thay vì nén thì chia nhỏ công việc, đồng thời giữ tài liệu và codebase dạng module thật gọn
    Với tác vụ một lần, ngữ cảnh lớn có thể hữu ích, nhưng nếu thường xuyên vượt 300k thì có khả năng bạn đang đánh mất nhiều thứ hoặc thiết kế codebase không tốt

    • Tôi cũng nén hoặc khởi động lại ở mức 250k. Kích thước ngữ cảnh cần thiết tỷ lệ với quy mô dự án, nên những người cần cửa sổ lớn hơn có vẻ chỉ là đang xử lý dự án lớn hơn
    • Cảm nhận của tôi cũng vậy, và tôi thậm chí sẽ đặt ranh giới ở 100–150k. Dù mô hình hỗ trợ ngữ cảnh dài, hiệu năng thực tế vẫn không tốt
    • Việc ngữ cảnh lớn hơn làm mô hình ngu đi rõ rệt thì không khớp với trải nghiệm của tôi. Nó chậm hơn và đắt hơn, nhưng đó là chi phí phải chấp nhận cho các tác vụ phức tạp
      Agent chính cho các sub-agent điều tra những điều cần thiết và lập kế hoạch, rồi để các sub-agent khác rà soát theo kiểu đối kháng và bổ sung. Khi xong, cửa sổ 1 triệu token đầy 30–40%, một luồng như vậy là bất khả thi với 272k
      Với 5.6 Sol, tôi phải thu nhỏ đáng kể quy trình này, và có lẽ đó cũng là lý do kết quả tệ hơn

  • Khi thay đổi này xảy ra, Tibo đã đăng kèm lời giải thích: https://x.com/thsottiaux/status/2076543065045795309

    • Có thể xem phần trả lời ở đây: https://xcancel.com/thsottiaux/status/2076543065045795309
      Tweet được liên kết là phản hồi không chính thức về thông tin chính thức của Tibo, và Tibo đã chỉnh lại nội dung trong phần trả lời
    • Tôi không hiểu biểu đồ này. Tôi thắc mắc vì sao đường vẫn tiếp tục tăng dù đang nén, hay liệu “overall trajectory size” có một ý nghĩa nào đó mà tôi chưa biết không
    • Tôi không rõ liệu độ dài quỹ đạo tổng thể có thể giống nhau dù cường độ suy luận khác nhau hay không. Ngay cả khi loại token suy luận khỏi độ dài quỹ đạo, điều đó cũng có vẻ không khả thi

  • Không thích cách họ nén context, và cho rằng giờ đây họ nên cung cấp ít nhất 1 triệu token
    GPT 5.5 và 5.6 mỗi khi bị nén đều khựng lại cho đến khi lấy lại tốc độ, và đôi khi quá tập trung vào các thông điệp chỉ dẫn cũ còn sót trong context đã nén

    • GPT-5.6-Sol hiệu quả token khoảng gấp 2 lần Opus/Fable, nên tối đa 258k tương đương khoảng 516k của Claude
      Suy thoái context vẫn là vấn đề[1][2], và cũng có bằng chứng rằng trong các tác vụ agent, nén tương đương hoặc tốt hơn context dài[3]. Tốt nhất là mô hình có thể suy luận trên context 1 triệu như với 256k, nhưng hiện vẫn chưa làm được
      [1] https://arxiv.org/abs/2605.12366
      [2] So sánh GraphWalks 256K và 1M F1 trong Opus 4.8 System Card: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
      [3] https://context-folding.github.io/
    • Khó chịu vì khác với các công cụ coding khác, không thể tắt nén tự động. Nó chạy thất thường khi context còn 10–20%, nên dung lượng được đảm bảo chỉ là 80% của 272k
      Trong một codebase lớn, khi công việc gần xong và chỉ còn khoảng 2 nghìn token phản hồi, nếu tụt xuống dưới 20% thì sau một lúc xử lý sẽ hiện Context compacted. Không thể quay lại trước khi nén, nên lại phải rà soát codebase, rồi lại bị nén tiếp, cuối cùng dùng hết sạch token
    • Hy vọng việc giảm token chủ yếu là để cắt chi phí chứ không phải một cách vòng để tăng mức sử dụng. Ở công ty, những người phụ trách chi phí cũng đã giới hạn context quá nặng, khiến LLM nội bộ ban đầu còn dùng được gần như trở nên vô dụng
      Cứ như giới lãnh đạo có một hội nhóm chia sẻ những thực hành tệ nhất vậy
    • Bộ nhớ làm việc có thể lưu vào file Markdown, không cần context lớn. Khi context tăng, attention bị phân tán và hiệu năng LLM giảm, nên giữ nhỏ sẽ có lợi cho chất lượng

  • Hằng ngày dùng Opus và thường chạy /clear. Ngay cả context 1 triệu cũng nhanh chóng giảm hiệu năng khi tiến gần 50%, nên thường reset ở mức 30–40% sẽ cho kết quả tốt hơn nhiều
    Bắt đầu mới và đưa context cần thiết vào từ đầu hoạt động tốt hơn nén. Cách hiệu quả là sắp xếp tài liệu Markdown theo từng tính năng thành nhiều bộ kỹ thuật, rồi ở lần tải đầu tiên cho biết nên tìm thông tin liên quan đến tác vụ ở đâu

  • Trong Codex, chưa từng cảm thấy kích thước context là vấn đề. Không biết cách nén ra sao, nhưng nó tiếp tục chạy như thể không có giới hạn

    • Có vẻ mới bắt đầu dùng Codex gần đây. Thời gian đầu, lỗi model context size exceeded rất nghiêm trọng, đến mức nén cũng không khôi phục được, và chỉ mới biến mất vài tháng trước
      Giờ đã tốt hơn nhiều, nhưng sau khi nén lại không cho thấy trong concise summary có những gì, nên khó biết nội dung quan trọng có được giữ lại hay không
      Codex dường như đang đi theo hướng che giấu tối đa với người dùng; như gần đây đã mã hóa prompt giữa agent và sub-agent, có vẻ họ cũng có thể mã hóa toàn bộ session log. Đáng tiếc, nhưng đây vẫn là tổ hợp công cụ·mô hình tốt nhất mà tôi từng dùng
    • Codex thường quên hoàn tất tác vụ cuối cùng khi xảy ra nén, đặc biệt nghiêm trọng khi gửi tin nhắn ngay trước lúc nén
    • Phần lớn vấn đề có thể chia để trị, nên khác biệt giữa 300k và 400k hầu như không thành vấn đề. Coding agent không phải là một cuộc trò chuyện vô hạn

  • Dù nén tốt đến đâu, trong dự án lớn vẫn phải đọc rất nhiều file. 200 nghìn token đầu tiên bị tiêu thụ rất nhanh, nhưng sau đó tốc độ chậm lại
    Phần lớn session Fable không vượt quá 500 nghìn token nên không cần nén, nhưng trong Codex thì phải nén liên tục trong một session

    • Lý do phải đọc nhiều file là vì agents.md quá sơ sài. Chỉ cần đọc file đang làm việc thực tế và vài file liên quan, còn lại nên được tổng hợp trong tài liệu

  • Với công việc của tôi thì kích thước này khá nhỏ. Tôi cố giữ dưới 200k, nhưng trong các session DeepSeek và MiMo, nếu đẩy các vòng lặp cuối cùng thì có khi tăng tới 350k token rồi mới nén
    Không biết OpenAI có thể áp dụng công nghệ K/V cache của DeepSeek đã xuất hiện trong các bài báo công khai để giảm mạnh chi phí hay không

    • Có vẻ không nơi nào làm caching tốt như DeepSeek, nên khác biệt triển khai rất lớn và khó bắt chước
      Khi dùng DeepSeek cùng Reasonix, đó là một phương thức chuyên dụng bổ sung được tối ưu theo cấu trúc cache, nên trong các session dài 97–98% token được cache. Một mô hình vốn đã rẻ lại còn rẻ hơn
    • Với các mô hình mở chạy local dựa trên llamacpp, agent sẽ theo chỉ dẫn để nén trong khoảng 55k–85k, và nếu không thật sự cần context lớn như khi truy vết log phức tạp thì hiếm khi lên tới 120k
      System prompt cũng được điều chỉnh để agent tạo sub-agent theo ngân sách suy luận và message của llamacpp rồi nén nội dung. Dùng dynamic context pruning của opencode để giữ định hướng mà không phình to dung lượng, nhìn chung hoạt động tốt khi phát triển lặp lại nhiều thành phần con

  • Trong hai tháng qua, với nhu cầu của tôi thì OpenAI tốt hơn nhiều nên đã chuyển từ Claude sang OpenAI. Tò mò không biết thay đổi lần này có khiến khác biệt về chất lượng đầu ra trở nên cảm nhận được không