Cách xử lý các lỗi từ chối Fable 5 trong API

Bạn gọi claude-fable-5, phản hồi trông bình thường, nhưng khi kiểm tra trường model bạn thấy claude-opus-4-8. Điều này thường có nghĩa là request đã kích hoạt bộ phân loại an toàn, Fable 5 từ chối xử lý, và một mô hình khác đã phục vụ phản hồi. Đây không phải lỗi runtime. Đây là hành vi thiết kế, và phần tích hợp của bạn nên xử lý nó một cách chủ động.

Dùng thử Apidog hôm nay

Chúng tôi đã giải thích kiến trúc này trong bài viết về các biện pháp bảo vệ an toàn của Fable 5. Bài này tập trung vào triển khai: khi nào request bị chuyển hướng, cách phát hiện bằng code, cách dùng tham số beta fallbacks, và cách kiểm thử nhánh từ chối trước khi đưa vào production.

Tại sao Fable 5 chuyển hướng một số request

Claude Fable 5 có các bộ phân loại an toàn chạy trước mô hình. Chúng sàng lọc request trong ba nhóm chính:

• An ninh mạng
• Sinh học và hóa học
• Chưng cất mô hình

Khi một bộ phân loại bị kích hoạt, Fable 5 từ chối request. Trên giao diện Claude, request có thể được Claude Opus 4.8 xử lý tiếp và người dùng được thông báo. Trên API, phần khôi phục này là trách nhiệm của bạn, trừ khi bạn cấu hình fallbacks.

Các bộ phân loại không cố định. Sau đợt tạm ngừng vào tháng 6, Anthropic đã huấn luyện lại bộ phân loại để chống lại một kỹ thuật jailbreak được báo cáo; phiên bản cập nhật chặn hơn 99% nỗ lực. Fable 5 được triển khai lại vào ngày 1 tháng 7 năm 2026 với bộ phân loại mới. Nếu bạn đã tạm dừng tích hợp, xem thêm trung tâm Fable 5 đã trở lại để nắm timeline và các thay đổi.

Một điểm quan trọng: bộ phân loại nằm phía trước mô hình, không nằm bên trong mô hình. Claude Mythos 5 là cùng một mô hình nhưng không có bộ phân loại, và quyền truy cập bị giới hạn cho người tham gia Project Glasswing. Hơn 95% phiên Fable không bị chuyển hướng; trong các phiên đó, hiệu năng của Fable 5 về cơ bản giống Mythos 5. Chúng tôi phân tích chi tiết hơn trong bài Fable 5 so với Mythos 5.

Chuyển hướng ảnh hưởng gì đến ứng dụng của bạn

Fable 5 và Opus 4.8 đều mạnh, nhưng không nên coi là hoàn toàn thay thế được nhau về mặt kỹ thuật.

Theo thông số hiện tại, Fable 5 có cửa sổ ngữ cảnh 1M token, đầu ra tối đa 128K, giá 10 USD / triệu token đầu vào và 50 USD / triệu token đầu ra. Opus 4.8 có giá và hành vi riêng. Xem tổng quan mô hình để lấy thông số mới nhất.

Điều này có thể ảnh hưởng đến:

• Định dạng output: prompt đã tinh chỉnh cho Fable 5 có thể trả định dạng hơi khác trên Opus 4.8.
• Độ dài phản hồi: output có thể dài/ngắn hơn kỳ vọng.
• Tool calling: mẫu gọi tool có thể khác, đặc biệt với agent workflow.
• Đánh giá mô hình: nếu benchmark yêu cầu một model cụ thể, fallback âm thầm sẽ làm nhiễu dữ liệu.
• Chi phí và audit: bạn cần biết model nào thực sự tạo response để phân bổ chi phí và ghi log tuân thủ.

Cách xử lý phụ thuộc vào use case:

• Chatbot, assistant, content generation: thường có thể chấp nhận phản hồi từ Opus 4.8.
• Structured extraction hoặc workflow cố định: nên phát hiện fallback và xử lý riêng.
• Benchmark/evaluation: không nên trộn response từ nhiều model.
• Sản phẩm bảo mật hoặc life science: cần coi fallback là nhánh code chính, vì prompt dễ nằm gần vùng kích hoạt classifier.

Phát hiện chuyển hướng bằng code

Tín hiệu đáng tin cậy nhất là trường model trong response. Mọi response của Messages API đều cho biết model thực sự tạo ra output.

Ví dụ:

• Request gửi đến: claude-fable-5
• Response trả về: claude-opus-4-8

=> Request đã được fallback/chuyển hướng.

Bạn cũng nên ghi log thêm:

• stop_reason: để phát hiện request bị từ chối hoàn toàn.
• usage: để phân bổ chi phí theo token.
• request ID hoặc trace ID nội bộ: để debug production.

Ví dụ Python:

response = client.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    messages=[
        {"role": "user", "content": prompt}
    ],
)

if response.stop_reason == "refusal":
    # Request bị từ chối và không có nội dung hữu ích để xử lý
    handle_refusal(response)

elif not response.model.startswith("claude-fable-5"):
    # Request đã được model khác phục vụ
    logger.info(
        "fallback served_by=%s input_tokens=%d output_tokens=%d",
        response.model,
        response.usage.input_tokens,
        response.usage.output_tokens,
    )

    handle_fallback_response(response)

else:
    handle_fable_response(response)

Một cách an toàn hơn là bọc logic này thành một hàm dùng chung:

def classify_claude_response(response, expected_model_prefix="claude-fable-5"):
    if response.stop_reason == "refusal":
        return "refusal"

    if not response.model.startswith(expected_model_prefix):
        return "fallback"

    return "normal"

Sau đó dùng trong service layer:

status = classify_claude_response(response)

match status:
    case "refusal":
        return build_refusal_message()
    case "fallback":
        metrics.increment("claude.fable5.fallback")
        return response.content
    case "normal":
        return response.content

Nếu bạn đang xây dựng API từ đầu, hãy bắt đầu với hướng dẫn cách sử dụng API Claude Fable 5, sau đó thêm bước kiểm tra response.model và stop_reason.

Dùng tham số fallbacks

Nếu không cấu hình fallback, một request bị từ chối sẽ dừng lại. Bạn nhận response từ chối, nhưng không có nội dung hữu ích cho người dùng.

Tham số fallbacks chuyển việc retry sang phía server:

1. Bạn gọi Fable 5.
2. Fable 5 từ chối request.
3. API tự chạy lại cùng request trên model fallback bạn chỉ định.
4. Bạn nhận response cuối cùng trong cùng một API call.

Theo tài liệu refusals and fallback của Anthropic, tính năng này đang ở dạng beta trên Claude API và Claude Platform trên AWS. Bạn cần bật beta header. Tại thời điểm ra mắt, model fallback được hỗ trợ là claude-opus-4-8.

Ví dụ:

response = client.beta.messages.create(
    model="claude-fable-5",
    max_tokens=16000,
    betas=["server-side-fallback-2026-06-01"],
    fallbacks=[
        {"model": "claude-opus-4-8"}
    ],
    messages=[
        {"role": "user", "content": prompt}
    ],
)

print(response.model)
# claude-opus-4-8 nếu request đã được fallback

Bạn vẫn cần kiểm tra response.model:

if response.model == "claude-opus-4-8":
    logger.info("Request was served by fallback model")

Và vẫn cần giữ nhánh xử lý từ chối:

if response.stop_reason == "refusal":
    return {
        "status": "refused",
        "message": "Yêu cầu không thể được xử lý."
    }

Lý do: nếu model fallback cũng từ chối, response cuối cùng vẫn có stop_reason: "refusal".

Một số giới hạn cần biết:

• fallbacks bị từ chối trên API Batches.
• Không khả dụng trên Amazon Bedrock, Google Vertex AI hoặc Microsoft Foundry.
• Trên các nền tảng đó, bạn cần tự retry ở phía client.
• Request bị từ chối trước khi tạo output không bị tính phí; nếu fallback model trả lời, bạn trả phí theo giá của model fallback.

Thiết kế policy xử lý fallback

Đừng chỉ phát hiện fallback rồi bỏ qua. Hãy chọn policy rõ ràng cho sản phẩm.

Policy 1: Chấp nhận câu trả lời từ Opus 4.8

Phù hợp với:

• Chat assistant
• Agent tổng quát
• Content generation
• Internal tooling

Triển khai:

if status == "fallback":
    metrics.increment("fable5.fallback")
    audit_log.write({
        "requested_model": "claude-fable-5",
        "served_model": response.model,
        "input_tokens": response.usage.input_tokens,
        "output_tokens": response.usage.output_tokens,
    })

return response.content

Ưu điểm: người dùng vẫn nhận được câu trả lời trong một round-trip.

Policy 2: Retry với request đã chỉnh sửa

Phù hợp khi bạn cần giữ output từ Fable 5 nhưng có thể sửa prompt.

Không nên gửi lại y nguyên prompt cũ, vì classifier đã từ chối một lần thì thường sẽ từ chối tiếp.

Các lựa chọn hợp lý:

• Diễn đạt lại prompt để tránh vùng kích hoạt.
• Tách task thành các bước nhỏ hơn.
• Định tuyến toàn bộ task sang Opus 4.8.
• Đưa vào hàng đợi review thủ công.

Pseudo-code:

if status == "fallback" and workflow.requires_fable_only:
    rewritten_prompt = rewrite_prompt_for_safety(prompt)

    retry_response = client.messages.create(
        model="claude-fable-5",
        max_tokens=16000,
        messages=[
            {"role": "user", "content": rewritten_prompt}
        ],
    )

    return retry_response

Policy 3: Hiển thị model đã phục vụ cho người dùng

Phù hợp khi:

• Khách hàng trả tiền riêng cho Fable 5.
• Có yêu cầu audit/compliance.
• Người dùng cần quyết định có chạy lại hay không.

Ví dụ response API nội bộ:

{
  "requested_model": "claude-fable-5",
  "served_model": "claude-opus-4-8",
  "fallback_used": true,
  "content": "..."
}

Dù chọn policy nào, hãy đo tỷ lệ fallback:

metrics.increment(
    "claude.request",
    tags={
        "requested_model": "claude-fable-5",
        "served_model": response.model,
        "status": status,
    },
)

Nếu tỷ lệ fallback gần 0, đó là bình thường. Nếu vượt vài phần trăm, prompt của bạn có thể đang chạm vào vùng classifier và nên được review.

Kiểm thử nhánh từ chối trước production

Fallback thường hiếm, nên rất dễ bị bỏ sót trong QA. Code có thể chạy tốt trong demo nhưng lỗi sau vài tuần khi người dùng thật kích hoạt classifier.

Bạn nên chủ động tạo test case cho các nhánh sau:

Trường hợp	Kỳ vọng
Prompt bình thường	model vẫn là claude-fable-5
Prompt gần vùng classifier	Có thể fallback sang claude-opus-4-8
Prompt bị từ chối hoàn toàn	stop_reason == "refusal"
Fallback thành công	Có nội dung hợp lệ và model là fallback model
Fallback cũng từ chối	App hiển thị thông báo từ chối an toàn

Apidog giúp bạn biến các test này thành kịch bản lặp lại được:

1. Tạo endpoint Claude Messages.
2. Lưu API key trong environment variable.
3. Tạo một bộ prompt nhỏ:
   • Prompt kiểm soát lành tính.
   • Prompt gần lĩnh vực an ninh.
   • Prompt gần lĩnh vực sinh học/hóa học.
   • Prompt kiểm tra nhánh từ chối.
4. Thêm assertion trên response body:
   • model
   • stop_reason
   • usage.input_tokens
   • usage.output_tokens

Ví dụ assertion logic:

pm.test("Response has model", function () {
  pm.expect(pm.response.json().model).to.exist;
});

pm.test("Response is not an unhandled refusal", function () {
  const body = pm.response.json();
  pm.expect(body.stop_reason).to.not.equal("refusal");
});

Với test case fallback, bạn có thể kiểm tra:

pm.test("Fallback served by expected model", function () {
  const body = pm.response.json();

  if (body.model !== "claude-fable-5") {
    pm.expect(body.model).to.equal("claude-opus-4-8");
  }
});

Chạy kịch bản này theo lịch hoặc trong CI. Khi Anthropic huấn luyện lại classifier, như trước lần triển khai lại ngày 1 tháng 7, bộ test sẽ cho bạn biết liệu các case biên của bạn còn hoạt động đúng với logic xử lý hiện tại hay không.

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

Tham số fallbacks có làm tăng chi phí không?

Không theo kiểu tính phí hai lần. Request bị từ chối trước khi tạo output không bị tính phí. Nếu model fallback trả lời, bạn trả phí theo token của model fallback cho nỗ lực khôi phục đó.

Prompt liên quan đến bảo mật có luôn bị fallback không?

Không. Classifier nhắm vào các request độc hại trong an ninh mạng, sinh học/hóa học và chưng cất mô hình, không nhắm vào chủ đề nói chung. Phần lớn công việc kỹ thuật bảo mật vẫn đi qua bình thường. Tuy vậy, false positive có thể xảy ra gần các lĩnh vực này, nên bạn nên test và ghi log tỷ lệ fallback.

Tôi đã dừng dùng Fable 5 trong đợt tạm ngừng tháng 6. Có thể quay lại không?

Có. Sau lần triển khai lại ngày 1 tháng 7, classifier đã được huấn luyện lại và giao diện API không thay đổi. Xem hướng dẫn cách quay lại API Fable 5. Với nhiều nhóm, phần cần thêm khi quay lại là cấu hình fallbacks và logging response.model.

Tóm lại

Hãy coi fallback của Fable 5 là một nhánh thiết kế, không phải lỗi bất thường.

Checklist triển khai:

• Kiểm tra response.model trên mọi request.
• Kiểm tra stop_reason == "refusal" trước khi đọc nội dung.
• Bật fallbacks nếu sản phẩm của bạn chấp nhận Opus 4.8 làm model khôi phục.
• Ghi log requested_model, served_model, usage và trạng thái fallback.
• Chọn policy rõ ràng: chấp nhận, retry có chỉnh sửa, hoặc hiển thị cho người dùng.
• Dùng Apidog để kiểm thử model và stop_reason theo lịch hoặc trong CI.

Tải Apidog để tạo bộ kiểm thử từ chối và fallback trước lần deploy tiếp theo.