Context7 — стандарт для доков AI-агента. Я измерил 8 альтернатив и собрал бесплатную связку

• Context7 — дефолтный docs-MCP, но у free-тарифа жёсткий потолок (~1000 запросов/мес, ещё и 60/час). Когда квота исчерпана, сервер молча отдаёт пусто — и агент спокойно пишет по устаревшей памяти. Замечаешь не сразу: код компилируется, просто API уже не тот.

• Не поверил лендингам — прогнал 8 способов на одном токенайзере. Считал ровно то, что влетает в контекст. Победил Ref: 170 токенов на прописку, медиана ответа 525, 100% попаданий. Но он платный.

• Дважды чуть не оболгал инструмент. Context7 CLI показал 79% против 93% — оказалось, я неправильно его вызывал. Локальный @neuledge показал 57% — оказалось, я не собрал пакеты и спотыкался на разборе имён. После фиксов: 93% и 100% при 5 миллисекундах.

• Локальный слой ещё и радикально быстрее. @neuledge отвечает за ~5 мс против ~3000 мс у облачных — в сотни раз. Агент дёргает доки десятки раз за задачу, и эта разница складывается: lookup становится фактически бесплатным по времени, плюс offline и без лимитов запросов.

• Собрал бесплатную связку: @neuledge (локальный L1) + Context7 free (L2-fallback). Локальный слой закрывает собранный стек, free-tier ловит длинный хвост.

• Замерил, переживёт ли связка лимит. По ядру стека — 0% fallback. Новая библиотека уходит в платный слой один раз, после context add переезжает в локальный навсегда. Чтобы упереться в 1000/мес, надо встречать больше тысячи новых либ в месяц и ни одну не добавлять. Так не бывает.

• Собрал миграционный кит — нейтральный промт внедрения (Claude Code / Codex / Cursor), результаты бенчмарка, замер fallback и чек-лист. Ссылка в конце.

---

Полтора года я не трогал свою схему работы с документацией. Был один MCP-сервер — Context7, — и этого хватало: агент перед тем, как писать код, дёргал свежие доки нужной библиотеки и не сочинял сигнатуры из головы. Работает — не трогай. Я и не трогал.

А потом начал ловить странное. Агент пишет валидацию на Zod и ставит z.string().email() — хотя в четвёртой версии это давно z.email(), а старая форма помечена как deprecated. Или собирает кэширование в Next и ведёт себя так, будто на дворе пятнадцатая версия, а у меня в lockfile шестнадцатая с другим поведением use cache. Код компилируется. Тесты, которых на этот кусок ещё нет, ничего не ловят. Всё выглядит нормально — просто API уже не тот.

Я не сразу понял, в чём дело. Грешил на модель, на свой промт, на фазу луны. А оказалось проще и обиднее: у Context7 на free-тарифе кончилась месячная квота. То, что free ограничен — порядка тысячи запросов в месяц плюс потолок 60 в час — давно не секрет, и претензия не к этому. Зацепило другое: сервер в ответ на запрос агента молча отдавал пусто, а агент пожимал плечами и ехал дальше на том, что помнит с обучения. А помнит он мир по состоянию на свой cutoff — то есть с устаревшими сигнатурами.

Вот это меня и зацепило. Не то, что инструмент уткнулся в лимит, — лимит дело житейское. А то, что он промолчал. Явная ошибка — это подарок: видишь её и чинишь. Молчаливая деградация — это худшее, что может случиться с источником истины для агента, потому что ты доверяешь, перепроверять перестаёшь, и брак протекает в код незаметно.

И ведь молчание — даже не самое коварное. Часто агент что-то получает и пишет, но кода и логов столько, что я просто не замечаю, что он взял устаревший путь. А бывает хуже: в принципе не понять, насколько правильно он использовал документацию. Код работает. Но я не знаю, на чём он работает — на новых возможностях библиотеки или на legacy, который ещё не выпилили; на том, что появилось в свежей версии, или по старинке, потому что так помнит модель. И это отравляет доверие ко всему пайплайну: я и так держу в голове десяток нюансов поведения модели, а теперь сверху — ещё и контроль, правильно ли отработал docs-сервер. Это изматывает сильнее, чем кажется.

Почему свежие доки — это вообще не мелочь

Коротко, потому что аудитория и так все всё понимают:) Агент без доступа к актуальной документации генерирует код по своим обучающим данным. Для стабильных вещей это нормально. Для всего, что движется быстро — фреймворки, валидаторы, ORM, UI-киты, — это лотерея: чем свежее релиз, тем выше шанс, что модель уверенно напишет вчерашний день. Документация в контексте — это та страховка, которая ловит разницу между «как было на момент обучения» и «как стало в той версии, что у тебя в lockfile».

Поэтому источник доков для меня — едва ли не самый важный MCP-сервер во всей обвязке. И когда мой дефолт начал подводить молча, я поймал себя на мысли, которую полтора года не задавал: а Context7 — это всё ещё лучший выбор? Когда я его ставил, он был очевидным стандартом. Но с тех пор я его ни с чем не сравнивал — просто пользовался. Самое время проверить, что изменилось на рынке.

Сначала я не поверил лендингам

Первым делом — разведка рынка. Я взял один и тот же исследовательский запрос («чем в середине 2026-го лучше всего кормить документацию AI-агенту, с учётом токенов, свежести, приватности и цены») и прогнал его через две разные модели, в режиме глубокого ресёрча. Намеренно через две, а не одну — чтобы поймать расхождения и не принять галлюцинацию одной модели за карту местности.

Модели слегка разошлись в акцентах. Одна сильнее топила за нативный путь Claude Code — skills плюс локальные доки плюс прямые fetch-команды, — с Context7 как удобным managed-бэкендом для публичных библиотек. Другая, заточенная под профиль «строгая приватность, on-prem», ставила во главу локальные индексаторы — @neuledge/context и подобные, — а облачные сервисы задвигала в fallback. Но в главном обе сошлись, и это совпадение для меня было важнее частностей:

Во-первых, рынок за последний год развернулся от «затащить агенту побольше кусков доков за один вызов» к «показывать ему только следующую релевантную порцию». Тот же принцип, что Anthropic зашила в skills и в отложенную загрузку инструментов: тяжёлое грузится по требованию, а не висит в контексте постоянно. Тут важная оговорка. После того как Claude Code в начале года включил поиск по инструментам с отложенной загрузкой схем, старый «налог» MCP на системный промт — тул-схемы, которые висели в окне всю сессию, — и правда почти исчез. Но это снимает только разовую, статическую часть. Раздувание контекста самими ответами, когда сервер на каждый запрос вываливает в окно килотокены доков, никуда не делось. И вот это, на мой взгляд, и есть главная боль.

Во-вторых — и это главный отрезвляющий вывод — независимых сравнений по качеству docs-grounding практически нет. Почти все красивые проценты на лендингах вендоры написали сами про себя. Самый показательный пример: один сервис рекламирует «90% точности против 65% у Context7». Лезешь в источник этой цифры — а это бенчмарк, который опубликовала та же компания, что продаёт этот сервис. Один прогон, два десятка сценариев, тринадцать звёзд на гитхабе, никем не воспроизведён. Это не значит, что сервис плохой. Это значит, что цифре верить нельзя, пока не проверил сам.

Вот после этого я и решил: рейтинги с чужих лендингов в мусорку, меряю своей линейкой.

Почему токены — мой главный вес

Прежде чем про замер — про то, что я мерил в первую очередь. Сейчас в моде мысль: окно у моделей большое, давно не четыре тысячи токенов, поэтому за расход контекста на MCP и доки можно особо не переживать. Я с этим категорически не согласен и уже разбирал почему — в отдельной статье про деградацию длинного контекста.

Окно действительно не четыре тысячи. У многих моделей в спеке вообще красуется миллион токенов. Только «миллион в характеристиках» и «миллион рабочих» — совсем разные числа. На практике где-то после двухсот тысяч начинается заметная деградация: модель плывёт, теряет нить, путает детали, хуже держит инструкции. А эти двести тысяч ты ещё и получаешь неполными — изрядную часть сразу отъели системный промт, твои инструкции, история диалога, схемы инструментов. То есть реально свободного места под полезную работу — кот наплакал относительно рекламного миллиона. Поэтому каждый лишний килотокен доков в окне бьёт дважды. Это деньги — при десятках тысяч вызовов каждый токен превращается в счёт или съедание подписки. И, что важнее, это ускоренная деградация: ты быстрее добиваешь рабочий потолок, агент к концу сессии тупеет, падает и качество, и скорость.

Вот почему приоритет №1 у меня — токены. Не из жадности, а потому что бережное окно — это более умный и быстрый агент. И поэтому наивный путь «скачать llms.txt и вывалить всё в контекст» для меня не «многовато», а «недопустимо». К цифрам ещё дойдём — они там показательные.

Как я мерил: одна линейка на всех

Главное правило, без которого сравнение превращается в маркетинг: считать всех одним прибором. Я написал гибридный раннер на TypeScript, который дёргает каждого кандидата его родным протоколом — MCP-серверы через официальный MCP SDK, CLI через subprocess, локальную библиотеку in-process, а наивный путь (llms.txt) через сырой fetch. И ловит ровно тот payload, который реально попал бы в контекст агента, а не сырой ответ бэкенда — для MCP это, между прочим, разные вещи.

Токены у всех считаю одним токенайзером — tiktoken o200k_base. Да, абсолют к Claude может гулять процентов на десять-пятнадцать, и точную калибровку под Anthropic я сделать не смог (нет доступа к их счётчику токенов). Но относительное сравнение «кто из них экономнее» при одной линейке — точное, а мне нужно было именно оно.

Ещё одна деталь, которую почти все «бенчмарки» игнорируют: у токенов две составляющие стоимости.

• STATIC — разовая прописка инструмента в системный промт: описания MCP-тулов или текст skill-файла. Платится один раз за сессию.

• PER-LOOKUP — собственно ответ на каждый запрос.

Если мерить только второе, картина врёт: инструмент с тяжёлыми тул-схемами выглядит дёшево, пока не вспомнишь, что он сидит в окне всю сессию.

Запросов — шестнадцать, с реальными версиями из моего фронтового lockfile (Next 16.2.5, React 19.2.6, Zod 4.1.12, Supabase JS 2.81.1, TanStack Query 5.90.21, Tailwind 3.4.18). Смесь специально разнородная: узкие сигнатуры с точностью до параметра (revalidatePath, опции createClient, флаги shadcn); быстро меняющиеся API (React 19 use, TanStack v5); явный bleeding-edge, где обучение устарело (Next 16 use cache, React Compiler, Zod 4 z.email()); широкие «как сделать X» как тест на раздувание; и пара запросов-ловушек — выдуманная quantumfizz-router, чтобы увидеть, сочинит инструмент ответ или признается.

Кандидатов — восемь: Ref, Context7 в двух режимах (MCP-сервер и CLI ctx7), GitMCP, локальный @neuledge/context, наивный WebFetch по llms.txt как контроль, плюс два managed-сервиса, которые я хотел поставить во главу сравнения. С последними вышла отдельная история — к ней вернусь.

Победитель — и контрольный выстрел в ногу

Вот компактная сводка по тому, что измерилось (полная таблица со всеми колонками — латентность p95, число протокольных раундов и прочее — лежит в ките, ссылка в конце):

_{¹ после исправления вызова — было 79%. ² после докрутки — было 57%. Об обоих случаях ниже.}

Победитель по моему главному приоритету — токенам — Ref, и с отрывом. Самая лёгкая прописка (170 токенов против 913 у Context7 MCP — впятеро легче), самый дешёвый ответ (медиана 525) и при этом 100% попаданий. Механика простая и правильная: сначала search отдаёт компактные указатели на нужные страницы, потом read_url точечно читает только то, что нужно. Отсюда и низкие токены. Из минусов — латентность средняя из-за двух раундов, и на широких запросах ответ может раздуться, когда он решает прочитать целую страницу.

А теперь контрольный выстрел — наивный путь, который многие до сих пор считают нормальным: скачать llms.txt и вывалить страницы в контекст. Медиана ответа: 4938 токенов. Пик: 14 546 на один запрос. При 50% попаданий. Вот от чего вообще нужны managed-сервисы: разница в токенах с тем же Ref — в пять-десять раз. Держать такой дамп постоянным слоем — значит палить контекст пачками ради половинной точности.

На этом можно было бы закончить «Ref выиграл, всем спасибо». Но самое полезное в этой истории случилось не с победителем.

Первый раз, когда я чуть не оболгал инструмент

Context7 умеет работать в двух режимах из одного и того же индекса: классический MCP-сервер и CLI плюс skill (ctx7). Я ждал, что CLI будет легче по токенам — меньше тул-схем висит в промте, — и это подтвердилось сразу: 664 против 913 на прописку. Но первый прогон точности расстроил: CLI дал 79% против 93% у MCP. На запросе про use cache он вообще уехал в какую-то чужую библиотеку next-shared-cache вместо нормального Next.

Соблазнительный вывод напрашивался сам: «CLI-режим хуже резолвит библиотеки, чем MCP». Я уже почти его записал. Но что-то кольнуло — субъективно CLI не казался тупее, и индекс-то у них общий. Полез в документацию. И оказалось, что правильная сигнатура — ctx7 library <имя> <запрос>: сначала имя библиотеки, потом запрос для ранжирования. А я-то передавал весь вопрос целиком как имя библиотеки.

То есть MCP-режиму я давал явный libraryName, а CLI кормил без подсказки имени — и сравнивал это как «равные условия». Сравнение было асимметричным, причём не в пользу CLI.

# как я звал (неправильно): весь вопрос уходит в поле имениctx7 library "how do I use the use cache directive in next"# → резолвится в /caching-tools/next-shared-cache  ❌# как надо: имя библиотеки + отдельно запросctx7 library next "use cache directive"# → /vercel/next.js  ✅

После фикса — ровно 93%, как у MCP, и при этом легче по токенам. Гипотеза «CLI экономнее MCP при той же точности» подтвердилась. Цена режима CLI — примерно лишние 0,4 секунды на запуск процесса, плюс нужен установленный skill и ключ. Выбор между режимами — вопрос вкуса, а не качества: индекс один, точность одна.

Вторая ошибка

С локальным @neuledge/context история повторилась, только глубже. Это MCP-сервер, который держит реестр доков и ищет по ним локально, через SQLite и полнотекстовый поиск (FTS5 плюс BM25) — то есть запросы вообще не уходят с машины. В первом прогоне он дал 57% с откровенными дырами: Supabase, TanStack, shadcn возвращали пусто. Я почти списал его в «нишевый baseline с неполным покрытием».

Но раз уж я задал себе вопрос «а можно ли вытянуть бесплатный локальный вариант» — решил докрутить. И снова нашёл три своих бага вместо недостатков инструмента.

Первый — самый стыдный. Я пропустил шаг сборки пакетов. Оказалось, neuledge собирает доки не только из своего реестра, а из любого источника — github-репозиторий, сайт с llms.txt, сырой URL — командой context add. Добавил Supabase и shadcn по одной команде на каждый. И сразу всплыла best-practice, которой я не знал: доки часто лежат в отдельном репозитории. Для React, например, исходники в facebook/react, а сама документация — в reactjs/react.dev. Если индексировать не то репо, получишь пусто и решишь, что инструмент слепой.

# доки часто в отдельном репо — индексируем именно егоcontext add https://github.com/reactjs/react.devcontext add https://supabase.com/docs   # 3472 секции одной командой

Второй баг — разбор имён. Пакет @tanstack/react-query физически лежал на диске, но имя со слэшем и ведущей собакой выпадало из моего регулярного выражения, которым я парсил список пакетов. Инструмент знал ответ, а я его не спрашивал как надо. Стал читать список напрямую — резолвится.

Третий — экстрактор ключевого слова. neuledge ищет по ключевым словам (это полнотекст, не семантика), и мой наивный экстрактор из запроса z.string().email() тянул первый вызванный метод — string. А нужно было email. Научил брать последний метод в цепочке — попадание.

После всех трёх фиксов — 100% попаданий при пяти миллисекундах на ответ. Пять. Это примерно в шестьсот раз быстрее облачных, потому что всё локально, без сети, без лимитов, а сам запрос весит 14 токенов. Что осталось реальной платой, а не моим багом: ответ дороже Ref по токенам — около 1880 в медиане, потому что neuledge отдаёт цельные куски доков, — и разовый context add для библиотек не из реестра.

И вот на скорости я хочу остановиться отдельно, потому что сам сначала её недооценил: смотрел только на токены и точность. Пять миллисекунд против трёх секунд — это не «приятная циферка в таблице». Агент за одну задачу лезет за доками не один раз, а десятки: проверил сигнатуру, уточнил опцию, сверил флаг. Три секунды на вызов превращаются в минуты ожидания за сессию — агент простаивает, ты смотришь на спиннер, и платишь за это временем. Локальные пять миллисекунд делают lookup фактически бесплатным по времени: агент спрашивает документацию так же свободно, как читает соседний файл. И тут вылезает неочевидный второй эффект. Когда обращение к докам дорогое (по времени или по лимиту), агент начинает их «экономить» — реже сверяется, чаще пишет по памяти. А когда оно бесплатное, он сверяется постоянно. То есть скорость влияет не только на комфорт — она напрямую тянет за собой качество: чем чаще агент заглядывает в актуальные доки, тем меньше отсебятины в коде.

Два сервиса, которые просто не дали себя протестировать

Помните managed-флагманы, которых я хотел поставить во главу сравнения? Их было два — оба разрекламированные, оба заявляют точность выше конкурентов. И оба не работают:))) Буквально.

С первым я даже не дошёл до регистрации: страница, где заводят аккаунт, отдавала «страница не найдена». Просто 404 на самом входе. Со вторым повезло чуть больше — зарегистрироваться удалось, но личный кабинет, где должен лежать API-ключ, не открывался, падал с ошибкой. И знаете, это в каком-то смысле исчерпывающая характеристика части современных dev-сервисов: тебе продают «самый точный контекст для твоего агента», а ты не можешь даже завести аккаунт и открыть личный кабинет.

Пометил оба как BLOCKED и зафиксировал причину. Это принципиальный момент: рейтинг — это не «у кого красивее лендинг», а «что я реально измерил». То, к чему нет доступа, в рейтинг не попадает — не потому что плохое, а потому что непроверяемое. И тот самый громкий «90% против 65%» так и остался непроверенным: воспроизвести его на своём наборе я физически не смог. Нельзя ранжировать то, во что не можешь войти, и нельзя верить заявленной точности, которую не воспроизвёл сам.

Никто не выдумал несуществующую библиотеку

Отдельно — тест на галлюцинации. Я подсунул всем выдуманную quantumfizz-router, которой нет в природе. Ни один не сгаллюцинировал ей API: Ref ответил «не найдено», GitMCP вернул пусто, Context7 не стал сочинять и предложил реальные альтернативы. Инструмент, который придумывает несуществующее, опаснее того, что просто молчит.

Ещё наблюдение из судейства сырых ответов — про формат. Context7 и neuledge отдают самые «богатые» сигнатуры: на запрос про revalidatePath я получал готовое revalidatePath(path: string, type?: 'page' | 'layout'): void и к нему полдюжины примеров вызова. Ref устроен иначе — отдаёт компактные указатели и точечно дочитывает нужное, потому и токенов тратит меньше всех. Это не «лучше/хуже», это разный размен: богатый контекст против бережного окна. Кому что важнее по приоритетам — тот то и берёт. Сам я решил всё-таки пойти в богатый контекст. Но не утверждаю, что это наиболее правильный путь!

А на свежести — ради которой всё и затевалось — managed-инструменты подняли актуальные факты по bleeding-edge (Next 16 use cache, React Compiler, Zod 4 z.email()): ровно то, на чём голый агент с устаревшим обучением вернул бы старый z.string().email() и поведение Next 15. Это и есть ценность слоя доков поверх обучения — та самая, которой я лишился, когда Context7 молча упёрся в лимит.

Победитель оказался платным — и тут начинается самое интересное

Ref выиграл по токенам. Но Ref платный. А я начинал весь этот заход именно потому, что упёрся в лимит бесплатного тарифа. Менять одну платную зависимость на другую — не то, ради чего я полтора года ничего не трогал.

Поэтому я задал следующий вопрос: можно ли собрать бесплатную связку, которая закроет процентов девяносто случаев? И собрал.

Архитектура двухуровневая. L1 — локальный @neuledge: основной слой, бесплатный, мгновенный, по собранному стеку отвечает за пять миллисекунд и без сети. L2 — Context7 free как fallback: дёргается только тогда, когда L1 не покрыл запрос — то есть на библиотеках, которых нет в локальном стеке. Политика для агента простая: сначала спроси локальный слой; если он не вернул релевантный результат или библиотеки нет — иди в Context7.

Транспорт у обоих уровней — MCP, не CLI. Тут я сознательно не стал экономить: fallback в этой схеме — редкое событие, один вызов на новую библиотеку, и token-экономия CLI-режима на нём несущественна. Зато MCP даёт zero-config и единообразие во всех проектах, а отложенная загрузка схем в Claude Code, о которой я говорил выше, снимает старый аргумент против «лишнего» MCP-сервера.

Но раз L2 бесплатный и ограничен той самой тысячей запросов в месяц — критично понять не «работает ли связка», а сколько реально уйдёт в платный лимит. Иначе я просто отложу ту же проблему на потом.

Сколько реально уходит в платный лимит

Я сделал замер намеренно не тепличным. К четырнадцати запросам по собранному стеку добавил шесть нишевых npm-библиотек вне его — nanoid, ky, ofetch, consola, citty, croner. Реальный длинный хвост, то, что встречается в проектах поштучно. Маршрутизация — как в проде: «покрыто локально» засчитывается, только если neuledge вернул именно нужный факт, иначе — fallback в Context7.

Сразу оговорка: эти 30% — не «реальная частота fallback». Это две крайние точки в одном флаконе: всё, что в стеке, — ноль процентов, всё, что вне, — сто. Реальная частота у вас будет равна вашей доле незнакомых библиотек в запросах, а не моим 30%.

И вот тут — главная находка, которая важнее любого процента. Это механизм, а не число. Новая библиотека уходит в платный L2 ровно один раз — при первой встрече. После этого ты делаешь по ней context add, и она навсегда переезжает в локальный L1. Больше она в fallback не упадёт никогда.

Сложите это с лимитом в тысячу запросов в месяц. Чтобы в него упереться, надо встречать больше тысячи разных новых библиотек в месяц и при этом не добавить локально ни одной. Это не рабочий сценарий. У любого живого проекта запас по лимиту — кратный. Бесплатная связка устойчива при любом реальном паттерне работы.

Отдельным бонусом — приватность, хотя я выбирал связку не ради неё. Локальный L1 держит доки и запросы у себя: на машину пришёл пакет один раз, дальше всё локально. Для кого важна data residency или строгий on-prem — это закрывает вопрос почти само собой.

Что в итоге у меня в проде

Расклад, к которому я пришёл:

• Локальный слой — @neuledge для всего, что в стеке. Собрал context add один раз — и дальше сплошные плюсы: ответ за ~5 мс вместо трёх секунд, работает offline, без лимитов запросов, сам запрос весит смешные 14 токенов, а доки прибиты к точной версии из lockfile, а не «вообще про библиотеку».

• Fallback — Context7 free. Ловит длинный хвост, тратит квоту только на первое касание незнакомой библиотеки, дальше та уезжает в локальный.

• Ref я держу в уме как платный максимум по токенам — если когда-нибудь токены станут важнее бесплатности, поставлю его вторым уровнем вместо Context7. Но пока бесплатная связка держит, и я не вижу повода платить.

• Наивный llms.txt-дамп постоянным слоем — мимо, только как live-fetch последней надежды.

Победитель рейтинга и то, что поехало в прод, — разные вещи. Ref выиграл по моему главному весу. А в прод поехала бесплатная связка, потому что мой реальный приоритет был не «минус десять токенов», а «не платить и не ловить молчаливый игнор». Цена решает.

Но самое ценное в этой миграции — даже не деньги и не токены. Раньше «а правильно ли агент достал доки» висело отдельной точкой беспокойства: контролируешь модель, контролируешь промпт, а сверху ещё и гадаешь, сработал ли docs-сервер. Теперь этой точки нет. Есть основной слой, есть fallback — и я просто уверен, что свежая документация до агента доедет. Минус одна точка фокуса внимания. А в работе с агентами правильная фокусировка — на том, что действительно требует тебя, — едва ли не главная ценность вообще. Плюс скорость: пять миллисекунд вместо трёх секунд чувствуются!

Миграционный кит — забрать и внедрить

Сразу про внедрение: оно оказалось не «сложным», а муторным. За полтора года Context7 у меня врос буквально везде — требование «используй context7» было прошито и в правилах агентов, и в десятках промптов, и в конфигах по всем проектам. Самая большая работа была не «понять, как», — как раз понятно, — а перелопатить весь этот объём: найти каждое место, заменить «дёргай Context7» на «сначала локальный слой, потом fallback», и не пропустить ни одного. Вот тут я и оценил, что эту рутину можно свалить на самого агента.

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

Внутри:

• PROMPT.md — нейтральный промт внедрения. Вставляешь агенту, и он сам проходит по проектам: инвентаризирует, где и как подключён Context7, собирает из lockfile реальные зависимости, ставит глобально @neuledge, прописывает Context7 как fallback и переписывает политику в правилах агента. Я специально сделал его не завязанным на мой сетап: работает в Claude Code, Codex и Cursor, ключ Context7 берётся из переменной окружения, ничего не коммитится без подтверждения.

• BENCHMARK.md — полная таблица всех восьми инструментов со всеми колонками, которые не влезли в статью: латентность p95, число протокольных раундов, покрытие.

• FALLBACK.md — детальный разбор замера fallback-rate: какие либы, как считал, таблица запаса до лимита.

• CHECKLIST.md — короткий чек-лист миграции, чтобы ничего не сломать вслепую: сначала инвентаризация и отчёт, потом изменения, всё идемпотентно и обратимо.

Кит лежит в моём Telegram-канале — забирайте оттуда. Если будете внедрять и наткнётесь на свою версию моих граблей (а формат context add и доки в отдельном репо — это прямо классика), напишите в личку, интересно собрать чужой опыт. Инструменты, которыми я оркеструю агентов, — на GitHub.

Чего я не доказал

Чтобы не выглядеть продавцом единственно верного решения — границы того, что я измерил.

Токены я считал прокси-токенайзером, не нативным счётчиком Anthropic, — абсолют может гулять процентов на десять-пятнадцать, но на ранжирование «кто экономнее» это не влияет, потому что линейка у всех одна. Два managed-сервиса я не протестировал вообще — у них не открылись сайты. Заявленной вендором точности я не верю, пока не воспроизвёл сам, — и вам не советую. И ещё раз про те 30% fallback: это не реальная частота, а две крайние точки замера; ваша частота будет своя и почти наверняка ближе к нулю, чем к тридцати.

Сравнение валидно ровно потому, что один токенайзер на всех, один набор запросов, нативный протокол каждого и исключённое то, что не далось. Всё остальное — нормальная инженерная дисциплина, а не магия. Прежде чем винить инструмент, проверьте свой вызов: меня это спасло дважды за один бенчмарк. Ну или хотя бы попросите проверить агента… Всем хорошей недели!