ProxyAPI предоставляет два способа обращаться к моделям: нативные эндпоинты каждого провайдера (/v1/messages у Anthropic, …:generateContent у Google, /v1/responses у OpenAI) и универсальный OpenAI-совместимый /v1/chat/completions. Совместимый формат удобен: он позволяет переключать провайдеров без изменения кода и проще для прототипирования. Но он сводит интерфейсы всех провайдеров к подмножеству OpenAI Chat Completions образца 2023 года, и часть провайдер-специфичных возможностей через него либо недоступна, либо работает заметно хуже.
Ниже — конкретные случаи, в которых это имеет значение.
В extended thinking (Claude 3.7 и Claude 4 и позже) модель возвращает ответ как последовательность блоков, среди которых есть thinking-блоки с её внутренними рассуждениями. Каждый такой блок сопровождается полем signature — криптографической подписью Anthropic над содержимым блока.
В многоходовом диалоге thinking-блоки последнего ответа модели нужно передавать обратно в следующий запрос байт-в-байт, вместе с подписью. Это не опциональная оптимизация, а часть протокола: подпись позволяет модели верифицировать, что цепочка рассуждений действительно её собственная, а не подделка. Если подпись отсутствует или не совпадает, API возвращает ошибку Invalid signature in thinking block. Если же удалить thinking-блоки из истории «чтобы не падало», модель теряет контекст рассуждений, и качество ответов в агентных сценариях с tool use заметно деградирует.
Поле signature не является частью схемы OpenAI Chat Completions, поэтому при работе через совместимый формат оно может теряться в стриминге или не передаваться обратно — многоходовые сценарии с reasoning перестают работать корректно.
Подробности — в документации Anthropic по extended thinking.
Reasoning-модели OpenAI (o3, o4-mini, GPT-5) генерируют невидимые reasoning-токены, на которых строится финальный ответ. У OpenAI два API: классический /v1/chat/completions и новый /v1/responses. Принципиальная разница в том, что в Chat Completions reasoning-токены отбрасываются между ходами, а в Responses API они сохраняются и передаются в следующий запрос (через previous_response_id или encrypted_content).
По публикуемым OpenAI замерам, сохранение reasoning-контекста даёт +3% на SWE-bench и +5% на TAU-bench в многоходовых сценариях, а главное — поднимает попадание в кеш с ~20% до ~80%, что в длинных агентных диалогах транслируется в 40–80% экономии на стоимости и latency. Шлюзы, которые реализуют только Chat Completions endpoint, лишают пользователя этой оптимизации автоматически.
См. руководство OpenAI по reasoning models.
Anthropic поддерживает кеширование части промпта со скидкой 90% на чтение из кеша. Управление кешированием — явное: на нужные блоки сообщения проставляется маркер cache_control, и провайдер кеширует префикс именно до этой границы. Это даёт точный контроль: можно закешировать длинный system prompt и список tool definitions, но не закешировать пользовательский ввод, который у каждого запроса свой.
Через универсальный формат cache_control либо не пробрасывается совсем, либо требует нестандартных полей в теле запроса. Иногда поверх делают «автоматическое» кеширование по эвристикам, но оно не даёт контроля над тем, где именно стоит cache breakpoint, и реальный hit rate в результате оказывается заметно ниже, чем при явной разметке.
См. документацию Anthropic по prompt caching.
Citations API — нативная возможность Anthropic, в которой модель при работе с документами сама расставляет точные ссылки на конкретные предложения в исходниках. Цитаты возвращаются как отдельные структурированные элементы ответа с указанием диапазонов символов в исходных документах. По данным Anthropic, точность таких цитат на 15 процентных пунктов выше, чем у prompt-based решений вида «попроси модель привести ссылки текстом».
В схеме OpenAI Chat Completions нет полей для структурированных цитат, поэтому через совместимый формат эта возможность недоступна.
См. документацию по Citations API.
У Gemini ряд возможностей доступен только через нативный API:
- Grounding with Google Search — встроенный инструмент, который позволяет модели обращаться к актуальной выдаче Google и возвращать
groundingMetadataс поисковыми запросами и ссылками на источники. thinking_config— управление бюджетом рассуждений и включение thought summaries в ответ.safety_settings— гранулярные пороги по четырём категориям контента (harassment, hate speech, sexually explicit, dangerous). Через универсальный формат в лучшем случае остаётся глобальный переключатель.- Function calling совместно со structured output — нативный API это поддерживает; OpenAI-совместимый endpoint Google возвращает 400 Bad Request при попытке скомбинировать.
- Стриминг аргументов tool call — нативно идёт по мере генерации; в совместимом режиме аргументы буферизуются и приходят одним куском в конце ответа, что критично для интерактивных интерфейсов с «живым» tool use.
См. документацию Google по grounding, thinking и safety settings.
OpenAI-совместимый формат подходит для простых случаев: короткие запросы без reasoning, один и тот же код для разных провайдеров, быстрая миграция с существующего проекта.
Если задача сложнее — агенты с инструментами, длинные диалоги с reasoning-моделями, работа с документами и цитатами, тонкая настройка под конкретного провайдера, — лучше обращаться напрямую к его нативному API. ProxyAPI передаёт такие запросы провайдеру как есть: тот же формат, тот же официальный SDK, та же документация. Меняется только базовый URL и ключ.
