Какая модель лучше пишет код на Python

Любой готовый ответ на «какая модель лучше пишет Python» устареет к следующему обновлению каталога — модели меняются, задачи у всех разные. Рабочий способ — не искать чужой рейтинг, а прогнать свою реальную задачу через несколько кандидатов и сравнить по фактическому результату и цене. Ниже — как это сделать за один вечер, а не за неделю.

Кандидаты в каталоге

Для кода имеет смысл сравнивать хотя бы три-четыре модели с разной специализацией: claude-opus-5-5 (флагман Anthropic) или claude-sonnet-5, gpt-5.6-sol/gpt-5.6-luna (линейка GPT-5.6), glm-5.3 или glm-5.3-flash (актуальный список — GET https://api.zukko.pro/v1/models). У Claude и GPT — vision и контекст 1M, у GLM — 128K и без vision, так что для большого модуля или скриншотов это стоит учесть; в остальном разница проявляется на конкретной задаче и в цене за токен.

Extended thinking полезен не для всех задач одинаково

У Claude extended thinking включается явно, через параметр thinking в запросе к /v1/messages:

curl https://api.zukko.pro/v1/messages \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5-5",
    "max_tokens": 4096,
    "thinking": {"type": "enabled", "budget_tokens": 2048},
    "messages": [{"role": "user", "content": "Почему падает этот тест: ..."}]
  }'

На задачах вроде «напиши функцию по описанию» разница от включённого thinking обычно небольшая — а вот на «почему падает тест после рефакторинга» или «найди race condition в этом асинхронном коде» именно extended thinking чаще даёт разницу, потому что задача требует нескольких шагов рассуждения, а не генерации кода с нуля.

Методика сравнения на своих данных

Берите 5-10 реальных задач из своего проекта — не абстрактные «напиши сортировку», а настоящие тикеты или PR-ревью. Прогоняйте один и тот же промпт через каждую модель-кандидата с одинаковыми параметрами (max_tokens, а temperature: 0 для воспроизводимости — только там, где модель его принимает: Claude-модели могут отклонить temperature, отличную от 1, с ошибкой 400, поэтому им этот параметр не передавайте) и запускайте результат через свой тестовый набор — pytest, mypy, что у вас используется. Считать вручную «нравится/не нравится» на глаз — не метод, а гадание; прогон через реальные тесты проекта — метод.

Считать цену параллельно с качеством

К каждому обычному (не потоковому) запросу возвращается заголовок X-Zukko-Cost-Micros — точная стоимость этого конкретного запроса; у ответов с stream: true его нет. Ведите таблицу «модель → задача → прошли тесты (да/нет) → стоимость» по ходу прогона, а не восстанавливайте её потом по памяти. На выходе у вас будет не абстрактное «модель X лучше», а конкретное «на моих 8 тикетах модель X решила 7 против 5 у модели Y, при цене на 40% выше» — и дальше можно решать, стоит ли разница того для вашего проекта.

Проверка размера контекста заранее

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

curl https://api.zukko.pro/v1/messages/count_tokens \
  -H "Authorization: Bearer fetch_ваш_ключ" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "claude-opus-5-5", "messages": [{"role": "user", "content": "<код модуля>"}]}'

Так вы не упрётесь в лимит модели уже после того, как отправили платный запрос — вход посчитан заранее и бесплатно.

Одна и та же модель, два формата — не путать с разными моделями

Если сравниваете через /v1/chat/completions и /v1/messages одновременно, помните, что это разные форматы запроса для потенциально одной и той же модели, а не два разных кандидата. Не засчитывайте «тот же claude-opus-5-5, вызванный по-другому» за отдельный пункт сравнения — это исказит выводы.

Не тестировать на выключенной модели

Если один из кандидатов внезапно отвечает 503 с кодом model_disabled — модель выключена; найдите замену в актуальном списке GET https://api.zukko.pro/v1/models, обновите имя модели в тестовом наборе и продолжайте сравнение с актуальной версией, а не пытайтесь удержать в тестах старый идентификатор.

Показывать модели больше, чем просто код

Если баг проявляется визуально — сломанная вёрстка, неправильный график, — не пересказывайте это текстом. Модели Claude и GPT из списка кандидатов принимают изображения (у GLM vision нет), так что можно отправить скриншот вместе с кодом компонента в одном запросе и спросить, что расходится между тем, что нарисовано, и тем, что написано. Для задач вроде «почему не проходит тест» это не нужно, а для фронтенд-багов часто экономит несколько раундов уточнений.

Не сжигать бюджет на повторных прогонах сравнения

Если сравнение из пяти-десяти задач гоняется несколько раз, пока подбираете промпт, добавляйте Idempotency-Key на каждый уникальный запрос вида «задача плюс модель» — так случайный повторный запуск скрипта после сбоя не спишет деньги дважды за одни и те же вызовы. И поставьте дневной лимит на тестовый ключ в кабинете, чтобы сравнение на десяти моделях не переросло в неожиданный счёт, если один из кандидатов начнёт отвечать намного длиннее, чем ожидалось.

Итог

Единого ответа «модель X лучше всех пишет Python» не существует в отрыве от задачи и кодовой базы. Есть быстрый способ получить точный ответ для своего конкретного случая: одинаковый промпт, реальные тесты вместо взгляда на код, замер цены через X-Zukko-Cost-Micros и бесплатный подсчёт токенов там, где вход большой.