Claude 5.5: Ngừng trả tiền cho các tác vụ thất bại

Cách thiết lập Sonnet và Opus thực sự quan trọng: effort, cache, xác minh và chi phí cho mỗi tác vụ hoàn thành

Mô hình rẻ nhất không phải là mô hình có giá token thấp nhất

Mà là mô hình hoàn thành công việc, vượt qua bước kiểm tra và không bắt bạn phải trả tiền cho cùng một context thêm năm lần nữa

Sonnet 5.5 và Opus 5.5 khiến sự khác biệt này trở nên đặc biệt quan trọng. Một bên được định giá cho khối lượng lớn. Bên còn lại được định giá cho những việc khó nhằn hơn. Cả hai đều có hành vi effort mới, và cả hai đều có thể rẻ đến bất ngờ khi chạy trong một agent loop được tối ưu cache tốt

Nếu bạn bê nguyên cấu hình cũ vào một trong hai mô hình, kết quả có thể chậm hơn, đắt hơn, hoặc dính lỗi 400

Đây mới là cách thiết lập mà tôi sẽ xây dựng

1TÁC VỤ → SONNET 5.5 → KIỂM TRA → OPUS 5.5 NẾU CẦN → KẾT QUẢ ĐÃ XÁC MINH
2             ↘ effort ↗         ↘ sổ ghi chép cache + mức sử dụng ↗

Tôi thường xuyên chia sẻ các bài phân tích thực tế về AI agent, quy trình làm việc và hệ thống production trên Substack

Đăng ký nhận bản tin tại đây

Con số quyết định kiến trúc hệ thống của bạn

Hầu hết các bài so sánh mô hình đều bắt đầu bằng số đô la trên mỗi triệu token

Nhưng agent của bạn không giao token. Nó giao các tác vụ đã hoàn thành

https://x.com/claudeai/status/2102435511222890900

Xin nhắc lại: đó là bài test của họ. Kiến trúc của bạn cần những con số của riêng bạn

Điều đó có nghĩa là bước kiểm tra không thể chỉ là cái gật đầu đại khái sau khi đọc một câu trả lời nghe có vẻ ấn tượng. Với code, hãy dùng chính bài test chặn lệnh merge. Với trích xuất dữ liệu, hãy đối chiếu các trường bắt buộc với một tập dữ liệu mẫu. Với nghiên cứu, hãy ghi nhận xem nguồn trích dẫn có thực sự hỗ trợ từng luận điểm hay không. Hãy tính cả chi phí của những tác vụ không bao giờ vượt qua vòng kiểm tra, chứ đừng chỉ nhìn vào vài ví dụ đẹp mắt trong bản demo

Và hãy soi kỹ phần đuôi phân phối (hard tail). Nếu thiết lập rẻ nhất xử lý được 90% yêu cầu nhưng lại ngốn nửa ngân sách cho 10% còn lại, thì con số trung bình có thể che giấu phần quy trình đang thực sự cần một mô hình khác

Bảng giá 5.5 thực sự nói lên điều gì

Tính đến ngày 3 tháng 10 năm 2026, theo mức giá API Claude tiêu chuẩn, trên mỗi triệu token:

1SONNET 5.5
2Input mới    $2       Output  $10
3Cache read   $0.20    Cache write  $2.50 / 5 phút, $4 / 1 giờ
4
5OPUS 5.5
6Input mới    $4       Output  $20
7Cache read   $0.20    Cache write  $5 / 5 phút, $8 / 1 giờ

Cả hai mô hình đều có context window 1 triệu token và output tối đa 128K token. Đây là giới hạn trần, không phải lý do để bạn cố nhồi nhét cho đầy

Thông số kỹ thuật và bảng giá mô hình

Điểm thú vị nằm ở dòng cache read

Opus đắt gấp đôi ở input và output mới, nhưng prefix được lưu cache lại có giá giống hệt nhau: $0.20 mỗi triệu token trên cả hai mô hình. Điều này không có nghĩa là chạy Opus sẽ rẻ ngang Sonnet: nó vẫn tốn nhiều tiền hơn cho input mới, output và cache write. Nhưng nó cho thấy khoảng cách giá giữa hai mô hình có thể thu hẹp đáng kể trong các phiên làm việc thiên về đọc

Có một điểm khác biệt thứ hai mà nhiều người bỏ lỡ. Con số "rẻ hơn 40% so với Opus 5" của Anthropic chỉ là ước tính cho \chi phí chạy\ thông thường. Giá token mới của Opus 5.5 giảm 20%; còn giá cache-read giảm tới 60%. Những con số này có liên quan, nhưng không thể đánh đồng với nhau

Effort là quyết định điều hướng, không phải thanh trượt chất lượng

Sonnet 5.5 hỗ trợ low, medium, high, xhigh và max. Trên API, mặc định là high, còn trong các ứng dụng Claude, Anthropic cho biết medium mới là mức mặc định. Opus 5.5 mặc định là medium trên API. Các mức này không mang ý nghĩa y hệt như những từ tương tự trên các mô hình đời trước.

Bản đồ khởi điểm của tôi:

• Sonnet low Dành cho các yêu cầu hẹp, nhạy cảm về độ trễ và có bước kiểm tra rẻ
• Sonnet medium Dành cho code có đặc tả rõ ràng và các tác vụ nhiều bước thông thường
• Sonnet high Khi bản chạy medium trượt bài test thực tế, hoặc tác vụ có mô hình độ phức tạp đã được chứng minh
• Opus medium Dành cho các tác vụ mơ hồ, liên quan nhiều file, tầm nhìn dài mà Sonnet cứ loay hoay vòng vo
• Xhigh/max Chỉ dùng khi bộ eval của bạn cho thấy lợi ích thu lại xứng đáng với thời gian và token bỏ ra thêm

Đây chỉ là giả thuyết ban đầu, không phải chân lý áp dụng cho mọi nơi. Trong kết quả FrontierCode mà Anthropic công bố cho Sonnet 5.5, xhigh lại ghi điểm cao hơn max. Bỏ ra nhiều effort hơn không đảm bảo kết quả tốt hơn

Chú thích của Anthropic giải thích nghịch lý này: ở mức max, mô hình thường tự khởi động thêm các bước review code. Trong hai trường hợp được khảo sát, điều đó dẫn đến timeout hoặc can thiệp sửa đổi vượt quá phạm vi tác vụ.

Lỗi ở đây không phải là "mô hình suy nghĩ chưa đủ sâu", mà là dồn effort sai chỗ. Nếu agent của bạn vốn đã vượt qua các bài test, những lượt review thừa thãi chỉ tổ tốn tiền và sinh thêm lỗi mới

https://x.com/edwinarbus/status/2104675431853248816

Ngoài ra, đừng đặt max_tokens thấp rồi gọi đó là tối ưu. Giới hạn này bao gồm cả phần suy nghĩ ẩn và output hiển thị. Nếu bạn cắt cụt giữa chừng, thay vì tiết kiệm, bạn sẽ nhận về một câu trả lời dở dang và phải tốn thêm một lượt chạy nữa

https://x.com/claudeai/status/2104633115620823187

Đó là một tuyên bố ra mắt rất hấp dẫn. Nhưng cấu hình production vẫn phải đánh bại được baseline của chính bạn

Hãy quét thử một vòng nhỏ trước khi tự chế model router

Chọn ra 10-30 tác vụ mà bạn thực sự quan tâm. Bao gồm cả việc dễ, việc mơ hồ và những ca thất bại phiền toái lấy từ log. Gán cho mỗi tác vụ một bộ xác minh: bài test, phép so sánh có cấu trúc, đáp án chuẩn, hoặc thang điểm của con người được chốt trước khi chạy

Dưới đây là đoạn dò API hữu ích và gọn nhẹ nhất. Nó ghi log các trường usage bạn cần. Hãy chạy nó trên từng mô hình và từng mức effort với cùng một tác vụ, sau đó gắn thêm bước pass/fail của riêng bạn. Đây không phải là một bộ benchmark agent hoàn chỉnh

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # lặp lại với claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # lặp lại ở mức high
8    messages=[{"role": "user", "content": "Thay thế nội dung này bằng một tác vụ thực tế."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("input mới", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

Đoạn code này giả định bạn đã cài gói Python chính thức của Anthropic và có biến môi trường ANTHROPIC_API_KEY. Đây là một lời gọi độc lập, không bật cache, nên số lượt cache read và write sẽ bằng không. Phần tiếp theo sẽ chỉ ra điều gì làm thay đổi chuyện đó

Với một agent thực tế, hãy cộng dồn usage qua tất cả các lời gọi API dưới cùng một task ID, bao gồm cả lượt thử lại và tool call. Chỉ tính là pass khi bộ xác minh báo rằng công việc đã xong

Hãy so sánh tổng số đô la cho mỗi lượt pass trước khi chọn cấu hình mặc định

Giữ cho bài test luôn trung thực:

• Chốt cứng tập tác vụ và bộ xác minh trước khi so sánh các cấu hình
• Chạy cùng một bộ tool, quyền hạn, context và yêu cầu output trên mọi ứng viên
• Ghi nhận tỷ lệ pass, tổng chi phí, chi phí mỗi lượt pass, độ trễ, cùng những ca thất bại lâu nhất hoặc đắt đỏ nhất
• Tính stop_reason: "max_tokens" là một nỗ lực chưa hoàn thành, chứ không phải một thành công giá rẻ

Đoạn code mẫu ngắn ở trên dùng giới hạn output 8K cho một lượt dò đơn giản. Đừng copy nguyên giới hạn đó vào một coding agent chạy dài.

Anthropic khuyến nghị nới rộng giới hạn này hơn nhiều cho các tác vụ agentic, bởi phần suy nghĩ ẩn cũng bị tính vào cùng một giới hạn đó.

Hãy đặt giới hạn phù hợp với công việc, rồi kiểm soát chi tiêu bằng effort, cache và ngân sách tác vụ, thay vì ép câu trả lời dừng lại giữa chừng

Hãy cache phần ổn định của công việc

Các agent liên tục gửi đi gửi lại cùng một system instruction, định nghĩa tool, sơ đồ repository và lịch sử hội thoại. Nếu phần prefix đó ổn định, prompt caching sẽ thay đổi bài toán kinh tế nhiều hơn là việc ngồi gọt lại prompt

Ví dụ: 200K token được lưu cache và đọc 50 lần sẽ tạo ra 10 triệu token cache-read. Với giá $0.20 mỗi triệu, chi phí đọc chỉ là $2 trên cả hai mô hình 5.5.

Trên Opus 5.5, nếu gửi 10 triệu token đó dưới dạng input mới, bạn sẽ mất $40. Lượt cache write 200K token đầu tiên (thời hạn 5 phút) tốn thêm $1.

Đây chỉ là ví dụ minh họa cho phí prefix: input mới, output, các lượt write khác, TTL hết hạn và cache miss thực tế sẽ cộng thêm vào hóa đơn

Các quy tắc thực chiến:

• Trên Claude API, hãy bật prompt caching bằng tham số cấp cao cache_control={"type": "ephemeral"} hoặc các breakpoint cache tường minh. Đoạn dò ở trên không dùng cách nào, nên bộ đếm cache của nó thường sẽ đứng yên ở mức 0
• Đặt instruction và tool ổn định trước yêu cầu của user (phần hay thay đổi)
• Giữ nguyên phần prefix dùng chung qua các lượt; hãy kiểm tra con số cache_read_input_tokens thực tế
• Coi việc chuyển mô hình như mở một ngân sách hội thoại mới, không phải nối tiếp miễn phí. Cache hoạt động theo từng mô hình: một request Opus không thể đọc phần prefix mà Sonnet vừa cache
• Tránh đổi effort cấp cao ở mỗi lượt; việc đó làm thay đổi prompt được render và vô hiệu hóa prefix đã cache

Trên các mô hình được hỗ trợ, việc thay đổi effort theo từng message có thể giữ lại phần cache trước đó, nhưng đòi hỏi header beta của Anthropic và không giống với việc đổi output_config cấp cao.

Sonnet 5.5 còn có một lưu ý về between_tools: effort không thể thay đổi giữa chừng cuộc hội thoại ở chế độ đó.

Tài liệu về Prompt caching

Đừng thấy phản hồi nhanh mà vội đoán là trúng cache. Hãy đọc object usage. Nó tách bạch rõ ràng input mới, cache creation và cache read

Cả hai mô hình 5.5 đều cần ít nhất 512 token trong prefix để có thể cache. Một system prompt tí hon sẽ không mang lại khoản tiết kiệm như ví dụ trên. Thời gian sống mặc định của cache là 5 phút, khá vừa vặn cho một tool loop tốc độ cao.

Lượt write thời hạn 1 giờ tốn kém hơn và chỉ hợp lý khi các phiên thực tế thường tạm nghỉ đủ lâu để trượt khỏi khung 5 phút. Hãy đo lường những khoảng trống đó trước khi trả tiền cho TTL dài hơn

Chỉ leo thang khi có bằng chứng, đừng leo thang vì lo lắng

Hầu hết các đội ngũ đều xây dựng router ngược: dán nhãn một tác vụ là "khó", ném nó sang mô hình đắt tiền, và chẳng bao giờ biết liệu đường đi rẻ hơn có vượt qua được hay không

Hãy dùng bộ xác minh làm tín hiệu điều hướng

11  Sonnet 5.5 · effort đã chọn  → chạy tác vụ
22  Bộ xác minh                  → chấp nhận nếu đạt
33  Opus 5.5 · medium            → chỉ thử lại khi có bằng chứng thất bại
44  Bộ xác minh                  → chấp nhận hoặc chuyển tiếp kèm bằng chứng

Bước kiểm tra có thể là một bộ test, validation schema, đáp án chuẩn hoặc người review. Nó cần chỉ ra được lỗi nằm ở đâu.

"Câu trả lời nghe hơi yếu" là một tín hiệu leo thang tồi, còn "endpoint vừa sửa làm trượt hai bài integration test" mới là tín hiệu hữu ích

Đừng mù quáng lặp lại y nguyên một prompt. Hãy cung cấp cho lượt thử tiếp theo bài test bị trượt, các artifact liên quan và một chỉ dẫn cụ thể để vá lỗ hổng. Hãy đặt giới hạn cho thang leo này để agent không đốt sạch ngân sách cố sửa một tác vụ vốn cần con người ra quyết định

Bạn có thể test thử bản retry Sonnet high trong vòng quét offline. Chỉ giữ nó trên luồng live nếu nó thực sự giảm chi phí cho mỗi tác vụ đã xác minh. Không có lý do gì bắt mọi ca thất bại đều phải trả tiền cho hai lượt chạy Sonnet trước khi đụng đến Opus

Bản thân việc chuyển mô hình cũng có thể phá vỡ prefix đã cache. Hãy tính đến điều này khi so sánh đường "cứu hộ" với đường ưu tiên Opus ngay từ đầu

Điểm giao nhau rất dễ bị bỏ qua. Giả sử một lượt chạy Sonnet tốn $0.06 và vượt qua 80% tác vụ của bạn.

Nếu mỗi tác vụ trượt sau đó tốn $0.20 để hoàn thành trên Opus, thì mức trung bình minh họa của bạn là $0.10 cho mỗi tác vụ hoàn thành: $0.06 cộng thêm $0.20 cứu hộ cho một trong năm tác vụ. Con số này tốt hơn việc trả $0.20 cho Opus ở mọi tác vụ. Nhưng nếu Sonnet tốn $0.14 mà chỉ qua được một nửa, thì cùng một thang leo đó sẽ ngốn $0.24, thậm chí chưa tính đến chi phí chuyển mô hình. Trong khối lượng công việc đó, ưu tiên Opus ngay từ đầu lại rẻ và nhanh hơn

Những con số trên chỉ là ví dụ, không phải kết quả đo lường thực tế từ Claude. Mục đích của chúng là giúp quy tắc điều hướng có thể kiểm chứng được. Thang leo này chỉ xứng đáng tồn tại nếu số lượt gọi Opus tiết kiệm được lớn hơn số lượt Sonnet thất bại, cache miss và độ trễ tăng thêm

Còn có một con đường ở giữa: advisor tool beta của Anthropic. Sonnet có thể tiếp tục chạy tác vụ và nhờ Opus tư vấn ở những quyết định khó, thay vì giao toàn bộ công việc cho Opus.

Cách này không tự động rẻ hơn. Hãy ghi log xem Sonnet thực sự hỏi advisor bao nhiêu lần, những lượt gọi đó tốn bao nhiêu và chúng có cải thiện tỷ lệ pass cuối cùng hay không. Nếu executor hiếm khi hỏi, advisor chỉ là một tính năng trang trí.

Với các mô hình 5.5 này, bản thân lời khuyên được trả về client dưới dạng mã hóa, nên hãy đánh giá công việc đầu ra thay vì ảo tưởng rằng bạn có thể kiểm tra nội dung tư vấn riêng tư đó

Bốn lỗ hổng làm đội hóa đơn trước cả khi bạn kịp chọn mô hình

Không phải bài toán chi phí nào cũng cần đến một router mới

Hãy kiểm tra những thứ này trước:

• Output phình to không kiểm soát Trên cả hai mô hình 5.5, token output đắt gấp năm lần token input mới. Trong một cuộc hội thoại, một câu trả lời dài ngoằng còn quay lại làm context cho các lượt sau. Hãy yêu cầu artifact kèm một ghi chú hoàn thành ngắn gọn, thay vì một bản tường thuật từng bước. Phần suy nghĩ ẩn cũng bị tính phí như output, nên chỉ viết câu trả lời cuối thật ngắn gọn sẽ không giải quyết được vấn đề effort. Nhưng cũng đừng lược bỏ những bằng chứng bạn cần để xác minh kết quả
• Ảnh lớn hơn mức tác vụ cần Sonnet 5.5 có thể xử lý ảnh độ phân giải cao hơn các bản Sonnet cũ, dẫn đến số token ảnh tăng lên. Nếu agent chỉ cần đọc nhãn nút bấm hoặc một đoạn văn, hãy crop hoặc resize trước. Nếu nó cần đọc biểu đồ dày đặc hoặc chi tiết UI li ti, hãy giữ nguyên độ phân giải và đo lường chi phí, thay vì mù quáng thu nhỏ ảnh
• Context chẳng ai dùng Định nghĩa tool, log cũ rích, kết quả tìm kiếm hết hạn và một file CLAUDE.md dài dằng dặc có thể bám theo mọi request. Hãy đưa các quy tắc bền vững vào một prefix ngắn và ổn định; giữ bằng chứng tạm thời gần với tác vụ cần đến nó. Việc cắt gọt context không được phép xóa đi những dữ kiện mà mô hình vẫn cần để hoàn thành công việc
• Trả giá tương tác cho những việc chẳng ai chờ Message Batches API giảm 50% phí input và output trên cả hai mô hình. Nó rất hữu ích cho các bài eval offline, backfill tài liệu và những tác vụ bất đồng bộ khác. Nhưng nó không thể thay thế một tool loop realtime, nơi người dùng cần bước tiếp theo ngay lập tức

Mô thức của cả bốn lỗ hổng này đều giống nhau: hãy loại bỏ những phần việc mà tác vụ không cần trước khi mua thêm trí tuệ hoặc hạ effort xuống mức làm hỏng chất lượng

Những cái bẫy di chuyển biến khoản tiết kiệm thành lỗi 400

Dùng lại body request cũ là một khởi đầu tệ hại cho dòng 5.5.

Cụ thể:

• Opus 5.5 luôn bật thinking Hãy xóa thinking: {"type": "disabled"} và các thiết lập budget_tokens cố định kiểu cũ; kiểm soát độ sâu bằng output_config.effort
• Ép chọn tool sẽ gây lỗi trên cả hai mô hình 5.5

Các giá trị any và tool của tool_choice sẽ trả về lỗi 400. Hãy dùng auto, chỉ định rõ khi nào nên dùng tool, và tự validate kết quả tool trong code của bạn

• Thinking block không phải là text block Hãy đọc content theo type, đừng đọc kiểu content [0]. Trong tool loop, hãy trả nguyên vẹn thinking block về ở lượt assistant
• Giao diện của bạn có thể trông như bị đơ Trên Opus 5.5, tiến trình giữa các tool có thể nằm trong các thinking block vốn trống rỗng ở chế độ hiển thị mặc định. Nếu trước đây bạn render những ghi chú đó cho người dùng, hãy yêu cầu một chế độ hiển thị thinking được hỗ trợ và render block theo type. Nếu không, agent có thể đang chạy ngầm trong khi giao diện trông như bị treo
• Các phiên bản tool computer-use cũ có thể thất bại Hãy kiểm tra phiên bản tool hiện tại trước khi di chuyển một browser/computer agent
• Giới hạn max_tokens nhỏ hơn có thể cắt cụt công việc

Phần suy nghĩ vẫn bị tính vào dù text bị ẩn đi

Đây là những thay đổi về hành vi API, không phải mẹo viết prompt.

Hướng dẫn di chuyển Opus và Hướng dẫn di chuyển Sonnet

Hãy đưa hợp đồng vào Claude Code, đừng giữ trong đầu

API là nơi bạn đo lường được mọi trường usage. Còn Claude Code là nơi nhiều người lần đầu cảm nhận được sự thay đổi của mô hình. Nguyên tắc vẫn vậy: hãy cho agent một định nghĩa hoàn thành có giới hạn, rồi bắt nó trưng ra bằng chứng

Trong Claude Code, /model dùng để chọn mô hình và /effort dùng để chọn mức effort được hỗ trợ. Hãy kiểm tra thiết lập đang hoạt động trước khi so sánh các phiên. Mức mặc định của API Sonnet không phản ánh chính xác những gì ứng dụng Claude hoặc phiên Claude Code của bạn đang thực sự dùng

Đây là một khối khởi đầu CLAUDE.md hoàn chỉnh và tái sử dụng được. Hãy sửa lại các lệnh cho khớp với dự án của bạn

1# Hợp đồng làm việc
2
3Chỉ thực hiện đúng thay đổi được yêu cầu. Giữ nguyên các phần không liên quan.
4Chạy các bài test liên quan sau khi sửa. Báo cáo lại bất kỳ bước kiểm tra nào bạn không thể chạy.
5Dừng lại khi phần việc được yêu cầu đã đạt. Không tự ý thêm tính năng hay vòng review phụ.
6Kết thúc bằng: Đã thay đổi / Đã xác minh / Rủi ro còn lại.
7Phải hỏi trước khi thực hiện các thao tác phá hủy, phát hành hoặc thay đổi ngoài repository này.

Khối đó sẽ không thần kỳ biến mọi lượt chạy thành rẻ mạt. Nó giúp thành công và thất bại trở nên hữu hình. Từ đó, bạn có thể so sánh quy trình ưu tiên Sonnet với quy trình ưu tiên Opus trên cùng một tập tác vụ

Message giao việc vẫn phải cụ thể. Đây là sự khác biệt giữa câu "sửa code thanh toán" và một công việc mà agent thực sự có thể hoàn thành

1Thay đổi: chuyển endpoint thanh toán sang client mới
2Hoàn thành: client cũ đã bị xóa, test endpoint đạt, diff chỉ giới hạn ở đường dẫn này
3Dừng: hỏi trước khi xóa dữ liệu hoặc thay đổi bất cứ thứ gì ngoài repo
4Báo cáo: các file đã sửa, chính xác những bước kiểm tra đã chạy, rủi ro còn lại

Bản hợp đồng nhỏ đó cho bộ xác minh một thứ cụ thể để đối chiếu. Nó cũng cho mô hình một lý do để dừng lại. Một chỉ dẫn mở kiểu "review cho đến khi hoàn hảo" có thể biến một thay đổi đã đạt chuẩn thành một vòng lặp tốn tiền khác

Với các dự án dài, hãy giữ checklist trong một file không bị mất khi compaction. Với subagent, hãy yêu cầu agent chính kiểm tra bằng chứng của chúng trước khi chấp nhận báo cáo. Và nếu bạn chỉ xin ý tưởng, hãy dặn Claude đừng bắt tay vào xây dựng. Đó là ranh giới quy trình, không phải prompt kiểu "hãy thông minh hơn"

Thiết lập mà tôi sẽ triển khai đầu tiên

• Chọn 10-30 tác vụ thực tế và định nghĩa bước kiểm tra cho từng tác vụ
• Quét Sonnet 5.5 ở mức medium và high, sau đó quét Opus 5.5 ở mức medium
• Ghi log input mới, output, cache write, cache read, độ trễ, lượt thử lại và trạng thái pass/fail cho mỗi tác vụ
• Giữ phần prefix ổn định có thể cache và xác nhận lượt hit trong usage
• Chỉ điều hướng các ca thất bại lên trên, kèm theo bằng chứng của chúng
• Xem xét lại thang leo khi khối lượng công việc thay đổi. Một bản benchmark đã lưu không phải là chân lý vĩnh cửu

Nếu 10% tác vụ khó liên tục đi thẳng từ thất bại trên Sonnet đến thành công trên Opus, hãy cân nhắc điều hướng nhóm tác vụ dễ nhận diện đó sang Opus ngay từ đầu. Nếu Sonnet high vượt qua được những ca đó với chi phí thấp hơn, hãy giữ chúng ở lại. Router là một chính sách dựa trên đo lường, không phải một định kiến vĩnh viễn về việc mô hình nào thông minh hơn

Bản nâng cấp 5.5 không chỉ đơn thuần là "dùng Sonnet cho việc rẻ và Opus cho việc khó"

Nó là cơ hội để bạn ngừng định giá mô hình và bắt đầu định giá công việc đã hoàn thành

Nếu bạn đã đọc đến đây

-> Đăng ký Substack của tôi

-> Tham gia Telegram của tôi

-> Lưu lại bài viết này

-> Theo dõi @0xwhrrari