Anthropic cho biết các lời nhắc Fable 5 hiện có của bạn sẽ hoạt động tốt trên Claude Fable 5.1 mà không cần thay đổi. Điều đó đúng với các câu trả lời. Điều đó ít đúng với mọi thứ xung quanh chúng: mô hình gộp bao nhiêu lệnh gọi công cụ mỗi lượt, nó tường thuật bao nhiêu, văn xuôi của nó dày đặc đến mức nào, nó định dạng trong cuộc trò chuyện bao nhiêu, liệu nó có viết lại toàn bộ tệp để thay đổi một dòng hay không, và liệu nó có dừng lại để xin phép cho công việc bạn đã yêu cầu hay không. Mỗi điều đó đã thay đổi giữa Fable 5 và Fable 5.1, và mỗi điều có một cách khắc phục cụ thể trong hướng dẫn nhắc lệnh của Anthropic cho Claude Fable 5.1.
Hướng dẫn này tổng hợp mọi thay đổi cùng với cách khắc phục, trích dẫn các đoạn mã chính thức nơi từ ngữ chính xác quan trọng, cộng với quy tắc đặt vị trí quan trọng hơn trên mô hình này so với bất kỳ mô hình trước đó nào: nơi bạn đặt một hướng dẫn theo từng lượt giờ đây quyết định liệu nó có làm mất hiệu lực các khối suy nghĩ của bạn và khởi động lại bộ đệm của bạn hay không. Để có cái nhìn tổng quan về mô hình, hãy xem Claude Fable 5.1 là gì.
Bắt đầu với nỗ lực, không phải lời nhắc
Nỗ lực (Effort) là kiểm soát chính để đánh đổi giữa trí thông minh, độ trễ và chi phí trên Fable 5.1, và nó nên được điều chỉnh trước bất kỳ thay đổi lời nhắc nào. Bắt đầu với mặc định, `high`, sau đó kiểm tra bốn cấp độ khác so với các đánh giá của riêng bạn. Chạy lại việc quét ngay cả khi bạn đã chạy một lần trên Fable 5: tên cấp độ không tương ứng với cùng một lượng suy nghĩ trên các mô hình.
Tuyên bố của Anthropic để kiểm tra: ở `medium`, kết quả gần tương đương với Fable 5 với chi phí thấp hơn; ở `low`, Fable 5.1 thường cạnh tranh với Opus và Sonnet về chi phí trên mỗi tác vụ trong khi đạt điểm cao hơn; lợi ích so với Fable 5 lớn nhất ở `xhigh` và `max`. Trên Fable 5.1, bạn có thể thay đổi nỗ lực giữa cuộc trò chuyện mà không cần đặt lại bộ đệm, bằng cách sử dụng tin nhắn `role: "system"` trống nội dung với `output_config` (tiêu đề beta `mid-conversation-output-config-2026-07-01`). Hướng dẫn API cho thấy hình dạng yêu cầu.
Vị trí quan trọng hơn từ ngữ
Các khối suy nghĩ của Fable 5.1 chỉ có giá trị trong cuộc trò chuyện chính xác đã tạo ra chúng (suy nghĩ được bảo toàn). Chèn một lời nhắc vào một lượt trước đó và xóa nó trong yêu cầu tiếp theo là một chỉnh sửa lịch sử: nó khởi động lại bộ đệm lời nhắc và, trên các tài khoản được tạo vào hoặc sau ngày 31 tháng 8 năm 2026, làm mất hiệu lực mọi khối suy nghĩ sau này.
Vì vậy, các hướng dẫn theo từng lượt được đặt ở một trong hai nơi. Với phiên bản beta `mid-conversation-system-clear-at-2026-08-21`, hãy thêm chúng dưới dạng tin nhắn hệ thống theo phạm vi lượt: `{"role": "system", "clear_at": "next_user_message", "content": "..."}` sau tin nhắn kết quả công cụ, và giữ mọi bản sao trước đó trong mảng. Khi một tin nhắn người dùng sau đó tồn tại, API sẽ xóa các bản sao trước đó, vì vậy mô hình chỉ đọc bản mới nhất, và các bản sao đã xóa không tốn token. Nếu không có bản beta, hãy đặt câu vào một khối văn bản sau các khối `tool_result` trong cùng tin nhắn người dùng, giữ lại các bản sao trước đó. Không bao giờ xóa hoặc viết lại một bản sao đã gửi. Hướng dẫn suy nghĩ được bảo toàn giải thích lý do.
Các hướng dẫn cấp độ phiên được đặt trong lời nhắc hệ thống hoặc lượt người dùng đầu tiên. Anthropic lưu ý rằng các hướng dẫn về phong cách trong lượt người dùng đầu tiên có hiệu quả tốt hơn so với cùng một văn bản trong lời nhắc hệ thống.
Một lệnh gọi công cụ mỗi lượt trong vòng lặp tác nhân
Sự thay đổi. Khi một yêu cầu đặt tên một số thứ cần lấy, Fable 5.1 thực hiện các lệnh gọi song song. Trong các vòng lặp mã hóa và sử dụng máy tính nơi các lần đọc độc lập tiếp theo chỉ được ngụ ý, nó có thể phát hành một lệnh mỗi lượt trong khi Fable 5 đã gộp nhiều lệnh. Câu trả lời không bị ảnh hưởng; mỗi lượt bổ sung tốn token, một chuyến đi khứ hồi và thời gian thực.
Đo lường trước. Theo dõi tỷ lệ các lượt của trợ lý với nhiều hơn một lệnh gọi công cụ, và chỉ thêm bản sửa lỗi nếu tỷ lệ đó giảm. Bản sửa lỗi, được thêm vào sau mỗi tin nhắn kết quả công cụ dưới dạng tin nhắn hệ thống theo phạm vi lượt:
Đầu tiên hãy liệt kê riêng những gì bạn cần tiếp theo; sau đó yêu cầu mọi mục không phụ thuộc vào kết quả của mục khác trong phản hồi này.
Giữ từ “privately” (riêng tư). Nếu không có nó, mô hình đôi khi trả lời lời nhắc thay vì người dùng. Một câu gần cuối yêu cầu hiện tại thay đổi số lượng nhiều hơn nhiều so với cùng một văn bản trong lời nhắc hệ thống.
Ít hoặc không có văn bản giữa các lệnh gọi công cụ
Sự thay đổi. Fable 5.1 viết ít cập nhật hướng tới người dùng hơn trong các lượt gọi công cụ dài so với Fable 5, đặc biệt ở nỗ lực cao hơn. Người dùng thấy tác nhân im lặng trong vài phút, hoặc một tin nhắn cuối cùng chỉ đề cập đến bước cuối cùng.
Ba cách khắc phục, theo thứ tự. Đầu tiên, kiểm tra xem bạn có nhận được cập nhật tiến độ hay không: các ghi chú giữa các công cụ của mô hình trở lại dưới dạng khối `thinking` trống theo mặc định `display: "omitted"`. Đặt `display: "updates"` (tiêu đề beta `thinking-display-updates-2026-08-18`) và hiển thị mỗi khối suy nghĩ không trống dưới dạng một dòng trạng thái. Thứ hai, xóa các dòng lời nhắc được viết cho các mô hình cũ hơn háo hức cập nhật, chẳng hạn như “giữ tất cả các phát hiện cho phản hồi cuối cùng.” Thứ ba, nếu bạn vẫn muốn nhiều hơn, hãy thêm một dòng lời nhắc hệ thống:
Trước khi bạn bắt đầu, hãy nói một dòng về những gì bạn sắp làm; các cập nhật ngắn gọn trong khi bạn làm việc giúp người dùng theo dõi. Kết thúc bằng một bản tóm tắt ngắn gọn tự nó đầy đủ, bao gồm những gì bạn đã tìm thấy, những gì bạn đã làm và những gì tiếp theo, để người đọc chỉ nhìn thấy tin nhắn cuối cùng có được bức tranh đầy đủ.
Nếu sản phẩm của bạn ẩn đầu ra công cụ, hãy cho mô hình biết dưới dạng tin nhắn hệ thống theo phạm vi lượt, nếu không nó có thể chạy các lệnh để “hiển thị” cho người dùng đầu ra mà họ không bao giờ thấy: “Chỉ bạn mới thấy đầu ra của lệnh đó. Nếu người dùng cần đọc bất kỳ phần nào của nó, hãy đưa nó vào câu trả lời của bạn.”
Lượt kết thúc trước khi công việc hoàn thành
Sự thay đổi. Trên các khối lượng công việc bất đồng bộ phức tạp, Fable 5.1 đôi khi mô tả những gì nó sẽ làm tiếp theo thay vì thực hiện, hoặc yêu cầu cấp phép cho một bước mà yêu cầu đã bao gồm. Người dùng phải trả lời “tiếp tục,” điều này hạn chế khả năng tầm nhìn dài của mô hình.
Bản sửa lỗi là một khối lời nhắc hệ thống mà câu mở đầu mang lại phần lớn hiệu quả:
Bạn đang hoạt động tự chủ. Người dùng không theo dõi theo thời gian thực và không thể trả lời các câu hỏi giữa nhiệm vụ, vì vậy việc hỏi 'Bạn có muốn tôi...?' hoặc 'Tôi có nên...?' sẽ làm tắc nghẽn công việc. Đối với các hành động có thể đảo ngược theo yêu cầu ban đầu, hãy tiến hành mà không cần hỏi. Chỉ dừng lại đối với các hành động phá hủy hoặc thay đổi phạm vi thực sự mà người dùng phải quyết định. Việc đưa ra các theo dõi sau khi nhiệm vụ hoàn thành là ổn; việc xin phép trước khi thực hiện công việc thì không.
Trước khi kết thúc lượt của bạn, hãy kiểm tra đoạn văn cuối cùng của bạn. Nếu đó là một kế hoạch, một phân tích, một câu hỏi, một danh sách các bước tiếp theo, hoặc một lời hứa về công việc bạn chưa làm, hãy thực hiện công việc đó ngay bây giờ bằng các lệnh gọi công cụ. Chỉ kết thúc lượt của bạn khi nhiệm vụ hoàn thành hoặc bạn bị chặn bởi đầu vào mà chỉ người dùng có thể cung cấp.
Anthropic kết hợp nó với một khối thứ hai định nghĩa yêu cầu của người dùng là phạm vi của kết quả công việc: không thu hẹp, mở rộng hoặc hoán đổi nó; hoàn thành mọi phần không bị chặn và nói rõ những gì còn thiếu; coi điều bạn nhận thấy nhưng không được yêu cầu như một gợi ý, không phải một thay đổi. Cặp này có thể làm cho mô hình ít có khả năng hỏi về các yêu cầu mơ hồ hơn, vì vậy hãy thêm một dòng liệt kê các xác nhận bạn vẫn muốn. Một điểm khác biệt so với Opus 5: nếu lời nhắc của bạn yêu cầu mô hình kiểm tra công việc của nó trước khi báo cáo, hãy giữ lại. Lời khuyên của Opus 5 về việc xóa các hướng dẫn xác minh không được áp dụng.
Các bản sửa lỗi không yêu cầu và các tệp kiểm tra bổ sung
Sự thay đổi. Khi được yêu cầu một tính năng mở, Fable 5.1 cung cấp nó và đôi khi còn nhiều hơn thế: các bản sửa lỗi gần đó, hành vi mở rộng, nhiều tệp kiểm tra được cam kết hơn mức thay đổi yêu cầu.
Bản sửa lỗi, mà Anthropic cho biết đã cắt giảm đáng kể các phần bổ sung mà không làm thay đổi thành công nhiệm vụ:
Nếu, trong khi làm việc hoặc thử nghiệm, bạn tìm thấy một lỗi đã tồn tại trước đó, một vấn đề về hiệu suất hoặc hành vi mà nhiệm vụ không đề cập, đừng sửa, tối ưu hóa hoặc mở rộng nó trong thay đổi này trừ khi hành vi được yêu cầu không thể hoạt động nếu không có nó; hãy báo cáo nó như một theo dõi trong bản tóm tắt của bạn. Xác minh công việc của bạn theo cách bạn muốn; các script nháp và kiểm tra nhanh không cần phải giữ lại. Chỉ cam kết các thử nghiệm khi nhiệm vụ yêu cầu chúng hoặc kho lưu trữ này đã giữ các thử nghiệm cho loại thay đổi này, có kích thước tương tự như các tệp thử nghiệm lân cận. Điều này chỉ liên quan đến các phần bổ sung: triển khai mọi hành vi mà nhiệm vụ yêu cầu, một cách hoàn chỉnh.
Toàn bộ tệp được viết lại cho các thay đổi nhỏ
Sự thay đổi. Fable 5.1 có nhiều khả năng viết lại toàn bộ một tệp hơn là thực hiện một chỉnh sửa mục tiêu so với Fable 5. Kết quả tương tự, nhiều token đầu ra hơn.
Bản sửa lỗi, trong lời nhắc hệ thống hoặc tin nhắn người dùng đầu tiên:
Số lượng token được sử dụng để chỉnh sửa tệp tốt nhất nên được giảm thiểu, tất cả các yếu tố khác đều như nhau. Do đó, khi nó không ảnh hưởng đến kết quả cuối cùng, hãy cố gắng chỉnh sửa tệp một cách chính xác thay vì viết lại toàn bộ.
Văn xuôi dài và dày đặc
Sự thay đổi. Cách viết của Fable 5.1 nhìn chung tốt hơn, với ít cụm từ sáo rỗng hơn, nhưng trong một số trường hợp, nó dày đặc hơn Fable 5: câu dài hơn, ít ngắt đoạn hơn.
Bản sửa lỗi là định nghĩa mô hình phản diện. Đoạn trích của Anthropic mô tả "văn xuôi kiểu cách" (mannered prose) là lối viết thay thế ẩn dụ và hoa mỹ cho lời nói trực tiếp và tồn tại để phô trương người viết hơn là truyền tải ý tưởng; hướng dẫn là nói lên ý bạn muốn và sử dụng cụm từ nghĩa đen khi có sẵn. Dạng ngắn cũng có tác dụng: "Vui lòng loại bỏ tất cả văn xuôi kiểu cách."
Phản hồi trò chuyện có cấu trúc ít hơn nội dung cần
Sự thay đổi. Các mô hình trước đây đã lạm dụng dấu đầu dòng và chữ in đậm, vì vậy nhiều lời nhắc có các quy tắc chống định dạng. Fable 5.1 lại nghiêng về hướng ngược lại: ít chữ in đậm hơn, ít tiêu đề và danh sách hơn. Những quy tắc cũ đó giờ đây lại làm mất đi cấu trúc mà nội dung cần.
Bản sửa lỗi. Xóa ngôn ngữ chống định dạng, hoặc thay thế nó bằng một quy tắc nói rõ khi nào định dạng hữu ích: sử dụng danh sách khi được yêu cầu hoặc khi nội dung đa diện đủ để chúng tăng cường sự rõ ràng; tôn trọng yêu cầu rõ ràng về định dạng tối thiểu; giữ văn xuôi đơn giản trong các cuộc trò chuyện hoặc trao đổi cảm xúc.
Tóm tắt sao chép nguyên văn nguồn mà không đánh dấu
Sự thay đổi. Khi tóm tắt tài liệu, Fable 5.1 có nhiều khả năng sao chép các đoạn văn bản từ nguồn mà không đánh dấu chúng là trích dẫn hơn Fable 5.
Bản sửa lỗi. Thêm một ví dụ hoàn chỉnh vào lời nhắc hệ thống: yêu cầu của người dùng, một phản hồi chính xác truyền đạt từng nguồn bằng lời nói gián tiếp của trợ lý với tối đa một trích dẫn ngắn được đánh dấu, và một lý do giải thích tại sao nó đúng chỉ trong một câu. Thay thế các phần giữ chỗ gọi công cụ trong ví dụ của Anthropic bằng tên công cụ của riêng bạn.
Trả lời từ bộ nhớ thay vì tìm kiếm ở mức nỗ lực thấp
Sự thay đổi. Ở mức nỗ lực `low`, Fable 5.1 gọi các công cụ tìm kiếm và truy xuất ít thường xuyên hơn Fable 5, rõ ràng nhất đối với các sản phẩm và mô hình có tên mà nó nhận ra nhưng có kiến thức cũ.
Hai cách khắc phục. Tăng nỗ lực cho các lượt bị ảnh hưởng bằng nỗ lực theo từng tin nhắn. Hoặc nói với mô hình trong lời nhắc hệ thống rằng việc nhận ra một tên từ một lĩnh vực phát triển nhanh không giống như biết trạng thái hiện tại của nó, rằng nó nên tìm kiếm trước khi trả lời, và rằng nó nên bao gồm tên như người dùng đã viết nó trong ít nhất một truy vấn.
Các sản phẩm dài ở xhigh và max mất quá nhiều thời gian
Sự thay đổi. Ở `xhigh` và đặc biệt là `max`, Fable 5.1 có thể soạn thảo phần lớn một sản phẩm dài trong suy nghĩ của nó và sau đó viết lại nó dưới dạng phản hồi, làm tăng gấp đôi thời gian chờ và token đầu ra.
Hai cách khắc phục. Chạy các yêu cầu đó ở `high` và chỉ tăng cấp khi bạn đã đo lường được lợi ích. Nếu bạn giữ ở `xhigh` hoặc `max`, hãy đặt `max_tokens` để dành chỗ cho suy nghĩ và phản hồi, và thêm một ghi chú vào tin nhắn người dùng nói rằng mọi thứ được tạo trong một phản hồi, bao gồm lý do, đều được tính vào một giới hạn duy nhất khoảng `max_tokens` thực tế của bạn, và việc soạn thảo sản phẩm đầy đủ dưới dạng lý do và lại dưới dạng phản hồi sẽ làm tăng gấp đôi lượt mà không cải thiện nó. Để các bản sao trước đó của ghi chú đó ở nguyên vị trí trên các yêu cầu sau.
Các yêu cầu mã hóa lành tính bị từ chối
Sự thay đổi. Các bộ phân loại của Fable 5.1 tạo ra ít dương tính giả hơn so với Fable 5 khi ra mắt, và việc tìm lỗ hổng trong mã nguồn hiện được phép. Dương tính giả vẫn xảy ra.
Ba cách diễn đạt cần thay đổi. Hỏi “Có bất kỳ lỗi nào trong chương trình này không?” thay vì “Chương trình này có biên dịch mà không có lỗi không?” Cung cấp cho mô hình tài liệu cho các ngôn ngữ ít được biết đến. Loại bỏ các công cụ trả về dữ liệu được mã hóa base64 vào ngữ cảnh. Giữ cấu hình `fallbacks` bất kể; hướng dẫn xử lý từ chối đề cập đến nó.
Tóm tắt nén phía client bỏ qua chi tiết
Fable 5.1 phản hồi tốt khi được chỉ dẫn chính xác những gì một bản tóm tắt nén phải giữ lại. Việc nén phía máy chủ đã làm điều này. Nếu bạn nén ở phía client, hãy hướng dẫn mô hình tóm tắt bên trong các thẻ `<summary>` và bảo toàn, theo thứ tự: những khó khăn đã xảy ra và cách chúng được giải quyết; các phương pháp tiếp cận đã được đưa ra hoặc gác lại và tại sao; bất cứ điều gì được hỏi hoặc quyết định, được nêu chính xác; tình hình hiện tại; bất cứ điều gì vẫn còn mở; và các chi tiết khó tái tạo như tên, số, và liên kết. Kết thúc bằng “Không gọi bất kỳ công cụ nào khi viết bản tóm tắt này; chỉ phản hồi bằng văn bản,” điều này quan trọng khi yêu cầu tóm tắt vẫn mang theo các công cụ của cuộc trò chuyện.
Các tác nhân phụ và thị giác
Hai bản sửa lỗi mang tính kiến trúc hơn là lời nhắc. Trên các tác vụ mã hóa, hãy để tác nhân chính tiếp tục làm việc trong khi các tác nhân phụ chạy: hãy để công cụ khởi động một tác nhân phụ trả về ngay lập tức, cung cấp mỗi kết quả trong một tin nhắn người dùng sau đó, và cấp cho tác nhân chính một công cụ riêng biệt mà nó có thể gọi khi muốn đợi. Đối với các biểu đồ dày đặc và bảng lồng nhau, hãy cung cấp cho mô hình một công cụ cắt xén trả về một vùng được chọn đã được phóng to, hoặc một vùng chứa với các thư viện hình ảnh cơ bản; ở mức nỗ lực `low` nó có thể bỏ qua việc cắt xén, vì vậy hãy kiểm tra nhật ký để tìm lệnh gọi.
Kiểm tra thay đổi lời nhắc trong Apidog
Mọi bản sửa lỗi ở trên đều là ứng viên cho một bài kiểm tra trước và sau. Trong Apidog, lưu ba lượt đầu tiên của vòng lặp tác nhân của bạn dưới dạng một chuỗi yêu cầu, tham số hóa lời nhắc hệ thống và chạy nó có và không có mỗi đoạn mã ở cùng mức nỗ lực. Xác nhận trên số lượng khối `tool_use` trên mỗi lượt trợ lý cho bản sửa lỗi gộp, trên `usage.output_tokens` cho các bản sửa lỗi chỉnh sửa mục tiêu và mật độ, và trên việc không có đoạn cuối cùng bắt đầu bằng “Next, I” cho bản sửa lỗi tự chủ. Tải xuống Apidog để xây dựng nó; hướng dẫn Claude Code cho biết dòng nào trong số này thuộc về một tệp `CLAUDE.md`.
Câu hỏi thường gặp
Các lời nhắc Fable 5 của tôi có hoạt động trên Fable 5.1 không? Anthropic nói rằng chúng sẽ hoạt động tốt mà không cần thay đổi. Sự khác biệt là về hành vi: ít lệnh gọi công cụ được gộp hơn, ít cập nhật tiến độ hơn, văn xuôi dày đặc hơn, ít định dạng trò chuyện hơn, viết lại toàn bộ tệp và mở rộng phạm vi trên các tác vụ mở.
Tôi nên đặt mức nỗ lực nào cho Fable 5.1? Bắt đầu ở `high` và quét. Anthropic nói rằng `medium` gần tương đương với Fable 5 với chi phí thấp hơn và `low` thường cạnh tranh với Opus và Sonnet về chi phí trên mỗi tác vụ.
Tôi nên đặt hướng dẫn theo từng lượt trên Fable 5.1 ở đâu? Dưới dạng một tin nhắn hệ thống theo phạm vi lượt với `clear_at: "next_user_message"` sau kết quả công cụ, giữ nguyên các bản sao trước đó. Chèn và xóa văn bản từ các lượt trước đó sẽ làm mất hiệu lực các khối suy nghĩ sau này và khởi động lại bộ đệm.
Tôi có nên loại bỏ các hướng dẫn “xác minh công việc của bạn” như trên Opus 5 không? Không. Hướng dẫn đó cụ thể cho việc xác minh quá mức của Opus 5. Hãy giữ chúng trên Fable 5.1.
Làm cách nào để ngăn Fable 5.1 viết lại toàn bộ tệp? Một dòng trong lời nhắc hệ thống hoặc tin nhắn người dùng đầu tiên: giảm thiểu token được sử dụng để chỉnh sửa tệp và chỉnh sửa chính xác thay vì viết lại khi nó không ảnh hưởng đến kết quả.