Bạn tung ra ba lượt chạy trước bữa trưa. Chín mươi giây sau, hai trong ba terminal chẳng in ra gì cả. Một cái đang suy luận xuyên qua kho mã. Một cái khác dính lỗi 504 ngay khi khởi chạy và sẽ không bao giờ quay lại. Từ chỗ bạn ngồi, cả hai chỉ là cùng một khung scrollback với một con trỏ nhấp nháy.
Đây không phải vấn đề mới, nhưng các bản ra mắt ngày 22/09/2026 khiến nó tệ hơn theo một cách cụ thể và có thể đo lường được. Các mức suy luận cao nhất trên những mô hình mới đánh đổi lấy độ chính xác bằng việc suy nghĩ rất lâu trước khi nói bất cứ điều gì. Artificial Analysis đo được biến thể suy luận “max” của GPT-6 Sol mất 102,15 giây đến token đầu tiên, còn GPT-6 Luna là 124,23 giây. Đây là các phép đo của bên thứ ba trên một cấu hình cụ thể, không phải số liệu của nhà cung cấp, và lưu ý đó rất quan trọng, nhưng xu hướng thì không có gì phải nghi ngờ: khoảng lặng ở đầu một lượt chạy giờ đây dài đến mức không thể phân biệt được với một thất bại.
TL;DR
Thời gian đến token đầu tiên là khoảng trễ giữa lúc gửi yêu cầu và lúc ký tự đầu tiên của câu trả lời xuất hiện, và trên một mô hình suy luận ở mức effort cao thì phần lớn quá trình suy nghĩ diễn ra chính trong khoảng trễ đó. Một terminal không thể cho bạn biết sự khác biệt giữa một lượt chạy đang suy nghĩ, một lượt chạy đang chờ người trả lời, và một lượt chạy đã chết từ hai phút trước, bởi cả ba đều không in ra gì. Một trạng thái thì có thể. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, trao quyền và nghiệm thu kết quả. Để hợp đồng đó vận hành được, cần có một trạng thái lượt chạy hiển thị rõ mà không đòi hỏi ai đó phải ngồi canh: Sharkly lưu giữ ngữ cảnh, tiến độ, điểm nghẽn, kết quả và phần người kiểm duyệt ngay trên Task từ lúc đưa ra yêu cầu đến lúc phát hành, nhờ đó một quãng suy nghĩ dài và một lượt chạy đã chết không còn trông giống nhau nữa.
Thời gian chờ dài hơn, và mô hình rẻ không phải mô hình nhanh
Dưới đây là những gì các phép đo của bên thứ ba cho thấy về hai mô hình GPT-6 mới ở mức suy luận tối đa.
| Mô hình | API id | Tốc độ đầu ra | Thời gian đến token đầu tiên | Đầu vào / đầu ra mỗi 1M token |
|---|---|---|---|---|
| GPT-6 Sol (max) | gpt-6-sol |
115,2 token/s | 102,15s | $2 / $10 |
| GPT-6 Luna (max) | gpt-6-luna |
153,9 token/s | 124,23s | $0,10 / $0,50 |
Hãy đọc hai cột cuối cùng cùng nhau. Luna có giá bằng một phần hai mươi so với Sol trên mỗi token mà còn khiến bạn chờ lâu hơn trước khi lên tiếng. Chi phí và độ trễ là hai trục riêng biệt, và trực giác cho rằng mô hình rẻ hơn thì phản hồi nhanh hơn đơn giản là sai trong trường hợp này.
Hai lưu ý thẳng thắn trước khi ai đó dựng dashboard dựa trên những con số đó. Thứ nhất, chúng đến từ Artificial Analysis chứ không phải từ OpenAI, và chúng mô tả cụ thể các biến thể suy luận “max”. Các mức effort thấp hơn là chuyện hoàn toàn khác, và con số của chính bạn sẽ thay đổi theo kích thước prompt, khả năng dùng công cụ, cùng nơi lưu lượng của bạn đổ về. Thứ hai, thời gian đến token đầu tiên không phải là phép đo giống với tốc độ đầu ra. Anthropic cho biết Claude Opus 5.5 tạo đầu ra nhanh hơn Opus 5 khoảng 30%, nhưng đó là phát biểu về các token phía sau token đầu tiên. Một mô hình có thể stream rất nhanh mà vẫn để bạn nhìn vào khoảng không suốt một phút rưỡi.
Một terminal im lặng không phải là một trạng thái
Sự im lặng trên terminal có ít nhất bốn nguyên nhân, và terminal hiển thị tất cả chúng giống hệt nhau:
- Runtime đang làm việc. Quá trình suy luận đang diễn ra, chưa có đầu ra.
- Lượt chạy đã kết thúc từ lúc nào đó và đang chờ người trả lời một câu hỏi.
- Yêu cầu đã thất bại. Tài liệu Sharkly nói thẳng về việc trường hợp này dễ bị hiểu nhầm đến mức nào: “Timeout / 408 / 504 nghĩa là yêu cầu bị chậm, bị hủy hoặc bị gateway làm trễ. Điều đó không giống với việc Computer đang offline.”
- Computer thực sự đã biến mất, hoặc thư mục mà lượt chạy cần chưa bao giờ được giải phóng.
Một agent, một terminal, và bạn giải quyết bằng cách chờ thêm một phút. Năm agent trải trên ba kho mã và hai Computer, và bạn giải quyết bằng cách chuyển qua lại giữa các cửa sổ rồi đoán mò. Đó chính là dáng vẻ thường thấy của sự hỗn loạn agent: không phải một thất bại kịch tính, chỉ là một nhóm đang dồn sự chú ý vào câu hỏi “cái này còn sống không?” vài lần mỗi giờ.
Phản xạ mà người ta thường dùng là tắt nó đi rồi chạy lại. Ở mức suy luận cao, phản xạ đó tốn kém gấp đôi. Bạn phải trả giá cho toàn bộ thời gian chờ token đầu tiên một lần nữa, và bạn ném đi phần suy nghĩ vừa mới sắp sửa xuất hiện.
Một trạng thái phải phân biệt được những gì
Mô hình của chính Sharkly đáng để học theo dù bạn có dùng Sharkly hay không, vì nó tách rời hai thứ mà terminal gộp làm một. Đó cũng chính là cách tách giúp trạng thái lượt chạy, log và tín hiệu thất bại trở nên dễ đọc. Một lượt chạy có trạng thái thực thi: Queued, Dispatched, Waiting for local directory, Running, Completed, Failed hoặc Canceled. Một Task có trạng thái vòng đời, và một Agent có thêm trạng thái làm việc nằm bên trên: Working, Waiting for human reply, Waiting for human review hoặc Error. Tài liệu nói rõ ranh giới này: những trạng thái lượt chạy đó “không tự động ngụ ý rằng Task có cùng trạng thái quy trình làm việc.”
Cách tách đó chính là toàn bộ câu trả lời cho câu hỏi kẹt hay đang suy nghĩ.
| Terminal hiển thị gì | Thực tế có thể là gì | Cái gì phân biệt chúng | Ai hành động tiếp theo |
|---|---|---|---|
| Không có gì, sau 100 giây | Running, trước token đầu tiên | Trạng thái lượt chạy là Running, log có dấu thời gian dispatch | Không ai cả. Cứ để nguyên. |
| Không có gì, sau 10 phút | Waiting for human reply | Trạng thái làm việc đã đổi, Task tạo một mục cần chú ý trong Inbox | Assignee trả lời ngay trong ngữ cảnh |
| Không có gì, mãi mãi | Failed | Trạng thái lượt chạy là Failed, log thực thi ghi lại tiêu đề và phản hồi gốc từ dịch vụ mô hình | Assignee đọc log trước khi thử lại |
| Không có gì, chưa từng khởi chạy | Queued hoặc Waiting for local directory | Trạng thái lượt chạy, kèm thông tin pool thư mục nào đang bận | Giải phóng một thư mục hoặc tăng khả năng chạy song song |
Không dòng nào trong bốn dòng trên đòi hỏi phải có người ngồi nhìn đúng lúc nó thay đổi. Đó chính là điểm mấu chốt. Trạng thái được ghi lại, và câu hỏi “nó đang suy nghĩ hay đang kẹt?” trở thành thứ bạn tra cứu, thay vì thứ bạn phải ngồi chịu đựng.
Cái timeout theo từng Task bạn đặt hồi tháng Ba
Một Agent trong Sharkly mang theo số Task chạy song song tối đa và một timeout cho từng Task. Phần lớn các nhóm đặt timeout đó một lần, từ sớm, dựa trên việc họ sẵn sàng nhìn chằm chằm vào terminal trong bao lâu. Nếu con số đó là hai phút và sau đó bạn đã chuyển một Agent sang mức suy luận max, thì bạn đã cấu hình một chính sách hủy các lượt chạy ngay trong giai đoạn suy nghĩ và báo chúng là thất bại.
Tuần này hãy đi xem lại con số của bạn. Ngưỡng sàn không phải là “tôi sẵn sàng chờ bao lâu”, mà là “Runtime này mất bao lâu ở đúng mức effort tôi đang dùng, cộng thêm chính khối lượng công việc”. Với một lượt chạy mà chỉ riêng token đầu tiên đã có thể mất hơn một trăm giây, một timeout dưới năm phút chẳng khác nào tung đồng xu mà khoác áo chính sách.
Có hai cài đặt liên quan cũng đáng xem lại trong cùng lượt rà soát. Số Task chạy song song tối đa mới là giới hạn đồng thời thực sự của bạn, và khi mọi thư mục đã cấu hình đều bận, các lượt chạy mới sẽ nằm ở Waiting for local directory thay vì thất bại — đây là hành vi đúng, nhưng trông như bị treo nếu bạn chỉ nhìn vào terminal.
Cache có giải quyết được không?
Một phần, và không phải phần bạn muốn. Tính năng prompt caching của OpenAI cho GPT-6 giảm giá 90% khi đọc input từ cache với tỷ lệ trúng cache cao hơn theo mặc định, bổ sung các breakpoint tường minh để bạn tự chọn điểm kết thúc của một tiền tố được cache, và không còn phá vỡ cache khi bạn thay đổi mức suy luận hay khả năng dùng công cụ. GitHub báo cáo số token prompt cần xử lý mới giảm hơn 50% trên hàng tỷ yêu cầu. Đó là một thắng lợi thực sự về chi phí và độ trễ ở phần prompt, và việc sửa lỗi khi thay đổi effort thực sự hữu ích cho những agent nâng một task từ mức rẻ lên mức đắt ngay giữa luồng.
Nó không loại bỏ được lượt suy luận. Cache đã nóng nghĩa là ít phần prompt của bạn phải xử lý lại từ đầu hơn. Điều đó không có nghĩa là mô hình đã suy nghĩ sẵn về lỗi của bạn. Dù sao thì hãy tính trước khoản thời gian chờ đó.
Khi nào nên chấp nhận chờ, khi nào không
Hãy dùng mức suy luận tối đa khi đó là task bạn không muốn phải chạy lại lần hai: một cuộc migration, một đợt refactor ảnh hưởng nhiều phần, hay bất cứ việc gì mà một câu trả lời sai tốn hơn chín mươi giây. OpenAI báo cáo Sol ở mức xhigh đạt 33,2% trên AutomationBench 1.0.6 với 0,27 đô-la mỗi task — đó chính là hình dạng của sự đánh đổi này. Độ chính xác giờ đây rẻ về tiền nhưng đắt về thời gian thực.
Hãy dùng mức effort thấp hơn khi có người đang ngồi đó chờ câu trả lời. Công việc tương tác, một câu hỏi nhanh về một file, một bản sửa nhỏ trong phạm vi hẹp: vấn đề im lặng gần như biến mất ở mức effort thấp hơn, vì token đầu tiên xuất hiện khi bạn vẫn còn nhớ mình đã hỏi gì.
Và đây là ranh giới thẳng thắn: nếu bạn chỉ chạy một agent trên một Task, bạn không cần một bảng điều khiển cho việc này. Cứ tail log. Vấn đề trạng thái bắt đầu từ lúc số lượt chạy vượt quá số terminal mà bạn có thể theo dõi một cách có ý nghĩa, và với hầu hết mọi người con số đó là khoảng ba.
Điều này không giải quyết được gì
Một trạng thái cho bạn biết lượt chạy đang Working. Nó không cho bạn biết lượt chạy đó đang làm điều gì hữu ích, và một agent sai một cách đầy tự tin vẫn hiển thị trạng thái xanh y như một agent tốt trong suốt thời gian lượt chạy kéo dài, mà với Opus 5.5 có thể là 18 tiếng hoặc hơn. Phân biệt “đang chạy” với “đang chạy tốt” vẫn là một bài toán review, và review vẫn là việc của con người. Tự động hóa dừng lại ở nơi cần đến phán đoán của cả nhóm.
Nếu bạn đã chạy nhiều agent cùng lúc, thay đổi nhỏ mà hữu ích nhất trong tuần này không phải là một mô hình mới. Mà là làm cho trạng thái của mọi lượt chạy đọc được mà không cần mở terminal, để chín mươi giây im lặng tiếp theo là thông tin chứ không phải một câu hỏi.
