{
  "title": "Бенчмарк LLM: мини-движок SQL",
  "date": "28-10-2026",
  "tests_total": 464,
  "perf_total": 5,
  "oracle": "SQLite 3.45",
  "oracle_note": "Python 3.12.7 / sqlite3 3.45.3",
  "task": {
    "name": "SQL-движок на чистом Python, совместимый с SQLite",
    "file": "task/task.md",
    "summary": "Нужно написать один модуль на Python 3.12 с функцией `run_query(tables, sql)`. Пользоваться можно только стандартной библиотекой, модуль `sqlite3` и eval/exec запрещены. Движок должен понимать SELECT и DISTINCT, INNER, LEFT и CROSS JOIN, WHERE, GROUP BY, HAVING, ORDER BY по выражению, алиасу и номеру колонки, LIMIT и OFFSET, агрегаты внутри выражений, CASE, LIKE, BETWEEN, IN, IS и функции ABS, LOWER, UPPER, LENGTH, COALESCE, IFNULL, NULLIF, ROUND, SUBSTR. Значения, их типы (int, float, str, None), число строк и порядок должны совпадать с SQLite 3.45 без type affinity и без ICU. JOIN двух таблиц по 50 000 строк должен укладываться в 3 секунды.",
    "checks": [
      "56 ручных запросов с ловушками. Среди них целочисленное деление и `%` с отрицательными числами, `ROUND(2.5)` и `ROUND(0.125, 2)`, `NOT IN` со списком, где есть NULL, трёхзначная логика AND, OR и NOT. Ещё есть `LOWER` и `UPPER`, которые в SQLite меняют регистр только у латиницы, LIKE, который не различает регистр тоже только у латиницы, отрицательные аргументы `SUBSTR`, превращение дробей в текст при `||` (`0.1+0.2` даёт `'0.3'`), сортировка NULL, агрегаты по пустой таблице, LEFT JOIN с условием в ON и соединение таблицы с самой собой.",
      "400 случайных запросов из генератора с фиксированным seed. В них есть типизированные выражения глубиной до трёх уровней, восемь вариантов FROM и JOIN, агрегаты, GROUP BY, HAVING, DISTINCT, ORDER BY, LIMIT и OFFSET.",
      "8 запросов, которые обязаны закончиться ошибкой `ValueError`: синтаксическая ошибка, неизвестная таблица, колонка или функция, неверное число аргументов.",
      "5 замеров скорости на таблицах по 50 000 строк, на каждый даётся 3 секунды. Вложенными циклами в лимит не уложиться, нужен hash join.",
      "Ответ сравнивается с настоящим SQLite. Значения и типы проверяются строго, int и float считаются разными, дроби сравниваются с точностью 1e-9. Если в запросе нет ORDER BY, порядок строк не важен. Строки с одинаковым ключом сортировки тоже можно выдать в любом порядке.",
      "Сам стенд проверен эталоном, обёрткой над sqlite3. Он проходит 464 теста из 464 и 5 замеров из 5."
    ]
  },
  "conditions": [
    "Каждая модель получила одно и то же задание слово в слово, одним сообщением, без системного промпта и без инструментов. У модели был один ответ, и запустить свой код она не могла.",
    "Запросы шли напрямую в API провайдера в потоковом режиме (`stream.py`), рассуждение было включено. У Qwen для этого служит `enable_thinking`, у GLM `thinking: enabled`, у GPT, Grok и Gemini `reasoning_effort: high`. Opus получал `thinking: adaptive` и `effort` high или max через нативный `/v1/messages`. Kimi и DeepSeek работали в режиме по умолчанию.",
    "Лимит ответа выставлен на максимум, который разрешает API: у DeepSeek это 384K, у Qwen и GLM 131K, у остальных 128K. Strata получила 128K при контексте 131K.",
    "В зачёт идёт код как есть. Если код ломается из-за одной опечатки, отдельно считается вариант с правкой одной строки. Он нужен только для понимания и в рейтинг не входит.",
    "Время считается от отправки запроса до последнего токена. Оно зависит и от загрузки серверов провайдера, поэтому это не чистая скорость модели.",
    "Opus 5.5 проверялся двумя способами: через API, как все остальные, и агентом Claude Code с чистым контекстом и запретом запускать код. У агента есть системный промпт Claude Code."
  ],
  "nuances": [
    "В первой попытке DeepSeek Flash потратил все 64K токенов на рассуждение и не выдал код. Лимит занизили мы, поэтому модель перезапустили с 384K. У DeepSeek 1M означает размер контекста, а не длину ответа.",
    "У аккаунта Moonshot для Kimi K3.1 Pro разрешён только один одновременный запрос.",
    "Из России запросы к api.moonshot.ai больше примерно 16 КБ обрываются на ТСПУ, потому что сервис стоит за Cloudflare. Поэтому трафик к Kimi шёл через VPN роутера.",
    "GPT-6.1 Sol, GPT-6.1 Terra, Grok, Opus 5.5 через API и Gemini 3.8 Flash работали через партнёрский шлюз. Мы проверили, что системный промпт он не подмешивает. GPT нормально работает через chat/completions. Claude полноценно работает только через нативный `/v1/messages`: через chat Opus на задаче не рассуждал. Gemini через шлюз не рассуждает ни при каких параметрах.",
    "Strata это локальная Qwen3.8-Flash-Next в квантовании Q2 размером около 66 ГБ на домашнем ПК. С лимитом 64K её код оборвался на 1931-й строке, поэтому её перезапустили с 128K.",
    "Генератор случайных запросов не использует арифметику над строками, сравнение числа со строкой и `%` над дробями, потому что задание явно исключает эти случаи.",
    "GLM 5.3 упёрся в максимум API в 131 072 токена на одном рассуждении. Это ограничение модели и провайдера, а не наших настроек.",
    "Opus 5.5 с адаптивным мышлением на этой задаче не думал вовсе, ни на `high`, ни на `max`: токенов рассуждения ноль, код пошёл с 4-й секунды. Остальные модели тратили на рассуждение от 25 до 130 тысяч токенов.",
    "Ошибку в одну строку сделали четыре модели из шести в рейтинге: DeepSeek Flash (регистр имён функций), GPT-6.1 Sol (`COUNT(*)`), Qwen (`CASE WHEN`) и Opus через API (`consume('IDENT')`). Ни одна из них не прогнала в голове простейший запрос.",
    "Время и токены Opus-агента оценочные. У субагента нет файла ответа, поэтому токены посчитаны по объёму, который попал в кэш контекста перед записью файла. Протокол агента проверен: он ни разу не читал файлы и не запускал код.",
    "Opus-агент с `effort: max` добавлен 29.10.2026, после основного прогона, по тому же протоколу: одно чтение задания и одна запись решения, без запуска кода. Его запустили, чтобы сравнить с Opus через API на том же `effort: max`: через партнёрский шлюз модель рассуждает заметно меньше. Его время и токены посчитаны по журналу агента."
  ],
  "warmup": {
    "summary": "Перед основной задачей была разминка: калькулятор выражений на `fractions.Fraction` с приоритетами `**`, унарным минусом, `%` как в Python, функциями, переменными и ошибками с позицией. Его проверяли 68 скрытых тестов из папки `warmup/`.",
    "results": [
      "Kimi K3.1 Pro через `kimi -p` прошёл 68 тестов из 68 за 3 мин 19 с.",
      "DeepSeek Flash через API прошёл 68 тестов из 68 за 2 мин 29 с и потратил 25 тысяч токенов на рассуждение.",
      "Задача оказалась по силам обеим и не различает модели, поэтому основной стала более сложная задача."
    ]
  },
  "participants": [
    {
      "id": "kimi",
      "name": "Kimi K3.1 Pro",
      "vendor": "Moonshot AI",
      "model": "kimi-k3.1-pro",
      "access": "API api.moonshot.ai (через VPN роутера)",
      "max_tokens": 128000,
      "answer": "answers/kimi.json",
      "grade": "grades/kimi.txt",
      "solution": "solutions/kimi/solution.py",
      "verdict": "460 тестов из 464 и 5 замеров из 5. Все четыре промаха связаны с одной тонкостью. SQLite превращает дробь в текст с 15 значащими цифрами: `0.1+0.2 || ''` даёт `'0.3'`, а `1e20` даёт `'1.0e+20'`. Kimi делает это через `repr` Python и получает `'0.30000000000000004'`. Ещё `ROUND(2.675, 2)` у него дал 2.68 вместо 2.67, потому что SQLite округляет двоичное значение, а не десятичную запись. Kimi оказался самым медленным из облачных моделей (около 24 минут), но самым экономным по токенам."
    },
    {
      "id": "dsflash",
      "name": "DeepSeek Flash (V4.1)",
      "vendor": "DeepSeek",
      "model": "deepseek-flash",
      "access": "API api.deepseek.com",
      "max_tokens": 384000,
      "answer": "answers/dsflash.json",
      "grade": "grades/dsflash.txt",
      "solution": "solutions/dsflash/solution.py",
      "fix": {
        "passed": 431,
        "perf": "4/5",
        "description": "`Func(lname, …)` заменено на `Func(lname.upper(), …)`"
      },
      "verdict": "104 теста из 464 из-за одной опечатки. Парсер сохраняет имя функции в нижнем регистре, а проверка сравнивает его с `\"COUNT\"` и `\"ABS\"` в верхнем. Поэтому не работает ни одна функция и ни один агрегат. С правкой одной строки код проходит 431 тест и 4 замера скорости из 5. Архитектура хорошая, есть hash join и правильная работа с NULL, но модель ни разу мысленно не прогнала `SELECT COUNT(*)`."
    },
    {
      "id": "dspro",
      "name": "DeepSeek V4 Pro",
      "vendor": "DeepSeek",
      "model": "deepseek-v4-pro",
      "access": "API api.deepseek.com",
      "max_tokens": 384000,
      "answer": "answers/dspro.json",
      "grade": "grades/dspro.txt",
      "solution": "solutions/dspro/solution.py",
      "fix": {
        "passed": 0,
        "description": "лямбда обёрнута в скобки, модуль импортируется, но падает на любом запросе"
      },
      "verdict": "0 из 464, модуль не импортируется. Многострочная `lambda` написана без скобок, это синтаксическая ошибка. После её исправления результат всё равно нулевой: токенайзер отдаёт кортежи, а парсер ждёт объекты с полем `.value`. Это ошибка в архитектуре, а не опечатка.",
      "excluded": "Код не импортируется из-за синтаксической ошибки, а после её исправления падает на каждом запросе. В отличие от большинства исключённых прогонов, это ошибка самой модели, а не API. Прогон исключён по решению автора бенчмарка."
    },
    {
      "id": "qwen",
      "name": "Qwen3.8-Max",
      "vendor": "Alibaba",
      "model": "qwen3.8-max",
      "access": "API token-plan.maas.qwencloudapi.com",
      "max_tokens": 131072,
      "answer": "answers/qwen.json",
      "grade": "grades/qwen.txt",
      "solution": "solutions/qwen/solution.py",
      "fix": {
        "passed": 462,
        "perf": "5/5",
        "description": "`match_kw(\"WHEN\")` съедал токен, вместо него проверка без сдвига"
      },
      "verdict": "294 теста из 464 и 5 замеров из 5. Одна ошибка ломает все `CASE WHEN` без операнда, это 168 тестов. Проверка `if not self.match_kw(\"WHEN\")` сдвигает указатель и съедает первый WHEN. С правкой этой строки код проходит **462 теста и 5 замеров из 5, это лучший результат с правкой**. Остальной код почти безупречен. Это самый долгий облачный прогон: 47 минут и 99 тысяч токенов рассуждения."
    },
    {
      "id": "glm",
      "name": "GLM 5.3",
      "vendor": "Z.ai (Zhipu)",
      "model": "glm-5.3",
      "access": "API api.z.ai",
      "max_tokens": 131072,
      "answer": "answers/glm.json",
      "grade": "grades/glm.txt",
      "solution": "solutions/glm/solution.py",
      "verdict": "0 из 464. Модель думала 33 минуты и потратила на рассуждение все 131 072 токена, это максимум API. До кода она так и не дошла (`finish_reason: length`). Поднять лимит выше нельзя, а сама модель не умеет вовремя остановиться и начать писать.",
      "excluded": "Весь максимум API в 131 072 токена ушёл на рассуждение, и до кода модель не дошла. Это ограничение провайдера на длину ответа."
    },
    {
      "id": "gpt",
      "name": "GPT-6.1 Sol",
      "vendor": "OpenAI",
      "model": "gpt-6.1-sol",
      "access": "партнёрский шлюз",
      "max_tokens": 128000,
      "answer": "answers/gpt.json",
      "grade": "grades/gpt.txt",
      "solution": "solutions/gpt/solution.py",
      "fix": {
        "passed": 445,
        "perf": "5/5",
        "description": "2 строки: узел `(\"*\",)` для `COUNT(*)` добавлен в два обхода дерева"
      },
      "verdict": "376 тестов из 464 и 2 замера из 5. Почти все промахи дала одна ошибка. Аргумент `COUNT(*)` хранится как узел `(\"*\",)`, а две функции обхода дерева, `_resolve` и `_replace_alias`, его не знают. Поэтому любой запрос с `COUNT(*)` заканчивается ошибкой «bad expression», в том числе три замера скорости. С правкой двух строк код проходит 445 тестов и 5 замеров из 5, это второе место по качеству кода. Остальные промахи связаны с теми же тонкостями SQLite, что у Kimi, плюс `SUBSTR` с началом 0 и неверное деление в семи случайных запросах. Модель быстрая: 6 минут и 17 тысяч токенов.",
      "reasoning_hidden": true
    },
    {
      "id": "gpt-terra",
      "name": "GPT-6.1 Terra",
      "vendor": "OpenAI",
      "model": "gpt-6.1-terra",
      "access": "партнёрский шлюз, `reasoning_effort: high`",
      "max_tokens": 128000,
      "reasoning_hidden": true,
      "answer": "answers/gpt-terra.json",
      "grade": "grades/gpt-terra.txt",
      "solution": "solutions/gpt-terra/solution.py",
      "fix": {
        "passed": 260,
        "perf": "1/5",
        "description": "`\"!=\", 4` заменено на `\"!=\": 4` в словаре приоритетов"
      },
      "excluded": "Код не импортируется из-за опечатки в словаре приоритетов операторов: `\"!=\", 4` вместо `\"!=\": 4`. Это ошибка самой модели. С исправлением одного символа код проходит 260 тестов из 464 и 1 замер скорости из 5, дальше ломается проверка зарезервированных имён.",
      "verdict": "0 из 464 из-за `SyntaxError`: в словаре стоит запятая вместо двоеточия. После исправления код проходит 260 тестов. 173 запроса падают на собственной проверке модели «reserved name», а JOIN написан без хеширования, поэтому прошёл только 1 замер скорости из 5. Прогон занял 6,5 минуты и 18 тысяч токенов. На этой задаче Terra заметно слабее GPT-6.1 Sol."
    },
    {
      "id": "opusmax",
      "name": "Claude Opus 5.5 (effort max)",
      "vendor": "Anthropic",
      "model": "claude-opus-5-5",
      "access": "партнёрский шлюз, нативный `/v1/messages`, `thinking: adaptive`, `effort: max`",
      "max_tokens": 128000,
      "answer": "answers/opusmax.json",
      "grade": "grades/opusmax.txt",
      "solution": "solutions/opusmax/solution.py",
      "verdict": "274 теста из 464 и 1 замер из 5. Адаптивное мышление даже на `max` решило не думать: токенов рассуждения ноль, код пошёл с 4-й секунды, прогон занял 2,5 минуты. В части запросов не находятся колонки с алиасом таблицы (`Column not found: e.dept_id`), не работает ORDER BY по колонке не из SELECT, а JOIN сделан вложенными циклами и не укладывается в лимит скорости. Ошибок в одну строку нет, просто код менее тщательный."
    },
    {
      "id": "opusmsg",
      "name": "Claude Opus 5.5 (effort high)",
      "vendor": "Anthropic",
      "model": "claude-opus-5-5",
      "access": "партнёрский шлюз, нативный `/v1/messages`, `thinking: adaptive`, `effort: high`",
      "max_tokens": 128000,
      "answer": "answers/opusmsg.json",
      "grade": "grades/opusmsg.txt",
      "solution": "solutions/opusmsg/solution.py",
      "fix": {
        "passed": 24,
        "perf": "1/5",
        "description": "`consume('IDENT')` сравнивает тип токена"
      },
      "verdict": "8 тестов из 464. Токенов рассуждения ноль, прогон занял 2 минуты, и в коде **ровно та же ошибка**, что в прогоне через chat: `consume('IDENT')` сравнивает значение токена со словом «IDENT». Сам код при этом другой, то есть кэша не было. Значит, это устойчивая привычка модели. С правкой код проходит лишь 24 теста, дальше ломаются другие места."
    },
    {
      "id": "opusapi",
      "name": "Claude Opus 5.5 (шлюз, chat)",
      "vendor": "Anthropic",
      "model": "claude-opus-5-5",
      "access": "партнёрский шлюз, `/v1/chat/completions`, `reasoning_effort: high`",
      "max_tokens": 128000,
      "answer": "answers/opusapi.json",
      "grade": "grades/opusapi.txt",
      "solution": "solutions/opusapi/solution.py",
      "fix": {
        "passed": 278,
        "perf": "1/5",
        "description": "`consume('IDENT')` сравнивает тип токена, а не значение"
      },
      "verdict": "8 тестов из 464, прошли только тесты на ошибки. Метод парсера `consume('IDENT')` сравнивает *значение* токена со словом «IDENT» вместо *типа*, поэтому падает любой `FROM <таблица>`. С правкой одной строки код проходит 278 тестов и 1 замер скорости из 5: JOIN вложенными циклами не укладывается в 60 секунд. Ответ пришёл за 1 мин 47 с, это 14 тысяч токенов, и первый текст появился на 3-й секунде, то есть почти без рассуждения. Через chat/completions шлюза не видно, как передаётся глубина рассуждения, поэтому Opus перезапущен через нативный `/v1/messages`.",
      "reasoning_hidden": true
    },
    {
      "id": "opusagent",
      "name": "Claude Opus 5.5 (агент)",
      "vendor": "Anthropic",
      "model": "claude-opus-5-5",
      "access": "субагент Claude Code, чистый контекст, без запуска кода",
      "max_tokens": null,
      "answer": null,
      "grade": "grades/opusagent.txt",
      "solution": "solutions/opusagent/solution.py",
      "seconds": 1922.8,
      "out_tokens": 138831,
      "reasoning_tokens": 118000,
      "reasoning_estimated": true,
      "verdict": "**464 теста из 464 и 5 замеров из 5, это единственный безупречный результат.** К тому же у него самые быстрые замеры скорости: от 0,04 до 0,08 секунды против 0,15–0,44 у остальных. Агент работал с чистым контекстом и ни разу не запускал код. В его протоколе ровно один вызов, запись файла, и это проверено. Прогон занял 32 минуты и около 139 тысяч токенов, из них примерно 118 тысяч ушло на рассуждение и 21 тысяча на код (оценка по кэшу контекста). От прогонов Opus через API (от 8 до 274 тестов) его отличает глубина размышления. В Claude Code модель работает с высоким effort и думает долго, а через API с адаптивным мышлением на этой задаче не думала совсем."
    },
    {
      "id": "opusagentmax",
      "name": "Claude Opus 5.5 (агент, effort max)",
      "vendor": "Anthropic",
      "model": "claude-opus-5-5",
      "access": "субагент Claude Code, `effort: max`, чистый контекст, без запуска кода",
      "max_tokens": null,
      "answer": null,
      "grade": "grades/opusagentmax.txt",
      "solution": "solutions/opusagentmax/solution.py",
      "seconds": 3288.8,
      "out_tokens": 379400,
      "reasoning_tokens": 368600,
      "reasoning_estimated": true,
      "verdict": "464 теста из 464 и 5 замеров из 5, все замеры от 0,03 до 0,06 секунды, это быстрее, чем у агента с уровнем по умолчанию. Думал 55 минут и около 370 тысяч токенов, втрое больше обычного агента, а код вышел самым длинным, 1390 строк. Opus через API на том же `effort: max` не рассуждал вовсе и прошёл 274 теста. Протокол соблюдён: одно чтение задания и одна запись решения."
    },
    {
      "id": "gemini",
      "name": "Gemini 3.8 Flash",
      "vendor": "Google",
      "model": "gemini-3.8-flash",
      "access": "партнёрский шлюз",
      "max_tokens": 128000,
      "answer": "answers/gemini.json",
      "grade": "grades/gemini.txt",
      "solution": "solutions/gemini/solution.py",
      "verdict": "0 из 464. Ответ пришёл за 5 секунд: 624 токена без рассуждения, то есть заготовка, а не решение. Модуль даже не импортируется, потому что флаг `(?i)` стоит в середине регулярного выражения, а Python 3.11+ так не разрешает. Похоже, `reasoning_effort` через шлюз до Gemini не доходит, а нативного эндпоинта Gemini у шлюза нет (404). Включить рассуждение невозможно, поэтому в этом бенчмарке Gemini не показателен.",
      "excluded": "Партнёрский шлюз не включает у Gemini рассуждение ни одним параметром, и модель ответила заготовкой за 5 секунд. Это проблема доступа, а не модели."
    },
    {
      "id": "strata",
      "name": "Strata Q2, лимит 128K",
      "vendor": "локальный ПК",
      "model": "qwen3.8-flash-next-q2_0",
      "access": "Strata на 127.0.0.1:8080",
      "max_tokens": 128000,
      "answer": "answers/strata.json",
      "grade": "grades/strata.txt",
      "solution": "solutions/strata/solution.py",
      "verdict": "32 теста из 464 и ни одного замера скорости. Прошли только тесты на ошибки и простые запросы без `t.col`. С лимитом 128K модель уложилась: 35 минут, около 111 тысяч токенов, из них примерно 97 тысяч на рассуждение (сервер не отдаёт разбивку, это оценка по длине текста), 1941 строка кода. Но токенайзер сломан в основе. Точку в `e.id` он принимает за начало числа, и на этом падает 401 тест, а операторы `.`, `=` в части позиций и `%` он не знает вовсе. После правки двух строк результат тот же, 32 теста, то есть ошибка не в одной строке. Для локальной модели в квантовании Q2 это честная попытка, но до облачных моделей ей далеко."
    },
    {
      "id": "strata-64k",
      "name": "Strata Q2, лимит 64K",
      "vendor": "локальный ПК",
      "model": "qwen3.8-flash-next-q2_0",
      "access": "Strata на 127.0.0.1:8080",
      "max_tokens": 64000,
      "answer": "answers/strata-64k.json",
      "grade": "grades/strata-64k.txt",
      "solution": "solutions/strata-64k/solution.py",
      "verdict": "0 из 464. Модель упёрлась в лимит 64K и оборвала код на 1931-й строке, потратив 48 тысяч токенов на рассуждение и 14 тысяч на код. Модуль не импортируется.",
      "excluded": "Наш заниженный лимит 64K оборвал код на середине. Прогон заменён запуском с лимитом 128K."
    },
    {
      "id": "grok",
      "name": "Grok 4.7",
      "vendor": "xAI",
      "model": "grok-4.7",
      "reasoning_hidden": true,
      "access": "партнёрский шлюз, `reasoning_effort: high`",
      "max_tokens": 128000,
      "answer": "answers/grok.json",
      "grade": null,
      "solution": null,
      "excluded": "Партнёрский шлюз каждый раз обрывал поток посреди рассуждения, и модель не успевала выдать ни строки кода. Это проблема доступа, а не модели. Grok стоит проверить через прямой API xAI. Три попытки оборвались на 383-й, 652-й и 252-й секунде.",
      "verdict": "Ответа нет: три попытки оборвались на стороне партнёрского шлюза на 383-й, 652-й и 252-й секунде, ни одна не дошла до кода."
    }
  ],
  "files": [
    [
      "README.md",
      "отчёт в формате Markdown"
    ],
    [
      "report.html",
      "страница отчёта с графиками, тёмной темой и подсказками"
    ],
    [
      "bench.json",
      "метаданные: участники, условия, нюансы и выводы, из них собирается отчёт"
    ],
    [
      "task/task.md",
      "задание, которое получили модели"
    ],
    [
      "harness/test_sql.py",
      "скрытые тесты, эталоном служит SQLite"
    ],
    [
      "harness/stream.py",
      "запросы к API моделей в потоковом режиме"
    ],
    [
      "harness/grade.py",
      "извлечение кода из ответа и прогон тестов"
    ],
    [
      "answers/<id>.json",
      "ответ модели целиком: код, рассуждение, токены и время"
    ],
    [
      "solutions/<id>/solution.py",
      "код, который написала модель; в папке `<id>-fix` он же с правкой одной строки"
    ],
    [
      "grades/<id>.txt",
      "результаты тестов и список падений"
    ],
    [
      "charts/*.svg",
      "графики для README"
    ],
    [
      "warmup/",
      "разминка, калькулятор выражений"
    ]
  ],
  "headline": "Мини-движок SQL",
  "lede": "Модели пишут SQL-движок на чистом Python. Он должен отвечать так же, как SQLite: с теми же значениями, теми же типами и в том же порядке строк. Ответ каждой модели проверяют 464 скрытых теста и 5 замеров скорости, а эталоном служит настоящий SQLite.",
  "findings": [
    [
      "Безупречно справились двое.",
      "Claude Opus 5.5, запущенный агентом Claude Code, прошёл все 464 теста, а Kimi K3.1 Pro прошёл 460. Оба уложились в лимит скорости во всех пяти замерах. Протокол агента проверен: он ни разу не читал файлы и не запускал код."
    ],
    [
      "Один и тот же Opus 5.5 набирает от 2% до 100%.",
      "Всё решает глубина размышления. Агентом он думал около 118 тысяч токенов. Через API с адаптивным мышлением модель на этой задаче не думала совсем, даже на effort max, и прошла от 8 до 274 тестов."
    ],
    [
      "Четыре модели из шести в рейтинге споткнулись об одну строку.",
      "Это DeepSeek Flash (регистр имён функций), GPT-6.1 Sol (`COUNT(*)`), Qwen3.8-Max (`CASE WHEN`) и Opus через API (сравнение токенов). С правкой Qwen проходит 462 теста, GPT 445, DeepSeek Flash 431. Архитектура у них сильная, подвела невнимательность. GPT-6.1 Terra и DeepSeek V4 Pro и вовсе сдали код с синтаксической ошибкой."
    ],
    [
      "Долгое размышление не гарантирует кода.",
      "GLM 5.3 потратил на рассуждение весь лимит API в 131 тысячу токенов и не написал ни строки, поэтому его прогон вне рейтинга. Qwen думал 47 минут и написал почти идеальный код с одной опечаткой."
    ],
    [
      "Локальной модели пока далеко до облачных.",
      "Strata (Qwen3.8-Flash-Next в квантовании Q2 на домашнем ПК) с лимитом 128K дописала код до конца, но её токенайзер сломан в основе. Итог 32 теста из 464."
    ]
  ]
}