Hacker News Digest

В середине 90‑х CD‑ROM‑диск стал главным «витриной» для новых игр: 640 MiB позволяли хранить 640×480‑фото с палитрой из 256 цветов, звук VOC и даже короткие видео‑фрагменты в Video For Windows – 12 fps, 240×179 px, длительностью несколько секунд.

Игры‑примеры, такие как The 7th Guest, Wing Commander III и Phantasmagoria, уже использовали FMV и качественную музыку, а Джон Кармак предвидел, что CD‑версии будут полны «цифрового голоса и видео».

В 1996 июне id Software выпустила Quake на CD‑ROM, обещая добавить к ней зашифрованные версии остальных игр компании. Идея была проста: избавиться от посредников, дать возможность покупать полную версию по телефону и кредитной карте.

Но уже через 39 дней хакерская группа GNOMON опубликовала Quakecrk.zip с QCRACK.EXE, позволяющим раскрыть все игры. Попытка id Software избавиться от розничных продаж через 800‑номер оказалась провальной: игроки сразу взламывали shareware, а система заказа превратилась в хаос, оставив в складских помещениях почти 150 000 нелибо распроданных дисков.

Запомните: CD‑ROM‑диск Quake стал последним крупным «мультимедийным» экспериментом, где ёмкость превысила потребности разработчиков, а попытка монетизации через шифрование обернулась быстрым взломом и коммерческим провалом.

Саундтрек Nine Inch Nails к Doom был единственным официальным аудио-релизом до винилового издания 2020 года; первый трек (data track) звучал плохо. Кряк QCRACK работал быстро и эффективно — его использовали десятилетиями, особенно подростки, не могущие позволить себе полную версию. Файлы копировались из директории ID1. Защита id Software была технически наивна: взлом в 90-х сводился к замене jnz на jz в бинарнике, что делало её тривиальной для групп вроде GNOMON. Некоторые считают это ошибкой, стоившей миллионов, а не маркетинговым ходом — бизнес не верил в эффективность защиты, а разработчики просто не сопротивлялись потерям. QCRACK мог разблокировать Final Doom через флаг `-g` с кодовым именем, так как стандартный ключ sku.17 не работал. «SOURCE CODE» при звонке для разблокировки не влиял на генерацию ключа — он служил для начисления комиссий дистрибьюторам (CompUSA, BestBuy и др.). Термин «zero-day» изначально означал взлом в день выхода, позже сменив смысл на уязвимости. Игра Phantasmagoria имела проблемы с некоторыми приводами (например, Mitsumi), вызывая заикание FMV — требовался возврат в магазин. Стоимость игры в 1996 году ($55) эквивалентна $116 сегодня, что объясняет популярность shareware. Пользователи ностальгируют по CompUSA: качественная упаковка, характерное освещение, контрастирующее с современными стандартами.

GPT-5.6 Sol — флагманская модель OpenAI из серии GPT-5.6, ориентированная на сложное рассуждение, программирование и агентные сценарии. Особенно эффективна в цепочках команд, длительных задачах и работе с командной строкой. В рамках ограниченного предложения сейчас доступна со скидкой 50 % — ввод $2,50, вывод $15 за миллион токенов, контекст до 1 млн токенов, актуальна с 9 июля 2026 года, база знаний обновлена до февраля 2026 года.

Модель размещается на нескольких провайдерах, а OpenRouter автоматически выбирает оптимальный вариант: Balanced — сочетание цены и скорости, Nitro — максимум быстродействия, Exacto — высокая точность вызова инструментов. Средняя фактическая стоимость составляет $0,87 ввода и $20,58 вывода за миллион токенов благодаря кэшированию и скидкам. В сравнении с другими провайдерами OpenAI предлагает лучшую комбинацию точности (GPQA Diamond ≈ 91 %) и скорости (латентность ≈ 3,6 с), при этом сохраняет высокую доступность 99,17 %. Эти цифры делают GPT-5.6 Sol привлекательным выбором для разработчиков, нуждающихся в надёжном и экономичном решении для сложных задач.

Скидка 50% на GPT-5.6 Sol доступна только через OpenRouter (вероятно, через Flex-тариф), не в официальной документации OpenAI. Пользователи отмечают, что Sol переусложняет простые задачи (например, превращая список дел в эссе), работает медленнее (32 токена/сек) и проигрывает предшественникам в скорости, но эффективен в сложных агентных сценариях. Конкуренция со стороны Kimi K3 и DeepSeek v4 Flash вынуждает снижать цены — Kimi K3 конкурирует с Sol по качеству при меньшей цене, DeepSeek вытесняет Gemini. Подписки Pro/Plus остаются выгоднее API даже со скидкой. Некоторые считают Sol регрессией, другие — прогрессом в коде и рассуждениях. Промпты для Claude не работают на Sol из-за различий в логике. Первоначальная цена Sol, вероятно, имела высокую маржу, позволяющую снизить цену вдвое. Скидка недоступна при включённом ZDR на OpenRouter. Действие OpenRouter связано с приобретением Stripe.

AI;DR (AI; didn’t read) — это реакция на наводнение AI‑содержанием: если текст не прошёл ручную проверку, его игнорируют. Автор делится личным «физическим» откликом — сутулившееся плечо, лёгкий судорожный моргание — когда видит «чистый» вывод нейросети. Он подчёркивает, что в Q3 2026 использование ИИ уже норма, но требует редактирования и личного отношения к материалу.

Ключевой факт: в соцсетях появился термин AI;DR как аналог TL;DR, но для отсева «AI‑отходов». Цитата: «Если ты не устал от проверки — я не буду читать». Автор настоятельно советует ставить человеческий контроль над любой коммуникацией, где важна репутация и смысл.

AI-генерируемый контент вызывает отторжение не из-за качества, а из-за отсутствия человеческой ответственности, усилий и прозрачности — особенно когда он заменяет личное участие в коммуникации. Люди воспринимают его как интеллектуальную лень: автор избегает ответственности за формулировку мысли. Комментарии, отчёты, коммит-сообщения и ответы на ревью, сгенерированные ИИ, часто шаблонны, избыточны, не содержат реального опыта и не решают конкретных проблем — их игнорируют как пустую формальность. В поддержке клиентов это снижает лояльность: пользователи ждут понимания, а не фраз из шаблонов. Даже качественный AI-текст воспринимается как «фальшивый» из-за переиспользования фраз, формальности и отсутствия личного голоса. Если человек не может объяснить или ответить на вопросы по тексту, который представил как свой — это сигнал, что он его не создавал, и это подрывает доверие, независимо от стиля. Лучшая альтернатива — отправлять не результат ИИ, а исходный промпт: он содержит реальную мысль автора, а не флюиды модели. Используйте ИИ только для черновиков, но всегда редактируйте — иначе вы становитесь посредником, разрушая доверие. Не заменяйте ИИ личным общением: если не хотите, чтобы кто-то читал ваш текст — не отправляйте его; если хотите — докажите, что вложили в него мысль. В некоторых компаниях уже введены запреты на генерацию текста для людей — признак перехода от эксперимента к регулированию. Спор: некоторые считают, что если текст полезен и хорошо написан, его происхождение не важно — как и у человеческого контента. Спор: текущая «шероховатость» ИИ может быть временной — будущие модели могут стать сжатее и глубже, чем люди.

Код теперь можно размещать напрямую в Cursor через новую функцию Origin — early‑beta‑режим для платных пользователей. В появившемся Codebase‑разделе можно создать репозиторий, задать ему название (URL будет выглядеть как cursor.com/codebase/название), установить CLI и начать пушить локальный проект. Синхронизация с GitHub позволяет держать репозитории как на GitHub, так и в Origin, при этом выбирая, какие из них синхронизировать, и отключать их в любой момент.

Pull‑requests работают в обе стороны: комментарии и реакции в Cursor мгновенно отражаются в GitHub и обратно. В каждом репозитории доступны встроенные агенты, которые могут отвечать на вопросы о коде, менять PR‑ы и пушить ветки. Интеграции с Vercel, Depot и Buildkite уже готовы: через Apps‑таб можно привязать Vercel для preview‑деплоя каждого PR, а Depot и Buildkite — для запуска CI‑pipeline, включая GitHub Actions. Настройки репозитория позволяют проверять статус синхронизации, управлять доступом и подключать приложения.

Запомните: название репозитория становится частью URL, а синхронизация происходит в реальном времени, сохраняя GitHub как источник истины. Сейчас Origin доступен в early‑beta для всех платных планов, кроме компаний, которые явно отключили его. Начать работу можно сразу в интерфейсе Cursor.

Пользователи отвергают Origin как GitHub-альтернативу из-за связи с Илоном Маском и опасений, что код будет использоваться для обучения Grok. Предпочтение отдается децентрализованным решениям (Radicle, Forgejo, SourceHut, Codeberg, Tangled) или self-hosted Git — как более безопасным для приватности. Origin ограничен синхронизацией с GitHub и не предлагает инноваций в агентных рабочих процессах, что вызывает критику как «GitHub clone». Технические недостатки — высокий расход CPU и требование SMS-верификации — снижают доверие. Споры идут о природе рисков: одни считают проблему в росте кода из-за AI, другие — в принудительном сборе данных Cursor для обучения моделей. Эксперты полагают, что Cursor ориентирован не на хостинг, а на сбор истории версий и патчей для AI.

AI-ассистент GitHub Copilot случайно внёс критическую уязвимость в репозиторий Snowflake, заменив безопасный шаблон обработки данных на прямую подстановку пользовательского ввода в shell-скрипт. Это позволило любому пользователю GitHub выполнить произвольный код через создание специально оформленного issue — уязвимость была активна всего пять дней, пока Wiz Red Agent, автономный AI-инструмент для поиска уязвимостей, не обнаружил и эксплуатировал её, получив доступ к внутренней системе Jira Snowflake через украденный токен. AI-ревью не заметило опасность, потому что не понимало исторический контекст: ранее использовавшийся метод с env: и jq был специально добавлен для предотвращения инъекций.

Snowflake оперативно устранила уязвимость в тот же день, сменить токен и подтвердила, что Wiz был единственным субъектом доступа. Инцидент стал ярким примером рисков, связанных с автоматизацией кода: AI-агенты могут удалять защищающие паттерны, не понимая их назначения. Важно внедрять «охранительные барьеры», запрещающие AI заменять структурированные парсеры на прямую подстановку строк. Уязвимость не была следствием человеческой ошибки — она родилась в AI-автоисправлении, что ставит под сомнение надёжность текущих практик код-ревью с участием ИИ.

Уязвимость возникла не из-за AI, а из-за слабой проверки изменений, устаревших практик в GitHub Actions и некорректной обработки null-значений в шаблонах, что усиливает риск доверия автоматическим исправлениям без ручного аудита. AI не создаёт новых типов уязвимостей, но ускоряет их появление, делая распространёнными существующие ошибки: интерполяцию пользовательского ввода в shell-командах через ${{ }} без экранирования, использование curl вместо надёжных действий для взаимодействия с Jira (технический долг), и логику с `github.event.pull_request` в событиях `issues` — где `pull_request` всегда null, что возвращает `false` при любом условии. Оригинальный шаблон с `env` + `jq` был безопасен: переменные передавались через окружение, а не вставлялись в shell-строку. AI заменил его на опасную подстановку в одинарные кавычки. Ручной аудит диффов стал узким местом: AI упрощает генерацию изменений, но стоимость проверки не снизилась. Культура ревью «LGTM» без анализа превратила AI в просто замену человека в цепочке, не снизив риски. Советы: — Использовать статический анализ (например, zizmor) в CI для выявления template-injection до слияния. — Минимизировать логику в GitHub Actions, вынося сложные операции в отдельные скрипты. — Избегать интерполяции пользовательского ввода в shell через ${{ }} — использовать env-переменные и jq. — Системы, обрабатывающие пользовательский ввод в shell, должны fail-closed при null-значениях — поведение GitHub Actions по умолчанию небезопасно. AI обнажил системные слабости: устаревшие действия, отсутствие статического анализа и слепое доверие к автоматическим изменениям.

Отключить навязчивый ИИ — частая задача для тех, кто хочет сохранить контроль над своим цифровым пространством. Главное правило: сначала выключайте функции, которые явно нарушают привычный интерфейс — например, в Adobe Acrobat и Reader есть отдельные разделы «Generative AI», где достаточно снять галочку и сохранить настройки. На мобильных платформах, особенно в Android-смартфонах с встроенным Gemini, отключить ассистента можно через настройки приложения «Messages» или раздел «Connected Apps», где отключаются как Gemini, так и «Personal Intelligence». На iOS и macOS Apple Intelligence требует полного отключения в «Apple Intelligence & Siri», а также отключения «Learn from this App» в настройках приложений, даже если основной режим выключен. Для браузеров с встроенным Copilot в Chrome флаг GLIC скрывает все AI-функции, а в Windows можно использовать O&O ShutUp 10 или Win11DeBloat для полного удаления Copilot. Yahoo Mail и Zoom тоже предлагают отключить AI-анализ писем и транскрибирование встреч через меню настроек. Важно помнить: многие сервисы включают AI по умолчанию, поэтому проверяйте параметры регулярно — особенно в Zoom, где новые функции появляются часто. Для полного контроля рекомендуется использовать альтернативные браузеры вроде Zen или Helium, а также следить за обновлениями в библиотечных ресурсах, где публикуются актуальные гайды по сопротивлению нежелательным технологиям.

Пользователи сталкиваются с системным принуждением к ИИ: корпорации намеренно делают его неотделимым от базовых функций, блокируя ключевые возможности при отключении — например, отключение Siri в CarPlay лишает доступа к картам и музыке без телефона. ИИ-функции добавляются не для улучшения опыта, а для привлечения инвестиций, несмотря на рост эксплуатационных расходов и отсутствие реальной потребности — как в PDF-редакторах Adobe. Для отключения ИИ: — В Google добавляйте `udm=14` или фильтр `-fuck` для подавления суммаризации; — Используйте uBlock Origin и Element Hider для скрытия AI-элементов в Google, Amazon и других сайтах; — В Chrome — расширение Adios Alexa for Shopping для блокировки всплывающих окон Alexa; — На Mac — Wairy.app для аудита и отмены разрешений (частично заблокирован за платой); — Переход на Linux устраняет навязчивый ИИ из macOS и Windows; — Альтернативные браузеры Zen и Helium (на базе Firefox и Chromium) предлагают чистый интерфейс без ИИ-элементов. Самый эффективный способ — отказ от продуктов, где ИИ нельзя отключить, что упрощает цифровую жизнь. NoToAI.org — открытый ресурс сообщества для отслеживания способов отключения ИИ.

DuckDB v2.0, codenamed «Cyanoptera», выходит этим осенью и представляет набор кардинальных изменений: серверный режим через расширение quack и оператор CONNECT, новый SQL‑парсер, переработанную СУБД‑структуру, асинхронный ввод‑вывод и тип VARIANT. Серверный режим позволяет любой процессу DuckDB обслуживать базы данных по сети, а клиентские запросы можно отправлять напрямую на удалённый PostgreSQL или MySQL без копирования данных. Кроме того, в v2.0 введены триггеры, более строгая типизация и поддержка транзакций в многопользовательском режиме, что делает DuckDB конкурентоспособным для аналитических и даже транзакционных нагрузок.

Ключевые нововведения: серверный режим (quack + CONNECT), новый тип VARIANT для гибкого хранения схем, асинхронный I/O ускоряющий запросы, новая хранилище‑формат с улучшенной компрессией, а также новый C‑API и небольшие, но важные ломающие изменения (переход на lambda‑синтаксис). В статье также упоминается создание DuckDB Foundation Advisory Board, который будет влиять на дальнейшее развитие проекта. Эти изменения формируют фундамент для «года DuckDB как сервера» и открывают путь к масштабным распределённым решениям.

DuckDB v2.0 трансформируется из локального аналитического процессора в основу облачной аналитической инфраструктуры, что подтверждено использованием в продакшене: многотенантные системы с данными 5–150 ГБ на тенанта, обработка миллионов Parquet-файлов, замена серверных решений. Он превосходит PostgreSQL и MariaDB в OLAP-задачах благодаря колоночному хранению и встроенному процессу, но уступает в многопользовательской конкурентности без Quack. Поддерживает обработку данных, превышающих ОЗУ, на потребительском оборудовании, снижая требования к инфраструктуре. Асинхронный ввод-вывод в v2.0 критически важен для масштабной работы с Parquet и обеспечивает значительный прирост производительности. WASM-сборка весит ~10 МБ, пригодна для браузера; расширения не увеличивают размер бинарников существенно. Заменяет сложные ETL-пайплайны, позволяя объединять запросы к CSV, Parquet и базам данных в одном SQL-интерфейсе. Стандартная практика — анализ лог-файлов (например, Nginx access.log) на диске. Рекомендации: - Использовать Arc для ускорения сканирования через pruning при работе с Parquet. - Для расширений применять официальный шаблон extension-template. - Ручная настройка memory_limit необходима для предотвращения убийства OOM-killerом. - При аналитике в браузере кастомизировать Emscripten-сборку — она оптимизирована, но требует настройки. - Документировать новый PEG-парсер — его детали критичны для совместимости. Quack (серверный режим) и CONNECT к PostgreSQL делают DuckDB гибридным инструментом, интегрируемым с OLTP-системами. Споры: - Некоторые считают DuckDB неподходящим для распределённой обработки против AWS Athena с Trino, но Quack и DuckLake меняют эту динамику. - Одни выражают разочарование, что DuckDB не переписан на Zig, другие не видят в этом проблемы.

GitHub.com переживает массовый сбой: более 20 % запросов к веб‑интерфейсу и API возвращают ошибки, а скачивание архивов и исходных файлов репозиториев падает до 50 %. Самые критичные проблемы — с доступом к Pull Requests, Issues, Actions, Pages, Webhooks и Copilot, а также с аутентификацией через SAML, OIDC, SCIM и Team Sync.

Ключевой факт: почти половина попыток загрузки кода не проходит, что делает текущие разработки почти невозможными. Команда GitHub уже работает над компенсацией и публикует регулярные обновления о ходе расследования.

Обсуждение подтверждает, что сбои GitHub перестали быть редкими и стали системной проблемой, вызывающей массовый переход на альтернативы, включая самоприюты вроде Gitea и Forgejo, а также ставящую под сомнение устойчивость централизованной платформы как критической инфраструктуры разработки.

• Многие участники отмечают, что частота сбоев GitHub достигла уровня, при котором платформа больше не может считаться надежной основой для CI/CD и критичных рабочих процессов.

• Самоприюты на базе Gitea, Forgejo и Woodpecker CI активно используются в продакшене как альтернатива GitHub, особенно среди тех, кто ценит контроль и отказ от зависимости от облачных провайдеров.

• Проблемы GitHub не связаны исключительно с ростом трафика от LLM — ключевым фактором называется плохое управление и отсутствие инвестиций в масштабируемость инфраструктуры.

• Совет: Рекомендуется всегда иметь зеркало репозитория в виде bare repo, чтобы обеспечить доступ к коду во время сбоев GitHub, даже если веб-интерфейс недоступен.

• Совет: Для критичных операций во время сбоев рекомендуется использовать gh CLI для одобрения и слияния pull requests, так как он может работать, когда веб-интерфейс недоступен.

• Совет: Самоприюты с Gitea и Woodpecker CI могут работать при затратах около $30/месяц на инфраструктуру, что дешевле, чем стоимость GitHub для команды, и обеспечивает полный контроль.

• Спор: Одни считают, что рост трафика от LLM — основная причина сбоев, другие настаивают, что это следствие управленческих ошибок Microsoft, а не нагрузки, приводя в доказательство исторические данные об отказах.

• Спор: Некоторые утверждают, что GitHub стал «too big to fail» и теперь не несет реальной ответственности за сбои, тогда как другие считают, что пользователи должны сами искать альтернативы, а не ждать улучшений.

• Состояние GitHub на статус-странице часто не отражает реальную доступность — пользователи фиксируют сбои, которых нет в логах, что подрывает доверие к официальной отчетности.

• Совет: Предлагается создать самоприют с полной синхронизацией PR и Issues между локальным инстансом и GitHub, чтобы работать офлайн и синхронизировать изменения при восстановлении сервиса.

• Ценность GitHub — не в git, а в PR, Issues, Actions и системе идентификации, и заменить эту экосистему сложнее, чем просто сменить хостинг.

• Совет: Для управления Issues без GitHub предлагается использовать простую структуру директорий в репозитории с файлами issue.md, что позволяет обойтись без веб-интерфейса и использовать стандартные git-команды.

• Частые сбои GitHub вызывают рост недоверия и моральное выгорание у разработчиков, что приводит к эмоциональному отторжению платформы, даже если она технически удобна.

• Отсутствие публичных пост-мортемов после регулярных сбоев усиливает подозрения в системной небрежности со стороны Microsoft и отсутствии прозрачности в управлении инфраструктурой.

• Совет: Пользователи рекомендуют пересмотреть политику использования GitHub как единственного источника правды — внедрять дублирование репозиториев и CI/CD пайплайнов на альтернативных платформах для устойчивости.

This is starting to feel like Twitter. For a variety of reasons, we had a centralized place where everyone of a particular set of persuasions could connect, and this had outsize benefits for the community as a whole. That place is becoming untenable, and with the loss of goodwill and stability, the… — @Arubis

GitHub.com переживает деградацию доступности API — запросы обрабатываются медленнее, часть функций временно недоступна.
Ключевые механизмы оповещения: подписка на email‑уведомления о создании, обновлении и решении инцидентов, SMS‑уведомления о создании и решении, а также webhook‑уведомления о любых изменениях статуса.
Подписка требует подтверждения OTP, согласие с политикой конфиденциальности и подтверждения условий использования Atlassian.
Запомните: API‑проблемы могут затронуть все сервисы GitHub, а подписка гарантирует мгновенные уведомления о любых изменениях статуса.

Частые сбои GitHub подрывают доверие к платформе как к критически важной инфраструктуре для open source и CI/CD, вызывая активный поиск альтернатив. Большинство согласны: GitHub больше не обеспечивает необходимую надёжность. Основные причины — рост трафика из-за LLM-генерируемого кода и плохое управление со стороны Microsoft, а не только технические ограничения. Споры идут о том, являются ли сбои следствием роста или исключительно результатом пренебрежения SLA. Некоторые предлагают вводить тарифы для бесплатных пользователей, но другие считают, что это не решит проблему без масштабирования инфраструктуры. Рекомендуется: — Всегда иметь зеркало репозитория (например, bare repo) для доступа во время простоя. — Рассмотреть самоприютные решения: Gitea + Woodpecker CI (до $30/мес) или Forgejo — они стабильны, дешевле, с полным контролем и быстрой миграцией (часы). — Поддерживать альтернативы: GitLab Free Tier (репозитории, PR, Issues, CI, Pages — надёжнее GitHub, хоть и без SLA), Codeberg, Forgejo, и звездить проекты на них. — Заменить GitHub Issues на директорию `Issues/` с файлами `issue.md`. — Отделять CI от хостинга репозиториев, чтобы снизить точки отказа. — Для замены Copilot доступны альтернативы, но ни одна не достигает его уровня интеграции в VS Code и CLI. По опыту @rglullis, самоприютная инфраструктура (Gitea + Woodpecker + Docker + PIPY) с x86/ARM раннерами работает стабильно и дешевле платных тарифов GitHub. Сбои становятся системными: статус-страница не отражает реальных проблем, исторические данные о простоях скрываются — это подрывает доверие к отчётности. GitHub утратил статус центрального узла open source; сообщество рассеивается, как с Twitter, но без чёткой альтернативы.

GPT‑5.6 Sol стал лучшей визуальной моделью, которую OpenAI представила до сих пор. В тестах на нашем предстоящем VLM‑бенчмарке, охватывающем детекцию, подсчёт, OCR и извлечение данных, Sol показал резкий рост: mAP@50 вырос с 13,8 у GPT‑5.5 до 46,2, а Terra и Luna набрали 44,7 и 43,3 соответственно. Это превратило объектное распознавание из слабого места в практичную возможность, особенно заметную в сложных сценах с множеством похожих предметов — например, таблеток, яиц или монет.

Пара ярких фактов: Sol обрабатывает документные макеты, выделяя заголовки, таблицы, подписи и подписи, а также умеет работать с плотными сценами, хотя иногда генерирует коробки в случайных местах, не совпадающих с реальными объектами. Стоимость и скорость тоже важны: Sol стоит около 2,5 ¢ за изображение и тратит ~10 секунд, Terra — ~6 секунд и ~1 ¢, а Luna — чуть более 5 секунд и < 0,5 ¢. При этом Gemini 3.5 Flash дешевле (0,8 ¢) и лидирует по точности при массовом использовании, делая его более выгодным для больших потоков данных.

GPT-5.6 Sol демонстрирует прогресс в визуальных задачах, но его практическая применимость ограничена высокой стоимостью, низкой скоростью (в 25–50 раз медленнее специализированных моделей) и ненадёжностью в production-сценариях. Gemini 3.5 Flash превосходит его по всем метрикам, кроме OCR, при трёхкратно меньшей цене, делая его предпочтительным для детекции и подсчёта. Локальные альтернативы — Qwen3.8 и MiniCPM-V-4.6 (0.8B) — показывают сопоставимую или лучшую производительность, особенно при требованиях к скорости, экономичности и работе на потребительском оборудовании. Подсчёт объектов, например таблеток, решается эффективнее классическими CV-методами (OpenCV), что ставит под сомнение ценность Sol в таких задачах. Sol ошибочно интерпретирует геометрию изображений (например, поворот монет на 90°) и галлюцинирует содержимое чёрных изображений, что указывает на фундаментальные проблемы понимания реальности. Он не распознаёт надёжно редкие или выцветшие кириллические надписи, несмотря на высокую точность в других OCR-задачах. Для распознавания нотной записи Sol показал неожиданно высокую точность, возможно, благодаря способности к сложному пространственному анализу. Для анализа изображений и кода лучше подходят модели OpenAI (Terra, Luna). Для обработки старых документов рекомендуется предварительная обработка изображений через Python. В задачах с низкой задержкой (например, робототехника в аптеках) Sol неприменим. Использование нескольких специализированных моделей (Fable, Gemini, Sol) по задачам эффективнее, чем полагаться на одну. Визуальные бенчмарки не учитывают глубину восприятия — отсутствие бинокулярных данных делает сравнение неполным, особенно для автономного вождения.