2026 Cursor вызывает OpenAI o1: аномальный счёт? Сначала проверьте реальную цепочку вызовов

На этой неделе сначала выполните проверку счёта Cursor при вызове OpenAI o1 по полной цепочке Cursor → LiteLLM → поставщик модели, и только после этого решайте, увеличивать ли локальную мощность. Аномальный расход не доказывает, что единственной причиной стала цена o1: его могут вызвать неверный псевдоним модели, повторные запросы, аварийный fallback или обход маршрута Qwen3-Coder.

Этот материал предназначен администраторам, которые сверяют использование Cursor, поставщика модели и шлюза; инженерам, поддерживающим LiteLLM, ключи и журналы; а также техническим руководителям, планирующим отдать обычное программирование локальному Qwen3-Coder, но ещё не завершившим проверку расходов.

Последнее обновление: 17 сентября 2026 года. Фактические границы поддержки сверены с документацией Cursor по собственным API-ключам, материалами OpenAI по o1 и usage, документацией LiteLLM и публикацией о Qwen3-Coder. При изменении этих страниц цепочку необходимо проверить повторно.

Три разных счёта одной операции

Основная ошибка при расследовании — складывать показатели из Cursor, LiteLLM и OpenAI API как независимые расходы. Это не три счёта за одну и ту же услугу, а три наблюдения на разных границах:

• Cursor показывает события клиентского продукта: выбранную модель, действия Agent, обращения к инструментам и видимые статусы.
• LiteLLM фиксирует прохождение запроса через шлюз: виртуальный ключ, внутреннее имя модели, попытки, fallback, время ответа и доступные поля usage.
• OpenAI API отражает запрос, который действительно достиг OpenAI, а также поля использования и биллинговую запись поставщика.

Для аудита создайте общий ключ корреляции из времени, request ID, виртуального ключа и model. В идеальном случае Cursor передаёт идентификатор без изменений, LiteLLM сохраняет его в журнале, а поставщик позволяет найти соответствующую запись. Если хотя бы один слой генерирует новый ID и не хранит связь со старым, конкретный расход нельзя уверенно приписать одному нажатию в Cursor. В такой ситуации допустимо говорить о совпадении тенденций, но не о доказанной принадлежности отдельного запроса.

OpenAI описывает usage через API-объекты и отдельные поля ответа; поэтому для сверки следует сохранять структуру ответа, а не только итоговую строку сообщения. Полезно заранее определить, какие поля принадлежат клиенту, какие — шлюзу, а какие — поставщику. Внутреннее руководство по сопоставлению журналов AI-шлюза и API-использования можно использовать как основу для схемы хранения, но конкретные поля нужно сверять с текущим API.

Модельный алиас и реальный deployment

Строка «OpenAI o1» в выпадающем списке Cursor — это намерение клиента или отображаемое имя, а не доказательство конечного backend. Запрос мог пройти через общий Base URL, совместимый прокси, алиас в LiteLLM или правило, которое переназначает имя на другое развёртывание. Обратная ситуация также возможна: интерфейс показывает нейтральный алиас, а шлюз отправляет запрос на o1.

Особенно важна граница поддержки собственного ключа. В документации Cursor стандартная поддержка OpenAI через собственные ключи описана для обычных чат-моделей, а не как подтверждение прямого вызова рассуждающей модели o1. Это означает, что руководитель не должен объявлять схему официально поддержанной только потому, что нужное имя отображается в интерфейсе. Сначала следует подтвердить способ подключения и фактическую конечную модель по журналам документации Cursor о собственных API-ключах.

Оценка вариантов для расследования выглядит так:

В журнале должны отдельно сохраняться requested_model, resolved_model, deployment, provider, request_id, virtual_key, status_code, retry_reason и временные метки. Если система хранит только model: o1, без resolved deployment и ID попытки, это недостаточно для доказательства маршрута. Нельзя подменять отсутствующее поле предположением о том, что выбранное пользователем имя совпало с реальным backend.

Reasoning tokens и неполный usage

OpenAI o1 относится к моделям, где расход нельзя оценивать по длине видимого ответа. Документация OpenAI отдельно описывает reasoning tokens и связанные с ними usage-поля; для проверки используйте материалы OpenAI о модели o1 и описание usage и reasoning-полей в Responses API.

В каждой записи разделяйте как минимум следующие категории:

• обычные входные токены;
• входные данные, учтённые как кэшированные, если такое поле возвращает используемый интерфейс;
• выходные токены;
• токены, связанные с рассуждением;
• агрегированный usage, если его формирует шлюз.

Имена полей и доступность отдельных значений зависят от используемого API-пути. Поэтому нельзя переносить схему из одного ответа в другой без проверки. Запрос к справочнику OpenAI Usage API нужен для сверки того, какой объект и какой период фактически используется в отчёте.

Третьесторонний прокси может:

• удалить usage при потоковой выдаче;
• переименовать reasoning-поля в общее поле output;
• записать только финальную попытку;
• объединить несколько попыток в одну строку;
• вернуть клиенту неполный объект, хотя сам поставщик получил более подробные данные.

Если это происходит, нельзя вычислять стоимость по количеству символов в ответе или по визуально короткому сообщению. Корректный статус участка — «совместимость usage не подтверждена». До исправления логирования следует ограничить использование модели, иначе финансовый отчёт будет выглядеть точным, хотя его ключевое поле потеряно.

Опыт аудита: короткое сообщение может сопровождаться значительным внутренним расходом, а длинный ответ — не быть причиной роста счёта. Длина текста годится для анализа качества, но не для восстановления reasoning tokens.

Повторы, Agent и аварийный fallback

Одна операция пользователя в Cursor Agent способна породить несколько сетевых событий: основной запрос, вызов инструмента, продолжение после результата инструмента, повтор после ошибки и отдельную попытку через fallback. Это не означает, что каждая операция всегда создаёт одинаковое количество обращений. Именно поэтому расследование должно начинаться не с суммы, а с группировки по correlation ID и временной последовательности.

Для каждой группы зафиксируйте:

1. время старта и завершения;
2. исходную модель и resolved model;
3. HTTP-статус каждой попытки;
4. причину повтора;
5. факт вызова инструмента;
6. выбранный fallback;
7. финальный результат.

LiteLLM действительно предоставляет единый интерфейс, механизмы повторов, fallback и отслеживание стоимости, но наличие этих функций не делает шлюз классификатором сложности задачи. Это важно для интерпретации правил: переход на OpenAI o1 после тайм-аута локального endpoint — аварийная надёжность, а не доказательство того, что шлюз распознал «сложную задачу». Возможности и ограничения необходимо сверять с официальной документацией LiteLLM.

Разделяйте два сценария:

• Надёжность: локальная модель не ответила, превысила заданный тайм-аут или возвратила несовместимый ответ; правило отправило повтор на облачную модель.
• Маршрутизация по задаче: политика заранее определила, что конкретный тип запроса должен использовать o1.

Если в журнале нет явного признака классификации, нельзя описывать обычный fallback как интеллектуальное распределение задач. Для финансового контроля это различие принципиально: первый случай указывает на проблему доступности, второй — на бизнес-правило.

Qwen3-Coder и скрытый обход локального маршрута

Локальный Qwen3-Coder может отвечать корректно, пока часть операций Cursor проходит по другому пути. Например, обычный текстовый запрос попал в локальный endpoint, а инструментальный вызов, продолжение Agent или запрос с несовместимым контекстом ушли в OpenAI o1. Итоговый ответ будет успешным, но облачная стоимость продолжит расти.

Проверьте четыре причины обхода:

• локальный endpoint не прошёл health-check в момент запроса;
• имя модели не совпало с алиасом, ожидаемым LiteLLM;
• тайм-аут оказался короче реального времени ответа локального сервиса;
• формат контекста или инструментов не поддерживается локальным deployment.

Официальные сведения о возможностях и сценариях Qwen3-Coder следует сопоставить с публикацией разработчиков модели. Даже при совместимом базовом API это не гарантирует идентичное поведение для tool calls, потоковой выдачи и длинного контекста. Поэтому проверять нужно не только обычный чат.

Минимальная проверка состоит из трёх отдельных тестов:

• Локальное попадание: простой запрос с принудительным алиасом Qwen3-Coder; в журналах должны появиться локальный deployment и отсутствие облачной попытки.
• Явное повышение: задача, для которой политика разрешает OpenAI o1; должны быть видны причина выбора, resolved model и usage поставщика.
• Отказ локального узла: контролируемая ошибка или недоступность endpoint; должна появиться одна понятная fallback-цепочка с исходным статусом и причиной перехода.

В каждом тесте сохраняйте обезличенные записи, например:

source=cursor
request_id=req_redacted_01
requested_model=code-default
virtual_key=team_redacted

source=litellm
request_id=req_redacted_01
resolved_model=qwen-local
deployment=local-redacted
status=200
fallback=false

source=provider
request_id=req_redacted_02
model=o1
usage=preserved
retry_reason=local_timeout

Это разные источники, а не три строки одного формата. Если Cursor ID заменяется шлюзом, храните таблицу соответствий с ограниченным доступом. Секреты API, исходный код и содержимое пользовательских запросов в диагностический экспорт включать не следует.

Пятишаговая схема расследования

Шаг 1. Зафиксируйте окно аудита. Выберите небольшой период, в котором рост счёта уже виден, и не меняйте одновременно модель, Base URL и правила fallback. Иначе невозможно определить, какое изменение повлияло на результат.

Шаг 2. Снимите конфигурацию на момент события. Сохраните выбранную в Cursor модель, способ авторизации, Base URL, алиасы LiteLLM, виртуальный ключ и список разрешённых deployment. Секреты замените маркерами. Важно сохранить именно фактическую конфигурацию, а не предполагаемую.

Шаг 3. Соберите три журнала. Экспортируйте клиентские события Cursor, записи LiteLLM и usage поставщика. Для каждой стороны обозначьте владельца поля: клиент, шлюз или модельный поставщик. Не объединяйте строки до того, как сохраните оригинальные записи.

Шаг 4. Постройте таблицу корреляции. Свяжите записи по request ID, времени, виртуальному ключу и модели. При расхождении времени используйте допустимое окно, но не стирайте исходные значения. Строки без достаточных признаков пометьте как «тренд», а не как доказанное списание.

Шаг 5. Разложите повторы. Для каждого пользовательского действия посчитайте не условное число обращений, а последовательность: первичная попытка, инструмент, повтор, fallback и финальный ответ. Причину каждого перехода подтвердите статусом или полем retry reason.

Шаг 6. Повторите три маршрута для Qwen3-Coder. Проверяйте локальное попадание, намеренное обращение к o1 и отказ локального узла. Финальный текст не является достаточным результатом теста; должна быть восстановима вся цепь.

Шаг 7. Проведите контрольный запуск после исправления. Сравните не виртуальную сумму, а условия прохождения: модель соответствует правилу, usage не теряется, fallback объясним, ключи разделены, а качество кода не ухудшилось заметно по принятому командой критерию.

Для командной работы полезно заранее разделить виртуальные ключи по проектам и бюджетным владельцам. В русскоязычном разделе JexMac можно также сверить условия аренды Mac для тестовых сред, но расширять вычислительную инфраструктуру до завершения аудита не следует: дополнительный узел не исправит ошибочный алиас или повторный облачный запрос.

Условия решения после исправления

Используйте следующие ветви, а не единый совет для всех команд:

• Если model и deployment совпадают с правилом, usage полностью сохраняется, повтор объясним, ключи изолированы и качество не ухудшилось, выбирайте продолжение работы с текущей схемой и наблюдением.
• Если локальные запросы работают, но часть стандартных операций уходит в o1 из-за слишком широкого условия, выбирайте корректировку маршрутизации и повторный контрольный запуск.
• Если usage обрезается, request ID теряется, fallback образует неясную цепочку или поставщик получает запросы после запрета, выбирайте откат прокси до подтверждения совместимости.
• Если только локальный узел регулярно становится причиной тайм-аутов, а правила и учёт уже подтверждены, переходите к сравнению постоянного устройства и эластичной Mac-мощности. Это следующий инфраструктурный выбор, а не средство скрыть нерасследованный рост счёта.

Частые вопросы

Как подтвердить модель после API-прокси

Название в Cursor проверяется только как исходное намерение. Фактический маршрут устанавливается сопоставлением requested_model, resolved_model, deployment, request ID и записи поставщика. При отсутствии сквозного идентификатора разрешено подтвердить лишь статистическое совпадение за период, но нельзя утверждать, что конкретная операция точно вызвала o1.

Причина fallback LiteLLM

Обычный запрос может попасть на o1 после тайм-аута, ошибки совместимости, недоступности локального сервиса или правила повторной попытки. LiteLLM не обязан понимать сложность задачи. Поэтому в расследовании нужны исходный статус, условие fallback и конечный model, а не предположение, что шлюз автоматически распределил работу по интеллектуальной сложности.

Сверка reasoning tokens

Сначала сопоставьте usage в ответе OpenAI API и в биллинговой записи с полями, сохранёнными LiteLLM. Не используйте длину видимого ответа как замену reasoning tokens. Если прокси объединил или удалил нужные поля, точная сверка невозможна до исправления логирования, даже если итоговый текст и статус запроса выглядят корректно.

Локальный Qwen3-Coder и растущий облачный расход

Локальный ответ подтверждает только конкретное событие. Параллельные tool calls, продолжения Agent, повтор после ошибки и другие сессии могли уйти в облако. Сверьте все request ID и временные метки, затем отдельно воспроизведите локальное попадание, намеренный вызов o1 и отказ локального endpoint с fallback.

После такой проверки выбор обычно становится техническим, а не эмоциональным. Текущая схема «Cursor напрямую через общий прокси» имеет три типичных недостатка: интерфейс может скрывать реальный deployment, шлюз способен потерять usage при несовместимой потоковой выдаче, а локальная ошибка может незаметно превратить обычную задачу в облачный повтор. Если причина именно в нестабильности локального узла, аренда Mac через JexMac даёт более управляемую временную среду для воспроизводимого тестирования, чем срочная покупка оборудования или расширение неаудированного прокси. Но при постоянной тяжёлой нагрузке и потребности в физических интерфейсах собственный узел может оказаться рациональнее; аренда имеет смысл прежде всего для временной мощности, проверки маршрута и контролируемого эксперимента.

FAQ