Tokenmaxxing đã chết, vạn tuế Tokenmaxxing

• Trong giai đoạn đầu doanh nghiệp áp dụng AI, tokenmaxxing — việc gắn lượng token sử dụng với đánh giá hiệu quả — đã tạo ra chi phí vô nghĩa, nhưng đồng thời cũng đóng vai trò ép việc dùng công cụ AI lan rộng trong tổ chức
• Tại Meta, khi lượng token dùng của từng cá nhân bị gắn với đánh giá, đã xuất hiện cả những kiểu sử dụng hình thức như cho hai agent nói chuyện với nhau cả ngày chỉ để tăng chỉ số token
• Trước đây, việc chạy agent trong thời gian dài rất rủi ro do lỗi tích lũy (compounding error) khi các lỗi nhỏ chồng chất lên nhau, nhưng gần đây đang nổi lên xu hướng độ đúng tích lũy (compounding correctness), nơi nhiều token hơn tạo ra kết quả tốt hơn
• Trong lĩnh vực bảo mật, đã xuất hiện cách làm đổ ngân sách token lớn vào các model như Mythos để tìm lỗ hổng, và đang hình thành cấu trúc mà bên phòng thủ phải dùng nhiều năng lực tính toán hơn kẻ tấn công
• Trong tương lai, thay vì chi tiêu không giới hạn cho các model đắt đỏ hàng đầu, trọng tâm thực dụng của tokenmaxxing có thể là chạy lặp nhiều hơn với các open model giá rẻ

---

Tokenmaxxing bắt đầu từ việc đốt token vô nghĩa

• tokenmaxxing chỉ hiện tượng lãnh đạo thúc ép nhân viên dùng thật nhiều token, khiến token bị tiêu tốn cả vào những công việc có giá trị thực tế thấp
• Ví dụ điển hình là Meta bị chỉ trích vì gắn đánh giá hiệu suất với lượng token sử dụng của từng cá nhân
  • Một nhân viên Meta cho biết đã cho hai agent nói chuyện với nhau cả ngày để đẩy chỉ số token lên
• Bề ngoài, điều này giống như ban quản lý đang đốt chi phí mà không tạo doanh thu, nhưng cũng có thể xem là một chính sách nhằm cưỡng ép phổ biến việc dùng công cụ AI
• Chỉ vài tháng trước thôi, trong tổ chức vẫn còn nhiều nhân sự senior phản đối mạnh việc dùng công cụ AI, và ngay cả khi thuyết phục được họ thì họ cũng thường dùng công cụ theo cách kỳ quặc hoặc dễ cho ra kết quả tệ
• Trong bối cảnh đó, áp lực dùng token từ trên xuống đã hoạt động như một biện pháp cưỡng chế thô bạo để phá vỡ bức tường này

Chính sách dùng không giới hạn đầu tiên kết thúc vì áp lực chi phí

• Chính sách tokenmaxxing đã tạo ra hiệu quả ở một mức độ nhất định, và hiện tại gần như mọi team đều đã ít nhất viết code với AI ở một mức nào đó
• Nhiều team vẫn chưa xây được các hệ thống riêng như Ramp Inspect hay Stripe Minions, nhưng về cơ bản đã đạt đến mức dùng Cursor trong sidebar
• Trong khi lượng token sử dụng tăng mạnh, OpenAI và Anthropic — trong bối cảnh thúc đẩy IPO — đã giới hạn mức cung trong gói thuê bao và tăng giá API
• Khi trợ cấp token cũng giảm đi, đã có những team bắt đầu rút lại chính sách dùng token không giới hạn
• tokenmaxxing không giới hạn theo nghĩa cũ đang tiến gần tới giai đoạn khó lòng vượt qua được khâu rà soát chi phí

Từ lỗi tích lũy sang độ đúng tích lũy

• Kỳ vọng dành cho công cụ AI là xử lý những việc khó và nhàm chán mà không cần con người giám sát liên tục
  • Di trú mã nguồn quy mô lớn
  • Nghiên cứu đối thủ cạnh tranh mỗi sáng
  • Xử lý luồng inbound và outbound
• Trước đây, AI chạy càng lâu thì những lỗi nhỏ và ảo giác của model càng tích tụ trong dự án, khiến việc hoàn tác trở nên khó khăn
• Hiện tượng này được gọi là lỗi tích lũy (compounding error), và vì cần rất nhiều giám sát của con người nên cũng không có nhiều lý do để chạy agent 24 giờ
• Giờ đây, môi trường đang chuyển sang độ đúng tích lũy (compounding correctness), nơi dùng nhiều token hơn làm tăng khả năng đi đến đáp án đúng
• Nếu chi tiêu token gắn trực tiếp với chất lượng kết quả, thì động lực dùng thật nhiều token sẽ xuất hiện trở lại

Cuộc đua ngân sách token thể hiện sớm nhất trong bảo mật

• Trong an ninh mạng, đã xuất hiện những trường hợp mà chi tiêu token gắn trực tiếp với thành quả
• Cybersecurity is Proof of Work Now lấy Mythos của Anthropic làm ví dụ và cho rằng để gia cố hệ thống, bên phòng thủ phải dùng nhiều token hơn cho việc tìm lỗ hổng so với số token mà kẻ tấn công dùng để khai thác
• AISI đặt ngân sách 100M token cho mỗi lần thử với Mythos, tương đương $12,500 mỗi lần và $125,000 cho 10 lần chạy
• Các model được cấp ngân sách 100M token không cho thấy dấu hiệu lợi nhuận giảm dần, và AISI cho biết trong phạm vi ngân sách token được thử nghiệm, model vẫn tiếp tục tiến bộ khi ngân sách tăng lên
• Trong cấu trúc này, khối lượng tính toán và ngân sách token có thể chi trả trở nên quan trọng hơn sự khôn khéo

Loop và việc chạy agent dài hạn

• Mối quan tâm tới loops mà Boris Cherny nói tới trên sân khấu Claude Code cũng gắn với cùng xu hướng đó
• Cấu trúc cơ bản của loops là để agent chạy cho đến khi kết thúc lượt của nó, rồi khi xong thì khởi động lại cùng một prompt
• Có thể tự động chia nhỏ những đặc tả nặng và để agent giải quyết từng phần theo thời gian
• Khái niệm này không mới; nó đã xuất hiện từ tháng 7 năm ngoái và từng được gọi là “Ralph Wiggum loop”
• Trước đây, cách này đòi hỏi hiểu biết sâu về thiết kế prompt và cách agent hoạt động, nhưng nhờ độ đúng tích lũy, giờ đây dễ kỳ vọng hơn vào các kết quả gần đúng sẽ cải thiện dần theo từng vòng lặp

Open model tạo ra khả năng lặp lại tốt hơn trên chi phí

• Về dài hạn, bên chiến thắng của tokenmaxxing có thể là nền tảng open model
• Cách đổ lượng lớn token vào các model hàng đầu từ những phòng lab top-tier rất khó vượt qua khâu rà soát của CFO
• Open model càng tốt lên, cách chạy lặp nhiều hơn với model rẻ sẽ càng trở nên hấp dẫn
• Ví dụ, nếu Claude cho mức cải thiện 1.1 lần mỗi vòng lặp còn GLM 5.2 cho mức cải thiện 1.05 lần nhưng chi phí chỉ khoảng 1/5, thì có thể chạy loop với GLM 5.2 nhiều hơn 5 lần sẽ có lợi hơn
• Ngay trong mục “Other things”, GLM 5.2 cũng được đánh giá là chưa phải tối tân nhất nhưng rẻ hơn rất nhiều so với các frontier model
  • GLM 5.2: khoảng $1.4 cho mỗi 1 triệu token đầu vào, $4 cho mỗi 1 triệu token đầu ra
  • Dòng Opus 4.X: $5 cho mỗi 1 triệu token đầu vào, $25 cho mỗi 1 triệu token đầu ra
  • Haiku 4.5: $1 cho mỗi 1 triệu token đầu vào, $5 cho mỗi 1 triệu token đầu ra
  • GLM 5.2 được cho là mạnh hơn Haiku, và trong một số benchmark thậm chí còn mạnh hơn GPT 5.5

Khác biệt giữa chi tiêu cho developer và chi tiêu cho pipeline

• tokenmaxxing có hai dạng khác nhau
• Dạng thứ nhất là chi tiêu token cho developer
  • Developer dùng các công cụ như Claude Code, chạy loops và tiêu thụ rất nhiều token
  • Nếu giúp tăng năng suất kỹ sư, đây có thể là khoản chi tốt
• Dạng thứ hai là chi tiêu token cho pipeline
  • Developer vẫn viết code bằng tay, rồi dùng code đó để tạo các agent dùng một lần cho từng tác vụ cụ thể
  • Những agent này hoạt động theo cách không xác định và mong manh, đồng thời tiêu tốn nhiều token
  • Đây chỉ là khoản chi tốt khi pipeline thực sự vận hành được, nhưng các agent như vậy vốn không chính xác bằng pipeline có tính xác định
• Nếu thêm một agent kiểm tra chất lượng để giảm chi phí do ảo giác, rồi lại gắn thêm một agent khác để bắt lỗi của agent kiểm tra, thì chi phí token sẽ tăng gấp 3
• Xu hướng đang lớn dần là các công cụ pipeline dùng một lần sẽ được xử lý như một nền tảng đa dụng bọc vỏ theo từng tác vụ, thay vì là các agent dành riêng cho từng công việc cụ thể

Software factory và chi tiêu token cực đoan

• Điểm đến tự nhiên là software factory, và xa hơn nữa là dark factory
• Trong cấu trúc này, codebase sẽ tự tạo code, review, sửa bug và viết test mà không cần giám sát của con người
• Con người chỉ còn vai trò đưa vào đặc tả và nhận lại ứng dụng
• Software factory của StrongDM được nhắc đến như một ví dụ đẩy hướng đi này tới cực hạn
• Phía StrongDM cho rằng kỹ sư nên nhắm tới mục tiêu dùng token trị giá $1000 mỗi ngày, nhưng điều này được đánh giá là mang tính cường điệu và quảng bá nhiều hơn
• Họ nói software factory nội bộ của mình dùng khoảng $600 mỗi tháng, và hiện tại việc chi mức token tương đương chi phí một kỹ sư senior của Google cho mỗi kỹ sư là quá đà
• Dù vậy, động lực chi mạnh tay cho token vẫn có khả năng tồn tại và hiện mới chỉ đang chờ lan rộng