GPT-6.1 Terra стоит $1 за миллион входных токенов. А сколько стоит законченная задача?

Оригинальная редакционная схема Ken Jo на основе источников, перечисленных ниже.

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

OpenAI представила GPT-6.1 Terra 26 октября 2026 года со стандартными тарифами API: $1 за миллион входных токенов, $0,05 за миллион кэшированных входных токенов и $5 за миллион выходных токенов. Компания позиционирует модель для визуального анализа, работы с компьютером и написания текстов и сообщает, что эти стандартные тарифы на 50% ниже тарифов GPT-5.6 Terra и GPT-6.1 Sol. Официальный анонс, датированная системная карточка.

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

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

Terra — модель OpenAI, компании, создавшей ChatGPT и Codex. Её выбор даёт приложению определённые языковые и визуальные возможности. При этом само приложение определяет, какой экран модель видит, какие инструменты может вызывать и к каким учётным записям эти инструменты имеют доступ.

Рассмотрим работу со счётом как условный пример. Модель наблюдает форму, предлагает действие и получает обновлённое изображение после его выполнения инструментом. Новое изображение важно: внешне правильный щелчок может открыть другую панель, показать ошибку проверки или оставить сохранение незавершённым. Прежде чем продолжать, процесс должен определить получившееся состояние.

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

В документации OpenAI по работе с компьютером, проверенной 27 октября, события браузерной активности отделены от итогового статуса всего хода. Документация также описывает управление включением снимков экрана в потоковый вывод. Разработчик может показывать ход выполнения через эти события и отдельно проверять существование запрошенного результата.

Условный цикл работы с компьютером. Приложение предоставляет инструменты и разрешения; проверка приёмки устанавливает, завершена ли запрошенная работа. Это авторская схема, а не снимок интерфейса OpenAI.

Таблица тарифов — отправная точка для бюджета задачи

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

В карточке модели, проверенной 27 октября, перечислены дополнительные условия. Запись в кэш имеет отдельные тарифы, запросы свыше 272 000 входных токенов запускают корректировки для длинного контекста, а режим обслуживания может менять цену. Используйте тариф, применимый к реальному запросу, вместо того чтобы считать минимальную строку таблицы универсальной ставкой.

В следующем примере предполагаются стандартная обработка, отсутствие кэша и запросы ниже порога длинного контекста. Каждая попытка расходует 10 000 тарифицируемых входных и 1 000 выходных токенов. Получается $0,01 + $0,005 = $0,015 за попытку. Числа токенов выбраны для расчёта; это не измерение Terra или процесса обработки счетов.

На этом различии строится полезный бюджет. Сначала определите стоимость одной попытки при явных предположениях. Затем выясните, сколько попыток нужно процессу, какими дополнительными сервисами он пользуется и какой объём проверки требуется до принятия результата.

Повторные попытки и проверка меняют стоимость принятой работы

Предположим, условная партия содержит 100 заданий. В одном сценарии система делает 100 попыток, из которых приняты 90 заданий. В другом восстановительные действия увеличивают число попыток до 150, а принятых заданий становится 95. Дополнительные успешные результаты полезны, но сравнение затрат уже изменилось.

Таблица добавляет третий сценарий: 30 элементов проверяет человек по 20 секунд, при условной стоимости труда $30 в час. Это 600 секунд, или 10 минут, стоимостью $5. Все объёмы работы, количества принятых заданий и предположения о труде здесь иллюстративны; измеренные результаты продукта не приводятся.

В знаменателе находятся принятые задания, а не сгенерированные ответы. Красиво сформулированное сообщение об успехе не увеличивает это число, если запись сохранена неправильно. Напротив, процесс, который просит короткое уточнение, может дать более полезный результат, чем процесс, уверенно продолжающий работу без необходимых данных.

Назовём дополнительные усилия счётом за завершение: это ресурсы, нужные для превращения попытки действия в принятый результат. Тариф на токены — одна строка такого счёта. Другими могут стать оплата инструментов, среда выполнения, восстановление и проверка человеком. Эти дополнительные сервисы не включены в таблицу, чтобы расчёт оставался наглядным; производственная оценка должна учитывать те из них, которые использует реальная интеграция.

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

Начните с черновой записи счёта с чётким критерием завершения

Первый практический сценарий — помощник по кредиторской задолженности, создающий черновую запись по предоставленному счёту. Используйте тестовую учётную запись и ограниченный набор документов. До взаимодействия модели с формой определите обязательные поля поставщика, валюты, суммы и номера документа.

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

В испытание нужно включить обычные документы и заведомо сложные примеры: неясную валюту, отсутствующий идентификатор поставщика или уже существующий номер счёта. Они выявляют разные виды сбоев. Правильно прочитать текст, выбрать нужную учётную запись и избежать дубликата — отдельные части работы.

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

Это пример устройства приложения, а не утверждение, что Terra поставляется с бухгалтерским коннектором или что для этой статьи проверялся конкретный бухгалтерский продукт. Модель — один компонент процесса, инструменты и бизнес-правила для которого необходимо предоставить отдельно.

Сопоставление каталога проверяет визуальное суждение до действия

Второй сценарий — сопоставление фотографии товара с существующей записью каталога. В карточке Terra от OpenAI, проверенной 27 октября, сопоставление фотографий товаров прямо названо одним из предполагаемых применений. Для продавца полезным результатом может быть предложенное совпадение с достаточным объяснением, чтобы проверяющий отличил визуально похожий товар от правильного.

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

Неопределённый результат может быть правильным. Если две упаковки различаются только невидимыми на фото сведениями, процессу нужна другая фотография или невизуальный идентификатор. Убедительное описание упаковки не создаёт доказательств, которых не было во входных данных.

Начните с предложений совпадений, прежде чем разрешать правки каталога. Так легче проверить правило приёмки и получить понятный команде набор ошибок. Если позднее приложение добавит создание текста, оцените, сохраняет ли черновик проверенные факты каталога, а не добавляет неподтверждённые детали на основании внешнего сходства.

Старый портал превращает восстановление в часть задачи

Третий сценарий — подготовка чернового обновления во внутреннем портале с браузерным интерфейсом. Задание может включать поиск записи, замену описания предоставленным текстом и подготовку результата к утверждению человеком. Польза возникает, когда понятный рабочий запрос связывается с последовательностью действий в интерфейсе.

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

Задайте бюджет восстановления до испытания. Например, приложение может разрешить одно повторное наблюдение после неясного сохранения, а затем остановиться для проверки, если результат по-прежнему неопределён. Это условное правило, а не ограничение Terra. Оно задаёт проверяемое поведение и помогает не тратить ресурсы на бесплодный цикл.

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

Доступность показывает точку старта, а не права каждой учётной записи

В анонсе 26 октября объявлена доступность Terra в ChatGPT Work и Codex для Plus, Pro, Enterprise и Edu, а также идентификатор API gpt-6.1-terra. Это способы доступа к модели. Инструменты и разрешения конкретного процесса по-прежнему зависят от используемого продукта, учётной записи и интеграции.

Для разработчиков карточка модели, проверенная 27 октября, указывает Responses API для вызова инструментов и medium как стандартный уровень усилия рассуждения. Записывайте выбранную модель и настройки рассуждения, чтобы осмысленно сравнивать два испытания. Одновременная смена модели, инструкций и инструментальной среды затрудняет интерпретацию разницы.

Команде, работающей в Work или Codex, стоит начать с уже поддерживаемого процесса и изучить его реальные средства управления. Для собственного приложения настройте среду выполнения и разрешённые действия по актуальной документации интеграции. Сам идентификатор модели не создаёт авторизованного подключения к приложениям компании.

Сравнивайте настройки на одинаковых принимаемых задачах

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

1. Выберите ограниченное задание. Назовите требуемый результат и человека, который решит, приемлем ли он. Для первого испытания предпочтительны черновик или действие в тестовой среде.
2. Подготовьте фиксированный набор случаев. Включите обычные входные данные, пропуски информации и значимые прерывания интерфейса. Не передавайте ожидаемые результаты в инструкции модели.
3. Запишите конфигурацию. Сохраните идентификатор модели, настройку рассуждения, инструкции, версию инструмента и необходимые права учётной записи.
4. Определите правила остановки и восстановления. Укажите, когда допустимо новое наблюдение, когда полезна повторная попытка и когда неопределённость должен разрешить человек.
5. Фиксируйте наблюдаемые результаты. Записывайте принятые и неверные результаты, неопределённые случаи, попытки, время и тарифицируемый расход. Статус операции инструмента — лишь часть записи.
6. Добавьте реальные эксплуатационные затраты. Учтите применимые расходы на инструменты и среду, а также измеренное время проверки. Делите на принятые задания при одинаковых определениях.
7. Меняйте одну существенную переменную. Сравните новую инструкцию или настройку рассуждения на тех же случаях, затем разберите изменившиеся ошибки до расширения испытания.

Предлагаемая модель затрат: сложите реально потребляемые процессом ресурсы и разделите на принятые задания. Это рамка оценки, а не опубликованные измерения работы Terra.

Такая запись полезна, даже если первое испытание разочаровало. Она показывает, что улучшать: визуальную интерпретацию, устройство процесса, надёжность инструментов или объём человеческих исправлений. Это гораздо более надёжное основание для выбора следующей автоматизации, чем одна средняя стоимость запроса.

Дешёвая работа с компьютером важна, когда доступнее становится завершение

Более низкие стандартные тарифы Terra дают возможность тщательнее тестировать и выполнять больше работы в рамках бюджета. Бизнес-вопрос заключается в том, сможет ли конкретная интеграция превратить эту возможность в принимаемые результаты при управляемых затратах на проверку и восстановление.

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

Источники

• Introducing GPT-6.1 Terra, OpenAI, 26 октября 2026 года: позиционирование, стандартные стартовые тарифы и способы доступа.
• Системная карточка GPT-6.1 Terra, OpenAI, 26 октября 2026 года: датированный выпуск и контекст оценки.
• Карточка модели GPT-6.1 Terra, проверена 27 октября 2026 года: идентификатор модели, API для инструментов, настройка рассуждения и условия тарификации.
• Документация интеграции работы с компьютером, проверена 27 октября 2026 года: браузерная активность, снимки экрана и механизм интеграции.

Три рабочих сценария, исходные данные расчёта и процедура оценки приведены как примеры. Расчёты в долларах используют указанные стандартные тарифы и явно выбранные допущения; это не измеренные задержки, точность или эксплуатационные расходы.

---

Рекомендация Telli.sh: Сохраняйте заметки об испытаниях, справочные материалы и причины изменений процесса так, чтобы к ним было легко вернуться. Создайте аккаунт Telli.sh для организации заметок об оценке.