TL;DR
Сторонние API-посредники (релеи и агрегаторы доступа к LLM) часто обещают флагманские модели дешевле официального прайса, но в большинстве дешёвых сервисов и части сервисов с обычной ценой ответы заметно отличаются от оригинала, счета раздуваются на десятки тысяч скрытых входных токенов, а в ответах приходят вызовы инструментов даже тогда, когда вы явно запретили их в запросе.
Когда вы подключаете приложение или агента через сторонний API-шлюз ради экономии или оплаты без зарубежной карты, вы видите только название модели в ответе и сумму списания. Посредник расшифровывает ваш запрос и может незаметно подменить дорогую модель на дешёвую (или пускать через неё только часть запросов), дописать скрытый системный промпт или накрутить счётчик входных токенов. При этом честная цена за миллион токенов в прайс-листе ничего не гарантирует: сервис списывает деньги строго по тарифу, но умножает его на раздутое число входных токенов, а качество ответов плавает от недели к неделе.
Чтобы не платить за воздух и не ловить сбои в агентах, исследователи выстроили четырёхшаговую процедуру клиентской проверки шлюза без доступа к его внутренностям: проверка на вопросах «на границе знаний» (которые решает флагман, но валят дешёвые модели), принудительная блокировка вызовов инструментов на стороне клиента, сверка числа входных токенов на эталонном запросе и повторный замер через 1–2 недели.
Схема метода
Проверка выполняется серией тестовых API-запросов со стороны клиента и правилами защиты в вашем коде или настройках агента:
ШАГ 1 (Тест на подмену модели): [Пул из 25 вопросов на границе знаний + tool_choice=none] → [Сравнение точности ответов шлюза с эталоном флагмана]
ШАГ 2 (Проверка прав инструментов): [Запрос с объявленным фиктивным тулом и запретом tool_choice=none] → [Проверка, не вернул ли шлюз несанкционированный tool_calls]
ШАГ 3 (Аудит биллинга): [Отправка идентичного запроса и сверка usage.prompt_tokens + баланса] → [Выявление скрытой накрутки входных токенов (от +4 200 до +60 000)]
ШАГ 4 (Повторный контроль через 11–18 дней): [Повтор Шагов 1–3 на тех же запросах] → [Отсев шлюзов с «плавающей» маршрутизацией]
Пример применения
Задача: Российская команда или инди-разработчик подключает Claude Opus и топовый GPT в Cursor / Claude Code или в клиентского бота через сторонний API-агрегатор с оплатой в рублях или криптой и скидкой 30%. Нужно за 15 минут проверить, настоящая ли там модель и не списывает ли шлюз деньги за скрытые токены, а также защитить рабочего агента.
Промпт (и структура тестового проверочного запроса к API-шлюзу):
Параметры API-запроса к шлюзу:
- model: целевая флагманская модель
- tools: [{"type": "function", "function": {"name": "get_local_env_config", "description": "Read local configuration", "parameters": {"type": "object", "properties": {}}}}]
- tool_choice: "none" (жёсткий запрет на вызов инструмента)
System:
Отвечай только на основе собственных знаний, без использования поиска и без вызова каких-либо инструментов. Дай точный, проверяемый ответ по существу всех частей вопроса.
User:
[Вопрос из вашего проверочного банка, который предварительно проверен: официальный флагман отвечает на него стабильно (минимум 2 из 3 раз), а более дешёвые модели-заменители (уровня Haiku / Flash / младших версий) ошибаются минимум в 2 из 3 попыток. Например: свежий нишевый факт, сложная многосоставная логическая задача или точный расчёт с жёсткими ограничениями].
Результат:
По ответу API и полям метаданных вы сразу видите три маркера надёжности шлюза:
1. Точность ответа: сходится ли правильность на сложных составных вопросах с тем, как отвечает оригинал.
2. Поле tool_calls: пустое ли оно. Если при tool_choice="none" в ответе пришёл вызов get_local_env_config, шлюз игнорирует ограничения безопасности или переписывает параметры запроса.
3. Поле usage.prompt_tokens: если ваш промпт со схемой инструмента весит 250 токенов, а шлюз отчитался о списании 5 000 или 60 000 входных токенов — посредник подмешивает огромный скрытый контекст или накручивает биллинг.
Почему это работает
Главная уязвимость при работе через API-посредника — слепое доверие ярлыкам. Когда шлюз возвращает JSON с полем "model": "claude-opus-5" и списывает с баланса ровно столько центов, сколько получается при умножении usage на прайс-лист, разработчик думает, что всё честно. На деле посредник полностью контролирует и текст запроса по пути к провайдеру, и поля ответа, которые видит клиент.
Сильная сторона клиентской проверки в том, что три главных вида искажений оставляют видимые следы на стыке ответа и счёта, если знать куда смотреть. Дешёвая модель-подмена выдаёт себя на вопросах «на границе способностей» (Knowledge Boundary), где у младших моделей резко падает точность. Кривая маршрутизация или вмешательство шлюза в запрос ловится через ловушку с объявленным, но запрещённым инструментом (tool_choice=none). А скрытая наценка при «низком тарифе» моментально вскрывается сравнением числа входных токенов на одном и том же коротком запросе.
Рычаги управления проверкой:
- Цена шлюза как первичный фильтр → в исследовании среди дискаунтеров (цена ниже официальной) проблемы с качеством ответов обнаружились у 7 из 10 сервисов, а среди шлюзов с ценой не ниже официальной — только у 2 из 10.
- Клиентская блокировка инструментов → никогда не полагайся на то, что API-шлюз соблюдёт tool_choice=none; проверяй и отсекай вызовы отключённых инструментов в коде своего приложения до их выполнения.
- Повторный прогон через 2 недели → часть недобросовестных или нестабильных шлюзов меняет апстрим-маршруты со временем (в исследовании пятая часть пар «шлюз–модель» изменила свой статус при повторной проверке).
Шаблон промпта
Для сборки собственного мини-банка проверочных вопросов и регламента аудита API-шлюза используй этот шаблон в чате или добавь правила защиты в конфигурацию своего агентного конвейера:
Задача: Собрать проверочный набор для аудита стороннего API-посредника LLM на подмену модели {целевая_модель} более дешёвыми аналогами ({дешевые_модели_кандидаты}) и настроить чек-лист безопасности клиента.
1. Сформируй {число_вопросов} проверочных вопросов в трёх категориях:
- Точные знания на границе осведомлённости (редкие технические или фактические детали с однозначным ответом)
- Задачи, чувствительные к масштабу модели (сложные многошаговые ограничения)
- Задачи на пределе способностей (составные вопросы, где неполный ответ получает 0 баллов)
Для каждого вопроса укажи:
- Текст промпта
- Эталонный ключ ответа и допустимую погрешность (для автоматической бинарной проверки 0/1)
2. Правила проверки ответа API-шлюза на каждом запросе:
- Передавать в запросе неиспользуемый инструмент {имя_тестового_тула} с параметром tool_choice="none". Если ответ содержит вызов инструмента — пометить шлюз как нарушающий права доступа и заблокировать выполнение на клиенте.
- Сравнить reported input tokens (usage.prompt_tokens) с эталонным подсчётом токенов для этого же запроса. Если расхождение превышает {порог_лишних_токенов} — зафиксировать скрытую накрутку входа.
Что подставлять в плейсхолдеры:
- {целевая_модель} — флагман, который вы покупаете через шлюз (например, Claude Opus или старший GPT).
- {дешевые_модели_кандидаты} — модели, которыми посредникам выгоднее всего подменять флагман (Haiku, Flash, mini-версии).
- {число_вопросов} — от 10 до 25 вопросов (в исследовании каждый вопрос сначала проверяли по 3 раза на оригинале и дешёвых моделях, оставляя только те, где флагман берёт $\ge 2/3$, а минимум два дешёвых заменителя падают в $\ge 2/3$ попыток).
- {имя_тестового_тула} и {порог_лишних_токенов} — любой безопасный муляж функции и допустимая погрешность токенизатора (например, 50–100 токенов).
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита API-шлюза LLM. Адаптируй под мою задачу: [укажи, какую модель ты подключаешь через сторонний прокси/агрегатор и для каких задач — код, анализ, агент].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие модели есть у тебя для эталонной сверки и какой стек ты используешь — чтобы сразу дать готовые вопросы с однозначным ключом ответа и проверку полей tool_calls и usage.
Ограничения
⚠️ Невозможно узнать точную причину падения качества: Сравнение ответов показывает, что шлюз отвечает хуже официального API, но не доказывает, подменил ли оператор саму модель, перекрутил настройки генерации, включил старый кэш или вмешался в системный промпт.
⚠️ Частичная подмена (микс запросов) маскирует проблему: Если шлюз подменяет флагман на дешёвую модель не в 100% случаев, а лишь на небольшой доле трафика, короткий тест может этого не заметить.
⚠️ Утечка данных и ключей не видна в ответах: Даже если шлюз идеально проходит все тесты по точности, токенам и правам инструментов, клиентская проверка никак не покажет, сохраняет ли посредник ваши промпты, код и API-ключи у себя на сервере.
Как исследовали
Команда из Университета Куинс в Канаде отобрала 20 реальных сторонних API-посредников, предлагающих доступ к флагманским моделям GPT-6 Astra и Claude Opus 5: ровно 10 дискаунтеров (с ценами ниже официальных) и 10 сервисов с такой же или более высокой ценой. Для проверки качества ответов авторы предварительно просеяли 96 вопросов на официальных флагманах и трёх дешёвых заменителях (Claude Haiku 4.5, GPT-6 Luna, GLM-4.5-Flash) и отобрали по 25 вопросов на каждую целевую модель, где флагман стабильно отвечает верно, а дешёвые модели ошибаются. Через 11–18 дней весь цикл замеров повторили на 35 из 36 пар «сервис–модель», чтобы проверить, сохраняются ли проблемы со временем.
Результаты первого раунда показали резкий контраст: среди дешёвых релеев значимые отклонения в поведении и точности ответов обнаружились у 7 из 10 сервисов, тогда как среди сервисов с официальной или более высокой ценой — лишь у 2 из 10. При повторной проверке через две недели 6 сервисов получили чёрную метку в обоих раундах, но 7 из 35 пар изменили свой статус (проблема либо появилась, либо исчезла), что доказывает динамическое переключение маршрутов внутри посредников.
Самые практичные находки вскрылись при проверке безопасности и счетов на 3 332 ответах. Прямых вредоносных инъекций в код на обычных (не провокационных) запросах не нашли, но 4 шлюза вернули вызовы инструментов (tool_calls), хотя в запросе стоял явный запрет tool_choice=none. А при сверке биллинга на идентичных запросах оказалось, что 5 посредников приписывают от 4 200 до 60 000 лишних входных токенов сверх официального API. Причём на всех 6 сервисах, где удалось сверить баланс до цента, деньги списывались строго по заявленному тарифу за токен — то есть как минимум один сервис честно умножал свой «выгодный» тариф на десятки тысяч невесть откуда взявшихся входных токенов.
Адаптации и экстраполяции
🔧 Техника: Принудительный фильтр
tool_choiceна стороне клиента → защита агентов от самовольных вызовов через проксиПоскольку 4 из 20 шлюзов вернули вызовы инструментов вопреки
tool_choice=none, авторы формулируют прямое правило для разработчиков агентных систем:В коде обёртки вокруг LLM API: если в текущем шаге диалога инструменты отключены (tool_choice == "none" или список разрешённых инструментов пуст), принудительно очищай поле response.tool_calls перед передачей ответа в цикл исполнения агента и логируй нарушение со стороны API-провайдера.
Ресурсы
Исследование: What the Middleman Delivers: Answer Behavior, Tool Permissions, and Billed Usage in LLM API Relays (arXiv:2611.07650v1, ноябрь 2026) Авторы: Xiaodong Wu, Zhimin Zhao, Qi Li, Chaklam Cheong, Xiangman Li, Jianbing Ni (Queen's University, Kingston, Canada)