Anthropic ra mắt Claude Fable 5.1 và bản Claude Mythos 5.1 giới hạn quyền truy cập vào ngày 1/9. Giá cơ bản giữ nguyên như Fable 5 — $10/$50 mỗi triệu token input/output — nên nhìn qua đây có vẻ chỉ là một bản cập nhật nhỏ: benchmark tốt hơn (52.6% trên Terminal-Bench-Science), context window 1M token, và các tầng safeguard phân biệt hai biến thể. Con số thực sự quan trọng với bất kỳ ai đang chạy workload agent production lại nằm ở vài đoạn sâu trong trang giá: giá đọc cache (cache read) giảm 75%. Theo Anthropic, điều này giảm chi phí thực tế 25–45% trên các workload điển hình. Đây không phải sai số làm tròn, và cũng không hẳn là “giảm giá” — đó là platform đang nói cho bạn biết nó muốn thưởng cho hình dạng prompt nào, và phần lớn pipeline agent tôi từng review năm nay đang có hình dạng sai hoàn toàn so với điều đó.

Vì sao giá per-token phẳng che giấu đòn bẩy thực sự

Tối ưu theo giá niêm yết là cái bẫy tôi thấy nhiều team mắc phải liên tục: họ benchmark $/triệu token giữa các provider, chọn cái rẻ nhất, rồi dừng lại ở đó. Nhưng với bất kỳ workload nào gửi lại context tương tự lượt này qua lượt khác — tức gần như mọi agent loop, mọi chat nhiều lượt, mọi pipeline dùng tool — chi phí thực tế không phải giá niêm yết, mà là (cache write × giá write) + (cache read × giá read) + (token mới × giá đầy đủ). Việc cắt 75% một số hạng trong phương trình đó không làm thay đổi giá niêm yết, nhưng có thể thay đổi hóa đơn thực tế của bạn hai chữ số phần trăm — và chỉ có lợi nếu kiến trúc của bạn tạo ra đủ lượt đọc cache ngay từ đầu.

Đây là phiên bản ngây thơ mà nhiều code agent vẫn đang chạy:

// naive: system prompt + toàn bộ tool docs gửi lại mỗi lần gọi, không có ranh giới cache
async function callModel(userMsg, history) {
  return await client.messages.create({
    model: 'claude-fable-5-1',
    system: SYSTEM_PROMPT + TOOL_DOCS, // ~8k token, giống hệt mỗi lần gọi
    messages: [...history, { role: 'user', content: userMsg }],
  })
}

Mỗi lần gọi ở đây đều trả giá đầy đủ cho 8k token nội dung không hề thay đổi kể từ khi session bắt đầu. Nhân con số đó lên trong một multi-agent fan-out — năm subagent, mỗi cái tự load lại tool docs — và bạn đang trả mức giá cao nhất cho những token mà model đã “thấy” cả chục lần trong session này rồi.

Cấu trúc lại xoay quanh ranh giới cache

Cách sửa không mới — prompt caching đã tồn tại một thời gian — nhưng việc cắt 75% giá read thay đổi bài toán ROI về mức độ quyết liệt bạn nên phân đoạn prompt giữa nội dung ổn định và nội dung thay đổi. Pattern tôi chuyển sang:

async function callModel(userMsg, history) {
  return await client.messages.create({
    model: 'claude-fable-5-1',
    system: [
      { type: 'text', text: SYSTEM_PROMPT, cache_control: { type: 'ephemeral' } },
      { type: 'text', text: TOOL_DOCS, cache_control: { type: 'ephemeral' } },
    ],
    messages: [
      ...history.map(markStableTurnsAsCached), // các lượt cũ có breakpoint cache riêng
      { role: 'user', content: userMsg },       // chỉ phần này thực sự mới
    ],
  })
}

Hai cache breakpoint thay vì không có: một cho khối system/tool-docs (về cơ bản tĩnh theo mỗi deployment), một cho lịch sử hội thoại tới vài lượt gần nhất (tĩnh trong session, tăng chậm). Chỉ tin nhắn user mới nhất và câu trả lời tiếp theo của model mới là token “giá đầy đủ”. Ở mức giá cache-read cũ, việc này đáng làm nhưng không cấp bách — mức tiết kiệm là thật nhưng đủ khiêm tốn để nhiều team bỏ qua. Ở mức giảm 75%, bỏ qua bước này bây giờ đồng nghĩa để lại 25–45% hóa đơn trên bàn miễn phí, trên một hình dạng workload mà gần như chắc chắn bạn đã có sẵn.

Nơi việc này thực sự đáng làm — và nơi không

Tôi đã tính toán với ba dạng workload tôi đang thực sự vận hành:

  • Session agent chạy dài với tool docs nặng (các subagent viết blog và research của tôi): lợi ích cao. Tool docs và system prompt là 6–10k token, gửi lại mỗi lượt trong 15–30 lượt/session. Cache hóa khối đó biến đường cong chi phí tuyến tính thành gần như phẳng sau lần gọi đầu tiên.
  • Các cuộc gọi phân loại hoặc trích xuất một lần: lợi ích gần như bằng không. Nếu không có lượt gọi thứ hai trong session, không có gì để đọc từ cache — bạn trả giá cache-write (hơi cao hơn) một lần và không bao giờ thu hồi được. Đừng thêm overhead cache ở đây; chỉ toàn downside.
  • Multi-agent fan-out với preamble tĩnh dùng chung (các subagent tóm tắt theo nguồn của digest curator): lợi ích cao, nhưng chỉ khi bạn kiến trúc preamble dùng chung như một cache entry được tái sử dụng giữa các agent thay vì mỗi subagent tự ghi cache riêng. Đây là lỗi phổ biến nhất: năm subagent mỗi cái tự cache-write nội dung gần như giống hệt nhau là năm lần trả phí write thay vì một lần write và bốn lần read.

Ranh giới rất đơn giản: cache đáng giá khi cùng một prefix được đọc lại nhiều hơn khoảng một lần sau khi ghi. Dưới mức đó, nó là overhead. Đa số mọi người không kiểm tra workload của mình đang ở phía nào của ranh giới trước khi gắn cache_control vào mọi nơi, và đó mới là sai lầm thực sự — không phải cache quá ít, mà cache bừa bãi rồi ngạc nhiên vì hóa đơn không nhúc nhích.

Góc độ governance chưa ai định giá

Theo Anthropic, Fable 5.1 và Mythos 5.1 “là cùng một model, nhưng với các mức safeguard khác nhau” — Mythos có guardrail linh hoạt hơn cho các use case an ninh mạng và khoa học sự sống đã được xác minh, giới hạn qua chương trình trusted-access. Đây là tín hiệu thứ hai đáng lên kế hoạch dù bạn không bao giờ đụng tới Mythos trực tiếp: tầng safeguard đang trở thành một chiều lựa chọn model hạng nhất, không chỉ là năng lực và giá. Nếu bạn đang xây layer routing model nội bộ — và tới thời điểm này của 2026 hầu hết platform team đều có — đáng để thêm “tầng safeguard” như một chiều routing bên cạnh chi phí và độ trễ ngay bây giờ, trước khi bạn có workload thực sự cần nó. Gắn thêm một chiều routing vào hệ thống chỉ biết “model rẻ vs model đắt” sau này sẽ tốn công hơn nhiều so với thêm cột đó khi hệ thống còn non trẻ.

Việc tôi sẽ làm trong tuần này

Nếu bạn đang chạy bất cứ thứ gì ngoài các lệnh gọi một lần với Claude: audit lại system prompt và tool docs để tách phần ổn định/thay đổi, thêm breakpoint cache_control tại ranh giới đó, và kiểm tra xem multi-agent fan-out của bạn có đang trùng lặp cache write đáng lẽ nên dùng chung hay không. Không cái nào trong số này đòi hỏi đổi model hay viết lại agent loop — nó đòi hỏi nhìn hóa đơn token qua lăng kính tỷ lệ đọc/ghi cache thay vì tổng gộp, thứ mà hầu hết dashboard billing không hiển thị mặc định. Mức giảm 75% không thưởng cho bạn vì dùng Fable 5.1. Nó thưởng cho bạn vì đã cấu trúc prompt theo cách cache mong muốn — và, tương đối mà nói, phạt tất cả những ai chưa kịp làm điều đó.

Xuất nội dung

Bình luận