Claude Fable 5.1 Tư duy bảo toàn: Khắc phục lỗi The Block Is Bound to a Different Conversation

Claude Fable 5.1: khắc phục lỗi thinking block bị gắn với cuộc hội thoại khác

Nếu bạn đã di chuyển một hệ thống điều khiển tác nhân (agent harness) sang Claude Fable 5.1 và bắt đầu gặp lỗi 400 cho biết một khối suy nghĩ (thinking block) “được gắn với một cuộc hội thoại khác”, mã của bạn có thể đã chỉnh sửa lịch sử hội thoại giữa các yêu cầu. Fable 5.1 là mô hình Claude đầu tiên bắt buộc kiểm tra này. Bài viết giải thích nguyên nhân, phạm vi ảnh hưởng, cách khôi phục và các mẫu append-only giúp giữ nguyên cả thinking blocks lẫn prompt cache. Kiểm tra này được mô tả trong phần suy nghĩ được bảo toàn và Có gì mới trong Claude Fable 5.1. Đây là thay đổi gây lỗi thứ ba trong ba thay đổi gây lỗi của Fable 5.1, đồng thời là thay đổi duy nhất có thể âm thầm làm giảm hiệu suất agent harness. Với hai thay đổi còn lại, hãy xem hướng dẫn di chuyển.

Thử Apidog ngay

Lỗi bạn sẽ thấy

messages.5.content.0: Invalid `signature` in `thinking` block.
The block is bound to a different conversation. Remove the block, or set
thinking.block_binding.prefix_mismatch_behavior to "drop_block".
That setting requires the thinking-binding-controls-2026-08-01 value
in the anthropic-beta header.

Đây là lỗi 400 invalid_request_error, xảy ra trước khi mô hình tạo bất kỳ đầu ra nào. Gửi lại cùng một nội dung sẽ tiếp tục thất bại.

messages.5.content.0 trỏ đến khối suy nghĩ đầu tiên không còn khớp. Thông báo đôi khi còn nêu tên tin nhắn đầu tiên đã bị thay đổi — đó là manh mối quan trọng để chẩn đoán.

Điểm cuối đếm token cũng thực hiện cùng một kiểm tra.

Nếu lỗi Invalid signature in thinking block không có câu “bound to a different conversation”, đó là trường hợp khác: chữ ký có thể đã bị giả mạo hoặc không thể giải mã. prefix_mismatch_behavior không áp dụng cho trường hợp này.

Kiểm tra này hoạt động như thế nào?

Mỗi thinking block của Fable 5.1 chứa chữ ký ghi lại:

• Mô hình đã tạo block.
• Tiền tố hội thoại chính xác đứng trước block: system prompt cấp cao nhất, mảng tools và tất cả tin nhắn trước đó.
• Liên kết với thinking block trước đó.

Khi bạn gửi lại lịch sử, API xác minh rằng tiền tố hiện tại giống từng byte với tiền tố đã tạo ra block.

Anthropic nêu hai mục đích:

1. Chống chắt lọc: các tài khoản API mới không thể tự chỉnh sửa ngữ cảnh trước đó của Claude trong hội thoại nhiều lượt mà vẫn giữ nguyên thinking blocks.
2. Bảo vệ prompt cache: các chỉnh sửa làm hỏng kiểm tra cũng khởi động lại prompt cache. Vì vậy, mã vượt qua kiểm tra thường cũng là mã nhận được giá đọc cache thấp hơn — khoảng 0,25 USD cho mỗi triệu token được đọc từ cache trong mỗi lượt.

Ai bị ảnh hưởng?

Phạm vi	Trạng thái
Tài khoản tạo vào hoặc sau ngày 31/08/2026	Bắt buộc kiểm tra
Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry	Có áp dụng
Tài khoản cũ hơn	Chỉ ghi nhận, trừ khi yêu cầu đặt prefix_mismatch_behavior
Claude Code, claude.ai, Claude Managed Agents, Claude Agent SDK	Không bị ảnh hưởng vì hệ thống giữ nguyên tiền tố
Claude Mythos 5.1	Không chạy kiểm tra này, nhưng chỉnh sửa lịch sử vẫn làm mất prompt cache
Code tự xây dựng mảng messages	Có khả năng bị ảnh hưởng

Nếu bạn phát hành công cụ cho người dùng chạy bằng API key của riêng họ, tài khoản của bạn có thể cũ hơn tài khoản của họ. Hãy bật kiểm tra ngay trong môi trường của bạn để phát hiện lỗi trước người dùng.

Để kiểm tra tài khoản có đang bị bắt buộc áp dụng hay không, gửi một yêu cầu có chỉnh sửa lịch sử nhưng không có beta header. Nếu lỗi 400 nhắc đến beta header, tài khoản đó đang bị bắt buộc.

Điều gì làm mất hiệu lực các thinking blocks?

Các thay đổi sau sẽ làm mất hiệu lực block hiện tại và mọi block sau đó:

• Chỉnh sửa, sắp xếp lại hoặc xóa lượt trước đó.
  • Xóa tool result cũ.
  • Cắt lượt ở giữa lịch sử.
  • Tóm tắt phía client nhưng giữ nguyên các lượt gần đây.
• Chèn nội dung tạm thời rồi xóa ở yêu cầu kế tiếp.
  • Lời nhắc theo lượt.
  • Dòng trạng thái.
  • Số token còn lại thay đổi theo từng lượt.
• Xây dựng lại system hoặc tools giữa các yêu cầu.
  • Ví dụ: cập nhật ngày hiện tại trong system prompt.
  • Thêm hoặc xóa tool trong phiên.
• Gửi cùng một URL hình ảnh hoặc tài liệu nhưng URL trả về các byte khác nhau.
  • Chữ ký gắn với byte nội dung, không phải chuỗi URL.
  • URL đã ký xoay vòng nhưng trả về đúng cùng byte vẫn hợp lệ.
• Xóa thinking block ở bất kỳ đâu ngoài phần đầu của lượt chạy.
  • Có thể xóa các block dẫn đầu, theo thứ tự từ cũ nhất.
  • Không thể xóa một block ở giữa lịch sử mà vẫn giữ các block sau đó.

Điều gì vẫn hợp lệ?

Các thao tác sau giữ nguyên tính hợp lệ:

• Duy trì lịch sử theo kiểu append-only.
• Thêm các tin nhắn role: "system" thay vì sửa system prompt cũ.
• Giữ lại các tin nhắn phạm vi lượt đã hết hiệu lực.
• Xóa một chuỗi thinking blocks ở đầu lịch sử, từ cũ nhất trước.
• Thay đổi tham số ngoài system, tools và messages, chẳng hạn:
  • max_tokens
  • output_config, bao gồm effort
  • tool_choice
  • metadata
• Thêm, di chuyển hoặc xóa cache_control.
• Dùng server-side compaction hoặc context editing, bao gồm xóa thinking blocks. API kiểm tra hội thoại như bạn gửi, trước khi máy chủ chỉnh sửa nó. Sau khi compaction, kiểm tra bắt đầu từ block compaction.

Cách khôi phục nhanh: drop_block

Gửi beta header và đặt hành vi xử lý một cách rõ ràng:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "block_binding": {
            "prefix_mismatch_behavior": "drop_block"
        }
    },
    betas=["thinking-binding-controls-2026-08-01"],
    messages=history,
)

for t in response.input_transformations or []:
    print(t.type, t.path, t.reason)

Với drop_block, API sẽ:

1. Bỏ thinking block đầu tiên không khớp.
2. Bỏ mọi thinking block theo sau nó.
3. Tiếp tục xử lý yêu cầu.
4. Báo cáo các block bị xóa trong input_transformations.

Ví dụ:

{
  "input_transformations": [
    {
      "type": "thinking_dropped",
      "path": "messages.1.content.0",
      "reason": "prefix_binding_mismatch"
    }
  ]
}

Ba điểm cần nhớ

• Cấu hình chỉ áp dụng cho yêu cầu hiện tại. Hãy gửi lại trong mọi yêu cầu còn lại của phiên.
• Mặc định khác nhau tùy bề mặt:
  • Không có beta header: tài khoản bắt buộc sẽ trả về lỗi.
  • Chỉ gửi beta header: mặc định của beta là drop_block.
  • Nên luôn đặt giá trị rõ ràng, không phụ thuộc vào mặc định.
• Gửi block_binding mà không gửi beta header sẽ tạo lỗi:

block_binding: Extra inputs are not permitted

reason giúp phân biệt:

• prefix_binding_mismatch: lịch sử hội thoại đã thay đổi.
• model_binding_mismatch: hội thoại đã chuyển sang mô hình khác, chẳng hạn qua router, retry hoặc fallback. Đây không nhất thiết là lỗi trong mã của bạn.

Khi beta header được bật, mọi response đều có mảng input_transformations; mảng rỗng nghĩa là không có block nào bị bỏ.

drop_block phù hợp làm công cụ chẩn đoán hoặc mạng lưới an toàn tại ranh giới compaction. Nếu agent harness làm mất hiệu lực lịch sử ở mọi yêu cầu, hệ thống sẽ mất thinking blocks theo từng lượt và khởi động lại prompt cache theo từng lượt. Anthropic cảnh báo điều này làm tăng chi phí tác vụ.

Khôi phục khi không có beta controls

Nếu nền tảng chưa hỗ trợ controls — Microsoft Foundry chưa cung cấp khi ra mắt, còn Bedrock và Google Cloud đang bổ sung theo từng mô hình — hãy:

1. Loại bỏ toàn bộ thinking và redacted_thinking khỏi lịch sử.
2. Giữ lại các block text và tool_use của từng lượt.
3. Gửi lại yêu cầu một lần.

Mô hình sẽ trả lời mà không có phần suy nghĩ đã bị loại bỏ. Đây chỉ là phương án khôi phục tạm thời, không phải thiết kế lâu dài.

Kiểm tra trước khi chuyển traffic

Hãy thực hiện ba bước sau trước khi đưa phiên bản mới vào production.

1. Ghi lại request thực tế

Chụp chính xác các request mà agent harness gửi trong vài lượt bình thường, bao gồm:

• Compaction.
• Thay đổi tools.
• Các biến thể khác trong sản phẩm.

Với mỗi cặp request liên tiếp, so sánh:

• System prompt.
• Mảng tools.
• Phần tiền tố chung của messages.

Mọi phần trước các lượt mới được thêm phải giống từng byte.

2. Chạy phiên kiểm thử với drop_block

Dùng claude-fable-5-1 với beta header và:

{
  "prefix_mismatch_behavior": "drop_block"
}

Ghi lại input_transformations trên từng response:

• []: lịch sử còn nguyên vẹn.
• prefix_binding_mismatch: nội dung trước path đã thay đổi.

Cấu hình này hoạt động trên mọi tài khoản vì việc đặt trường này kích hoạt kiểm tra bắt buộc.

Trong CI, dùng "error" thay cho "drop_block" để mọi chỉnh sửa lịch sử làm pipeline thất bại ngay.

3. Chọn hành vi production rõ ràng

• Chọn "error" nếu mismatch luôn là lỗi lập trình.
• Chọn "drop_block" nếu cần tiếp tục chạy với suy giảm chất lượng.

Sau đó giám sát một trong hai tín hiệu:

• Lỗi HTTP 400.
• Các phần tử trong input_transformations.

Đừng để trường này không được đặt trên tài khoản cũ hơn: máy chủ có thể chỉ ghi nhận mismatch mà không gửi tín hiệu để bạn giám sát.

Trong Apidog, bước 2 chỉ cần hai request:

1. Gửi lượt đầu tiên.
2. Sửa system prompt, gửi lượt kế tiếp với beta header và xác nhận input_transformations.

Lưu kiểm thử này trong collection để chạy lại sau mỗi thay đổi agent harness. Bạn cũng có thể tải xuống Apidog.

Chuyển agent harness sang append-only

Không nên làm	Nên làm
Sửa system prompt giữa phiên, chẳng hạn cập nhật ngày hoặc chế độ	Đóng băng system prompt khi bắt đầu phiên. Khi thay đổi có hiệu lực, thêm tin nhắn system mới: {"role": "system", "content": "The current date is 2026-09-14."}
Sửa mảng tools giữa phiên	Khai báo toàn bộ tools lúc bắt đầu, dùng defer_loading: true cho tools ban đầu bị ẩn. Gửi tool_addition và tool_removal trong tin nhắn role: "system" với beta mid-conversation-tool-changes-2026-07-01
Chèn lời nhắc theo lượt rồi xóa ở request tiếp theo	Gửi lời nhắc dưới dạng system message có clear_at: "next_user_message" với beta mid-conversation-system-clear-at-2026-08-21, đồng thời giữ nguyên bản ghi cũ
Xóa tool result cũ phía client	Dùng server-side context editing để xóa tool result
Compaction phía client	Ưu tiên server-side compaction với beta compact-2026-01-12; tham số instructions cho phép dùng prompt tóm tắt riêng
Tham chiếu hình ảnh hoặc tài liệu bằng URL qua nhiều lượt	Upload một lần vào Files API rồi gửi file_id, hoặc gửi nội dung base64

Nếu không có beta hỗ trợ system message phạm vi lượt, đặt lời nhắc vào block văn bản sau các tool_result trong cùng user message và giữ nguyên các bản sao trước đó.

Tránh hai kiểu client-side compaction

Hai kiểu sau sẽ thất bại với kiểm tra binding:

• Giữ đuôi: tóm tắt các lượt cũ hơn nhưng giữ nguyên các lượt gần đây. Thinking blocks của các lượt này được tạo dựa trên toàn bộ lịch sử ban đầu.
• Tóm tắt nền: tạo bản tóm tắt ngoài luồng rồi thay thế lịch sử sau đó. Mọi lượt được tạo từ lúc bắt đầu tóm tắt đến lúc thay thế đều bị ảnh hưởng.

Cắt các lượt riêng lẻ ở giữa lịch sử luôn làm mất hiệu lực các block sau đó. Không có biến thể client-side nào giải quyết được vấn đề này.

Nếu cần thay đổi hướng dẫn, dùng system message giữa hội thoại. Nếu cần xóa chọn lọc dữ liệu, dùng server-side context editing.

Vì sao đây cũng là vấn đề về prompt cache?

Mọi thao tác làm mất binding ở trên cũng khởi động lại prompt cache.

Fable 5.1 khiến cache hit rẻ hơn khoảng bốn lần so với Fable 5, nhưng cache miss cũng đắt hơn tương ứng. Một agent harness append-only nhận được hai lợi ích:

• Thinking blocks vẫn tồn tại.
• Mỗi lượt đọc tiền tố có giá khoảng 0,25 USD / triệu token, thay vì viết lại với giá khoảng 12,50 USD / triệu token.

Xem thêm:

• Phân tích giá Claude Fable 5.1
• Hướng dẫn API
• Hướng dẫn prompt
• Hướng dẫn Claude Code

Câu hỏi thường gặp

“Block được gắn với một cuộc hội thoại khác” nghĩa là gì?

Một thinking block của Claude Fable 5.1 đã được phát lại sau khi một phần đứng trước nó thay đổi: system prompt, mảng tools hoặc tin nhắn trước đó. Trên tài khoản bị bắt buộc, API sẽ từ chối request bằng lỗi 400.

Tài khoản nào bắt buộc kiểm tra lịch sử Fable 5.1?

Các tài khoản được tạo vào hoặc sau ngày 31/08/2026 trên mọi nền tảng. Tài khoản cũ hơn chỉ bắt buộc kiểm tra khi request đặt thinking.block_binding.prefix_mismatch_behavior. Anthropic dự kiến áp dụng bắt buộc cho mọi người trên các mô hình tương lai.

Làm sao loại bỏ lỗi nhanh nhất?

Gửi beta header thinking-binding-controls-2026-08-01 cùng:

{
  "prefix_mismatch_behavior": "drop_block"
}

API sẽ bỏ các block bị ảnh hưởng và tiếp tục. Sau đó sửa nguyên nhân chỉnh sửa lịch sử, vì bỏ block ở mọi lượt sẽ làm mất thinking và khởi động lại prompt cache.

Thay đổi effort hoặc max_tokens có làm mất hiệu lực thinking blocks không?

Không. Bạn có thể thay đổi mọi tham số ngoài system, tools và messages. Các marker cache_control cũng có thể thay đổi.

Server-side compaction có làm hỏng kiểm tra không?

Không. Kiểm tra so sánh hội thoại như bạn gửi trước khi máy chủ thực hiện compaction hoặc context editing. Ngược lại, client-side compaction giữ nguyên các lượt gần đây sẽ làm hỏng binding.

Claude Mythos 5.1 có cùng kiểm tra không?

Không. Mythos 5.1 không chạy kiểm tra hội thoại, dù vẫn gắn thinking blocks với mô hình tạo ra chúng. Chỉnh sửa lịch sử vẫn khởi động lại prompt cache.

Tài liệu tham khảo

• Suy nghĩ được bảo toàn
• Có gì mới trong Claude Fable 5.1
• Claude.ai
• Tin nhắn system giữa hội thoại
• Server-side compaction
• Apidog