DEV Community: Jemmmm

Claude Opus 5 và GPT-5.6 Luna: 18 bài kiểm chứng, không xếp hạng theo tốc độ

Jemmmm — Thu, 30 Jul 2026 00:45:14 +0000

Kết luận nhanh

Ở vòng khó, Claude Opus 5 đạt 17/18 (94,4%), còn GPT-5.6 Luna đạt 16/18 (88,9%). Chênh lệch một bài trong mẫu này không chứng minh Opus mạnh hơn toàn diện. Điều đáng chú ý là kiểu lỗi: Opus bàn giao thành công cả ba tệp thuật toán nhưng phá vỡ hợp đồng JSON nghiêm ngặt; Luna làm đúng cả ba yêu cầu định dạng nhưng hai tệp Python bị lỗi ngay khi import.

Vì sao cần tăng độ khó

Vòng đầu tám bài không tạo khác biệt: cả hai đều 8/8. Vòng hai vì thế tăng lên 18 bài, gồm hard, harder và extreme trong sáu nhóm. Bài kiểm tra yêu cầu phân số chính xác, mô hình vật lý nhiều giai đoạn, tệp mã hoàn chỉnh, khả năng bác bỏ tiền đề sai, nghiệm logic duy nhất và kỷ luật đầu ra đến từng ký tự. Câu trả lời không được điểm chỉ vì nghe thuyết phục; kết luận quyết định phải được xác nhận bằng phép tính, parser JSON hoặc chạy Python.

Cách chấm vòng 18 bài

Hai mô hình nhận cùng đề, system prompt, temperature và ngân sách đầu ra theo bài. Toán và vật lý được đối chiếu với giá trị chính xác hoặc sai số cho phép. Mã được lưu nguyên trạng rồi import vào cùng bộ hidden test. JSON và CSV được chấm như sản phẩm máy đọc. Nếu phải xóa assert do mô hình tự viết thì tệp mới chạy được, kết quả đó chỉ dùng để tìm nguyên nhân chứ không đổi điểm bàn giao ban đầu. Độ trễ tuyến chỉ nằm trong JSON gốc và hoàn toàn không dùng để chọn bên thắng.

Kết quả trên sáu nhóm năng lực

Nhóm đánh giá	Opus 5	GPT-5.6 Luna
Suy luận toán học	3/3	3/3
Vật lý phức tạp	3/3	3/3
Bàn giao thuật toán	3/3	1/3
Chống tiền đề sai	3/3	3/3
Suy luận ràng buộc	3/3	3/3
Tuân thủ chỉ dẫn	2/3	3/3
Total	17/18 (94.4%)	16/18 (88.9%)

Khoảng cách thuật toán nằm ở chất lượng bàn giao

Hai câu thuật toán Luna thất bại có phần hàm cốt lõi vượt qua hidden test sau khi bỏ các assert ở cuối tệp. Tuy nhiên, chính các assert này chứa kết quả mong đợi sai, khiến tệp gốc ném AssertionError khi import. Với yêu cầu “tệp Python hoàn chỉnh”, đó là lỗi thật. Ba tệp của Opus import và vượt qua cùng một harness mà không cần sửa. Trong production, thân hàm có vẻ đúng chưa đồng nghĩa với sản phẩm có thể triển khai.

JSON nghiêm ngặt lại nghiêng về Luna

Lỗi duy nhất của Opus đi theo hướng ngược lại. Các key và value đều đúng, nhưng mô hình bọc JSON trong code fence Markdown dù đề yêu cầu đúng một object và không có gì khác. Lần chạy lại độc lập tái hiện đúng hành vi này. Luna vượt qua cả ba bài tuân thủ chỉ dẫn. Nếu đầu ra được chuyển thẳng vào parser, lớp bọc cũng là một phần của độ chính xác.

Tách giới hạn đầu ra khỏi lỗi trí tuệ

Một số lần thử sớm kết thúc với finish_reason=length vì phần suy luận ẩn dùng hết ngân sách đầu ra. Chúng được giữ làm bằng chứng nhưng không bị tính là lỗi trí tuệ. Ngân sách hiệu dụng được tăng giống nhau cho hai mô hình trước khi chấm. Cách làm này không trộn cấu hình với năng lực, đồng thời vẫn cho thấy rủi ro tích hợp: suy luận dài có thể chiếm chỗ của sản phẩm nhìn thấy được.

Áp dụng vào định tuyến thực tế

Ưu tiên Luna cho JSON nghiêm ngặt, CSV, trích xuất ngắn và xử lý có cấu trúc số lượng lớn, nhưng luôn giữ schema validation. Ưu tiên Opus cho tệp thuật toán dài, kiểm tra biên và kỹ thuật phòng thủ. Toán, vật lý phức tạp, tiền đề sai và suy luận ràng buộc hòa nhau trong mẫu này; khi đó giá, giao diện và phong cách trả lời là tiêu chí hợp lý hơn. Dù dùng mô hình nào, hãy parse JSON, kiểm tra số quan trọng và chạy mã nguyên trạng.

Cách tái hiện và bằng chứng gốc

Trình chạy là scripts/opus5_vs_luna_hard_benchmark.py. Kết quả đầy đủ nằm ở .tmp/opus5-vs-luna-hard-benchmark-results.json; các lần tái thử độc lập nằm ở .tmp/opus5-hard-failure-retry.json và .tmp/luna-hard-failure-retry.json. Endpoint sử dụng là https://cn.crazyrouter.com/v1/chat/completions; dữ liệu độ trễ chỉ được giữ trong bằng chứng gốc.

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

17/18 có nghĩa Opus 5 là bên thắng tuyệt đối không?

Không. Opus chỉ dẫn một bài trong bộ 18 bài này. Thử nghiệm chưa bao phủ hình ảnh, công cụ, ngữ cảnh cực dài hay agent nhiều lượt.

Vì sao tự kiểm thử sai vẫn tính là lỗi thuật toán?

Vì sản phẩm được yêu cầu là một tệp Python hoàn chỉnh. Nếu tệp gốc lỗi khi import, hệ thống phía sau không thể dùng nếu không sửa tay.

Vì sao độ trễ không xuất hiện trong kết luận?

Độ trễ chịu tác động của mô hình, gateway, tải upstream và trạng thái tuyến. Nó hữu ích cho vận hành nhưng không đo độ đúng của trí tuệ.

Kết luận cuối

Trong bài kiểm tra ưu tiên độ chính xác có thể kiểm chứng, Opus 5 dẫn 17/18 so với 16/18 nhờ bàn giao trọn vẹn ba thuật toán. Luna tốt hơn ở kỷ luật định dạng nghiêm ngặt. Kết luận thực tế là quy tắc định tuyến dựa trên lỗi có thể tái hiện, không phải một nhà vô địch cho mọi tình huống.

Thử cả hai mô hình trên Crazyrouter bằng prompt production của bạn

Claude Opus 5 против GPT-5.6 Luna: 18 проверяемых задач без рейтинга скорости

Jemmmm — Thu, 30 Jul 2026 00:43:04 +0000

Короткий ответ

В усложнённом раунде Claude Opus 5 получил 17/18 (94,4%), а GPT-5.6 Luna — 16/18 (88,9%). Это преимущество в одну задачу в данной выборке, а не доказательство универсального превосходства. Важнее тип ошибок: Opus сдал все три исполняемых алгоритма, но нарушил контракт строгого JSON; Luna идеально выполнила три форматных инструкции, однако два Python-файла падали уже при импорте.

Почему задачи пришлось усложнить

Первый раунд из восьми задач не разделил модели: обе набрали 8/8. Поэтому второй раунд включил 18 задач уровней hard, harder и extreme в шести категориях. Требовались точные дроби, многоэтапные физические модели, целые исполняемые файлы, распознавание ложных предпосылок, единственные решения систем ограничений и буквальное соблюдение формата. Красивое объяснение само по себе баллов не давало: решающие утверждения проверялись вычислением, парсером JSON или запуском Python.

Как оценивались 18 задач

Обе модели получали одинаковые задания, системную инструкцию, temperature и бюджет вывода для каждой задачи. Математика и физика сверялись с точными значениями и допусками. Код сохранялся без правок и импортировался одним скрытым набором тестов. JSON и CSV проверялись как машинные артефакты. Если файл начинает работать только после удаления написанных моделью assert, это объясняет причину сбоя, но не превращает исходную поставку в успешную. Задержка маршрута сохранена только в исходном JSON и не влияет на победителя.

Результаты по шести направлениям

Направление	Opus 5	GPT-5.6 Luna
Математические рассуждения	3/3	3/3
Сложная физика	3/3	3/3
Готовые алгоритмы	3/3	1/3
Отказ от ложных предпосылок	3/3	3/3
Логика ограничений	3/3	3/3
Соблюдение инструкций	2/3	3/3
Total	17/18 (94.4%)	16/18 (88.9%)

Разрыв в алгоритмах оказался разрывом в поставке

В двух неудачных ответах Luna основные функции проходили скрытые тесты после удаления нижнего блока самопроверки. Но собственные assert содержали неверные ожидаемые значения, поэтому исходные файлы выбрасывали AssertionError при импорте. По контракту «готовый Python-файл» это ошибки. Все три файла Opus импортировались и прошли общий harness. Для продакшена вывод прост: правдоподобное тело функции ещё не является готовым артефактом.

Строгий JSON показал преимущество Luna

Единственная ошибка Opus была зеркальной. Поля и значения JSON оказались правильными, но объект был окружён Markdown-блоком, хотя требовался ровно один JSON-объект без дополнительного текста. Независимый повтор дал тот же результат. Luna прошла все три задачи на соблюдение инструкции. Если ответ сразу поступает в парсер, оболочка — часть корректности, а не вопрос оформления.

Лимит вывода отделён от ошибок интеллекта

Ранние ответы иногда завершались с finish_reason=length: скрытое рассуждение съедало доступный бюджет. Эти попытки сохранены, но не засчитаны как интеллектуальные ошибки. Перед итоговой оценкой эффективный бюджет одинаково увеличили обеим моделям. Так конфигурация не смешивается с качеством рассуждения, но интеграционный риск остаётся видимым.

Как маршрутизировать запросы в продакшене

Для строгого JSON, CSV, короткого извлечения и массовой структурированной обработки разумно начинать с Luna, обязательно сохраняя schema-валидацию. Для длинных алгоритмов и защитного инженерного кода — с Opus. В математике, сложной физике, сопротивлении ложным предпосылкам и логике ограничений получилась ничья; здесь полезнее учитывать цену, интерфейс и стиль ответа. Любой результат нужно проверять как артефакт: парсить JSON, сверять числа и запускать код без ручной очистки.

Воспроизведение и исходные данные

Сценарий запуска: scripts/opus5_vs_luna_hard_benchmark.py. Полный результат: .tmp/opus5-vs-luna-hard-benchmark-results.json. Независимые повторы: .tmp/opus5-hard-failure-retry.json и .tmp/luna-hard-failure-retry.json. Использовался чистый API-адрес https://cn.crazyrouter.com/v1/chat/completions; параметры задержки находятся только в исходных доказательствах.

Частые вопросы

Означает ли 17/18, что Opus 5 — абсолютный победитель?

Нет. Это лидерство в одну задачу на конкретном наборе. Здесь не тестировались изображения, инструменты, сверхдлинный контекст и многошаговые агенты.

Почему ошибочные самотесты считаются провалом алгоритма?

Потому что требовался полный Python-файл. Если исходный файл падает при импорте, система не может использовать его без ручного ремонта.

Почему задержки нет в итоговом решении?

Она зависит от модели, шлюза, маршрута, нагрузки и состояния канала. Это важная операционная метрика, но не показатель правильности интеллекта.

Итог

В тесте с приоритетом проверяемой точности Opus 5 выиграл 17/18 против 16/18 благодаря трём готовым алгоритмам. Luna лучше соблюдала строгий формат. Практический итог — не «вечный чемпион», а воспроизводимое правило маршрутизации.

Проверьте обе модели в Crazyrouter на собственных рабочих запросах

Claude Opus 5 và GPT-5.6-SOL: kiểm thử 10 bài về độ chính xác, kết quả cốt lõi hòa 10/10

Jemmmm — Thu, 30 Jul 2026 00:25:53 +0000

Claude Opus 5 và GPT-5.6-SOL: kiểm thử 10 bài về độ chính xác, kết quả cốt lõi hòa 10/10

Khi tích hợp mô hình vào API thực tế, câu hỏi hữu ích không chỉ là “mô hình nào thông minh hơn?”, mà còn là:

Kết quả nào được tính là đạt?
Có thể kiểm tra đầu ra bằng mã cục bộ hay không?
Mô hình đã hoàn thành mọi yêu cầu con hay mới chỉ đưa ra đáp án chính?
Phản hồi JSON có thể đưa thẳng vào hệ thống phía sau không?
Có phải đầu ra bị cắt do hết ngân sách token?
Một lần chạy thành công hoặc thất bại có đủ để kết luận không?

Nếu không định nghĩa trước tiêu chí pass/fail, rất dễ đánh đồng HTTP 200 với hoàn thành tác vụ, hoặc chọn một phản hồi trông thuyết phục rồi tuyên bố mô hình chiến thắng.

Trong lần đánh giá này, Claude Opus 5 và GPT-5.6-SOL được gọi qua cùng một OpenAI-compatible endpoint của Crazyrouter. Bộ kiểm thử gồm 10 bài có thể nghiệm thu độc lập; phần tuân thủ JSON nghiêm ngặt được chấm riêng, không trộn với độ chính xác toán học hay lập luận.

Kết quả chính:

Độ chính xác của đáp án cốt lõi: Opus 5 10/10, GPT-5.6-SOL 10/10.
Hoàn thành đầy đủ mọi yêu cầu con: Opus 5 9/10, GPT-5.6-SOL 10/10.
Hai bài thuật toán Python với kiểm thử ẩn: cả hai đều đạt 2/2.
JSON nghiêm ngặt ở lần chạy đầu: Opus 5 0/1, GPT-5.6-SOL 1/1.
Opus tiếp tục không tuân thủ định dạng JSON nghiêm ngặt trong hai lần thử lại bổ sung vì vẫn chèn văn bản hoặc hàng rào mã.

Nói cách khác, hai mô hình hòa nhau về tính đúng đắn cốt lõi trong bộ 10 bài này, nhưng hành vi giao kết quả không hoàn toàn giống nhau.

Tạo API Key và kiểm thử lại bằng bộ đề thực tế của bạn

Trả lời nhanh

Câu hỏi	Kết quả trong lần kiểm thử này
Mô hình nào đưa ra đáp án cốt lõi chính xác hơn?	Hòa: cả hai đều đạt 10/10
Mô hình nào hoàn thành đầy đủ nhiều yêu cầu hơn?	GPT-5.6-SOL: 10/10; Opus 5: 9/10
Mã của mô hình nào đáng tin cậy hơn?	Hòa trong bộ kiểm thử này; cả hai đều vượt qua kiểm thử ẩn của hai bài thuật toán
Opus có tính sai bài xác suất khó không?	Không. Đáp án cốt lõi đúng, nhưng đầu ra bị cắt tại `max_tokens=3200`, làm thiếu yêu cầu giải thích cuối cùng
Mô hình nào tuân thủ JSON nghiêm ngặt tốt hơn?	GPT-5.6-SOL ổn định hơn trong lần này; Opus thêm văn bản hoặc hàng rào mã ở cả 3 lần
Có thể từ đây kết luận GPT thông minh hơn không?	Không. Độ chính xác lập luận và khả năng tuân thủ định dạng phải được chấm riêng

Nếu bài toán chủ yếu là toán học, vật lý hoặc thuật toán có đáp án kiểm chứng được, mẫu kiểm thử này không cho thấy chênh lệch rõ ràng. Nếu hệ thống yêu cầu phản hồi phải là JSON có thể phân tích cú pháp trực tiếp, hoặc không được bỏ sót bất kỳ yêu cầu con nào, GPT-5.6-SOL hoàn chỉnh hơn trong lần đánh giá này.

Vì sao độ trễ mạng không được tính vào điểm năng lực

Thời gian phản hồi đầu cuối của API chịu ảnh hưởng bởi nhiều biến số không phản ánh trực tiếp khả năng suy luận:

đường truyền từ cổng API đến từng nhà cung cấp phía trên;
tải hệ thống tại thời điểm gửi yêu cầu;
giới hạn tốc độ của tài khoản hoặc kênh;
việc có trúng bộ nhớ đệm hay không;
yêu cầu được định tuyến đến phiên bản dịch vụ thực tế nào;
cách nhà cung cấp thống kê hoặc ẩn reasoning token.

Một yêu cầu nhanh hơn vài giây có thể chỉ phản ánh tuyến mạng hoặc tải tức thời. Nó không chứng minh mô hình suy luận tốt hơn.

Muốn đánh giá độ trễ một cách có ý nghĩa, cần cố định hệ thống phía trên, chạy lặp đủ nhiều lần và báo cáo phân phối hoặc khoảng tin cậy. Khi chưa đáp ứng các điều kiện đó, độ trễ phù hợp để giám sát vận hành, không phù hợp để đưa vào “điểm thông minh”.

Vì vậy, bài này không xếp hạng hoặc công bố mô hình thắng về tốc độ. Nếu cần kiểm tra phạm vi mô hình có thể truy cập, hãy xem danh sách mô hình Crazyrouter. Việc lập kế hoạch chi phí nên được thực hiện riêng qua Crazyrouter pricing.

Môi trường kiểm thử và tiêu chí pass/fail

Trước khi chạy, danh sách mô hình được truy vấn để xác nhận hai model ID chính xác đều khả dụng:

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
gpt-5.6-sol

Mọi yêu cầu chính thức đều sử dụng:

POST https://cn.crazyrouter.com/v1/chat/completions

Trong mỗi đợt kiểm thử, hai mô hình nhận cùng:

system prompt;
user prompt;
temperature;
max_tokens.

Không sử dụng công cụ bên ngoài. HTTP 200 cũng không tự động được tính là hoàn thành tác vụ.

Việc chấm điểm được chia thành ba lớp:

Độ chính xác cốt lõi: giá trị chính, kết luận vật lý hoặc hành vi thuật toán có đúng không.
Mức độ hoàn thành tác vụ: mô hình có xử lý đầy đủ mọi yêu cầu con trong đề hay không.
Khả năng nghiệm thu bằng máy: mã có vượt qua kiểm thử ẩn không, JSON có thể được phân tích cú pháp trực tiếp không.

Sau bước chấm tự động theo chuỗi, kết quả được rà soát thủ công để tránh âm tính giả. Cùng một đáp án có thể được biểu diễn bằng LaTeX khác nhau, dùng phân số tương đương hoặc làm tròn với số chữ số có nghĩa khác nhau.

Ví dụ:

GPT-5.6-SOL không sao chép nguyên phân số tham chiếu trong bài xác suất, nhưng đưa ra công thức tương đương và giá trị thập phân đúng.
Opus viết 0.30 m với hai chữ số có nghĩa thay cho 0.302 m trong bài vật lý; đây không phải là một đáp án sai.

Kết quả 10 bài kiểm thử

Tác vụ	Tiêu chí nghiệm thu	Claude Opus 5	GPT-5.6-SOL
Chuỗi Markov chính xác	`E[τ]=5`, `E[τ²]=43`, `Var(τ)=18`	Đúng	Đúng
Dao động tử hai bậc tự do	Hai tần số riêng, hai biên độ, hai pha	Đúng	Đúng
Tìm kiếm có ràng buộc	Thứ tự duy nhất `A,C,E,B,D`	Đúng	Đúng
Sửa lập luận Cantelli	Không thể xác định xác suất; cận trên là `0.2`	Đúng	Đúng
Rà soát phát hiện chu trình bằng Python	Lỗi, phản ví dụ DAG, bản sửa tối thiểu	Đúng	Đúng
Thiết kế thí nghiệm	Ghép cặp cùng đề, kiểm soát độ khó, khoảng tin cậy	Đúng	Đúng
Thời gian chờ đồng xu lệch cho `HHTH`	Kỳ vọng xấp xỉ `12.6547` và chuyển trạng thái đúng	Phần cốt lõi đúng; thiếu giải thích cuối do bị cắt	Đúng và đầy đủ
Thuật toán tổng hợp nhật ký	Cửa sổ thời gian, sự kiện lỗi, tỷ lệ bộ nhớ đệm, người dùng hàng đầu	Vượt qua kiểm thử ẩn	Vượt qua kiểm thử ẩn
Va chạm không đàn hồi và lò xo	`v1≈6.10`, `v2≈2.44`, `x≈0.302`	Đúng	Đúng
Thuật toán định tuyến ổn định	cost, latency, reliability và quy tắc thứ tự từ điển	Vượt qua kiểm thử ẩn	Vượt qua kiểm thử ẩn

Tổng hợp theo từng lớp chấm:

Chỉ số	Claude Opus 5	GPT-5.6-SOL
Đáp án cốt lõi chính xác	10/10	10/10
Hoàn thành đầy đủ yêu cầu con	9/10	10/10
Bài mã vượt qua kiểm thử ẩn	2/2	2/2
JSON nghiêm ngặt ở lần đầu	0/1	1/1

Bài xác suất khó: đúng đáp án chưa chắc đã hoàn thành tác vụ

Bài toán yêu cầu tính thời gian chờ để xuất hiện mẫu HHTH, với đồng xu lệch:

P(H)=0.62
P(T)=0.38

Đề yêu cầu xây dựng các phương trình trạng thái theo tiền tố dài nhất đồng thời là hậu tố phù hợp. Ngoài việc tính kỳ vọng, mô hình còn phải giải thích hai điểm dễ sai:

Sau trạng thái HH, nếu tiếp tục xuất hiện H, vì sao hệ thống vẫn ở trạng thái HH?
Vì sao không thể viết trực tiếp thời gian chờ kỳ vọng thành 1/P(HHTH)?

Cả hai mô hình đều tính đúng:

E[N] ≈ 12.6547

GPT-5.6-SOL hoàn thành toàn bộ phép suy diễn và chỉ ra rằng mẫu có hiện tượng chồng lấn, do đó:

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5 cũng đưa ra đúng hệ trạng thái, phương trình, phân số chính xác và kết quả thập phân. Tuy nhiên, phản hồi kết thúc với:

finish_reason=length

Đầu ra dừng ở phần giá trị kỳ vọng bổ sung của trạng thái, trước khi hoàn thành yêu cầu giải thích vì sao không thể dùng trực tiếp nghịch đảo xác suất.

Ngân sách đầu ra của lần chạy này là:

max_tokens=3200

Do đó, cách chấm hợp lý là:

Đáp án cốt lõi: đạt, vì 12.6547 và mô hình trạng thái đều đúng.
Hoàn thành toàn bộ tác vụ: không đạt, vì thiếu một yêu cầu giải thích bắt buộc.

Đây là điểm khác biệt quan trọng trong tích hợp API:

Kết quả số đúng không đồng nghĩa với việc toàn bộ tác vụ đã hoàn thành.

Cùng phương pháp này đã được áp dụng trong bài kiểm thử cắt đầu ra do max_tokens. Hệ thống kiểm thử nên lưu đồng thời nội dung đáp án, finish_reason và ngân sách đầu ra. Không nên thấy phần đầu đúng rồi mặc định toàn bộ phản hồi đạt yêu cầu.

Kiểm chứng mã thực thi: phải chạy, không chỉ đọc

Đánh giá mã bằng cảm giác rất dễ sai. Một lời giải dài hơn, nhiều chú thích hơn hoặc có cấu trúc đẹp hơn chưa chắc đúng ở các trường hợp biên.

Trong lần kiểm thử này, mã do mô hình tạo ra được lưu thành tệp .py và chạy trong chế độ cách ly với cùng một bộ kiểm thử ẩn.

Bài tổng hợp nhật ký

Hàm phải xử lý đồng thời:

cửa sổ thời gian nửa mở;
quy tắc đếm khác nhau giữa yêu cầu thành công và thất bại;
trường hợp thiếu người dùng hoặc mô hình;
cache hit rate;
sắp xếp người dùng theo thứ tự từ điển khi cost bằng nhau;
không sửa đổi đối tượng đầu vào.

Cả Claude Opus 5 và GPT-5.6-SOL đều vượt qua kiểm thử ẩn.

Bài định tuyến ổn định có ràng buộc độ tin cậy

Hàm tìm đường phải áp dụng đúng thứ tự ưu tiên:

tổng chi phí thấp nhất;
nếu chi phí bằng nhau, chọn độ trễ thấp nhất;
nếu vẫn bằng nhau, chọn độ tin cậy cao nhất;
cuối cùng chọn đường đi theo thứ tự từ điển.

Ngoài ra, lời giải còn phải xử lý:

banned nodes;
số hops tối đa;
độ tin cậy tối thiểu;
cạnh không hợp lệ.

Cả hai mô hình đều vượt qua toàn bộ kiểm thử. Vì vậy, kết luận về mã trong bộ đề này là hòa 2/2, không phải chọn bên thắng dựa trên độ dài hay phong cách trình bày của mã.

Có thể tham khảo thêm GPT-5.6-SOL vs GPT-5.5 trong bộ bài vật lý khó và mã.

JSON nghiêm ngặt: phép thử tuân thủ chỉ dẫn, không phải bài toán trí tuệ

Bài JSON yêu cầu nén dữ liệu sự cố thành đúng một đối tượng và nêu rõ:

exactly one JSON object and no Markdown

Hai mô hình đều tính đúng các trường dữ liệu, bao gồm:

tỷ lệ lỗi;
bên chịu trách nhiệm theo kênh;
số lỗi chưa phục hồi sau khi thử lại.

Khác biệt nằm ở lớp bao quanh đầu ra:

GPT-5.6-SOL chỉ trả về JSON ngay lần đầu và có thể đưa trực tiếp vào json.loads.
Opus 5 thêm hàng rào mã và phần Verification ở lần đầu.
Trong lần thử lại thứ nhất, Opus trả JSON rút gọn nhưng tiếp tục thêm Verification phía sau.
Trong lần thử lại thứ hai, Opus lại thêm hàng rào mã và phần giải thích.

Vì vậy, kết quả JSON nghiêm ngặt là:

GPT-5.6-SOL: 1/1 ở lần đầu.
Opus 5: 0/1 ở lần đầu.
Opus vẫn không tuân thủ trong hai lần thử lại bổ sung.

Đây là trường hợp “dữ liệu đúng nhưng định dạng không đạt”, không phải “không biết tính”. Nếu trộn kết quả này vào điểm suy luận toán học, hai loại lỗi khác nhau sẽ bị nhập thành một điểm số mơ hồ.

Một bộ kiểm tra cục bộ tối thiểu có thể viết như sau:

import json

REQUIRED_KEYS = [
    "window",
    "total_requests",
    "failed_requests",
    "failure_rate_pct",
    "provider_owned_failures",
    "customer_owned_failures",
    "recovered_by_retry",
    "unrecovered_failures",
    "root_cause",
    "action",
]


def parse_incident_json(raw: str) -> dict:
    payload = json.loads(raw)
    if list(payload) != REQUIRED_KEYS:
        raise ValueError("unexpected schema or key order")
    if payload["failed_requests"] != 84:
        raise ValueError("failed request count mismatch")
    return payload

Không nên dựa hoàn toàn vào system prompt để bảo đảm đầu ra có cấu trúc. Với hệ thống thật, quy trình an toàn hơn là:

sử dụng tham số đầu ra có cấu trúc nếu nhà cung cấp hỗ trợ;
phân tích cú pháp JSON cục bộ;
kiểm tra schema và giá trị bắt buộc;
thử lại hoặc chuyển mô hình khi nghiệm thu thất bại;
chỉ chuyển dữ liệu sang bước tiếp theo sau khi toàn bộ kiểm tra đạt.

Cách kiểm thử lại qua cùng một API

Ví dụ tối thiểu dưới đây gọi OpenAI-compatible chat completions endpoint. API endpoint không gắn tham số UTM.

import os
import requests

BASE_URL = "https://cn.crazyrouter.com/v1"
API_KEY = os.environ["CRAZYROUTER_API_KEY"]


def ask(model: str, prompt: str, max_tokens: int = 4000) -> dict:
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "system", "content": "Answer accurately and follow every requested constraint."},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.2,
            "max_tokens": max_tokens,
        },
        timeout=600,
    )
    response.raise_for_status()
    return response.json()


for model in ("claude-opus-5", "gpt-5.6-sol"):
    result = ask(model, "Your benchmark prompt here")
    choice = result["choices"][0]
    print(model, choice.get("finish_reason"), choice["message"].get("content", ""))

Khi chạy bộ đánh giá thật, nên lưu thêm:

response ID;
returned model;
câu trả lời nguyên gốc;
finish_reason;
cấu hình temperature và max_tokens;
kết quả của từng bộ kiểm tra cục bộ;
lý do pass/fail cụ thể.

Có thể kiểm tra khả năng truy cập mô hình trong danh sách mô hình Crazyrouter, sau đó chạy hồi quy theo lô nhỏ bằng chính prompt nghiệp vụ của bạn.

Cách tránh kết luận sai từ một lần chạy

Một lần chạy chỉ là một mẫu. Nó có thể hữu ích để phát hiện lỗi rõ ràng, nhưng chưa đủ để mô tả hành vi dài hạn của mô hình.

Để kết quả có giá trị cho tích hợp thực tế:

Định nghĩa pass/fail trước khi chạy

Mỗi bài nên có tiêu chí máy có thể kiểm tra, chẳng hạn:

giá trị số phải nằm trong sai số cho phép;
tất cả yêu cầu con bắt buộc phải xuất hiện;
finish_reason không được là length;
mã phải vượt qua kiểm thử đơn vị và kiểm thử ẩn;
JSON phải phân tích cú pháp được;
schema, kiểu dữ liệu và thứ tự khóa phải đúng nếu hệ thống yêu cầu.

Tách các loại lỗi

Không nên dùng một điểm tổng duy nhất cho mọi tình huống. Ít nhất cần tách:

sai đáp án cốt lõi;
bỏ sót yêu cầu con;
đầu ra bị cắt;
mã không vượt qua kiểm thử;
JSON không phân tích được;
vi phạm định dạng dù dữ liệu bên trong đúng.

Không chọn mẫu theo kết luận mong muốn

Quy trình hợp lý là xác định bộ đề, đáp án và bộ kiểm tra trước, sau đó mới gửi cùng đầu vào cho các mô hình. Không nên chọn sẵn mô hình thắng rồi tìm một vài phản hồi phù hợp để minh họa.

Không biến độ trễ thành điểm suy luận

Độ trễ mạng bị ảnh hưởng bởi tuyến truyền, tải, bộ nhớ đệm và hệ thống phía trên. Vì vậy, nó bị loại khỏi điểm năng lực trong bài này và không có mô hình thắng về tốc độ.

Hướng dẫn lựa chọn cho môi trường sản xuất

Trường hợp cả hai mô hình đều phù hợp

Cả Claude Opus 5 và GPT-5.6-SOL đều đáng đưa vào danh sách ứng viên khi tác vụ có:

đáp án tham chiếu rõ ràng cho toán học hoặc vật lý;
thuật toán Python có thể chạy kiểm thử;
yêu cầu phát hiện tiền đề sai hoặc kết luận thống kê không đủ căn cứ;
bộ xác thực cục bộ có thể quyết định tác vụ thành công hay thất bại.

Trường hợp nên ưu tiên thử GPT-5.6-SOL

Dựa riêng trên lần kiểm thử này, GPT-5.6-SOL phù hợp hơn để ưu tiên đánh giá khi:

mọi yêu cầu con phải được hoàn thành trong một phản hồi;
phần thân phản hồi bắt buộc là JSON thuần;
muốn giảm công sức bóc tách dữ liệu có cấu trúc khỏi văn bản giải thích.

Điều này phản ánh hành vi giao kết quả trong bộ đề hiện tại, không chứng minh mô hình có năng lực suy luận cốt lõi cao hơn.

Các lớp bảo vệ nên bổ sung khi dùng Opus 5

Cấp max_tokens lớn hơn cho lời giải dài.
Luôn kiểm tra finish_reason.
Phân tích và xác thực JSON trước khi đưa sang hệ thống phía sau.
Có nhánh xử lý khi đầu ra chứa thêm Markdown hoặc văn bản giải thích.
Tách “dữ liệu đúng” khỏi “định dạng đạt” trong nhật ký đánh giá.

Các biện pháp này không có nghĩa Opus 5 suy luận yếu hơn. Trong 10 bài, toàn bộ đáp án cốt lõi của Opus đều đúng và cả hai lời giải mã đều vượt qua kiểm thử ẩn. Chênh lệch chủ yếu nằm ở việc mọi yêu cầu có được đóng gói đầy đủ vào phản hồi cuối hay không.

Nếu đang so sánh hành vi giao kết quả trong dòng Claude, có thể đọc thêm Claude Opus 5 vs Claude Fable 5 qua API thực tế.

FAQ

Claude Opus 5 hay GPT-5.6-SOL thông minh hơn?

Trong 10 bài có thể nghiệm thu khách quan của lần đánh giá này, cả hai đều đạt 10/10 về đáp án cốt lõi. Không có đủ bằng chứng để tuyên bố một mô hình thông minh hơn toàn diện.

Vì sao tỷ lệ hoàn thành đầy đủ không hòa?

Phản hồi của Opus trong bài xác suất khó bị cắt tại max_tokens=3200 và trả về finish_reason=length. Giá trị kỳ vọng cùng hệ phương trình trạng thái đều đúng, nhưng yêu cầu giải thích cuối cùng bị thiếu. Vì vậy, Opus đạt 9/10 về hoàn thành đầy đủ, còn GPT-5.6-SOL đạt 10/10.

Đáp án xác suất chính xác là bao nhiêu?

Cả hai mô hình đều đưa ra:

E[N] ≈ 12.6547

Đây là đáp án cốt lõi đúng cho thời gian chờ mẫu HHTH với P(H)=0.62 và P(T)=0.38.

Lỗi JSON có nên được tính là lỗi trí tuệ không?

Không nên trực tiếp tính là lỗi toán học hoặc lập luận. Trong trường hợp này, các trường và giá trị do Opus tính đều đúng, nhưng đầu ra chứa thêm văn bản hoặc hàng rào mã. Cách phân loại chính xác hơn là lỗi tuân thủ chỉ dẫn và định dạng.

Kết quả JSON nghiêm ngặt cụ thể ra sao?

GPT-5.6-SOL đạt 1/1 ngay lần đầu vì chỉ trả về một đối tượng JSON. Opus đạt 0/1 ở lần đầu và vẫn thêm nội dung ngoài JSON trong hai lần thử lại bổ sung.

Hai bài mã được chấm như thế nào?

Đầu ra của mô hình được lưu thành tệp Python rồi chạy với cùng bộ kiểm thử ẩn. Bộ kiểm thử bao phủ trường hợp biên, quy tắc sắp xếp, đầu vào không hợp lệ và yêu cầu không sửa đổi dữ liệu đầu vào. Cả hai mô hình đều đạt 2/2.

Vì sao bài này không công bố mô hình thắng về tốc độ?

Thời gian đầu cuối phụ thuộc vào tuyến mạng, kênh, bộ nhớ đệm, tải hệ thống phía trên và cách định tuyến. Khi chưa cố định các biến đó và chưa chạy lặp đủ nhiều, độ trễ không thể đại diện cho độ chính xác hay năng lực suy luận. Vì thế, nó không được đưa vào điểm năng lực.

HTTP 200 có đồng nghĩa với tác vụ thành công không?

Không. HTTP 200 chỉ cho biết yêu cầu API đã được xử lý ở cấp giao thức. Phản hồi vẫn có thể sai đáp án, thiếu yêu cầu, bị cắt với finish_reason=length, chứa mã không chạy được hoặc trả JSON không hợp lệ.

`finish_reason` quan trọng như thế nào?

Rất quan trọng với các tác vụ dài. Nếu finish_reason=length, đầu ra có thể bị cắt dù phần đầu hoàn toàn chính xác. Hệ thống không nên đánh dấu hoàn thành nếu chưa xác nhận tất cả yêu cầu bắt buộc đều có mặt.

Mười bài có đủ để quyết định lựa chọn lâu dài không?

Không. Đây là một lát cắt nhỏ nhưng có thể tái hiện. Trước khi triển khai, nên dùng bộ đề nghiệp vụ thật và chạy lặp 20–50 lần, sau đó thống kê riêng độ chính xác cốt lõi, tỷ lệ hoàn thành đầy đủ, tỷ lệ mã vượt qua kiểm thử và tỷ lệ vi phạm định dạng.

Nên bắt đầu so sánh mô hình như thế nào?

Hãy chọn 10–30 prompt nghiệp vụ thật, định nghĩa tiêu chí pass/fail có thể thực thi cho từng bài, rồi gửi cùng đầu vào qua một API thống nhất. Không nên quyết định người thắng trước rồi mới chọn các trường hợp hỗ trợ kết luận đó.

Kết luận cân bằng

Kết quả đáng chú ý nhất không phải là “GPT thắng” hay “Opus thắng”, mà là sự khác biệt giữa đúng về cốt lõi và giao đầy đủ tác vụ:

Claude Opus 5 và GPT-5.6-SOL đều đạt 10/10 về đáp án cốt lõi trong 10 bài kiểm thử. GPT-5.6-SOL ổn định hơn về hoàn thành toàn bộ yêu cầu con và giao JSON nghiêm ngặt; Opus 5 cần được bảo vệ tốt hơn bằng ngân sách đầu ra, kiểm tra finish_reason và xác thực định dạng cục bộ.

Nếu tác vụ có đáp án tham chiếu hoặc kiểm thử ẩn, cả hai mô hình đều xứng đáng nằm trong danh sách ứng viên. Nếu hệ thống phía sau tiêu thụ JSON trực tiếp, xác thực định dạng, thử lại và chuyển mô hình khi thất bại nên được coi là thành phần bắt buộc của kiến trúc, không phải tối ưu hóa tùy chọn.

Bộ dữ liệu này không tạo ra bên thắng về tốc độ, cũng không chứng minh một mô hình thông minh hơn toàn diện. Nó cho thấy một kết luận thực dụng hơn cho lập trình viên: hãy chấm riêng tính đúng đắn, mức độ hoàn thành và khả năng nghiệm thu bằng máy—đồng thời tránh suy rộng từ một lần chạy duy nhất.

Tạo tài khoản Crazyrouter và chạy bộ kiểm thử Opus 5 / GPT-5.6-SOL của bạn

Claude Opus 5とGPT-5.6-SOLを10問で検証：正解率はともに10/10、完遂率と形式遵守には差

Jemmmm — Thu, 30 Jul 2026 00:25:38 +0000

Claude Opus 5とGPT-5.6-SOLを10問で検証：正解率はともに10/10、完遂率と形式遵守には差

モデル比較では、ひとつの総合点だけを見ても、実際の業務適性は判断しにくいものです。最終的な答えが正しいこと、指定されたすべての要件を満たすこと、機械処理できる形式で返すことは、それぞれ別の能力だからです。

そこで今回は、Crazyrouterの同一OpenAI-compatible endpointを通じて、Claude Opus 5とGPT-5.6-SOLに10問の検証課題を実行しました。評価対象は、数学・物理の正解、誤った前提の指摘、Pythonコードの隠しテスト、全サブ要件の完遂です。厳密なJSON出力は、推論問題とは分けて指示遵守テストとして扱いました。

結果は次のとおりです。

中核となる回答の正解率：Opus 5は 10/10、GPT-5.6-SOLも 10/10
すべてのサブ要件を完了した割合：Opus 5は 9/10、GPT-5.6-SOLは 10/10
Pythonアルゴリズム2問の隠しテスト：両モデルとも 2/2
厳密なJSONの初回提出：Opus 5は 0/1、GPT-5.6-SOLは 1/1
Opus 5は追加の2回の再試行でも、JSON以外の文章またはコードフェンスを付加

この結果から言えるのは、10問の中核正解率は同率だった一方、タスクの完遂と出力形式の遵守には違いが見られた、ということです。単純な順位にまとめるより、正解率・完遂率・形式遵守を分けて読むほうが、実運用には役立ちます。

API Keyを作成し、実際の業務問題で再検証する

早見表

確認したい点	今回の結果
中核となる回答の正解率は？	同率。両モデルとも10/10
すべての設問要件を完了した割合は？	GPT-5.6-SOLは10/10、Opus 5は9/10
コードの検証結果は？	同率。2問とも両モデルが隠しテストに合格
Opus 5は難しい確率問題を間違えた？	いいえ。中核の答えは正解。ただし`max_tokens=3200`で打ち切られ、最後の説明要件が欠けた
厳密なJSONを守れたのは？	初回はGPT-5.6-SOLが1/1、Opus 5が0/1。Opusは追加の2回の再試行でもJSON以外を付加
この結果だけで一方がより賢いと言える？	言えない。中核正解率、タスク完遂率、形式遵守率は別々に評価すべき
応答速度は評価した？	知能スコアには含めていない。ネットワークや上流負荷の影響を分離できないため

数学・物理・アルゴリズムの正しさを重視する用途では、このサンプルから明確な差は確認できませんでした。一方、応答をそのままJSONとして解析する処理や、すべてのサブ要件を1回で満たす必要がある用途では、今回のGPT-5.6-SOLのほうが完全な形で提出できています。

まず分けて読むべき3つの指標

今回の結果を解釈する際は、以下の3層を混同しないことが重要です。

中核回答の正解率

主要な数値、結論、物理モデル、アルゴリズムの動作が正しいか。
タスク完遂率

設問に列挙されたサブ要件を、最後まで漏れなく回答したか。
機械的な受け入れ可否

コードがテストに合格するか、JSONをそのまま解析できるか。

たとえば、正しい数値を出していても最後の説明が欠けていれば、中核回答は正解でもタスク完遂とは判定できません。また、JSON内の値がすべて正しくても、前後に説明文が付いていれば、厳密なJSONを要求する処理では受け入れられません。

この分離によって、「推論を間違えた」のか、「出力が途中で切れた」のか、「形式だけが要件に違反した」のかを区別できます。

応答速度を知能スコアから除外した理由

モデルAPIの端から端までの待ち時間には、モデルの推論能力以外の要因が含まれます。

ゲートウェイから各上流サービスまでのネットワーク経路
検証時点のチャネル負荷やアカウント制限
キャッシュの有無
実際に割り当てられたサービスインスタンス
上流側におけるreasoning tokenの計測方法や非表示処理

単発のリクエストが数秒早かったとしても、それだけではモデルの推論能力が高いとは判断できません。上流環境を固定し、十分な回数を反復し、信頼区間まで示さない限り、待ち時間は運用監視の指標であって、知能の指標ではありません。

そのため、今回はネットワーク待ち時間を知能スコアから明示的に除外しています。また、応答速度について、どちらかを優位とは判定していません。

利用可能なモデルや接続範囲はCrazyrouterのモデル一覧、費用計画はCrazyrouter pricingで別々に確認できます。

検証環境と採点方法

検証前にモデル一覧APIを呼び出し、対象とする正確なモデルIDが表示されることを確認しました。

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
gpt-5.6-sol

本番の検証リクエストには、次のAPIを使用しました。

POST https://cn.crazyrouter.com/v1/chat/completions

各テストでは、両モデルに同じsystem prompt、user prompt、temperature、max_tokensを設定しました。外部ツールは使用せず、HTTP 200が返っただけでは合格と判定していません。

採点は次の手順で行っています。

期待値、必須要件、テスト条件を事前に定義する
両モデルに同一条件で問題を送信する
数値や必須文字列を自動検査する
Pythonコードは保存して隠しテストを実行する
JSONは実際にパーサーへ渡す
自動判定後に人手で内容を再確認する
中核正解、完遂、形式遵守を別々に記録する

人手による再確認を行ったのは、表記差による偽陰性を避けるためです。LaTeXの書き方、英字の大小、厳密な分数と丸めた小数の違いだけで、不正解と判定すべきではありません。

実際に、GPT-5.6-SOLは確率問題で参照用の分数をそのまま複製していませんでしたが、等価な式と正しい小数を提示しました。また、Opus 5は物理問題の0.302 mを有効数字2桁の0.30 mとしていました。いずれも中核的な誤りではありません。

10問の検証結果

課題	主な受け入れ条件	Claude Opus 5	GPT-5.6-SOL
厳密なマルコフ連鎖	`E[τ]=5`、`E[τ²]=43`、`Var(τ)=18`	正解	正解
2自由度振動子	2つの固有振動数、2つの振幅、2つの位相	正解	正解
制約付き探索	一意な順序`A,C,E,B,D`	正解	正解
Cantelliの不等式の訂正	確率は特定不能、上限は`0.2`	正解	正解
Python循環検出のレビュー	バグ、DAGの反例、最小限の修正	正解	正解
実験計画	同一問題での対応付け、難易度制御、信頼区間	正解	正解
偏りのあるコインで`HHTH`を待つ問題	期待値約`12.6547`と正しい状態遷移	中核は正解。打ち切りにより最後の説明が欠落	正解かつ完遂
ログ集計アルゴリズム	時間窓、失敗イベント、キャッシュ率、上位ユーザー	隠しテスト合格	隠しテスト合格
非弾性衝突とばね	`v1≈6.10`、`v2≈2.44`、`x≈0.302`	正解	正解
安定経路選択アルゴリズム	cost、latency、reliability、辞書順規則	隠しテスト合格	隠しテスト合格

10問の中核回答は両モデルとも 10/10 です。ただし、すべてのサブ要件を満たした完全な回答は、Opus 5が 9/10、GPT-5.6-SOLが 10/10 でした。

最難関の確率問題：正解と完遂を分けて評価する

対象パターンはHHTHで、偏りのあるコインの確率はP(H)=0.62、P(T)=0.38です。

設問では、最長の接頭辞・接尾辞一致に基づく状態を使って方程式を立て、さらに次の2点を説明するよう求めました。

状態HHの後に再びHが出たとき、なぜ状態がHHのままなのか
なぜ期待待ち時間を単純に1/P(HHTH)とは書けないのか

両モデルが得た期待値は正しいものでした。

E[N] ≈ 12.6547

GPT-5.6-SOLは状態遷移と導出を最後まで提示し、パターンの重なりを考慮して次の関係を示しました。

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5も、正しい状態、方程式、厳密な分数、小数値を提示しています。しかし、応答のfinish_reasonはfinish_reason=lengthでした。

この問題ではmax_tokens=3200が出力上限となり、Opus 5の回答は追加の状態期待値を記述している途中で終了しました。そのため、最後に要求されていた「なぜ単純な逆確率を使えないのか」という説明が欠けています。

評価は次のように分けました。

期待値12.6547と状態方程式は正しいため、中核回答は正解
最後の説明要件がないため、完全なタスク提出としては不合格

つまり、正しい途中結果が含まれていることと、依頼全体を完遂したことは同義ではありません。

この点は、以前のmax_tokensによる打ち切りの再検証とも共通します。検証時は回答本文だけでなく、finish_reasonと出力上限も保存する必要があります。

実行可能コードの検証：見た目ではなくテスト結果で判定

コード生成では、長い実装や丁寧なコメントが正しさを保証するわけではありません。そこで今回は、両モデルの出力を.pyファイルとして保存し、隔離した環境で同一の隠しテストを実行しました。

ログ集計アルゴリズム

関数には、次の要件を設定しました。

半開区間の時間窓を正しく処理する
成功リクエストと失敗リクエストで異なる集計規則を適用する
ユーザーまたはモデルが欠落した入力を処理する
cache hit rateを計算する
costが同じ場合はユーザー名の辞書順で並べる
入力オブジェクトを変更しない

両モデルの実装が隠しテストに合格しました。

信頼性制約付きの安定経路選択

経路探索では、次の条件を同時に処理する必要があります。

総コストが最小の経路を選ぶ
コストが同じ場合はlatencyが最小の経路を選ぶ
latencyも同じ場合はreliabilityが最大の経路を選ぶ
それでも同じ場合は経路の辞書順で選ぶ
banned nodes、最大hops、最小reliability、不正な辺を処理する

こちらも両モデルが隠しテストに合格しました。

したがって、今回のコード検証結果は両モデルとも 2/2 です。コードの長さや説明の読みやすさではなく、実行結果に基づいて同率と判定しています。

GPT-5.6-SOLの別の複雑な物理・依存関係アルゴリズムの検証については、GPT-5.6-SOL vs GPT-5.5 高難度物理・コード検証も参照できます。

厳密なJSON：推論の正しさではなく形式遵守を測る

厳密なJSONの課題では、事故データを単一オブジェクトへまとめ、次の条件を明記しました。

exactly one JSON object and no Markdown

両モデルとも、失敗率、チャネルの帰属、再試行後も復旧しなかった件数を正しく計算しました。違いは、JSONの前後に何を出力したかです。

GPT-5.6-SOLは初回からJSONだけを返し、json.loadsで直接解析できた
Opus 5は初回にコードフェンスとVerificationを付加した
Opus 5の1回目の再試行では、圧縮されたJSONの後にVerificationを付加した
Opus 5の2回目の再試行では、再びコードフェンスと説明を付加した

したがって、厳密なJSONの初回提出結果は次のとおりです。

モデル	初回の厳密JSON	追加再試行
Claude Opus 5	0/1	2回とも非準拠
GPT-5.6-SOL	1/1	不要

Opus 5はデータや計算を間違えたのではありません。すべてのフィールドと値は正しかったものの、要求された出力形式に違反しました。これは「計算能力の失敗」ではなく「形式および指示遵守の失敗」です。

本番環境では、最低限でもローカル側で次のような検証を行えます。

import json

REQUIRED_KEYS = [
    "window",
    "total_requests",
    "failed_requests",
    "failure_rate_pct",
    "provider_owned_failures",
    "customer_owned_failures",
    "recovered_by_retry",
    "unrecovered_failures",
    "root_cause",
    "action",
]


def parse_incident_json(raw: str) -> dict:
    payload = json.loads(raw)
    if list(payload) != REQUIRED_KEYS:
        raise ValueError("unexpected schema or key order")
    if payload["failed_requests"] != 84:
        raise ValueError("failed request count mismatch")
    return payload

system promptだけで構造化出力を保証することはできません。より堅牢にするには、供給元が対応する構造化出力パラメータを使用し、ローカルでschema検証を行い、解析に失敗した場合は再試行またはモデルの切り替えを実施します。

同一APIで再検証する方法

以下はOpenAI-compatible chat completions endpointを使う最小構成です。API endpoint自体にはUTMパラメータを付けません。

import os
import requests

BASE_URL = "https://cn.crazyrouter.com/v1"
API_KEY = os.environ["CRAZYROUTER_API_KEY"]


def ask(model: str, prompt: str, max_tokens: int = 4000) -> dict:
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "system", "content": "Answer accurately and follow every requested constraint."},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.2,
            "max_tokens": max_tokens,
        },
        timeout=600,
    )
    response.raise_for_status()
    return response.json()


for model in ("claude-opus-5", "gpt-5.6-sol"):
    result = ask(model, "Your benchmark prompt here")
    choice = result["choices"][0]
    print(model, choice.get("finish_reason"), choice["message"].get("content", ""))

再検証では、少なくとも次の情報を保存しておくと、後から判定根拠を追跡しやすくなります。

response ID
returned model
finish_reason
原文の回答
リクエスト時のmax_tokens
ローカル検証の結果
JSON解析エラー
コードテストの標準出力と終了コード

現在のモデル表示はCrazyrouterのモデル一覧で確認し、その後に実際の業務promptを使って小規模な回帰テストを行うのが安全です。

本番導入時の考え方

両モデルを候補にしやすい用途

正解や許容誤差を事前に定義できる数学・物理問題
単体テストを実行できるPythonアルゴリズム
誤った前提や不十分な統計的結論を指摘する処理
ローカル検証器によって成功・失敗を判定できる作業手順

今回、両モデルは10問すべてで中核回答が正解し、2問のコード課題でも隠しテストに合格しました。そのため、検証可能な処理では、どちらも候補に含められます。

今回の結果でGPT-5.6-SOLを優先しやすい条件

すべてのサブ要件を1回の応答で満たす必要がある
応答本文が厳密なJSONでなければならない
説明文から構造化データを抽出する処理を減らしたい

これは総合的な知能順位を意味するものではありません。今回の観測範囲では、GPT-5.6-SOLがタスクの完遂と厳密なJSON提出で要件を満たした、という限定的な判断です。

Opus 5を使う場合に追加したい保護策

長い導出には十分なmax_tokensを設定する
必ずfinish_reasonを確認する
JSONは下流へ渡す前に解析する
余分なMarkdownや説明文がある場合の回退処理を用意する
必須サブ要件を個別に検査する
打ち切り時には出力上限を調整して再試行する

Opus 5の推論が弱かったという結果ではありません。今回の10問では中核回答がすべて正しく、2つのコード実装も隠しテストを通過しました。差が表れたのは、正しい内容を最終応答の中にすべて収められたか、指定形式だけで返せたかという点です。

Claude系モデル内での提出挙動も比較する場合は、Claude Opus 5 vs Claude Fable 5 実API検証も参考になります。

FAQ

Claude Opus 5とGPT-5.6-SOLのどちらがより賢いですか？

今回の10問では、両モデルの中核回答が 10/10 でした。この結果だけでは、一方が全面的により賢いとは判断できません。用途別に正解率、完遂率、形式遵守率を確認する必要があります。

中核正解率とタスク完遂率は何が違いますか？

中核正解率は、主要な数値や結論が正しいかを評価します。タスク完遂率は、それに加えて、指定された説明や根拠などの全サブ要件を満たしたかを評価します。正しい答えを出しても、一部の要求が欠けていれば完遂とは判定しません。

なぜ完遂率は同率ではないのですか？

Opus 5の難しい確率問題がmax_tokens=3200で打ち切られ、finish_reason=lengthとなったためです。期待値12.6547と状態方程式は正しかったものの、最後に求められた説明が欠けました。GPT-5.6-SOLはすべてのサブ要件を完了しました。

Opus 5は確率問題を間違えたのですか？

いいえ。中核となる確率計算は正しく、期待値は12.6547でした。不足していたのは、なぜ期待値を単純に1/P(HHTH)とできないかという最後の説明です。

JSONの形式違反は知能上の誤りですか？

数学や推論の誤りとは分けて扱うべきです。Opus 5が計算したJSONのフィールドと値は正しかった一方、JSON以外の文字列を追加したため、厳密な形式要件には違反しました。より正確には、形式および指示遵守の失敗です。

厳密なJSONの結果はどうなりましたか？

初回はGPT-5.6-SOLが 1/1、Opus 5が 0/1 でした。Opus 5は追加の2回の再試行でも、説明文またはコードフェンスを付加し、厳密なJSON要件には準拠しませんでした。

コード課題はどのように採点しましたか？

モデルの出力をPythonファイルとして保存し、同一の隠しテストを実行しました。境界条件、並べ替え規則、不正入力、入力オブジェクトの不変性などを検査し、両モデルとも 2/2 で合格しました。

なぜ応答速度の優劣を出していないのですか？

端から端までの待ち時間には、ネットワーク経路、チャネル負荷、キャッシュ、上流インスタンス、アカウント制限などが影響します。固定された上流環境で十分な反復を行わない限り、モデルそのものの推論性能から分離できないため、知能スコアには含めていません。

10問だけで長期的なモデル選定はできますか？

できません。今回は再現可能な小規模サンプルです。本番導入前には、実際の業務問題を使って20～50回程度反復し、中核正解率、タスク完遂率、コードテスト合格率、形式違反率を別々に集計する必要があります。

自社で比較を始めるには何が必要ですか？

まず実際の業務から10～30件のpromptを選び、各問題について機械的に実行可能な合格条件を定義します。その後、同じAPI条件で両モデルに同一入力を送り、回答本文だけでなく、finish_reason、コードテスト、JSON解析結果も保存します。先に結論を決めてから都合のよい事例を選ぶ方法は避けてください。

最終評価

今回の検証を単純なモデル順位にまとめるのは適切ではありません。確認できた事実は、次のように指標別に整理できます。

Claude Opus 5とGPT-5.6-SOLは、10問の中核回答でともに10/10。すべてのサブ要件を完了した割合はOpus 5が9/10、GPT-5.6-SOLが10/10。Pythonの隠しテストは両モデルとも2/2。厳密なJSONの初回提出はOpus 5が0/1、GPT-5.6-SOLが1/1で、Opus 5は追加の2回の再試行でも非準拠だった。

正解や隠しテストを用意できる業務であれば、両モデルとも候補に含められます。一方、下流システムがJSONを直接処理する場合は、形式検証、再試行、モデルの切り替えを必須の構成要素として設計すべきです。

また、長い推論では中核回答の正しさだけでなく、finish_reasonと出力上限を確認しなければなりません。今回のmax_tokens=3200の事例が示すように、正しい答えが含まれていても、タスク全体が完了しているとは限らないためです。

Crazyrouterアカウントを作成し、Opus 5 / GPT-5.6-SOLを自社問題で検証する

Claude Opus 5 vs GPT-5.6-SOL: Core Accuracy Ties at 10/10 in a Reproducible Model Test

Jemmmm — Thu, 30 Jul 2026 00:25:19 +0000

Claude Opus 5 vs GPT-5.6-SOL: Core Accuracy Ties at 10/10 in a Reproducible Model Test

Model leaderboards often compress very different capabilities into a single score. That may be convenient, but it is not enough for engineering decisions. A useful comparison needs reproducible prompts, objective graders, executable tests, and separate accounting for reasoning correctness, task completion, and output format.

Network latency is deliberately excluded from this intelligence score. End-to-end API time depends on routing, upstream load, rate limits, caching, and the service instance handling a request. Without a fixed upstream, enough repeated measurements, and confidence intervals, latency is an operational observation—not evidence that one model reasons better than another.

This test sent 10 objectively gradable tasks to Claude Opus 5 and GPT-5.6-SOL through the same OpenAI-compatible Crazyrouter endpoint. Strict JSON was evaluated separately as an instruction-following test.

The results resist a simple leaderboard narrative:

Core-answer accuracy: Claude Opus 5 scored 10/10; GPT-5.6-SOL scored 10/10.
Complete delivery of every sub-requirement: Claude Opus 5 scored 9/10; GPT-5.6-SOL scored 10/10.
Hidden tests across two Python tasks: both models scored 2/2.
Strict JSON on the first attempt: Claude Opus 5 scored 0/1; GPT-5.6-SOL scored 1/1.
Additional strict-JSON retries: Opus remained noncompliant in two extra retries by appending text or using code fences.

The defensible conclusion is that core correctness was tied. The models did not, however, behave identically when evaluated for complete task delivery and machine-readable output.

Create an API key and rerun the test with your own workload

Quick answers

Question	Result in this test
Which model produced more correct core answers?	Tie: both scored 10/10
Which model completed every requested sub-requirement more often?	GPT-5.6-SOL: 10/10; Opus 5: 9/10
Which model produced more reliable code?	Tie in this sample: both passed hidden tests for both algorithm tasks, scoring 2/2
Did Opus get the difficult probability problem wrong?	No. Its core answer was correct, but the response hit the `max_tokens=3200` boundary and omitted the final requested explanation
Which model followed the strict-JSON instruction more reliably?	GPT-5.6-SOL in this test. Opus added extra text or code fences on the first attempt and on two additional retries
Does this prove that GPT is more intelligent?	No. Core reasoning accuracy and format compliance should be measured separately
Which model was faster?	This test does not rank speed because network latency was excluded from the intelligence score

For workloads dominated by objectively checked mathematics, physics, or algorithms, this sample does not show a meaningful accuracy gap. For systems that require directly parseable JSON or complete delivery of every instruction in a single response, GPT-5.6-SOL was more consistent in this run.

Why network latency is not part of the score

API response time is not a clean measure of model intelligence. It can vary because of:

the network path from the gateway to each upstream provider;
channel load and account rate limits at the time of the request;
whether a cache is hit;
which service instance receives the request;
how the upstream provider counts or conceals reasoning tokens.

A request completing several seconds earlier does not establish stronger reasoning. A credible latency comparison would require a controlled upstream, enough repeated requests, and reported confidence intervals.

For that reason, no response-time metric appears in the result table, and this article does not name a speed winner. Latency remains important for operations and user experience, but it should be benchmarked separately from correctness.

For current model availability, see the Crazyrouter model list. Cost planning should likewise be handled separately using Crazyrouter pricing.

Test environment and grading methodology

Before testing, the model-list endpoint was queried to confirm that both exact model IDs were available:

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
gpt-5.6-sol

All benchmark requests used:

POST https://cn.crazyrouter.com/v1/chat/completions

Within each test batch, both models received the same system prompt, user prompt, temperature, and max_tokens. No external tools were enabled. An HTTP 200 response was not treated as evidence that the task had passed.

Results were graded on three separate layers:

Core-answer accuracy: Were the key values, conclusions, and algorithmic behaviors correct?
Complete task delivery: Did the response satisfy every listed sub-requirement?
Machine-verifiable delivery: Did generated code pass hidden tests, and could JSON be parsed directly?

Automated string checks were followed by manual review. This matters because equivalent LaTeX, capitalization differences, exact fractions, and rounded decimals can otherwise produce false negatives.

For example, GPT-5.6-SOL did not reproduce the reference fraction verbatim on the probability task, but it supplied an equivalent formula and the correct decimal. Opus reported the physics result 0.302 m as 0.30 m to two significant figures; that was not counted as an error.

Results across the 10 intelligence tasks

Task	Acceptance criteria	Claude Opus 5	GPT-5.6-SOL
Exact Markov chain	`E[τ]=5`, `E[τ²]=43`, `Var(τ)=18`	Correct	Correct
Two-degree-of-freedom oscillator	Two natural frequencies, two amplitudes, and two phases	Correct	Correct
Constraint search	Unique ordering `A,C,E,B,D`	Correct	Correct
Correcting a Cantelli premise	Probability is not identifiable; upper bound is `0.2`	Correct	Correct
Python cycle-detection review	Identify the bug, provide a DAG counterexample, and give the minimal fix	Correct	Correct
Experimental design	Paired evaluation on the same tasks, difficulty control, and confidence intervals	Correct	Correct
Biased-coin waiting time for `HHTH`	Expected value of approximately `12.6547` and correct state transitions	Core answer correct; final explanation omitted after truncation	Correct and complete
Log aggregation algorithm	Time window, failure events, cache rate, and top users	Passed hidden tests	Passed hidden tests
Inelastic collision and spring	`v1≈6.10`, `v2≈2.44`, `x≈0.302`	Correct	Correct
Stable routing algorithm	Cost, latency, reliability, and lexicographic rules	Passed hidden tests	Passed hidden tests

These results produce two different—and equally important—scores:

Core correctness: 10/10 for both models.
Complete task delivery: 9/10 for Opus 5 and 10/10 for GPT-5.6-SOL.

Treating those as the same metric would conceal the most useful operational difference in the test.

The hardest probability task: a correct answer can still be incomplete

The target pattern was HHTH, with a biased coin defined by P(H)=0.62 and P(T)=0.38.

The task required the models to construct equations using longest prefix-suffix matching states. It also requested explicit explanations of two common sources of error:

Why does another H after state HH leave the process in state HH?
Why can the expected waiting time not be written simply as 1/P(HHTH)?

Both models reached the correct expected waiting time:

E[N] ≈ 12.6547

GPT-5.6-SOL completed the full derivation and explained that the pattern overlaps with itself, giving:

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5 also supplied the correct states, equations, exact fraction, and decimal result. However, the response ended with:

finish_reason=length

The generation reached the max_tokens=3200 boundary while listing additional state expectations. It therefore omitted the final requested explanation of why inverse pattern probability alone is insufficient.

This distinction is central to the evaluation:

A correct final value counts toward core-answer accuracy. A response that omits a requested explanation does not count as complete task delivery.

The finding reflects the same methodological issue examined in the earlier max_tokens truncation retest: a reliable evaluator should retain the answer, finish_reason, and output budget. A partially correct response should not be declared complete merely because the visible portion looks convincing.

Executable-code validation: run the code instead of grading its style

Code comparisons are particularly vulnerable to subjective judgments. Longer output, more comments, and cleaner-looking abstractions do not prove that an implementation is correct.

For both programming tasks, the generated code was saved as a .py file and executed in isolation against the same hidden tests.

Log aggregation

The required function had to handle:

half-open time windows;
different counting rules for successful and failed requests;
missing users and models;
cache hit rate;
lexicographic user ordering when costs were equal;
preservation of the input objects without mutation.

Both models passed the hidden tests.

Stable routing with reliability constraints

The routing function had to apply the following priorities and constraints:

minimize total cost;
when costs tie, minimize latency;
when both tie, maximize reliability;
when all three tie, select by lexicographic path order;
support banned nodes, maximum hops, minimum reliability, and invalid edges.

Both models passed every hidden test for this task as well.

The executable-code result is therefore a tie: 2/2 hidden code tests for Claude Opus 5 and 2/2 for GPT-5.6-SOL. Code length or presentation style was not used to infer a winner.

For another GPT-5.6-SOL test involving difficult physics and dependency algorithms, see GPT-5.6-SOL vs GPT-5.5 高难物理与代码实测.

Strict JSON: an instruction-following test, not a mathematics test

The strict-JSON task asked each model to condense incident data into one object. The output constraint was explicit:

exactly one JSON object and no Markdown

Both models correctly calculated the failure rate, assigned channel ownership, and determined the number of failures that remained unrecovered after retries. The difference was the response envelope:

GPT-5.6-SOL returned JSON only on the first attempt, and the output could be passed directly to json.loads.
Opus 5 added a code fence and a Verification section on the first attempt.
On the first additional retry, Opus returned compact JSON but still appended Verification text.
On the second additional retry, Opus again added a code fence and explanatory text.

The first-run score was therefore:

Claude Opus 5: 0/1
GPT-5.6-SOL: 1/1

Opus remained noncompliant in both extra retries. This should be described as “correct data, invalid delivery format,” not as a calculation failure.

Combining strict formatting and reasoning correctness into one undifferentiated score would obscure the actual engineering issue.

A basic local validator could look like this:

import json

REQUIRED_KEYS = [
    "window",
    "total_requests",
    "failed_requests",
    "failure_rate_pct",
    "provider_owned_failures",
    "customer_owned_failures",
    "recovered_by_retry",
    "unrecovered_failures",
    "root_cause",
    "action",
]


def parse_incident_json(raw: str) -> dict:
    payload = json.loads(raw)
    if list(payload) != REQUIRED_KEYS:
        raise ValueError("unexpected schema or key order")
    if payload["failed_requests"] != 84:
        raise ValueError("failed request count mismatch")
    return payload

A system prompt alone does not guarantee structured output. A safer production design is to use any structured-output controls supported by the provider, validate the schema locally, and retry or switch models when parsing fails.

Reproducing the comparison through one API

The following minimal Python example uses the OpenAI-compatible chat completions endpoint. UTM parameters belong in website links, not API endpoint URLs.

import os
import requests

BASE_URL = "https://cn.crazyrouter.com/v1"
API_KEY = os.environ["CRAZYROUTER_API_KEY"]


def ask(model: str, prompt: str, max_tokens: int = 4000) -> dict:
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "system", "content": "Answer accurately and follow every requested constraint."},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.2,
            "max_tokens": max_tokens,
        },
        timeout=600,
    )
    response.raise_for_status()
    return response.json()


for model in ("claude-opus-5", "gpt-5.6-sol"):
    result = ask(model, "Your benchmark prompt here")
    choice = result["choices"][0]
    print(model, choice.get("finish_reason"), choice["message"].get("content", ""))

For a production-grade evaluation, also retain:

the response ID;
the returned model;
the unmodified response content;
finish_reason;
request settings, including max_tokens;
local grader results;
code-test or schema-validation output.

Check current availability in the Crazyrouter model list, then run a small regression suite using prompts drawn from your own workload.

Production guidance

Workloads where both models belong on the shortlist

Both models performed well for:

mathematics and physics problems with explicit reference answers;
Python algorithms that can be checked with unit or hidden tests;
tasks requiring detection of false premises or unsupported statistical conclusions;
workflows with local validators that can determine whether a response succeeded.

Workloads where GPT-5.6-SOL had an advantage in this test

GPT-5.6-SOL was more consistent when:

every sub-requirement had to be completed in one response;
the raw response body had to contain pure JSON;
the application needed to avoid extracting structured data from explanatory prose.

These are findings from this test rather than a claim of universal superiority.

Additional safeguards for Opus 5

Based on the observed failures, an Opus 5 integration should:

allocate more max_tokens for long derivations;
always inspect finish_reason;
parse and validate JSON before sending it downstream;
define explicit recovery behavior for Markdown fences or explanatory text;
retry or switch models when output fails structural validation.

None of these precautions implies that Opus 5 reasoned less accurately here. It answered all 10 core tasks correctly and passed both hidden code tests. The observed difference was primarily whether every requirement fit into—and remained isolated within—the final response.

For another comparison of delivery behavior within the Claude family, see Claude Opus 5 vs Claude Fable 5 真实 API 测试.

FAQ

Which is more intelligent, Claude Opus 5 or GPT-5.6-SOL?

This test does not establish an overall intelligence winner. Across 10 objectively gradable tasks, both models achieved 10/10 core-answer accuracy.

Why was complete task delivery not a tie?

Opus reached the max_tokens=3200 boundary during the difficult probability task. Its expected value and state equations were correct, but it omitted the final requested explanation. That produced 9/10 complete tasks for Opus versus 10/10 for GPT-5.6-SOL.

Was the Opus probability answer wrong?

No. Opus correctly obtained:

E[N] ≈ 12.6547

The failure was incomplete delivery, not an incorrect probability result. The response ended with finish_reason=length.

Should invalid JSON count as an intelligence error?

Not automatically. In this case, Opus calculated the JSON fields and values correctly but added material forbidden by the output contract. It is more precise to classify that as a format and instruction-following failure.

What happened during the two additional Opus JSON retries?

Opus remained noncompliant in both. One retry appended Verification text after compact JSON, while the other again used a code fence and added explanatory text.

How were the code tasks graded?

Each model’s output was saved as executable Python and run against the same hidden tests. The tests covered edge cases, ordering rules, invalid input, and input immutability. Both models passed both programming tasks, scoring 2/2.

Why is there no speed winner?

End-to-end latency can reflect network routes, gateway behavior, caching, rate limits, upstream load, and service-instance selection. Because those variables were not controlled through a fixed upstream and sufficient repeated measurements, network latency was excluded from the intelligence score.

Are 10 tasks enough for a long-term model-selection decision?

No. This is a small, reproducible capability sample. Before deployment, run real workload prompts repeatedly—ideally 20–50 times—and track core accuracy, complete task delivery, code-test pass rate, and format-violation rate separately.

How should I design my own model comparison?

Start with 10–30 representative production prompts. Define an executable or objectively reviewable pass condition for each task, then submit identical inputs and settings through the same API. Choose the grading rules before inspecting the model outputs.

Should a production system trust a model’s JSON without validation?

No. Parse the output locally, validate it against the expected schema, and define retry or fallback behavior. Even explicit instructions such as exactly one JSON object and no Markdown may not guarantee compliant output.

Final verdict

The most useful result is not “GPT wins” or “Opus wins.” It is a more precise engineering conclusion:

Claude Opus 5 and GPT-5.6-SOL both achieved 10/10 core-answer accuracy across the 10 intelligence tasks. GPT-5.6-SOL was more consistent at completing every sub-requirement and delivering strict JSON, while Opus 5 requires closer management of output budgets and format validation.

Both models deserve consideration when tasks have reference answers, executable tests, or local validators. If downstream software consumes JSON directly, schema validation, retries, and model fallback should be treated as required system components rather than optional improvements.

Create a Crazyrouter account and run your own Opus 5 / GPT-5.6-SOL test

Claude Opus 5 vs Claude Fable 5: 7 реальных API-тестов и рекомендации по production-маршрутизации

Jemmmm — Sun, 26 Jul 2026 14:58:52 +0000

Claude Opus 5 vs Claude Fable 5: 7 реальных API-тестов и рекомендации по production-маршрутизации

Как выбрать между Claude Opus 5 и Claude Fable 5? Если смотреть только на один успешный ответ, обе модели способны написать аккуратное математическое решение. Но на production-опыт обычно сильнее влияют три другие вещи: стабильно ли задача доводится до результата, подходит ли задержка для интерактивного сценария и можно ли автоматически восстановиться после сбоя.

25 июля 2026 года мы протестировали обе модели на 7 типах задач через один и тот же OpenAI-compatible API, с одинаковыми промптами и параметрами. Результаты не укладываются в простую формулу «более крупная модель всегда лучше»:

claude-fable-5 была быстрее и лаконичнее в задачах, которые успешно решили обе модели;
claude-opus-5 в итоге покрыла все 7 типов задач;
Fable 5 несколько раз подряд срабатывала на content_filter в обычных промптах для code review и JSON-сводки инцидента;
Opus 5 в задаче по физике первые два раза вернула HTTP 200, но ответила только приветствием; нормальный результат появился лишь с 3-й попытки.

Это значит, что production-выбор не должен сводиться к одному model ID. Более надежный подход: сначала выбирать основную модель по типу задачи, а затем закрывать аномалии через проверку содержимого, retry и fallback на другую модель.

Протестировать Opus 5 и Fable 5 через один API

Краткие выводы

Вопрос	Ответ по этому тесту
Какая модель покрыла больше задач?	Opus 5: 6/7 в основном тесте, 7/7 после retry
Какая модель быстрее?	В задачах, успешно решенных обеими моделями, P50 общей задержки у Fable 5 примерно на 24% ниже
Какая модель отвечает лаконичнее?	Fable 5: в среднем примерно на 43% меньше видимых output tokens
Какая модель лучше подходит для code review и строгого JSON?	В этом тесте Opus 5 стабильнее; Fable 5 в двух задачах 3 раза подряд была отфильтрована
Можно ли ориентироваться только на HTTP 200?	Нет; у обеих моделей были случаи HTTP 200 без фактического выполнения задачи
Какую маршрутизацию рекомендовать?	Для проверенных задач — сначала Fable 5; при фильтрации или пустом теле — fallback на Opus 5; при аномальном приветствии от Opus — автоматический retry

Если тип входных данных непредсказуем или вам важно минимизировать риск фильтрации обычных бизнес-промптов, в первую очередь стоит рассматривать Opus 5. Если структура задач фиксирована, уже покрыта regression-тестами, а скорость интеракции и длина ответа важнее, Fable 5 лучше подходит как первая модель в цепочке.

Как мы тестировали

Перед тестом мы вызвали endpoint со списком моделей и убедились, что оба точных model ID доступны:

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
claude-fable-5

Все основные запросы шли через один endpoint:

POST https://cn.crazyrouter.com/v1/chat/completions

Общие условия:

Одинаковый system prompt
Одинаковый user prompt
temperature = 1
Для каждой задачи одинаковый max_tokens
stream = true
Без инструментов и доступа к интернету

Единый system prompt требовал только точного ответа и соблюдения формата вывода, без роли или установки, смещающей поведение в пользу какой-либо модели:

Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.

Мы фиксировали не только итоговый текст, но и:

HTTP-статус и finish_reason;
response ID и returned model;
время до первого видимого token и общую задержку;
completion tokens, reasoning tokens;
проходит ли видимый ответ проверку по условиям задачи;
восстанавливается ли аномальный запрос повтором с теми же параметрами.

Это end-to-end-тест через шлюз Crazyrouter, а не эксперимент с жестко заданным единственным upstream-каналом. Поэтому результаты одновременно отражают поведение модели, upstream-фильтрацию, маршрутизацию шлюза и состояние каналов на тот момент. Они хорошо отвечают на вопрос «с чем реально столкнется пользователь через этот API», но не подходят для упаковки в чистый офлайн-рейтинг возможностей семейства Claude.

Если вам важно понять, почему при тестировании моделей нужно фиксировать finish_reason и бюджет вывода, посмотрите также повторный max_tokens-тест Claude Fable 5 vs GPT-5.5.

Сводная таблица по 7 задачам

Тестовое направление	Claude Opus 5	Claude Fable 5	Production-эффект
Точная математика: цепь Маркова	Пройдено	Пройдено	Обе модели получили правильные первый момент, второй момент и дисперсию
Численная физика: связанные осцилляторы	Первые два раза только приветствие, с 3-й попытки пройдено	Пройдено с первой попытки	Для Opus нужны проверка содержимого и retry на уровне задачи
Поиск с ограничениями	Пройдено	Пройдено	Обе модели нашли единственное решение
Статистическая коррекция	Пройдено	Пройдено	Обе модели отвергли неверную предпосылку и дали корректную верхнюю границу
Code review на Python	Пройдено	3 раза подряд `content_filter`	В текущем тесте Fable не подходит для code-review-трафика без regression-проверки
Строгая JSON-сводка инцидента	Пройдено	3 раза подряд `content_filter`	В текущем тесте Fable не подходит для такого текста production-инцидента
Дизайн эксперимента	Пройдено	Пройдено	Обе модели распознали непарные выборки и смешение по сложности

Доля задач, доставленных с первой основной попытки:

Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%

С учетом retry:

Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7

Под «доставкой» здесь понимается не успешный HTTP-запрос, а наличие видимого ответа, который бизнес-логика может принять как соответствующий заданию. Даже если есть HTTP 200, имя модели и token usage, но тело пустое, отфильтровано или содержит только приветствие, задача считается невыполненной.

Математика, ограничения и статистика: обе модели надежны

Математическая задача использовала трехсостоянийную цепь Маркова и требовала вычислить время первого достижения состояния 3 из состояния 1:

E1[τ]
E1[τ²]
Var1(τ)

Обе модели выдали:

E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18

Обе также выписали транзиентную матрицу Q и уравнения для первого и второго моментов. В этой задаче не было ситуации, когда финальные числа правильные, а вывод противоречивый.

В задаче на поиск с ограничениями нужно было расставить пять докладов A, B, C, D, E по пяти слотам с условиями непосредственного соседства, порядка, расстояния и отсутствия соседства. Обе модели получили единственный порядок:

A, C, E, B, D

В задаче на статистическую коррекцию намеренно давался неверный вывод: «среднее равно 10, дисперсия равна 4, значит P(X≥14)=0.5». Обе модели указали, что двух моментов недостаточно для однозначного определения хвостовой вероятности, и через одностороннее неравенство Чебышева/Кантелли получили:

P(X >= 14) <= 0.2

Эти три класса задач показывают, что преимущество Fable 5 в скорости не достигается за счет потери базовой корректности рассуждений. В четких, коротких и проверяемых математических и логических задачах она вполне может быть более легкой первой моделью.

Предыдущие материалы — API-тест Claude Fable 5 vs Claude Sonnet 5 и тест output budget GLM-5.2 vs Fable 5 — также показывают: чтобы понять, подходит ли модель для production, нужно рассматривать корректность, бюджет вывода и форму доставки результата вместе.

Физика: Fable справилась с первой попытки, Opus восстановилась на третьей

Задача по физике требовала обработать двухстепенной осциллятор с демпфированием на землю и связующим демпфированием, вычислить две собственные частоты без демпфирования, а также комплексный частотный отклик двух масс при ω=8 rad/s.

Референсные значения:

ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
|X2| = 0.07174 m, phase = -13.90°

Fable 5 с первой попытки дала все правильные результаты. У Opus 5 в первых двух вызовах возникла аномалия, на которую production-командам стоит обратить особое внимание: API вернул HTTP 200 и finish_reason=stop, но тело ответа содержало только:

Hi! How can I help you today?

В обеих этих реакциях prompt tokens равнялись всего 10, что очевидно не соответствовало реальному входу. При 3-м выполнении того же запроса Opus 5 через 34.901 секунды вернула полный ответ, и все шесть численных значений прошли проверку.

Поэтому такую аномалию не стоит классифицировать как «модель ошиблась в физике». Правильнее считать это случаем, когда контекст запроса не был нормально обработан. Самая простая защита — не ручной просмотр логов, а task-level acceptance check на стороне клиента: ответ должен содержать ω1, ω2, X1, X2; если отсутствует хотя бы одно поле, выполняется retry.

Код и строгий JSON: фильтрация Fable стала главным отличием теста

Задача по коду просила модель проверить Python-реализацию DFS-детектора циклов. Ошибка была вполне обычной: после завершения DFS для узла он не удалялся из множества visiting, из-за чего уже обработанный узел продолжал считаться находящимся в рекурсивном стеке, и на DAG ошибочно находился цикл.

Opus 5 корректно указала минимальное исправление:

visiting.discard(node)
visited.add(node)
return False

Fable 5 не вернула анализа кода: finish_reason=content_filter, тело пустое. Чтобы исключить смещение system prompt и случайную маршрутизацию, мы провели три раунда: исходный тест, повторный тест с чистым system prompt и независимый retry одной задачи. Во всех случаях результатом был content_filter.

Задача со строгим JSON также не содержала опасного контента. Во входе были только общее число запросов за 15 минут, число ошибок, attribution каналам, число восстановленных retry и предпринятые действия; требовалось вывести один JSON-объект. JSON, который вернула Opus 5, можно было сразу распарсить; Fable 5 снова 3 раза подряд была отфильтрована.

Эти два типа сбоев показывают: **сам safety-фильтр — тоже часть production-качества model API. Если модель стабильно дает ложную фильтрацию на нормальном code review или тексте postmortem-инцидента, она не может напрямую принять на себя весь бизнес-трафик, даже если в математических задачах быстрее.

response ID двух независимых retry:

Ревью кода: gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
JSON инцидента: gen-1784915390-buOWZQSnqjgHeJ6nUogF

Задержка и длина ответа

Чтобы не засчитывать короткое время неуспешных запросов как «преимущество в скорости», здесь сравниваются только четыре задачи, которые успешно выполнили обе модели: математика, поиск с ограничениями, статистическая коррекция и дизайн эксперимента.

Метрика	Claude Opus 5	Claude Fable 5
P50 общей задержки	10.729 s	8.147 s
P50 первого видимого token	8.376 s	6.974 s
Среднее число видимых completion tokens	797.5	452.3

В этой небольшой выборке P50 общей задержки у Fable 5 примерно на 24% ниже, время до первого видимого token — примерно на 17% ниже, а ответы короче примерно на 43%. Для чатов, пакетных сводок и высокочастотных структурированных задач такие различия напрямую влияют на ожидание пользователя и нагрузку на последующую обработку.

Но не стоит превращать медиану по 4 задачам в SLA. Upstream-нагрузка, кеши, маршрутизация и rate limiting могут менять задержку. Перед полноценным запуском нужно повторить тесты на собственных бизнес-промптах 20–50 раз, а затем посчитать P50, P95, P99 и реальную стоимость каждого результата, прошедшего acceptance check.

В основных ответах Fable 5 присутствовало поле cost; суммарно за7 вызовов получилось около $0.24596. В usage для Opus 5 не было поля cost той же методики, поэтому в статье не делается вывод о победителе по цене в долларах. Отсутствие поля не означает бесплатность, и его не следует заполнять непроверенными ценами.

Финальная рекомендация

Самый ценный вывод этого теста не в том, кто набрал больше очков, а в том, что формы отказа у двух моделей разные:

Преимущество Fable 5 — более высокая скорость и более короткие ответы в общих успешных задачах; риск — стабильное срабатывание фильтрации на части обычных бизнес-промптов.
Преимущество Opus 5 — покрытие всех задач после retry; риск — редкое возвращение приветствия, не связанного с реальным входом.

Поэтому Fable 5 стоит ставить первой на уже проверенных высокочастотных задачах, Opus 5 — использовать как fallback с более широким покрытием, а на обеих ветках выполнять проверку содержимого на уровне задачи. Так результаты сравнения моделей превращаются в реальную надежность, а не остаются строкой в рейтинговой таблице.

Создать API Key и воспроизвести эту двухмодельную маршрутизацию

FAQ

Claude Opus 5 точно сильнее Claude Fable 5?

Из этой небольшой выборки нельзя сделать вывод, что она сильнее во всех задачах. Обе модели прошли математику, ограничения, статистическую коррекцию и дизайн эксперимента; Fable 5 была быстрее и короче, а Opus 5 дала более полное покрытие задач. Выбор должен опираться на success rate для конкретных задач, а не на название модели.

Подходит ли Claude Fable 5 для production?

Подходит для задач, прошедших regression-тестирование. В этом тесте она корректно и быстро справилась с несколькими reasoning-задачами, но code review и JSON-инцидент несколько раз подряд вызвали фильтрацию. Перед запуском нужно измерить filter rate на реальных промптах и настроить fallback на Opus 5 или другую модель.

Почему HTTP 200 все равно считается провалом?

HTTP 200 означает только то, что API завершил ответ. Пустое тело, finish_reason=content_filter, обрезанный вывод или ответ в виде одного приветствия не решают бизнес-задачу. Production-метрики должны считать «долю ответов, прошедших acceptance check», а не только HTTP success rate.

Почему returned model равен `anthropic/claude-fable-5`?

В запросе использовался claude-fable-5, а returned model в ответе стабильно был anthropic/claude-fable-5 с provider-префиксом. Это можно считать нормализованным alias; одного изменения префикса недостаточно, чтобы утверждать, что модель была подменена.

Можно ли напрямую сравнить долларовую стоимость двух моделей?

В этом тесте — нет. В ответах Fable 5 было поле cost, а для Opus 5 не было поля в той же методике. Корректное сравнение стоимости должно брать данные из единых billing-логов и считать метрику «стоимость результата, прошедшего acceptance check».

Сколько повторов нужно сделать перед запуском?

Для каждого ключевого семейства задач рекомендуется минимум 20–50 повторов, с покрытием нормальных входов, граничных входов, длинных входов и входов, которые потенциально могут вызвать фильтрацию. Как минимум фиксируйте task success rate, filter rate, долю пустых ответов, truncation rate, P50/P95/P99 задержки и стоимость.

Как начать тестирование?

Используйте https://cn.crazyrouter.com/v1 как OpenAI-compatible base URL и по очереди вызывайте claude-opus-5 и claude-fable-5. Зафиксируйте промпты и параметры, сохраняйте сырые ответы, а затем через локальные assertions или структурную валидацию проверяйте, действительно ли задача выполнена.

Начать собственный двухмодельный тест Claude

Claude Opus 5 vs Claude Fable 5：実 API での 7 タスク検証と本番ルーティングの提案

Jemmmm — Sun, 26 Jul 2026 14:57:47 +0000

Claude Opus 5 vs Claude Fable 5：実 API での 7 タスク検証と本番ルーティングの提案

Claude Opus 5 と Claude Fable 5 は、どちらを選ぶべきでしょうか。成功した 1 回の回答だけを見れば、どちらのモデルも見栄えのよい数学的導出を書けます。しかし本番体験を左右するのは、多くの場合それとは別の 3 点です。タスクを安定して完了できるか、レイテンシが対話用途に合うか、失敗後に自動復旧できるかです。

私たちは 2026 年 7 月 25 日、同じ OpenAI-compatible API を使い、同一のプロンプトとパラメータで、2 つのモデルに対して 7 種類のタスクをテストしました。結果は「大きいモデルほど常に優れている」という単純な話にはなりませんでした。

claude-fable-5 は、両モデルが成功したタスクではより高速で、出力も簡潔でした。
claude-opus-5 は、最終的に 7 種類すべてのタスクをカバーしました。
Fable 5 は、通常のコードレビューとインシデント JSON のプロンプトで連続して content_filter を発生させました。
Opus 5 は、物理問題で最初の 2 回は HTTP 200 を返したにもかかわらず、無関係な挨拶を 1 文返しただけで、3 回目にようやく正常に完了しました。

つまり、本番でのモデル選定は 1 つのモデル ID だけに依存すべきではありません。より堅実なのは、まずタスク種別ごとに主モデルを選び、そのうえで内容検収、リトライ、モデルフォールバックによって異常系を包み込む方法です。

同じ API で Opus 5 と Fable 5 をテストする

要点

質問	今回の回答
より多くのタスクをカバーしたのはどちらか？	Opus 5：本テストでは 6/7、リトライ後は 7/7
より高速だったのはどちらか？	両方がしたタスクでは、Fable 5 の P50 総レイテンシが約 24% 低い
出力がより簡潔だったのはどちらか？	Fable 5。平均可視出力 token が約 43% 少ない
コードレビューと厳密な JSON により適していたのはどちらか？	今回は Opus 5 のほうが安定。Fable 5 は 2 問で連続 3 回フィルタされた
HTTP 200 だけを見ればよいか？	いいえ。両モデルとも HTTP 200 だがタスク未完了のケースがあった
推奨ルーティングは？	検証済みタスクでは Fable 5 を優先し、フィルタまたは空本文なら Opus 5 へフォールバック。Opus が異常な挨拶を返した場合は自動リライ

入力タイプが予測しにくい場合、または通常の業務プロンプトがフィルタされるリスクをできるだけ避けたい場合は、Opus 5 を優先的に検討すべきです。一方、タスク構造が固定され、すでに回帰テスト済みで、対話速度と出力長を重視する場合は、Fable 5 を最初の呼び出し先にするのが適しています。

テスト方法

テスト前にモデル一覧 API を呼び出し、2 つの正確なモデル ID が見えていることを確認しました。

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
claude-fable-5

すべての正式リクエストは同じ endpoint を使いました。

POST https://cn.crazyrouter.com/v1/chat/completions

共通条件は次のとおりです。

同一 system prompt
同一 user prompt
temperature = 1
各問題で同一の max_tokens を使用
stream = true
ツールとインターネット接続は無効

共通の system prompt は、正確に回答し、指定された出力形式に従うことだけを求めています。特定モデルに有利なロール設定は加えていません。

Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.

記録したのは最終的な本文だけではありません。以下も記録しました。

HTTP ステータスと finish_reason
response ID と returned model
最初の可視 token までの時間と総レイテンシ
completion tokens、reasoning tokens
可視回答がタスクの検収条件を満たしたか
異常リクエストが同一パラメータのリトライで復旧できるか

これは Crazyrouter ゲートウェイのエンドツーエンドテストであり、単一の上流チャネルを指定した実験ではありません。したがって結果には、モデルの挙動、上流のフィルタリング、ゲートウェイのルーティング、その時点でのチャネル状態が同時に反映されています。「ユーザーがこの API 経由で実際に何に遭遇するか」を答えるには適していますが、Claude ファミリーの純粋なオフライン能力ランキングとして扱うべきものではありません。

モデルテストで finish_reason と出力予算を記録すべき理由を知りたい場合は、Claude Fable 5 vs GPT-5.5 の max_tokens 再テストも参照してください。

7 項目の結果サマリー

テスト観点	Claude Opus 5	Claude Fable 5	本番への影響
厳密な数学：マルコフ連鎖	合格	合格	どちらも正しい一次モーメント、二次モーメント、分散を得た
数値物理：結合振動子	最初の 2 回は挨拶のみ、3 回目で合格	初回で合格	Opus には内容レベルの検収とリトライが必要
制約探索	合格	合格	どちらも一意解を見つけた
統計の誤り訂正	合格	合格	どちらも誤った前提を拒否し、正しい上界を提示した
Python コードレビュー	合格	連続 3 回 `content_filter`	Fable は現時点では、回帰未検証のコードレビュー流量には適さない
厳密 JSON のインシデント要約	合格	連続 3 回 `content_filter`	Fable は現時点では、この種の本番インシデント文面には適さない
実験設計	合格	合格	どちらも非対応サンプルと難易度の交絡を識別できた

本テストにおける 1 回目での納品率は次のとおりです。

Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%

リトライを含めると次のようになります。

Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7

ここでいう「納品」はリクエストの成功ではなく、業務側が問題要件を満たす可視回答を受け取れたことを指します。HTTP 200、モデル名、token usage が存在していても、本文が空、フィルタされた、または挨拶しか返らなかった場合は、タスク失敗として扱います。

数学、制約、統計：どちらのモデルも信頼できる

数学問題では 3 状態のマルコフ連鎖を使い、状態 1 から初めて状態 3 に到達するまでの待ち時間について、次を計算するよう求めました。

E1[τ]
E1[τ²]
Var1(τ)

どちらのモデルも次を返しました。

E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18

また、両方とも一時状態行列 Q と一次・二次モーメントの方程式を書いていました。この問題では、「最終的な数値は正しいが導出が一貫しない」という状況は発生しませんでした。

制約探索では、A、B、C、D、E の 5 つの講演を 5 つの時間枠に配置し、直後に隣接、前後関係、間隔、非隣接といった条件を同時に満たすよう求めました。どちらも一意の順序を得ました。

A, C, E, B, D

統計の誤り訂正問題では、あえて誤った結論を与えました。「平均が 10、分散が 4 なので P(X≥14)=0.5」というものです。両モデルとも、二次までのモーメントだけでは尾確率を一意に決定できないと指摘し、片側 Chebyshev/Cantelli 不等式により次を得ました。

P(X >= 14) <= 0.2

この 3 種類のタスクから分かるのは、Fable 5 の速度面の優位が、基礎的な推論の正確性を犠牲にしたものではないということです。明確で短く、検収しやすい数学・論理タスクでは、より軽い第一候補として十分に使えます。

以前の Claude Fable 5 vs Claude Sonnet 5 API テストと GLM-5.2 vs Fable 5 出力予算テストでも示したように、あるモデルが本番に適しているかを判断するには、正確性、出力予算、納品形態を合わせて必要があります。

物理問題：Fable は初回完了、Opus は 3 回目で復旧

物理問題では、接地減衰と結合減衰を持つ 2 自由度振動子を扱い、2 つの非減衰固有振動数と、ω=8 rad/s における 2 つの質量の複素周波数応答を計算するよう求めました。

参照値は次のとおりです。

ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
|X2| = 0.07174 m, phase = -13.90°

Fable 5 は初回で正しい結果をすべて返しました。一方、Opus 5 の最初の 2 回の呼び出しでは、本番チームが特に注意すべき異常が発生しました。インターフェースは HTTP 200 と finish_reason=stop を返しましたが、本文は次の 1 文だけでした。

Hi! How can I help you today?

この 2 回のレスポンスでは prompt tokens がどちらも 10 で、実際の入力とは明らかに一致していませんでした。同じリクエストを 3 回目に実行したところ、Opus 5 は 34.901 秒後に完全な回答を返し、6 つの数値はすべてチェックを通過しました。

したがって、この種の異常は「物理問題を計算ミスした」と分類するべきではなく、「リクエストコンテキストが正常に処理されなかった」と分類すべきです。最も簡単な防御策は、人間がログを見ることではなく、呼び出し側でタスクレベルの検収を設定することです。回答に ω1、ω2、X1、X2 が含まれていなければリトライします。

コードと厳密 JSON：Fable のフィルタリングが今回最大の差分

コード問題では、Python の DFS サイクル検出器をレビューさせました。バグはごく一般的なものです。ノードの DFS 完了後に visiting 集合から削除していないため、すでに処理済みのノードがまだ再帰スタック上にあると誤認され、DAG に対してサイクルを誤検出します。

Opus 5 は最小修正を正しく指摘しました。

visiting.discard(node)
visited.add(node)
return False

Fable 5 はコード分析を返さず、finish_reason=content_filter で本文は空でした。system prompt の偏りや偶発的なルーティングを除外するため、3 回確認しました。元のテスト、クリーンな system prompt での再テスト、単独問題としての独立リトライのいずれも、結果は content_filter でした。

厳密 JSON 問題にも危険な内容は含まれていません。入力には、15 分間のリクエスト総数、失敗数、チャネル別要因、リトライで復旧した数、対応アクションだけが含まれており、出力として JSON オブジェクトを求めました。Opus 5 が返した JSON はそのままパースできましたが、Fable 5 は同様に連続 3 回フィルタされました。

この 2 種類の失敗が示しているのは、安全フィルタリングそのものもモデル API の本番能力の一部であるということです。通常のコードレビューやインシデント振り返りのテキストで安定して誤フィルタが発生するなら、たとえ数学問題で高速でも、すべての業務トラフィックをそのモデルに任せることはできません。

2 回の独立リトライの response ID は次のとおりです。

コードレビュー：gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
インシデント JSON：gen-1784915390-buOWZQSnqjgHeJ6nUogF

レイテンシと出力長

失敗リクエストの短い処理時間を「速度優位」として数えないため、ここでは両モデルが成功した 4 つの共通タスク、すなわち数学、制約探索、統計の誤り訂正、実験設計だけを比較します。

指標	Claude Opus 5	Claude Fable 5
P50 総レイテンシ	10.729 s	8.147 s
P50 最初の可視 token	8.376 s	6.974 s
平均可視 completion tokens	797.5	452.3

この小さなサンプルでは、Fable 5 の P50 総レイテンシは約 24% 低く、最初の可視 token は約 17% 早く、回答は約 43% 短くなりました。チャット、バッチ要約、高頻度の構造化タスクでは、これらの差はユーザーの待ち時間と下流処理量に直接影響します。

ただし、4 問の中央値を SLA として書くべきではありません。上流の負荷、キャッシュ、ルーティング、レート制限はいずれもレイテンシを変化させます。本番投入前には、自社の業務プロンプトで 20–50 回繰り返し、P50、P95、P99 と、検収を通過した結果 1 件あたりの実コストを集計すべきです。

Fable 5 の本テストレスポンスには cost フィールドがあり、7 回の合計は約 $0.24596 でした。Opus 5 の usage には同じ基準の cost が提供されていなかったため、本記事ではドル価格での勝敗判断は行いません。フィールドがないことは無料を意味せず、未検証の価格で補完すべきでもありません。

推奨する本番ルーティング戦略

単一モデル呼び出しは最も実装しやすい一方で、モデルのあらゆる偶発的な挙動をそのままエンドユーザーに露出させます。今回の 2 モデルについては、次のように役割を分けるのがより合理的です。

Fable 5 を第一候補にする

適している用途：

回帰テスト済みの数学、制約推論、短い要約
最初の token と全体レイテンシに敏感な対話
回答長を抑え、後処理負荷を減らしたいタスク

前提として、対象タスク群でフィルタリングのテストが済んでおり、呼び出し側で content_filter、空本文、必須フィールド欠落をチェックする必要があります。

Opus 5 を広範囲カバーのフォールバックにする

適している用途：

入力タイプが予測しにくい
コードレビュー、厳密 JSON、複雑な物理など、より広いタスクカバレッジが必要な場面
Fable 5 がフィルタされた後、ユーザーリクエストを自動復旧したい場面

Opus 5 も無検査で使うべきではありません。今回の挨拶異常が示すとおり、HTTP 200 と stop であっても、業務上の回答が含まれていないことがあります。

OpenAI-compatible Python の例

次の例では、まず Fable 5 を呼び出し、フィルタ、空本文、検収失敗が発生した場合に Opus 5 へフォールバックします。Opus でも挨拶しか返らない場合は、さらに 1 回リトライします。

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)


def valid_answer(text: str, required_terms: tuple[str, ...]) -> bool:
    normalized = (text or "").strip()
    if not normalized:
        return False
    if normalized.lower().startswith("hi! how can i help"):
        return False
    return all(term in normalized for term in required_terms)


def call_model(model: str, prompt: str) -> tuple[str, str | None]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        temperature=1,
        max_tokens=3000,
    )
    choice = response.choices[0]
    return choice.message.content or "", choice.finish_reason


def routed_completion(prompt: str, required_terms: tuple[str, ...] = ()) -> str:
    for model, attempts in (("claude-fable-5", 1), ("claude-opus-5", 2)):
        for _ in range(attempts):
            text, finish_reason = call_model(model, prompt)
            if finish_reason == "content_filter":
                break
            if valid_answer(text, required_terms):
                return text
    raise RuntimeError("No model produced a valid business answer")


answer = routed_completion(
    "Return a JSON incident summary with keys total, failed, recovered.",
    required_terms=('"total"', '"failed"', '"recovered"'),
)
print(answer)

本番実装ではさらに、model、response ID、finish_reason、総レイテンシ、検収失敗理由を記録すべきです。そうすることで、モデルの計算ミス、出力打ち切り、内容フィルタリング、ルーティングによる入力欠落を区別できます。これらをすべて曖昧な「モデル失敗」にまとめてしまうべきではありません。

マルチモデル基盤を計画している場合は、AI API Gateway、アグリゲーター、モデル API 直結の違いと、Kimi K3 vs Opus 4.8 の 7 次元テストも参考になります。

最終的な提案

今回最も価値のある結論は、どちらが高得点だったかではなく、2 つのモデルの失敗形態が異なるという点です。

Fable 5 の強みは、共通タスクでより高速かつ短いことです。リスクは、一部の通常業務プロンプトが安定してフィルタを発生させることです。
Opus 5 の強みは、リトライ後にすべてのタスクをカバーしたことです。リスクは、実入力と無関係な挨拶を偶発的に返すことです。

したがって、検証済みの高頻度タスクでは Fable 5 を前段に置き、Opus 5 をより広範囲のフォールバックとして使い、両方の経路で内容レベルの検収を行うことを推奨します。そうして初めて、モデル比較の結果を単なるランキングではなく、実際の信頼性へ変換できます。

API Key を作成して、この 2 モデルルーティングを再現する

FAQ

Claude Opus 5 は Claude Fable 5 より必ず強いのですか？

この小さなサンプルから「すべてのタスクでより強い」とは結論できません。数学、制約、統計の誤り訂正、実験設計ではどちらも合格しました。Fable 5 はより高速で短く、Opus 5 はタスクカバレッジがより完全でした。選択はモデル名ではなく、具体的なタスク成功率に基づいて行うべきです。

Claude Fable 5 は本番環境に適していますか？

回帰テスト済みのタスクには適しています。今回、複数の推論タスクでは正確かつ比較的高速でしたが、コードレビューとインシデント JSON では連続してフィルタを発生させました。本番投入前には実際のプロンプトでフィルタ率を測定し、Opus 5 または他モデルへのフォールバックを設定すべきです。

HTTP 200 でも失敗とみなすのはなぜですか？

HTTP 200 は、インターフェースがレスポンスを完了したことだけを示します。本文が空、finish_reason=content_filter、出力が途中で切れている、または挨拶だけを返す場合、業務タスクは完了していません。本番指標では HTTP 成功率だけでなく、「検収通過率」を集計すべきです。

returned model が `anthropic/claude-fable-5` なのはなぜですか？

リクエストでは claude-fable-5 を使用し、レスポンス内の returned model は provider プレフィックス付きの anthropic/claude-fable-5 で安定していました。これは正規化されたエイリアスと見なせます。プレフィックスの変化だけでは、モデルが置き換わった証拠にはなりません。

2 つのモデルのドルコストを直接比較できますか？

今回の結果だけではできません。Fable 5 のレスポンスには cost フィールドがありましたが、Opus 5 には同じ基準のフィールドがありませんでした。厳密なコスト比較は、統一された課金ログから取得し、「検収を通過した結果 1 件あたりのコスト」を指標にすべきです。

本番投入を判断する前に何回繰り返すべきですか？

各コアタスク群について少なくとも 20–50 回の繰り返しを推奨します。通常入力、境界入力、長い入力、フィルタを誘発しやすい入力を含めてください。少なくとも、タスク成功率、フィルタ率、空本文率、打ち切り率、P50/P95/P99 レイテンシ、コストを記録すべきです。

どうやってテストを始めればよいですか？

https://cn.crazyrouter.com/v1 を OpenAI-compatible base URL として使い、claude-opus-5 と claude-fable-5 をそれぞれ呼び出します。プロンプトとパラメータを固定し、元レスポンスを保存したうえで、ローカルのアサーションまたは構造検証によってタスクが本当に完了したかを判定します。

Claude 2 モデルのテストを始める

Kimi K3 vs GPT-5.6-SOL: 수학·물리·프로그래밍 고난도 실측 비교

Jemmmm — Sat, 18 Jul 2026 01:18:01 +0000

Kimi K3 vs GPT-5.6-SOL: 수학·물리·프로그래밍 고난도 실측 비교

이번에는 단순 질의응답이 아니라, 연속적인 추론이 필요한 문제 3개를 고정해 테스트했다. 패턴 중첩과 2차 모멘트가 포함된 확률 문제, 도르래의 회전 관성과 줄 이완 전환이 들어간 물리 문제, 그리고 클로저, 여러 날짜의 용량, 3단계 tie-break에 의존하는 Python 문제다. 두 모델은 같은 인터페이스, 같은 프롬프트, 비슷한 출력 상한을 사용했으며, 도구와 웹 접속은 사용하지 않았다.

먼저 결론부터 정리하면 다음과 같다.

gpt-5.6-sol은 세 문제 모두에서 완전한 가시 응답을 반환했고, 수학과 물리의 기준 결과도 정확했다.
kimi-k3는 1차 테스트의 6500 token 상한에서 수학과 물리 모두 finish_reason=length로 종료되었고, 보이는 답변은 비어 있었다. 수학 문제는 상한을 10000으로 올린 뒤에도 잘렸다. 프로그래밍 문제는 약 245초 후 읽기 타임아웃이 발생했다.
GPT-5.6-SOL의 프로그래밍 구현은 별도로 보강한 의존성 클로저, 용량, tie-break, 잘못된 의존성, 순환 의존성 검사를 통과했다. 다만 모델이 자체적으로 붙인 첫 번째 assert 예제의 기대값은 틀려 있었다. 즉 “코드 본문이 맞는지”와 “예제 테스트가 모두 맞는지”는 분리해서 검수해야 한다.

이 글의 지연 시간은 이번 요청에서 관측된 값일 뿐, 고정 SLA를 의미하지 않는다. 1차 병렬 요청에서 GPT의 수학 및 물리 요청은 HTTP 408을 받은 적이 있었고, 이후 순차 재시도로 바꾸었다. 따라서 속도는 호출 경험을 관찰하는 용도로만 사용하며, 절대적인 순위를 주장하는 근거로 삼지 않는다.

테스트 설정

테스트 시간은 베이징 시간 2026-07-17부터 2026-07-18까지였고, 인터페이스는 다음과 같다.

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

1차 테스트에서는 공통으로 수학과 물리에 max_tokens=6500, 프로그래밍에 max_tokens=7500을 사용했다. 각 문제마다 모델에 검증 가능한 유도 과정 또는 실행 가능한 코드를 요구했으며, finish_reason, completion/reasoning token, 요청 지연 시간, 수치 정확성, 코드가 Python 3.11에서 독립 실행 가능한지를 기록했다.

결과 요약표

작업	kimi-k3	gpt-5.6-sol	판정
수학: HHTH의 기대값과 분산	`length`, 186.98 s, 6500 tokens; 보이는 내용 없음	순차 재시도 `stop`, 236.07 s, 6872 tokens	GPT는 완전 답변; Kimi는 1차에서 답변 형성 실패
물리: 도르래, 바닥 충돌, 스프링	`length`, 202.05 s, 6500 tokens; 보이는 내용 없음	순차 재시도 `stop`, 156.29 s, 4501 tokens	GPT는 완전하고 수치도 정확
프로그래밍: 의존성 클로저 배낭 문제	245.54 s 후 `TimeoutError`	`stop`, 87.96 s, 4514 tokens	GPT 코드는 실행 가능; Kimi는 완전한 코드 미반환
Kimi 수학 재측정	`length`, 286.99 s, 10000 tokens	—	예산을 늘려도 종료되지 않음

Kimi의 수학 및 물리 요청에서 인터페이스가 보고한 reasoning token은 각각 6497에 가까웠다. 수학 재측정의 reasoning token은 9997에 가까웠다. 이는 Kimi에 추론 능력이 없다는 뜻이 아니라, 이 문제 프롬프트와 현재 라우팅 조건에서는 추론 예산이 쉽게 소진되어 호출자가 최종 답변을 받지 못할 수 있음을 보여준다.

수학 문제: 패턴 중첩은 기대값뿐 아니라 분산에도 영향을 준다

문제는 다음과 같다. 앞면 확률 p=3/5, 뒷면 확률 q=2/5인 동전을 계속 던져 HHTH가 처음 나타날 때까지의 시간 T에 대해, 패턴 중첩을 허용할 때 E[T]와 Var(T)를 구한다.

올바른 접두사 오토마톤 상태는 S0=空前缀, S1=H, S2=HH, S3=HHT, S4=HHTH（吸收态）이다. 핵심 전이는 S2 --H--> S2다. 이미 HH가 나온 상태에서 다시 H가 나오면 가장 긴 접미사는 여전히 HH이므로, 이를 빈 상태로 잘못 되돌리면 안 된다.

GPT-5.6-SOL이 세운 1차 모멘트 방정식은 다음과 같다.

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

이어서 2차 모멘트 방정식을 세우면 다음 결과를 얻는다.

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

기대값은 경계 공식으로도 독립 검산할 수 있다. HHTH의 비어 있지 않은 진경계는 한 글자 H이므로 E[T] = 1/p + 1/(p³q) = 715/54이다. GPT의 완전한 답변은 상태 전이, 2차 모멘트 전개, sanity check를 모두 포함했다. Kimi는 6500 및 10000 상한 모두에서 보이는 유도 과정을 출력하지 못했기 때문에, 이번 라운드에서는 수학적 정확성을 채점할 수 없고 “예산 내 미완료”로만 기록했다.

물리 문제: 바닥에 닿은 뒤에는 제약이 끊기므로 같은 에너지 방정식을 계속 적용하면 안 된다

문제 설정은 다음과 같다. m_A=4.0 kg가 25°의 거친 경사면 위에 있고, μ_k=0.18이다. m_B=3.0 kg는 매달려 있다. 도르래는 M_p=1.2 kg, R=0.10 m이다. B가 1.50 m 내려간 뒤 바닥에 닿고, 줄은 즉시 느슨해진다. A는 이후 경사면 위로 0.10 m 더 올라가 k=250 N/m 스프링에 닿는다. g=9.8 m/s²이다.

바닥에 닿기 전에는 줄이 팽팽하고 미끄러짐이 없으므로, 도르래의 등가 관성 질량은 I/R²=(1/2)M_p=0.60 kg이다. 두 물체와 도르래 회전 방정식을 함께 풀면 다음을 얻는다.

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

바닥에 닿은 뒤에는 B의 속도가 지면과의 충돌로 바뀌고, A는 여전히 경사면 위쪽 방향의 속도를 가진다. 도르래도 계속 회전할 수 있다. 그러나 문제에서 줄이 즉시 느슨해진다고 명시했으므로, 이후에는 v_A=v_B=Rω를 계속 사용할 수 없다. 그다음 단계는 A만 분석해야 한다.

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL은 차원, 스프링이 없을 때의 정지 거리, 스프링 에너지와 마찰/중력 손실의 합도 함께 점검했으며, 수치적으로도 일관적이었다. Kimi는 1차 테스트에서 보이는 답변을 형성하지 못했기 때문에 중간 모델링 품질을 비교할 수 없었다.

프로그래밍 문제: 알고리즘 본문은 독립 검사를 통과했지만, 모델이 붙인 예제에는 bug가 있었다

프로그래밍 문제는 optimize_release_plan(items, capacity_by_day, dependencies)를 구현하는 것이다. 매일의 용량, 설정되지 않은 날짜의 용량 0 처리, 직접 및 간접 의존성 클로저, 잘못된 의존성과 순환 의존성 검출, 그리고 value → risk → 排序后的 id 列表 3단계 tie-break를 처리해야 한다. items <= 18이므로 bitmask 완전 탐색은 합리적인 기준선이다.

GPT-5.6-SOL은 의존성 클로저 캐시와 2^n 부분집합 열거를 사용했다. 코드를 추출해 Python 3.11에서 독립적으로 검사한 결과, 의존성 클로저, 여러 날짜 용량 예제, value/risk/id 3단계 tie-break, 설정되지 않은 날짜 용량, 존재하지 않는 의존성, 순환 의존성까지 총 6개 검사 모두를 통과했다.

하지만 모델이 코드 끝에 붙인 첫 번째 assert는 실패했다. 모델은 A -> B -> C를 작성해 놓고, 동시에 가치가 11인 X도 넣었다. 주어진 용량에서 B + C + X의 총가치는 13으로, A + B + C의 12보다 높다. 따라서 함수가 ['B', 'C', 'X']를 반환하는 것이 맞고, assert를 ['A', 'B', 'C']로 쓴 것은 테스트 픽스처 오류다.

이 지점은 꽤 상징적이다. 코드 문제에서는 함수 본문만 봐서도 안 되고, “assert 8개를 붙였으니 테스트가 믿을 만하다”고 가정해서도 안 된다. 모델이 생성한 테스트 데이터 역시 사람이나 기준 구현으로 다시 검산해야 한다. Kimi K3의 프로그래밍 요청은 약 245초 뒤 읽기 타임아웃이 발생해 완전한 코드를 받지 못했다.

종합 평가

차원	kimi-k3	gpt-5.6-sol
수학 완성도	`6500/10000` token 모두에서 잘려 검수 불가	기대값, 2차 모멘트, 분산, sanity check까지 완전
물리 모델링	1차 테스트에서 잘림	도르래 관성, 줄 이완, 스프링 단계를 올바르게 처리
프로그래밍 산출물	이번 라운드에서는 타임아웃	코드 본문은 독립 검사 통과, 단 자체 assert 1개 오류
출력 안정성	reasoning 점유가 높아 보이는 답변을 받지 못하기 쉬움	세 문제 모두 순차 재시도에서 `stop`
응답 속도	약 187–246 s, 게다가 잘림/타임아웃 발생	성공 요청 기준 약 88–236 s; 병렬 1차에서 408 발생

더 정확한 결론은 “어떤 모델이 절대적으로 더 똑똑하다”가 아니라 다음에 가깝다.

이번 라우팅과 예산에서는 GPT-5.6-SOL이 복잡한 추론을 최종 답변으로 수렴시키는 데 더 유리했다. 즉시 읽을 수 있는 유도 과정이나 코드를 받아야 하는 워크플로에 더 적합했다.
Kimi K3의 핵심 문제는 추론 예산과 가시 출력 사이의 변환 효율이다. 수학 문제에서 10000 token까지 올려도 종료되지 않았다.
GPT-5.6-SOL의 코드도 맹신해서는 안 된다. 함수 로직은 독립 검사를 통과했지만, 함께 제공한 테스트 픽스처에는 가치 계산 오류가 있었다.
프로덕션 모델 선택에서는 finish_reason, reasoning token, 지연 시간, 로컬 테스트 결과를 함께 기록해야 한다. 마지막에 “답이 맞다”는 한 문장만 보고 판단해서는 안 된다.

실험 재현

이번 테스트 스크립트와 순차 재시도 결과는 다음 위치에 저장했다. 병렬 1차 테스트의 요약도 스크립트 출력에 기록되어 있다.

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

재측정할 때는 모델 ID, 프롬프트, temperature, max_tokens, 동시성 수준을 고정하고, 매번의 출력을 별도 파일로 저장하는 것을 권장한다. 상위 채널의 부하, 캐시 적중 여부, rate limit 상태는 모두 지연 시간에 영향을 줄 수 있다. 이 글에서는 HTTP 408, length, 읽기 타임아웃을 모두 테스트 결과의 일부로 기록했으며, 이를 숨기지 않았다.

Kimi K3 face à GPT-5.6-SOL : test réel sur des exercices difficiles en maths, physique et programmation

Jemmmm — Sat, 18 Jul 2026 01:16:38 +0000

Kimi K3 face à GPT-5.6-SOL : test réel sur des exercices difficiles en maths, physique et programmation

Cette fois, pas de questions-réponses triviales : j’ai fixé trois problèmes qui exigent un raisonnement en chaîne — un problème de probabilité avec recouvrement de motifs et second moment, un problème de physique avec inertie du poulie et bascule vers un câble détendu, et un problème Python qui dépend de fermetures de dépendances, d’une capacité sur plusieurs jours et d’un tie-break en trois niveaux. Les deux modèles ont été interrogés via la même interface, avec le même prompt et des plafonds de sortie proches, sans outils ni accès réseau.

D’abord, la conclusion :

gpt-5.6-sol a produit une réponse visible complète sur les trois exercices, avec des résultats de référence corrects en maths et en physique.
kimi-k3 a atteint finish_reason=length sur les maths et la physique dès la première passe avec une limite de 6500 tokens ; aucune réponse visible n’a été produite. En maths, même après avoir porté la limite à 10000, la sortie a encore été tronquée. Sur le problème de programmation, la requête a expiré en lecture après environ 245 secondes.
L’implémentation de programmation de GPT-5.6-SOL a passé des vérifications indépendantes supplémentaires sur la fermeture des dépendances, la capacité, le tie-break, les dépendances invalides et les dépendances cycliques, mais sa première assertion d’exemple intégrée contenait une valeur attendue erronée. Cela montre bien qu’il faut valider séparément « le corps du code est correct » et « tous les tests d’exemple passent ».

La latence indiquée ici est l’observation de cette requête précise, pas une SLA fixe. Lors des requêtes parallèles initiales, les requêtes mathématiques et physiques de GPT ont reçu un HTTP 408, puis ont été relancées séquentiellement ; la vitesse ne sert donc ici qu’à observer l’expérience d’appel, pas à revendiquer un classement absolu.

Configuration de test

Les tests ont été exécutés entre le 2026-07-17 et le 2026-07-18 (heure de Pékin), avec l’API suivante :

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

La première passe utilisait uniformément : maths et physique max_tokens=6500, programmation max_tokens=7500. Chaque problème demandait au modèle de fournir un raisonnement vérifiable ou du code exécutable, et l’on a enregistré finish_reason, les tokens de completion/reasoning, la latence de requête, la justesse numérique, ainsi que la capacité du code à s’exécuter de façon autonome sous Python 3.11.

Tableau récapitulatif des résultats

Tâche	kimi-k3	gpt-5.6-sol	Verdict
Maths : espérance et variance de HHTH	`length`, 186.98 s, 6500 tokens ; contenu visible vide	relance séquentielle `stop`, 236.07 s, 6872 tokens	GPT a répondu complètement ; Kimi n’a pas produit de réponse au premier tour
Physique : poulie, contact au sol, ressort	`length`, 202.05 s, 6500 tokens ; contenu visible vide	relance séquentielle `stop`, 156.29 s, 4501 tokens	GPT complet et numériquement correct
Programmation : sac à dos avec clôture de dépendances	`TimeoutError` après 245.54 s	`stop`, 87.96 s, 4514 tokens	Le code GPT s’exécute ; Kimi n’a pas renvoyé de code complet
Re-test maths de Kimi	`length`, 286.99 s, 10000 tokens	—	L’augmentation du budget n’a toujours pas permis de terminer

Dans les requêtes maths et physique de Kimi, le nombre de reasoning tokens rapporté par l’API était proche de 6497 dans les deux cas ; pour le re-test maths, il était proche de 9997. Cela ne veut pas dire que Kimi est incapable de raisonner, mais simplement que, pour ces prompts et avec ce routage, le budget de raisonnement est très facilement consommé, ce qui empêche le client d’obtenir la réponse finale.

Problème de maths : le chevauchement des motifs affecte non seulement l’espérance, mais aussi la variance

L’énoncé est le suivant : à chaque lancer, la probabilité de face vaut p=3/5 et celle de pile q=2/5. On lance jusqu’à ce que HHTH apparaisse pour la première fois, en autorisant les recouvrements de motif. On demande E[T] et Var(T).

L’automate des préfixes correct est S0=préfixe vide, S1=H, S2=HH, S3=HHT, S4=HHTH (état absorbant). La transition clé est S2 --H--> S2 : après HH, un nouveau H laisse encore comme plus long suffixe pertinent HH, il ne faut donc pas retomber à tort dans l’état vide.

Les équations du premier moment établies par GPT-5.6-SOL sont :

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

En poursuivant avec les équations du second moment, on obtient :

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

L’espérance peut aussi être vérifiée indépendamment par une formule de bord. HHTH n’a comme bord propre non vide que le caractère H, donc E[T] = 1/p + 1/(p³q) = 715/54. La réponse complète de GPT couvre à la fois les transitions d’état, le développement du second moment et un contrôle de cohérence. Kimi n’ayant produit aucun raisonnement visible sous les plafonds 6500 et 10000, il est impossible d’évaluer sa justesse mathématique sur cette passe ; on ne peut que noter qu’elle n’a pas été menée à terme dans le budget.

Problème de physique : après l’impact au sol, la contrainte se rompt, on ne peut plus réutiliser le même bilan énergétique

Le problème est défini ainsi : m_A=4.0 kg est sur un plan incliné rugueux à 25°, avec μ_k=0.18 ; m_B=3.0 kg est suspendue ; la poulie a M_p=1.2 kg, R=0.10 m ; après une descente de 1.50 m, B touche le sol et la corde se détend immédiatement ; A continue à monter de 0.10 m avant d’entrer en contact avec un ressort de k=250 N/m ; g=9.8 m/s².

Avant que B touche le sol, la corde est tendue et il n’y a pas de glissement ; la masse inertielle équivalente de la poulie vaut I/R²=(1/2)M_p=0.60 kg. En écrivant les équations couplées des deux masses et de la rotation de la poulie, on obtient :

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

Après l’impact au sol, la vitesse de B est modifiée par la collision avec le sol, A conserve encore une vitesse vers le haut du plan incliné, et la poulie peut continuer à tourner ; l’énoncé précise en plus que la corde se détend immédiatement, donc on ne peut plus imposer v_A=v_B=Rω. La suite doit donc être analysée uniquement pour A :

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL a également vérifié les dimensions, la distance d’arrêt sans ressort, ainsi que la cohérence entre l’énergie du ressort et la somme des pertes par frottement et gravité ; les valeurs sont auto-cohérentes. Kimi n’ayant pas produit de réponse visible lors de la première passe, il est impossible de comparer la qualité de son modélisation intermédiaire.

Problème de programmation : le cœur de l’algorithme passe les vérifications indépendantes, mais l’exemple du modèle contient un bug

Le problème demandait d’implémenter optimize_release_plan(items, capacity_by_day, dependencies), en gérant la capacité journalière, une capacité par défaut de 0 pour les dates non configurées, la fermeture transitive des dépendances directes et indirectes, la détection des dépendances invalides et des cycles, ainsi qu’un tie-break en trois niveaux value → risk → liste d’identifiants triée. Comme items <= 18, une exploration exhaustive par bitmask est une base raisonnable.

GPT-5.6-SOL a utilisé un cache de fermeture des dépendances et une énumération des sous-ensembles en 2^n. Nous avons extrait le code et l’avons vérifié indépendamment sous Python 3.11 : fermeture des dépendances, exemple de capacité multi-jour, tie-break en trois niveaux valeur/risque/id, capacité des dates non configurées, absence de dépendance et dépendance cyclique — les 6 groupes de vérifications ont tous passé.

En revanche, la première assertion ajoutée à la fin du code par le modèle échoue : elle écrit A -> B -> C, tout en introduisant un X de valeur 11. Avec la capacité donnée, la valeur totale de B + C + X est 13, donc supérieure à celle de A + B + C, qui est 12 ; la fonction doit donc renvoyer ['B', 'C', 'X']. L’assertion attendant ['A', 'B', 'C'] est incorrecte, c’est un bug dans le harnais de test.

C’est un point très parlant : pour un exercice de code, il ne faut pas se contenter du corps de la fonction, et il ne faut pas non plus considérer qu’« il y a 8 assertions, donc les tests sont forcément fiables ». Les données de test générées par le modèle doivent, elles aussi, être relues par un humain ou par une implémentation de référence. La requête de programmation de Kimi K3 a expiré en lecture après environ 245 secondes, sans code complet récupérable.

Bilan global

Dimension	kimi-k3	gpt-5.6-sol
Complétude en maths	les tokens `6500/10000` ont tous été tronqués, impossible à valider	espérance, second moment, variance et check de cohérence complets
Modélisation physique	troncature dès la première passe	traitement correct de l’inertie de la poulie, de la détente de la corde et de la phase ressort
Livraison du code	timeout sur cette passe	corps du code validé indépendamment, mais une assertion interne est fausse
Stabilité de sortie	forte consommation de reasoning, réponse visible souvent absente	sur les trois problèmes, les relances séquentielles sont toutes revenues en `stop`
Vitesse de réponse	environ 187–246 s, avec troncature/timeout	requêtes réussies d’environ 88–236 s ; 408 sur la première passe concurrente

La conclusion la plus juste n’est pas « tel modèle est objectivement plus intelligent », mais plutôt :

Avec ce routage et ce budget, GPT-5.6-SOL parvient plus facilement à condenser un raisonnement complexe en réponse finale ; c’est plus adapté à un workflow où il faut obtenir tout de suite une démonstration ou du code lisible.
Le principal problème de Kimi K3 est l’efficacité de conversion entre budget de raisonnement et sortie visible ; même en portant les maths à 10000 tokens, la génération n’aboutit toujours pas.
On ne peut pas faire une confiance aveugle au code de GPT-5.6-SOL. La logique de la fonction passe les vérifications indépendantes, mais le jeu de tests fourni contient une erreur de calcul de valeur.
Pour un choix en production, il faut enregistrer à la fois finish_reason, les reasoning tokens, la latence et les résultats des tests locaux ; il ne faut pas s’arrêter à la dernière phrase du type « la réponse est correcte ».

Reproduire l’expérience

Les scripts de test et les résultats de relance séquentielle de cette passe sont conservés ici (le résumé de la première passe concurrente a aussi été écrit dans la sortie du script) :

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

Pour refaire l’expérience, il est conseillé de figer les IDs de modèle, le prompt, temperature, max_tokens et le degré de concurrence, puis d’enregistrer chaque sortie dans un fichier séparé. La charge du canal amont, les hits de cache et l’état du rate limiting influencent tous la latence ; ici, les HTTP 408, length et les timeouts en lecture ont été conservés comme résultats de test à part entière, sans être masqués.

Kimi K3 против GPT-5.6-SOL: жёсткое сравнение на математике, физике и программировании

Jemmmm — Sat, 18 Jul 2026 01:15:10 +0000

Kimi K3 против GPT-5.6-SOL: жёсткое сравнение на математике, физике и программировании

На этот раз мы не гоняли простые вопросы, а взяли три задачи, где нужно делать последовательные выводы: вероятностную задачу с перекрытием шаблона и вторым моментом, физическую задачу с моментом инерции шкива и переключением после провисания нити, а также Python-задачу на замыкание зависимостей, многодневные ёмкости и трёхуровневый tie-break. Оба модели работали через один и тот же интерфейс, с одинаковым промптом и близкими лимитами вывода, без инструментов и без доступа к интернету.

Сначала короткий итог:

gpt-5.6-sol по всем трём задачам дал полный видимый ответ, а эталонные результаты для математики и физики совпали.
kimi-k3 при первом лимите 6500 tokens на математике и физике завершался с finish_reason=length, при этом видимый ответ был пустым; на математике после повышения лимита до 10000 тоже произошёл обрыв. Программная задача спустя примерно 245 секунд ушла в read timeout.
Реализация GPT-5.6-SOL по программированию прошла независимую проверку на замыкание зависимостей, ёмкости, tie-break, невалидные зависимости и циклы, но в собственной первой строке assert у модели был неверный ожидаемый результат. Это показывает, что «ядро кода верное» и «все примерные тесты корректны» — это разные вещи, которые надо проверять отдельно.

Задержка, указанная в статье, — это наблюдение именно для данного запроса; это не SLA. В первой параллельной серии запросов математический и физический запросы к GPT возвращали HTTP 408, после чего мы перешли к последовательным повторным попыткам. Поэтому скорость здесь используется только как характеристика опыта вызова, а не как абсолютный рейтинг.

Настройки теста

Тестирование проводилось по пекинскому времени с 2026-07-17 по 2026-07-18, интерфейс:

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

В первой серии везде использовались одинаковые лимиты: для математики и физики max_tokens=6500, для программирования max_tokens=7500. В каждой задаче модель должна была дать проверяемый вывод или исполняемый код; дополнительно фиксировались finish_reason, completion/reasoning token, задержка запроса, численная корректность и способность кода запускаться отдельно в Python 3.11.

Сводная таблица результатов

Задача	kimi-k3	gpt-5.6-sol	Вердикт
Математика: матожидание и дисперсия HHTH	`length`, 186.98 s, 6500 tokens; видимое содержимое пустое	последовательный повтор `stop`, 236.07 s, 6872 tokens	GPT ответил полностью; Kimi в первой попытке не дал ответ
Физика: шкив, касание пола, пружина	`length`, 202.05 s, 6500 tokens; видимое содержимое пустое	последовательный повтор `stop`, 156.29 s, 4501 tokens	GPT ответил полностью и численно верно
Программирование: dependency closure knapsack	через 245.54 s `TimeoutError`	`stop`, 87.96 s, 4514 tokens	GPT-код исполняется; Kimi не вернул полный код
Повтор математики у Kimi	`length`, 286.99 s, 10000 tokens	—	Даже при увеличенном бюджете ответ не был завершён

В запросах Kimi по математике и физике интерфейс сообщал reasoning token, близкие к 6497; на повторе по математике — около 9997. Это не означает, что у Kimi нет способности к рассуждению; это означает, что при данном промпте и текущей маршрутизации бюджет рассуждений очень легко выгорает, и вызывающая сторона не получает финальный ответ.

Математическая задача: перекрытие шаблона влияет не только на ожидание, но и на дисперсию

Условие: вероятность орла p=3/5, решки q=2/5; бросаем монету до первого появления HHTH, с разрешённым перекрытием шаблона, найти E[T] и Var(T).

Корректный автомат по префиксам имеет состояния S0=пустой префикс, S1=H, S2=HH, S3=HHT, S4=HHTH（absorbing state）. Ключевой переход — S2 --H--> S2: после HH ещё один H сохраняет наибольший суффикс HH, а не откатывает нас ошибочно в пустое состояние.

У GPT-5.6-SOL уравнения для первого момента были записаны так:

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

После построения уравнений для второго момента получаем:

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

Ожидание можно отдельно проверить по формуле границ. У HHTH единственная непустая собственная граница — однобуквенная H, поэтому E[T] = 1/p + 1/(p³q) = 715/54. В полном ответе GPT были и переходы состояний, и раскрытие второго момента, и sanity check. Kimi при лимитах 6500 и 10000 не выдал видимого вывода, так что в этом раунде его математическую корректность оценить не удалось — только зафиксировать, что в пределах бюджета задача не была завершена.

Физическая задача: после касания пола ограничение исчезает, и прежние уравнения энергии уже не годятся

Условие: m_A=4.0 kg на шероховатой наклонной плоскости под углом 25°, μ_k=0.18; m_B=3.0 kg висит; шкив M_p=1.2 kg, R=0.10 m; B опускается на 1.50 m, касается пола, нить сразу провисает; A затем поднимается по плоскости ещё на 0.10 m и касается пружины k=250 N/m; g=9.8 m/s².

До касания пола нить натянута и проскальзывания нет, поэтому эквивалентная инерционная масса шкива равна I/R²=(1/2)M_p=0.60 kg. Совместное решение для двух тел и вращения шкива даёт:

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

После касания пола скорость B меняется ударом о землю, у A по-прежнему остаётся скорость вверх вдоль плоскости, а шкив может продолжать вращаться; но в условии прямо сказано, что нить немедленно провисает, значит использовать v_A=v_B=Rω дальше нельзя. Последующий этап нужно анализировать только для A:

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL также проверил размерности, расстояние до остановки без пружины и согласованность суммы энергии пружины с потерями на трение и гравитацию; численно всё сходится. У Kimi в первой попытке не появилось видимого ответа, поэтому сравнить качество промежуточного моделирования не удалось.

Программная задача: основной алгоритм прошёл независимую проверку, но в собственном примере модели есть баг

Задача требовала реализовать optimize_release_plan(items, capacity_by_day, dependencies), учитывая ежедневные ёмкости, нулевую ёмкость для неуказанных дат, замыкание по прямым и косвенным зависимостям, валидацию невалидных зависимостей и циклов, а также тройной tie-break value → risk → отсортированный список id. Поскольку items <= 18, полный перебор по bitmask — вполне разумная базовая стратегия.

GPT-5.6-SOL использовал кеширование замыкания зависимостей и перебор всех подмножеств 2^n. Мы извлекли код и отдельно прогнали его в Python 3.11: проверки на замыкание зависимостей, пример с многодневной ёмкостью, тройной tie-break по value/risk/id, ёмкость для неуказанных дат, отсутствие зависимости и цикл — всего 6 наборов проверок — все прошли.

Но в конце кода у модели была собственная первая проверка, которая упала: она задавала цепочку A -> B -> C, одновременно добавляя объект X с ценностью 11. При данных ограничениях суммарная ценность B + C + X равна 13 и выше, чем A + B + C с 12, поэтому корректным ответом будет ['B', 'C', 'X'], а не ['A', 'B', 'C']. То есть ошибка была в тестовом каркасе, а не в логике функции.

Этот момент показателен: в кодовых задачах нельзя смотреть только на тело функции, и нельзя считать тесты корректными лишь потому, что «их там 8 штук». Сгенерированные моделью тестовые данные тоже нужно проверять вручную или через эталонную реализацию. Запрос на программирование у Kimi K3 спустя примерно 245 секунд завершился read timeout, полного кода получить не удалось.

Сводная оценка

Измерение	kimi-k3	gpt-5.6-sol
Полнота математического решения	при `6500/10000` tokens обрыв, приёмке не подлежит	ожидание, второй момент, дисперсия и sanity check есть полностью
Физическое моделирование	в первой попытке обрыв	корректно учтены инерция шкива, провисание нити и этап с пружиной
Результат по коду	в этот раз таймаут	основная логика прошла независимую проверку, но собственный пример содержит ошибку
Стабильность вывода	высокий расход reasoning, часто не удаётся получить видимый ответ	во всех трёх задачах последовательный повтор дал `stop`
Скорость ответа	около 187–246 s, с обрывом/таймаутом	успешные запросы примерно 88–236 s; в первой параллельной серии был 408

Более точный вывод — не «одна модель объективно умнее другой», а следующий:

При данной маршрутизации и бюджете GPT-5.6-SOL легче сводит сложные рассуждения к финальному ответу, поэтому он лучше подходит для рабочих сценариев, где нужен сразу читаемый вывод или код.
У Kimi K3 основная проблема — эффективность преобразования reasoning-бюджета в видимый результат; даже при увеличении лимита по математике до 10000 tokens ответ не был завершён.
Код GPT-5.6-SOL нельзя принимать на веру. Логика функции прошла независимую проверку, но приложенный тестовый каркас содержал ошибку в ожидаемом значении.
Для продакшн-выбора нужно фиксировать одновременно finish_reason, reasoning token, задержку и локальные тесты, а не только смотреть на финальную фразу «ответ верен».

Воспроизведение эксперимента

Скрипт теста и результаты последовательных повторов сохранены здесь (сводка по первой параллельной серии тоже записана в вывод скрипта):

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

При повторе рекомендуется жёстко фиксировать model ID, промпт, temperature, max_tokens и уровень параллелизма, а каждый вывод сохранять в отдельный файл. Нагрузка на upstream, попадание в cache и состояние rate limit заметно влияют на задержку; в этой статье HTTP 408, length и read timeout сознательно зафиксированы как часть результата, а не скрыты.

Kimi K3 vs GPT-5.6-SOL: Stress Tests in Math, Physics, and Programming

Jemmmm — Sat, 18 Jul 2026 01:13:49 +0000

Kimi K3 vs GPT-5.6-SOL: Stress Tests in Math, Physics, and Programming

This time I didn’t benchmark simple Q&A. Instead, I fixed three problems that require chained reasoning: a probability problem with overlapping patterns and a second moment, a physics problem involving pulley inertia plus a rope slack transition, and a Python problem that depends on closures, multi-day capacity, and a three-level tie-break. Both models used the same interface, the same prompt, and roughly the same output budget, with tools and web access disabled.

Bottom line first:

gpt-5.6-sol produced a complete visible answer on all three tasks, and its reference results for the math and physics problems were correct.
Under the initial 6500 token cap, kimi-k3 ended both the math and physics tasks with finish_reason=length, leaving the visible answer empty; even after raising the math cap to 10000, it was still truncated. The programming task timed out on read after about 245 seconds.
GPT-5.6-SOL’s programming solution passed separate extra checks for dependency closure, capacity, tie-breaks, invalid dependencies, and cyclic dependencies. However, the first assertion sample bundled with the model itself had an incorrect expected value. That means “the core code is correct” and “all example tests pass” have to be validated separately.

The latency figures in this article are just what I observed for this request; they do not imply any fixed SLA. In the initial concurrent run, GPT’s math and physics requests received HTTP 408, and I retried them sequentially afterward. So the timing numbers here are only for call experience, not for claiming an absolute ranking.

Test Setup

The tests were run from Beijing time 2026-07-17 to 2026-07-18, using:

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

The first round used the same limits for both models: max_tokens=6500 for math and physics, and max_tokens=7500 for programming. Each task asked the model to provide a derivation that could be verified or code that could be run directly, and I recorded finish_reason, completion/reasoning tokens, request latency, numerical correctness, and whether the code ran independently in Python 3.11.

Summary Table

Task	kimi-k3	gpt-5.6-sol	Verdict
Math: Expected value and variance of HHTH	`length`, 186.98 s, 6500 tokens; visible content empty	Sequential retry `stop`, 236.07 s, 6872 tokens	GPT answered completely; Kimi did not finish in the first round
Physics: Pulley, ground contact, spring	`length`, 202.05 s, 6500 tokens; visible content empty	Sequential retry `stop`, 156.29 s, 4501 tokens	GPT complete and numerically correct
Programming: dependency-closure knapsack	`TimeoutError` after 245.54 s	`stop`, 87.96 s, 4514 tokens	GPT code runs; Kimi did not return complete code
Kimi math retry	`length`, 286.99 s, 10000 tokens	—	Even with more budget, it still did not finish

For Kimi’s math and physics requests, the API reported reasoning tokens of roughly 6497 each; the math retry was close to 9997 reasoning tokens. That does not mean Kimi lacks reasoning ability. It means that under this prompt and the current routing, the reasoning budget was very easy to exhaust, and the caller never got the final answer.

Math Problem: Pattern Overlap Affects Not Just the Expectation, but the Variance Too

The problem is: with heads probability p=3/5 and tails probability q=2/5, keep tossing until HHTH appears for the first time, allowing overlaps. Find E[T] and Var(T).

The correct prefix automaton states are S0=empty prefix, S1=H, S2=HH, S3=HHT, and S4=HHTH (absorbing state). The key transition is S2 --H--> S2: after HH, another H still leaves the longest suffix as HH, so you must not incorrectly fall back to the empty state.

GPT-5.6-SOL set up the first-moment equations as:

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

Continuing with the second-moment equations gives:

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

The expectation can also be checked independently using the boundary formula. The only non-empty proper border of HHTH is the single character H, so E[T] = 1/p + 1/(p³q) = 715/54. GPT’s full answer covered the state transitions, the second-moment expansion, and a sanity check. Under the 6500 and 10000 limits, Kimi produced no visible derivation, so there is no way to score its mathematical correctness in this run; it can only be recorded as “not completed within budget.”

Physics Problem: Once the Mass Hits the Ground, You Cannot Keep Using the Same Energy Equation

The setup is: m_A=4.0 kg on a rough 25° incline with μ_k=0.18; m_B=3.0 kg hanging; pulley M_p=1.2 kg, R=0.10 m; after B drops 1.50 m and hits the ground, the rope immediately goes slack; A then slides up another 0.10 m before contacting a k=250 N/m spring; g=9.8 m/s².

Before B hits the ground, the rope is taut and there is no slip, so the pulley’s effective inertial mass is I/R²=(1/2)M_p=0.60 kg. Solving the translational equations for the two blocks together with the pulley rotation equation gives:

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

After B hits the ground, B’s velocity is altered by the collision with the floor, while A is still moving up the incline, and the pulley may still be spinning. The problem also explicitly says the rope immediately goes slack, so you can no longer use v_A=v_B=Rω. From that point on, you should analyze only A:

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL also checked dimensional consistency, the stopping distance without a spring, and the sum of spring energy plus friction/gravity losses, and the numbers were self-consistent. Kimi never produced a visible answer in the first round, so there is no way to compare its intermediate modeling quality.

Programming Problem: The Core Algorithm Passed Independent Checks, but the Model’s Own Sample Has a Bug

The programming task was to implement optimize_release_plan(items, capacity_by_day, dependencies), handling daily capacity, zero capacity for unconfigured dates, direct and transitive dependency closure, invalid dependencies, cycle detection, and a three-level tie-break of value → risk → sorted id list. Since items <= 18, bitmask enumeration is a reasonable baseline.

GPT-5.6-SOL used dependency-closure caching plus 2^n subset enumeration. I extracted the code and ran separate checks in Python 3.11: dependency closure, multi-day capacity samples, value/risk/id three-level tie-breaks, unconfigured-date capacity, missing dependencies, and cyclic dependencies. All 6 checks passed.

However, the first assertion bundled at the end of the model’s code failed: it wrote A -> B -> C while also including an item X with value 11. Under the given capacity, B + C + X has a total value of 13, which is higher than A + B + C at 12, so returning ['B', 'C', 'X'] is correct; the assertion ['A', 'B', 'C'] is a test fixture bug.

This is a good reminder that in code tasks, you cannot judge only the function body, and you also cannot assume a test suite is trustworthy just because it includes 8 assertions. Model-generated test data still needs to be checked manually or against a reference implementation. Kimi K3’s programming request timed out on read after about 245 seconds, and no complete code was obtained.

Overall Assessment

Dimension	kimi-k3	gpt-5.6-sol
Math completeness	Both `6500/10000` token runs were truncated, so there was nothing to accept	Expectation, second moment, variance, and sanity check all complete
Physics modeling	Truncated in the first round	Correct handling of pulley inertia, rope slack, and spring phase
Programming delivery	Timed out in this run	Core code passed independent checks, but one bundled assertion was wrong
Output stability	High reasoning usage, easy to end up with no visible answer	All three sequential retries ended with `stop`
Response speed	About 187–246 s, with truncation/timeouts	Successful requests around 88–236 s; the initial concurrent run had 408

The more accurate conclusion is not “one model is absolutely smarter,” but:

Under this routing and these budgets, GPT-5.6-SOL was more likely to collapse complex reasoning into a final answer, making it a better fit for workflows that need a readable derivation or runnable code right away.
Kimi K3’s main issue here was the conversion efficiency between reasoning budget and visible output; even when the math limit was raised to 10000 tokens, it still did not finish.
GPT-5.6-SOL’s code should not be trusted blindly either. Its function logic passed independent checks, but the attached test fixture had a value-calculation error.
For production selection, you should record finish_reason, reasoning tokens, latency, and local test results together, instead of relying only on the final sentence saying the answer is correct.

Reproducing the Experiment

The test script and sequential retry results are stored here, and the summary of the initial concurrent run is also written into the script output:

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

For reruns, it is best to pin the model IDs, prompt, temperature, max_tokens, and concurrency level, and save each output to a separate file. Upstream traffic, cache hits, and rate-limit state all affect latency; in this article, HTTP 408, length, and read timeouts were all recorded as part of the test results rather than being hidden.

Kimi K3와 Claude Fable 5 실측: 수학 검증, 코드 완결성, 응답 속도의 차이

Jemmmm — Fri, 17 Jul 2026 17:11:43 +0000

Kimi K3와 Claude Fable 5 실측: 수학 검증, 코드 완결성, 응답 속도의 차이

운영 환경에서는 정답처럼 보이는 문장보다 검증 가능한 과정과 완성된 산출물이 중요합니다. 이번 테스트는 중간 계산과 실행 가능한 코드까지 확인했습니다.

이번 테스트의 핵심 차이

Fable 5의 평균 지연은 37.1초, Kimi K3는 108.0초였습니다. 반면 수학 문제의 중간 상태 검증은 Kimi K3가 더 일관적이었습니다.

결과 요약

과제	Kimi K3	Claude Fable 5
HHTH 확률	통과	최종값은 통과했지만 중간 산술 오류
충돌과 스프링	통과	통과
Python 집계	4k에서 잘림, 7k에서 통과	4k에서 잘림, 7k에서 통과
일정 제약	통과	통과

평균 지연 — Kimi K3: 108.0 s
평균 지연 — Claude Fable 5: 37.1 s

reasoning tokens와 운영 비용

Kimi K3 completion tokens: 13,975
Kimi K3 reasoning tokens: about 12,500
Fable 5 completion tokens: 10,187

Kimi K3는 첫 라운드에서 약 12,500 reasoning tokens를 보고했습니다. 더 많은 검증은 높은 지연과 긴 코드의 가시 출력 부족으로 이어질 수 있습니다.

코드: 첫 실패 원인은 출력 예산

Python 함수는 request_id 기준 retry 병합, ISO-8601 시간 처리, 반개구간 [start,end) 필터링, token·지연 집계, 다중 키 정렬을 수행해야 했습니다.

Round 1, max_tokens=4000:
Kimi K3 finish_reason=length
Fable 5 finish_reason=length

Retry, max_tokens=7000:
Kimi K3: 145.2 s, 5199 completion tokens, 8/8 assertions
Fable 5: 46.6 s, 3710 completion tokens, 8/8 assertions

4,000 tokens에서는 두 응답 모두 length로 종료됐습니다. 7,000으로 늘리자 두 Python 구현 모두 같은 8개 assert를 통과했습니다.

테스트 조건

Test date: 2026-07-17
Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Models: kimi-k3, claude-fable-5
temperature: 0.2
Round 1 max_tokens: 4000
Coding retry max_tokens: 7000

두 모델에는 동일한 프롬프트와 검수 기준을 적용했습니다. HTTP 200만으로 성공을 판단하지 않고 최종값, 중간 상태, finish_reason, 실행 가능한 Python, 동일한 assertion을 확인했습니다.

수학: 최종 답보다 중간 일관성

편향된 동전 문제는 P(H)=3/5, 패턴 중첩 허용 조건에서 첫 HHTH까지의 기대 횟수를 묻습니다. 정답은 다음과 같습니다.

E[T] = 715/54 ≈ 13.2407407407
E1 = 625/54
E2 = 475/54
E3 = 170/27

Kimi K3는 상태 방정식, 패턴 border, 공정한 동전 특수값을 교차 검증했습니다. Fable 5는 최종값은 맞았지만 두 중간값이 자체 방정식과 일치하지 않았습니다.

물리: 두 모델 모두 단계 분리 성공

물리 문제는 완전 비탄성 충돌, 마찰, 스프링 압축의 두 단계로 구성했습니다. 두 모델의 결과는 다음과 같습니다.

Post-collision speed: 2.4 m/s
Energy lost in collision: 21.6 J
Maximum compression: about 0.2212 m

두 모델 모두 스프링 압축량 약 0.2212 m와 Eli, Bo, Ada, Cici, Deng의 유일 일정을 찾았습니다.

제약 추론: 동일한 유일 해

두 모델은 동일한 유일한 요일별 일정을 찾았습니다.

월요일	화요일	수요일	목요일	금요일
Eli	Bo	Ada	Cici	Deng

두 모델 모두 스프링 압축량 약 0.2212 m와 Eli, Bo, Ada, Cici, Deng의 유일 일정을 찾았습니다.

업무별 모델 라우팅

대량의 테스트 가능한 코드는 Fable 5부터 평가
정확한 수학 전개에는 Kimi K3 유지
긴 코드는 finish_reason과 실행 테스트를 필수화

테스트의 한계

작은 표본의 실측이지 보편적인 순위표가 아닙니다. 운영 평가에서는 각 범주를 20~50회 반복하고 성공률, 잘림 비율, 첫 token 시간, P50/P95/P99 지연, completion tokens, 승인된 결과당 비용을 측정해야 합니다.

결론

이번 표본에서 Fable 5는 빠른 전달 경로였고, Kimi K3는 수학 중간 상태를 더 신중하게 검증하는 경로였습니다.

from openai import OpenAI

client = OpenAI(api_key="YOUR_API_KEY", base_url="https://cn.crazyrouter.com/v1")
response = client.chat.completions.create(
    model="kimi-k3",
    temperature=0.2,
    max_tokens=4000,
    messages=[{"role": "user", "content": "YOUR_TEST_PROMPT"}],
)
print(response.model, response.choices[0].finish_reason, response.usage)

전체 글: https://crazyrouter.com/ko/blog/kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-ko

API: https://crazyrouter.com/register?utm_source=crazyrouter_blog&utm_medium=article&utm_campaign=kimi_k3_fable5_multilingual_20260718&utm_content=kimi-k3-vs-claude-fable-5-hard-reasoning-benchmark-2026-ko__body_cta&utm_term=kimi-k3+claude-fable-5+benchmark

DEV Community: Jemmmm

Claude Opus 5 và GPT-5.6 Luna: 18 bài kiểm chứng, không xếp hạng theo tốc độ

Kết luận nhanh

Vì sao cần tăng độ khó

Cách chấm vòng 18 bài

Kết quả trên sáu nhóm năng lực

Khoảng cách thuật toán nằm ở chất lượng bàn giao

JSON nghiêm ngặt lại nghiêng về Luna

Tách giới hạn đầu ra khỏi lỗi trí tuệ

Áp dụng vào định tuyến thực tế

Cách tái hiện và bằng chứng gốc

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

17/18 có nghĩa Opus 5 là bên thắng tuyệt đối không?

Vì sao tự kiểm thử sai vẫn tính là lỗi thuật toán?

Vì sao độ trễ không xuất hiện trong kết luận?

Kết luận cuối

Claude Opus 5 против GPT-5.6 Luna: 18 проверяемых задач без рейтинга скорости

Короткий ответ

Почему задачи пришлось усложнить

Как оценивались 18 задач

Результаты по шести направлениям

Разрыв в алгоритмах оказался разрывом в поставке

Строгий JSON показал преимущество Luna

Лимит вывода отделён от ошибок интеллекта

Как маршрутизировать запросы в продакшене

Воспроизведение и исходные данные

Частые вопросы

Означает ли 17/18, что Opus 5 — абсолютный победитель?

Почему ошибочные самотесты считаются провалом алгоритма?

Почему задержки нет в итоговом решении?

Итог

Claude Opus 5 và GPT-5.6-SOL: kiểm thử 10 bài về độ chính xác, kết quả cốt lõi hòa 10/10

Claude Opus 5 và GPT-5.6-SOL: kiểm thử 10 bài về độ chính xác, kết quả cốt lõi hòa 10/10

Trả lời nhanh

Vì sao độ trễ mạng không được tính vào điểm năng lực

Môi trường kiểm thử và tiêu chí pass/fail

Kết quả 10 bài kiểm thử

Bài xác suất khó: đúng đáp án chưa chắc đã hoàn thành tác vụ

Kiểm chứng mã thực thi: phải chạy, không chỉ đọc

Bài tổng hợp nhật ký

Bài định tuyến ổn định có ràng buộc độ tin cậy

JSON nghiêm ngặt: phép thử tuân thủ chỉ dẫn, không phải bài toán trí tuệ

Cách kiểm thử lại qua cùng một API

Cách tránh kết luận sai từ một lần chạy

Định nghĩa pass/fail trước khi chạy

Tách các loại lỗi

Không chọn mẫu theo kết luận mong muốn

Không biến độ trễ thành điểm suy luận

Hướng dẫn lựa chọn cho môi trường sản xuất

Trường hợp cả hai mô hình đều phù hợp

Trường hợp nên ưu tiên thử GPT-5.6-SOL

Các lớp bảo vệ nên bổ sung khi dùng Opus 5

FAQ

Claude Opus 5 hay GPT-5.6-SOL thông minh hơn?

Vì sao tỷ lệ hoàn thành đầy đủ không hòa?

Đáp án xác suất chính xác là bao nhiêu?

Lỗi JSON có nên được tính là lỗi trí tuệ không?

Kết quả JSON nghiêm ngặt cụ thể ra sao?

Hai bài mã được chấm như thế nào?

Vì sao bài này không công bố mô hình thắng về tốc độ?

HTTP 200 có đồng nghĩa với tác vụ thành công không?

finish_reason quan trọng như thế nào?

Mười bài có đủ để quyết định lựa chọn lâu dài không?

Nên bắt đầu so sánh mô hình như thế nào?

Kết luận cân bằng

Claude Opus 5とGPT-5.6-SOLを10問で検証：正解率はともに10/10、完遂率と形式遵守には差

Claude Opus 5とGPT-5.6-SOLを10問で検証：正解率はともに10/10、完遂率と形式遵守には差

早見表

まず分けて読むべき3つの指標

応答速度を知能スコアから除外した理由

検証環境と採点方法

10問の検証結果

最難関の確率問題：正解と完遂を分けて評価する

実行可能コードの検証：見た目ではなくテスト結果で判定

ログ集計アルゴリズム

信頼性制約付きの安定経路選択

厳密なJSON：推論の正しさではなく形式遵守を測る

同一APIで再検証する方法

本番導入時の考え方

両モデルを候補にしやすい用途

`finish_reason` quan trọng như thế nào?

Почему returned model равен `anthropic/claude-fable-5`?