Как ChatGPT/Codex ищет в интернете: инструменты и сравнение расхода токенов

Когда в ChatGPT или Codex просят «исследовать» тему, агент не обязательно открывает один и тот же универсальный браузер. В зависимости от интерфейса, доступных инструментов и самой задачи он может использовать внутренний Web Search, встроенный браузер, внешний Chrome/Edge через расширение или структурированный плагин/MCP-инструмент. Эти механизмы дают разный контекст, решают разные задачи и обычно создают разную нагрузку на токеновый бюджет.

Главный вывод: внутренний Web Search и встроенный @Browser — не одно и то же. Встроенный @Browser и внешний @Chrome ближе друг к другу, потому что оба относятся к браузерной автоматизации/Computer Use, но работают в разных профилях и с разным пользовательским контекстом.

Какие способы веб-доступа есть у ChatGPT и Codex

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

Инструмент	Лучший сценарий	Относительный расход
Web Search	Публичные факты и поиск источников	Низкий или умеренный
Плагин / MCP / API	Структурированные данные и повторяемые операции	Часто низкий или умеренный
Встроенный @Browser	Интерактивные сайты и визуальная проверка	Обычно умеренный или высокий
Внешний @Chrome / @Edge	Авторизованные кабинеты и текущая сессия	Обычно умеренный или высокий

Механизм	Что реально происходит	Когда особенно полезен	Ожидаемый относительный расход
Web Search	Модель вызывает hosted-инструмент поиска и получает результаты из поискового индекса либо из live-веба. Страницей как интерфейсом она не управляет.	Публичные факты, свежие новости, документация, первичный список источников, сравнение нескольких сайтов.	Обычно самый низкий или умеренный.
Встроенный @Browser	ChatGPT/Codex открывает страницу в отдельном встроенном профиле, кликает, вводит текст, читает rendered-состояние, при необходимости делает скриншоты.	JavaScript-сайты, формы, визуальная проверка, localhost, таблицы и страницы, которые плохо раскрываются через поиск.	Обычно выше Web Search из-за последовательности действий и повторного чтения состояния страницы.
Внешний @Chrome / @Edge	Официальное расширение даёт агенту доступ к выбранному обычному браузеру, его вкладкам и авторизованному профилю в пределах разрешённых сайтов.	Личные кабинеты, CRM, сервисы с логином, уже открытые вкладки, выделенный текст, работа с текущей пользовательской сессией.	Сопоставим со встроенным браузером; сложный интерфейс может увеличить расход.
Плагин / MCP / API	Модель вызывает специализированный инструмент и получает структурированные данные или выполняет конкретное действие без ручной навигации по интерфейсу.	Gmail, Drive, GitHub, базы данных, повторяемый extraction, массовые операции, точное чтение полей.	Часто ниже браузера, если ответ инструмента компактный; может стать высоким при больших payload или полном HTML/DOM.

Почему Web Search и встроенный браузер — разные вещи

Web Search — это поисковый tool call: агент формулирует запрос, получает результаты и релевантные фрагменты, после чего решает, нужен ли следующий запрос. Он не обязан визуально загружать страницу, прокручивать её и нажимать элементы.
Встроенный браузер — это уже управляемая веб-сессия. Агент видит состояние страницы после загрузки, может открыть меню, нажать кнопку, заполнить форму, проверить результат и повторить цикл. Поиск Google из адресной строки встроенного браузера тоже остаётся обычным действием внутри браузерной сессии и не превращается во внутренний инструмент Web Search.

Почему @Browser и @Chrome тоже не идентичны

У встроенного @Browser отдельный профиль и отдельная история. Он не получает автоматически вкладки, cookies и сессии из обычного Chrome. В нужный аккаунт можно войти непосредственно во встроенном браузере, но это всё равно отдельное окружение.
Расширение для @Chrome, @Edge, @Brave, @Opera или @Vivaldi, наоборот, подключается к вашему обычному браузеру. ChatGPT может использовать контекст открытой вкладки, выделенный текст и сайты, где пользователь уже авторизован. Поэтому различие прежде всего не в «качестве поиска», а в доступном контексте и состоянии сессии. Читать полный обзор сервиса ChatGPT.

Внутренний Web Search: cached и live-режимы

В локальных задачах Codex CLI и IDE Extension Web Search включён по умолчанию. Стандартный режим использует поддерживаемый OpenAI кэш поисковых результатов. Он возвращает предварительно проиндексированные данные и обычно подходит для стабильной документации и фактов, которые не меняются ежедневно.
Для новостей, текущих тарифов, цен, расписаний, законов, свежих релизов и любых данных, где важна сегодняшняя актуальность, лучше явно включать live-поиск. Его можно задать в конфигурации или включить флагом командной строки.

web_search = "cached"    # режим по умолчанию: кэш поисковых результатов
web_search = "live"      # получает самые свежие данные из веба
web_search = "disabled"  # отключает инструмент поиска

codex --search "Изучи последние изменения..."

Важно: встроенный браузер недоступен в Codex CLI и IDE Extension. Там исследование открытого интернета обычно строится вокруг Web Search, shell/network-доступа в разрешённой среде и подключённых инструментов. Браузерный @Browser для Codex используется в desktop-приложении ChatGPT/Codex; доступность отдельных возможностей может зависеть от rollout и настроек workspace.

Когда Web Search — лучший выбор

• Нужно быстро собрать 10–30 источников по публичной теме.
• Нужно найти официальную документацию, changelog, новости или несколько независимых подтверждений.
• Нужно сравнить сервисы по ценам, функциям и ограничениям без действий в личном кабинете.
• Нужно минимизировать расход и не требуется визуально проверять интерфейс каждой страницы.

Встроенный @Browser: управляемая отдельная веб-сессия

Встроенный Browser умеет открывать страницы, кликать, вводить текст, анализировать rendered-состояние, делать скриншоты и проверять результат действий. В Developer mode он также может получать контролируемый доступ к Chrome DevTools Protocol: анализировать DOM, стили, console, network и производительность.
Это делает @Browser особенно полезным для задач, где важен не только текст страницы, но и то, как она реально работает: динамические фильтры, графики, модальные окна, формы, авторизация, ошибки JavaScript и локальные веб-приложения.

Когда открывать страницу через @Browser

• Web Search нашёл источник, но не смог получить нужную таблицу, график или динамически загружаемые данные.
• Нужно проверить визуальное состояние: адаптивность, вёрстку, наличие кнопки, форму, ошибку или результат изменения.
• Нужно протестировать localhost и связать браузерную проверку с правками кода.
• Нужно выполнить несколько действий на сайте, но нежелательно использовать основной пользовательский профиль.

Внешний браузер через расширение: @Chrome, @Edge и другие

Официальное расширение ChatGPT поддерживает Chrome, Edge, Brave, Opera и Vivaldi. После настройки в desktop-приложении нужный браузер выбирают через @-mention: например, @Chrome или @Edge.
Главное преимущество — работа с существующим браузерным контекстом. Агент может использовать открытую вкладку, переданный фрагмент страницы и авторизованную сессию в пределах разрешений. Это не «более мощный поисковик», а доступ к реальному рабочему окружению пользователя.

Когда внешний браузер лучше встроенного

• Нужны cookies и уже выполненная авторизация в CRM, аналитике, рекламном кабинете или внутренней системе.
• Нужно изучить конкретную открытую вкладку, а не искать страницу заново.
• Нужно использовать выделенный на странице текст или контекст нескольких существующих вкладок.
• Нужно продолжить работу в привычном браузерном профиле, сохранив текущие настройки и расширения.

Плагины, MCP и site tools: часто лучший путь к данным

Когда сервис предоставляет специализированную интеграцию, плагин или MCP-инструмент, агент может получить структурированные данные напрямую. Например, вместо того чтобы открыть почту, прокрутить список писем и читать интерфейс, он вызывает поиск Gmail и получает сообщения в предсказуемой схеме.
Такой путь часто экономнее браузера: меньше визуального шума, меньше действий, проще повторная проверка. Но экономия не гарантирована. MCP-сервер, который на каждый шаг возвращает полный HTML, гигантское accessibility tree или десятки тысяч строк JSON, способен раздувать контекст сильнее браузера.
Отдельная разновидность — site tools/WebMCP во встроенном браузере. Они позволяют сайту предложить агенту структурированные операции вместо ручных кликов. На момент подготовки материала OpenAI указывает поддержку site tools для GPT-5.6 Sol и Terra; Luna для них не поддерживается. Для понимания этого подхода пригодится статья о WebMCP и работе ИИ-агентов с сайтами.

Как на самом деле считается расход токенов

OpenAI не публикует фиксированную цену вида «один web search = N токенов», «один клик = N credits» или «одна открытая страница = N токенов». Для Codex и агентных задач расход зависит от фактически использованных input tokens, cached input tokens и output tokens.
На итог также влияют выбранная модель, накопленный контекст диалога, reasoning effort, количество tool calls, retrieval, размер ответов инструментов, число просмотренных страниц, скриншоты, повторные проверки и кеширование. Поэтому два внешне похожих запроса могут расходовать заметно разный объём.

Инструмент	Что попадает в контекст	Почему расход растёт	Практическая оценка
Web Search	Поисковые запросы, результаты, сниппеты и выбранные фрагменты источников.	Много итераций поиска, длинные страницы, большой список источников, повторное уточнение запросов.	Обычно низкий–умеренный.
Структурированный плагин/MCP	Поля и объекты, возвращённые конкретной интеграцией.	Слишком широкий запрос, большие JSON-ответы, полный HTML/DOM, десятки вложенных объектов.	Часто низкий–умеренный.
Встроенный @Browser	Состояние страницы, текст/DOM, скриншоты, результаты каждого действия и reasoning между шагами.	Длинная цепочка «посмотреть → кликнуть → проверить», сложный UI, popup, перезагрузки, визуальные проверки.	Обычно умеренный–высокий.
Внешний @Chrome/@Edge	То же плюс контекст реальной вкладки и авторизованной сессии, который нужен задаче.	Много открытых состояний, тяжёлые dashboards, сложная навигация, несколько вкладок, повторные действия.	Обычно умеренный–высокий.

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

Web Search часто укладывается в несколько циклов: сформулировать запрос, получить результаты, выбрать источники, уточнить поиск и написать вывод. Браузерная задача чаще превращается в агентный цикл с большим числом состояний:

посмотреть страницу
→ решить, куда нажать
→ выполнить действие
→ получить новый DOM / скриншот / состояние
→ снова проанализировать
→ прокрутить или открыть следующую страницу
→ повторить

Каждый шаг может добавить в контекст описание интерфейса, текст страницы, изображение, результат действия и новые reasoning/output tokens. Поэтому при исследовании двадцати публичных источников обычно выгоднее сначала найти и отсортировать их через Web Search, а Browser использовать только для нескольких проблемных страниц.

Есть ли разница между расходом @Browser и @Chrome

Отдельного официального коэффициента для встроенного и внешнего браузера OpenAI не публикует. При одинаковом количестве действий и сопоставимом объёме страницы расход должен определяться теми же общими факторами. На практике @Chrome может оказаться тяжелее, если авторизованный интерфейс сложнее, содержит много виджетов, popup и данных из нескольких вкладок. Но это следствие контента и числа шагов, а не известного фиксированного множителя.

Тарифные коэффициенты GPT-5.6 Sol, Terra и Luna

Для поддерживаемой token-based credit-модели Codex/OpenAI публикует следующие ставки на один миллион токенов. Они позволяют сравнить стоимость одинакового объёма работы на разных моделях.

Модель	Input tokens	Cached input	Output tokens
GPT-5.6 Sol	100 credits / 1M	10 credits / 1M	500 credits / 1M
GPT-5.6 Terra	50 credits / 1M	5 credits / 1M	300 credits / 1M
GPT-5.6 Luna	5 credits / 1M	0,5 credits / 1M	30 credits / 1M

Из этих ставок следует: Terra примерно вдвое дешевле Sol по входным токенам и на 40% дешевле по выходным. Luna в 20 раз дешевле Sol по input и примерно в 16,7 раза дешевле по output. При этом более дешёвая модель может сделать больше шагов или потребовать повторной проверки, поэтому реальная экономия зависит от качества выполнения задачи, а не только от ставки.

Формула расчёта

credits = input_tokens / 1 000 000 × input_rate
        + cached_input_tokens / 1 000 000 × cached_rate
        + output_tokens / 1 000 000 × output_rate

Пример: 100 000 input tokens + 20 000 output tokens

Предположим, что одинаковая задача на каждой модели использовала 100 тысяч обычных входных токенов и 20 тысяч выходных, без cached input. Тогда расчёт выглядит так:

Модель	Input	Output	Итого
Sol	0,1 × 100 = 10	0,02 × 500 = 10	20 credits
Terra	0,1 × 50 = 5	0,02 × 300 = 6	11 credits
Luna	0,1 × 5 = 0,5	0,02 × 30 = 0,6	1,1 credits

Это иллюстрация ставок, а не обещание одинакового поведения моделей. Sol, Terra и Luna могут сделать разное количество запросов, reasoning-шагов, browser actions и повторных проверок, поэтому фактический объём токенов одной и той же задачи может отличаться.
В актуальной rate card OpenAI также указывает ориентир: типичная задача Codex на GPT-5.6 Sol может расходовать примерно 5–30 credits. Это широкий диапазон, и конкретное значение зависит от размера и сложности задачи. В старой legacy-схеме для небольшого числа Enterprise-клиентов приводились средние около 14 credits для Sol, 6 для Terra и 1 для Luna за локальное сообщение; эти legacy-цифры не следует переносить на большинство текущих аккаунтов.

Оценочные лимиты локальных сообщений

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

Модель	Plus / Business	Pro 5×	Pro 20×
GPT-5.6 Sol	10–100	50–500	200–2 000
GPT-5.6 Terra	25–200	125–1 000	500–4 000
GPT-5.6 Luna	250–2 000	1 250–10 000	5 000–40 000

Какая модель лучше всего подходит для сбора информации

Официальное позиционирование семейства совпадает с практической логикой: Sol предназначен для сложной открытой работы и глубокого исследования, Terra — универсальная рабочая модель с сильным reasoning и tool use, Luna — быстрый и дешёвый вариант для чётких повторяемых операций.

Модель / режим	Лучше всего подходит	Сильная сторона	Ограничение
Terra Medium	Повседневный ресерч сервисов, SEO-площадок, тарифов, конкурентов, документации и отзывов.	Лучший баланс качества, tool use и расхода.	Может уступить Sol в сложной оценке противоречивых источников.
Sol Medium / High	Неоднозначные темы, юридические/финансовые детали, deep research, стратегические выводы, финальная редактура.	Лучшее суждение, глубина, проверка и качество синтеза.	Самая высокая ставка и обычно больший расход.
Luna Low / Medium	Extraction, классификация, нормализация, рерайт, обработка заранее отобранных URL и структурированные summaries.	Очень низкая цена и высокий объём.	Хуже подходит для самостоятельного отбора источников и разрешения противоречий; site tools/WebMCP недоступны.
Ultra	Большое исследование, которое естественно делится на независимые направления и subagents.	Параллельная проработка нескольких частей.	Может резко увеличить общий объём работы; большинство задач не требует Ultra.

Оптимальный вариант для большинства исследований: Terra Medium

Для типичных задач вроде «изучи сервис», «сравни площадки», «найди свежие кейсы», «собери тарифы и отзывы» разумная стартовая конфигурация — GPT-5.6 Terra с Medium reasoning и live Web Search. Она заметно дешевле Sol, но сохраняет достаточно сильный reasoning и работу с инструментами.

Модель: GPT-5.6 Terra
Reasoning: Medium
Web Search: live
Browser: только для страниц, которые нельзя надёжно проверить через поиск

Когда переходить на Sol

• Источники противоречат друг другу, и нужно оценить качество доказательств.
• Тема неоднозначная, дорогая или рискованная: право, финансы, безопасность, сложная техническая архитектура.
• Нужен не просто сбор ссылок, а самостоятельная стратегия, выводы и polished-материал.
• Нужно качественно объединить результаты нескольких веток исследования и проверить пробелы.

Когда достаточно Luna

• Список URL уже собран и нужно извлечь из каждой страницы одинаковые поля.
• Есть чёткий JSON/schema и заранее известно, как выглядит правильный результат.
• Нужно массово классифицировать, нормализовать, сокращать или переписывать данные.
• Ошибки легко выявляются автоматической проверкой или выборочным контролем.

Практический исследовательский pipeline

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

1. Terra Medium + live Web Search: найти источники, классифицировать их и сохранить подтверждающие фрагменты.
2. Открывать @Browser или @Chrome только для страниц с JavaScript, закрытым контентом, визуальными таблицами, формами или авторизацией.
3. Передать компактную таблицу находок Sol Medium/High для проверки качества источников, разрешения противоречий и финального вывода.

Готовая инструкция для первого этапа

Используй live Web Search как основной инструмент. Сначала найди и классифицируй источники. Не открывай Browser без необходимости. Для каждого важного вывода сохрани URL, дату публикации и подтверждающий фрагмент. Отделяй подтверждённые факты от предположений и рекомендаций.

Инструкция для точечного браузерного этапа

Через @Browser открой только страницы, где:

• Web Search не получил полный текст;
• данные генерируются JavaScript;
• есть таблица, график или визуальное состояние;
• нужно проверить авторизованный интерфейс;
• между источниками осталось противоречие.

Инструкция для финального анализа

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

Итоговая рекомендация

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

Задача	Рекомендуемая связка
Повседневное исследование публичной темы	Terra Medium + live Web Search → Browser точечно
Сложное исследование и итоговый стратегический вывод	Terra для сбора → Sol Medium/High для синтеза
Работа в личном кабинете или с текущей авторизацией	Terra Medium + @Chrome / @Edge
Массовое извлечение из заранее отобранных страниц	Luna Low/Medium + структурированный MCP/API
Визуальная проверка сайта или localhost	Sol/Terra + @Browser, при необходимости Developer mode

Практичная формулировка для контроля бюджета: «Используй Web Search как основной инструмент, Browser — только при необходимости, максимум N страниц через Browser, а перед финальным выводом покажи список источников и пробелы». Она не гарантирует фиксированное число токенов, но сокращает ненужные агентные циклы и делает исследование проверяемым.

Источники OpenAI

• Codex / ChatGPT Browser — возможности встроенного браузера и отдельный профиль
• Browser extension — Chrome, Edge, Brave, Opera и Vivaldi, вкладки и авторизованный профиль
• ChatGPT & Codex changelog — cached/live Web Search и site tools/WebMCP
• Codex models — назначение GPT-5.6 Sol, Terra, Luna и режимов reasoning/Ultra
• Codex pricing — оценочные лимиты локальных сообщений и факторы расхода
• ChatGPT Rate Card — token-based credit rates и формула фактического потребления

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