Короткий ответ
На 25 октября 2026 мы не знаем, окажутся ли запланированные изменения лучше текущей архитектуры DSHREM. Это честная позиция, и страница написана так, чтобы её можно было проверить, а не просто заявить. Здесь зафиксирована точка старта, перечислено неизвестное, названо то, что проверяется, и заранее записано, какой результат признает каждое изменение бесполезным.
Запись держится на двух правилах. Число появляется только с источником и датой. Неизмеренная величина пишется как неизвестная, а не как ноль. Где утверждение является прогнозом, оно помечено прогнозом и соединено с наблюдением, которое его опровергнет.
Что измерено 25 октября 2026
Зарегистрировано семь самостоятельных сервисных аккаунтов; публичный домен открыт 18 октября 2026. Это счёт аккаунтов, а не людей, и он исключает помеченные и выделенные QA-аккаунты. Расширение редактора выпущено версией 0.10.9 с успешным прогоном CI. Это счётчики принятия и выпуска.
Датированная квитанция проверки runtime от 24 октября фиксирует 61 пройденную регрессию runtime, 32 проверки знаний, 4 проверки авторизованного завершения в браузере, 6 из 6 публичных HTTPS-сценариев и 821 проверку редактора. Та же квитанция фиксирует 7 сверенных платных вызовов координатора на дешёвом маршруте при наблюдаемом расходе провайдера 0.0026731264 USD и нулевой незакрытой сумме. Первые публично квитированные платные вызовы 18 октября — две попытки на 0.00016842 USD; один черновик был отклонён заранее объявленным белым списком, принятую правку внесли вручную.
Эти числа описывают сервис, который работает, покрыт проверками и учтён. Они не описывают, насколько быстро он работает, сколько стоит завершённая задача по коду и лучше ли один редактор другого. Смешать эти две вещи — именно та ошибка, ради предотвращения которой существует запись.
Что не измерено
На эту дату не измерены: стоимость одной успешной задачи по коду, задержка p50 и p95, входные и выходные токены на задачу, доля попаданий в кеш по данным провайдера, пиковая резидентная память на задачу, секунды CPU на задачу, частота ошибок по классам задач, платные повторы на принятую задачу и какое-либо преимущество одного редактора над другим.
Машиночитаемый список опубликован как baseline JSON вместе с этой статьёй и подчиняется тому же правилу исправлений. Отсутствующее значение там означает ровно это: его пока никто не измерил, и из молчания никакого вывода не делается.
Как определяется каждая метрика
Успешная задача — та, чья приёмка была объявлена до запуска, проходит на полученном артефакте и оставляет записанную квитанцию. Задача, которая «выглядит хорошо» без объявленной проверки, считается непринятой. Стоимость успешной задачи делит весь расход провайдера и сервиса на задачу, включая неудачные попытки, на число принятых задач в наборе. Определение выбрано так, чтобы подход не мог выглядеть дешёвым за счёт частых провалов.
Задержка — время от первого запроса до итогового артефакта, включая повторы и ожидание модели, измеренное на клиенте, чтобы время провайдера не исчезло. Доля попаданий в кеш — сообщённая провайдером часть входных токенов из кеша; если провайдер её не сообщает, доля неизвестна и экономия не заявляется. Пиковая память и секунды CPU читаются из контрольной группы хоста, пока задача выполняется одна: совместное измерение на занятом хосте даёт декоративные цифры.
Повторы — платные попытки сверх первой для той же задачи; они считаются, а не скрываются. Частота ошибок делится по классам задач, потому что один агрегат скрывает разницу между неудавшимся переименованием и неудавшимся рефакторингом нескольких файлов.
Какие изменения проверяются
Проверяемая программа включает шесть технических изменений. Первое — семантическая навигация по коду через языковой сервер, с переиспользованием существующего эквивалента до добавления новой зависимости. Второе — компактная карта репозитория, которая заменяет контекст целыми файлами структурной сводкой. Третье — структурная правка кода вместо правки свободным текстом. Четвёртое — кеширование промпта вместе со сжатием контекста. Пятое — загрузка инструментов по требованию вместо длинного каталога в каждом запросе. Шестое — аудит маршрутизации и эскалации, включая стоимость повторных запросов и правило, отправляющее работу более дорогой модели.
Ещё три пункта — исследование, а не обязательство. Воспроизводимый benchmark на тридцати реальных задачах. Сравнение с более лёгкими средами агентов, включая вопрос редактора-хоста. И изучение автоматической оптимизации рабочих процессов, которое сначала читают, а потом устанавливают. Локальный вывод моделей в этот раунд не входит: без ускорителя нужно было бы доказать, что полная стоимость с учётом железа, энергии и времени оператора ниже, а такого доказательства пока нет.
Метод зафиксирован заранее. Сначала ищем аналог в своём коде и только потом добавляем библиотеку. Кандидаты тестируются, лучший сохраняется и вводится за флагом функции. Каждое изменение живёт в своей ветке с тестами и коммитом. Ни выкатка в прод, ни слияние в основную линию, ни платная операция не происходят без отдельного разрешения.
Гипотезы и пороги опровержения
H1, навигация по коду: поиск символов и зависимостей сокращает входной контекст на работе с несколькими файлами. Оставляем при снижении входных токенов на принятую задачу не менее чем на 15 процентов без потери качества; убираем при снижении ниже 5 процентов. H2, карта репозитория: компактная структурная сводка заменяет контекст целыми файлами на задачах уровня репозитория. Оставляем при снижении от 20 процентов; убираем ниже 8 процентов. H3, структурная правка: меньше неудачных попыток патча, прежде всего там, где правка затрагивает несколько мест. Оставляем при снижении числа неудач на 20 процентов; убираем ниже 5 процентов.
H4, кеш и сжатие: стоимость падает только там, где префикс действительно переиспользуется. Оставляем, если провайдер сообщает кешированные токены и стоимость задачи снижается на 10 процентов и более; если провайдер кешированных токенов не сообщает, измеренный эффект равен нулю и заявление снимается. H5, инструменты по требованию: меньше входных токенов без роста выбора неверного инструмента. Оставляем при снижении токенов на 10 процентов; убираем при росте неверного выбора. H6, аудит маршрутизации: каждая эскалация к более дорогой модели имеет записанную причину, а повторная одинаковая работа не оплачивается дважды. Оставляем при снижении стоимости на повторных задачах на 20 процентов; убираем, если эскалацию нельзя объяснить.
Гипотеза, которая провалилась, не получает второго, более мягкого порога. Она записывается опровергнутой вместе с измерением, и работа на этом останавливается.
Метод: тридцать задач, две ветви
Benchmark — тридцать реальных задач этого проекта, выбранных и замороженных до измерения кандидатов: десять небольших правок, десять изменений в нескольких файлах, пять починок падающих тестов, пять задач по знаниям или документации с проверяемым результатом. У каждой задачи указаны ревизия репозитория, проверка приёмки и эталонный исход, чтобы поздний читатель мог воспроизвести её, не доверяя автору.
Каждая задача выполняется дважды: на текущей архитектуре и с включённым флагом кандидата, при одинаковых идентификаторах моделей и одинаковом лимите задачи. Порядок чередуется, чтобы тёплый кеш или неудачный час не благоприятствовали одной ветви постоянно. Стоимость читается из журнала учёта по идентификатору задачи, а не из рассказа модели о собственном счёте.
Сравнение публикуется только тогда, когда обе ветви прошли один и тот же набор задач в один день с одинаковыми идентификаторами моделей. Если условие не выполнено, результат помечается как несопоставимый, а не подаётся с процентом.
Контроль и искажающие факторы
Для каждого прогона записываются пять искажающих факторов: изменение цен провайдера, тепло кеша, квота подписки против измеряемого API, нагрузка на общий хост и незаметная смена версии модели. Шестой — сам наблюдатель. Автор изменения сам его и измеряет, и это настоящая предвзятость даже при честном намерении.
Защита процедурная, а не словесная: пороги фиксируются до прогона, сырые артефакты сохраняются, отрицательные результаты публикуются, а прогон, где искажающий фактор не удалось исключить, помечается так в отчёте.
Даты решений и контрольные точки
1 ноября 2026: набор из тридцати задач заморожен, стенд даёт первый базовый прогон. 8 ноября 2026: контрольная точка по навигации по коду и карте репозитория. 24 ноября 2026: решение по структурной правке, кешированию и инструментам по требованию, по одному вердикту на гипотезу. 24 декабря 2026: отчёт до и после, включая сравнение редакторов и список отклонённого. 23 января 2027: пересмотр программы — либо продолжение выживших пунктов, либо закрытие с разбором.
Это даты решений, а не обещания поставки. Дата может пройти с честным вердиктом «не измерено, потому что стенд не был готов»; она не может пройти с придуманным числом.
Чеклист приёмки
Программа принимается, когда каждый пункт либо пройден, либо явно не выполнен с причиной. Набор базовых данных отвечает стабильным дайджестом, и у каждого измерения есть источник и дата. У каждой гипотезы порог зафиксирован до измерения и объявлено правило остановки. Все тридцать задач воспроизводимы из закреплённых ревизий. Каждый платный вызов привязан к идентификатору задачи в журнале. Ни одна платная работа не начинается без объявленного потолка. Итоговый отчёт называет ревизии коммитов и публикует то, что не сработало.
Критерии остановки
Программа останавливается в четырёх случаях. Если на тридцати задачах нет измеренного снижения стоимости успешной задачи, путь роста закрывается и остаются только бесплатные структурные пункты. Если кандидат даёт регрессию качества, которую не удалось починить, его флаг откатывается, а не компенсируется более дешёвой моделью. Если расход неизвестен или бронь не сверена, платная работа замораживается до сверки названным оператором; неизвестное не равно нулю. Если опубликованное утверждение теряет артефакт, утверждение публично снимается на этой странице.
Прогнозы и что их опровергнет
Прогноз по навигации и карте репозитория: входные токены на задачах уровня репозитория снижаются на 15–35 процентов, на правках одного файла эффекта нет. Опровергается, если измеренное снижение ниже 5 процентов или падает качество приёмки. Прогноз по структурной правке: неудачные попытки патча снижаются на 20–40 процентов, прежде всего на правках в нескольких местах; опровергается, если неудачи просто переезжают на более позднюю стадию.
Прогноз по кешу: стоимость снижается на 5–20 процентов только там, где переиспользование префикса реально, и эффект ровно нулевой там, где провайдер не сообщает кешированные токены. Прогноз по инструментам по требованию: входные токены снижаются на 5–15 процентов, с риском неверного выбора инструмента, который сотрёт выигрыш. Цель программы в минус 20–30 процентов стоимости успешной задачи — проверяемая цель, а не обещание, что она будет достигнута.
Два прогноза отрицательные, и это сказано прямо. Эти изменения не должны улучшить p95-задержку: её определяет провайдер, а не наш клиент. Локальный вывод моделей не должен выиграть на хосте без ускорителя, если считать железо, энергию и время оператора. Подтвердившийся отрицательный прогноз — полезный результат, а не провал.
Сравнение редакторов: VSCodium с MCP против расширения VS Code
Частый вопрос: эффективнее ли сборка рабочего пространства для кода внутри VSCodium с локальным MCP-сервером, чем существующее расширение VS Code, работающее через размещённый шлюз. В такой постановке ответить нельзя, потому что меняются сразу две вещи: редактор-хост и транспорт. Разница в стоимости может происходить из любой из них.
Поэтому схема — сравнение два на два на тех же тридцати задачах: VSCodium с локальным сервером, VSCodium с размещённым шлюзом, VS Code с локальным сервером, VS Code с размещённым шлюзом. Одинаковые идентификаторы моделей, одинаковый лимит задачи, чередующийся порядок. Измеряются: стоимость успешной задачи, p50 и p95, время до первой принятой задачи, пиковая память процесса редактора и типы отказов, а не только их число.
Записанный прогноз узкий: стоимость модели должна совпасть, потому что модель одна и та же, а различия должны проявиться во времени настройки, памяти и типах отказов. Прогноз записан здесь, чтобы его можно было опровергнуть измерением, а не защищать после.
Угрозы достоверности
Выборка мала: тридцать задач, один оператор, молодой сервис с семью зарегистрированными аккаунтами. Задачи выбирал тот же человек, который делает улучшение, поэтому они проще реального распределения. Провайдеры меняют цены и версии моделей, не спрашивая. Общий хост добавляет шум. Результат, измеренный в ноябре, может не сохраниться в феврале.
Эти угрозы не снимаются уверенностью. Они ограничиваются заранее объявленными порогами, опубликованными артефактами, отрицательными результатами и закреплённым набором для воспроизведения, и они повторяются в каждом отчёте, чтобы читатель мог верно обесценить числа.
Что публикуется, а что нет
Публикуется: метод, определения метрик, агрегированные счётчики, вердикты, тупики и ревизии за ними. Не публикуется никогда: учётные данные, денежный путь, данные клиентов и личные контакты, а также любое число без артефакта за ним. Непроверяемая цифра не публикуется с оговоркой; она остаётся за скобками, пока её нельзя проверить.
Причина практическая. Опубликованный процент входит в чужие решения. Если его нельзя возвести к наблюдению, он вредит ещё долго после того, как автор занялся другим.
Как обновляется эта запись
Базовая точка не переписывается. Поздние результаты добавляются датированными ревизиями ниже исходного текста, а исправление пишется рядом с исправляемым утверждением. Дата проверки вверху страницы означает, что источники сверены в этот день; она не означает, что что-то улучшилось.
Машиночитаемый спутник — набор базовых данных, опубликованный рядом с этой страницей. В нём те же числа, те же неизвестные и то же правило исправлений, поэтому автоматическому и человеческому читателю нельзя сказать разное.