Запустіть gpt-researcher на кастомному OpenAI-сумісному ендпоінті.

Коротка відповідь: п'ять рядків у .env.

Задокументований шлях кастомного ендпоінта gpt-researcher — змінні середовища. Встановіть OPENAI_BASE_URL на https://api.apisrouter.com/v1, встановіть OPENAI_API_KEY на ваш ключ шлюзу й призначте три слоти моделей з префіксом провайдера openai:. Префікс каже gpt-researcher, який клієнт використовувати; рядок після двокрапки пересилається до ендпоінта, тож валідний будь-який id, який обслуговує шлюз, включно з id Claude і Gemini. Це конфігурація, задокументована на docs.gptr.dev для кастомних OpenAI-сумісних ендпоінтів, і вона працює ідентично для pip-пакета, веб-застосунку й мультиагентних потоків, оскільки всі вони резолвлять ту саму конфігурацію.

OPENAI_BASE_URL=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FAST_LLM=openai:claude-haiku-4-5-20251001
SMART_LLM=openai:claude-sonnet-4-6
STRATEGIC_LLM=openai:gpt-5.5

Як gpt-researcher витрачає токени на три слоти.

gpt-researcher (assafelovic на GitHub, приблизно 28 тис. зірок) перетворює запит на досліджений, процитований звіт: він планує дослідницькі питання, розгалужує веб-пошуки через рітрівер, скрейпить і підсумовує джерела, а потім пише розлогий звіт. Фреймворк розділяє цей конвеєр на три налаштовувані слоти моделей замість одного. FAST_LLM обробляє об'ємну роботу з низькими ставками, головним чином підсумовування скрейпнутих сторінок. SMART_LLM робить важке написання, включно з фінальним звітом. STRATEGIC_LLM обробляє планування: генерацію дослідницьких питань і вибір підходу. За замовчуванням вони налаштовані на моделі OpenAI (gpt-4o-mini, gpt-4.1 і o4-mini відповідно на момент написання), що й пояснює, чому єдине перевизначення OPENAI_BASE_URL настільки ефективне: усі три слоти використовують клієнт у формі OpenAI, тож один base URL рухає весь конвеєр. Оскільки кожен слот бере власний рядок provider:model, слотам не потрібно ділити постачальника. Прогін може підсумовувати швидкою моделлю Claude, писати сильнішою моделлю Claude чи GPT і планувати моделлю рівня міркування — усе через той самий ендпоінт і ключ. На ключі одного постачальника такий мікс вимагав би трьох облікових записів; за шлюзом це три рядки в .env.

Повне налаштування: .env плюс Python API.

Створіть файл .env у вашій робочій директорії (чи експортуйте змінні в оболонці) і запускайте gpt-researcher як зазвичай; pip-пакет і веб-застосунок обидва зчитують те саме середовище. Python API взагалі не потребує коду, специфічного для ендпоінта, у чому й суть: маршрутизація — це конфігурація, і дослідницький код лишається ідентичним, чи то ендпоінт OpenAI, чи шлюз. Два суміжні налаштування мають значення. Веб-пошук йде через рітрівер, за замовчуванням Tavily, з власним ключем (TAVILY_API_KEY); ці облікові дані незалежні від ендпоінта LLM і все ще потрібні для живого веб-дослідження. А ембедінги за замовчуванням — openai:text-embedding-3-small, тож виклики ембедінга йдуть за тією самою конфігурацією клієнта у формі OpenAI; якщо ендпоінт за OPENAI_BASE_URL не обслуговує цю модель ембедінга, налаштуйте EMBEDDING на провайдера, який обслуговує (документація використовує префікс custom: для OpenAI-сумісних ендпоінтів ембедінга, а також підтримуються локальні варіанти на кшталт Ollama).

import asyncio
from gpt_researcher import GPTResearcher

async def main():
    researcher = GPTResearcher(
        query="State of small modular reactors in 2026",
        report_type="research_report",
    )
    await researcher.conduct_research()
    report = await researcher.write_report()
    print(report)

asyncio.run(main())  # routing comes entirely from .env

Вибір моделі для кожного слоту.

Апстрим-значення за замовчуванням кодують правильну форму: маленька модель для об'єму, сильна модель для написання, модель міркування для планування, тож тримайте цю форму й підвищуйте слоти, а не зводьте їх до однієї моделі. За одним ендпоінтом A/B двох авторів — це зміна одного рядка .env на прогін, а лог використання за ключем каже, скільки насправді коштувала кожна конфігурація звіту.

• FAST_LLM спрацьовує найчастіше: кожне скрейпнуте джерело підсумовується. Швидкий id (claude-haiku-4-5-20251001, deepseek-v4-flash) не дає звіту з багатьма джерелами бути домінованим вартістю підсумовування, а втрата якості тут обмежена, бо підсумки живлять автора, а не читача.
• SMART_LLM пише звіт, який користувач насправді читає. Довгий вивід, стійка структура, дисципліна цитування: тут claude-sonnet-4-6 чи gpt-5.5 заробляють свою ціну, і саме тут падіння якості видно одразу.
• STRATEGIC_LLM формує прогін до його початку. Погані дослідницькі питання дають поганий звіт незалежно від того, наскільки хороший автор; сильна в міркуванні модель тут — мало викликів, але великий важіль.
• Id з довгим контекстом, такі як gemini-3.1-pro-preview, варто протестувати в слоті SMART для прогонів detailed_report, де автор працює над великим накопиченим контекстом підсумків.

Оплата за фактом · нижче офіційних цін

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Збої, специфічні саме для gpt-researcher.

Втрата префікса провайдера. Формат слоту — provider:model, і префікс обирає клієнта. Встановлення SMART_LLM=claude-sonnet-4-6 без openai: не маршрутизує id Claude через ваш base URL; це змушує gpt-researcher намагатися інтерпретувати рядок як іншого провайдера. Кожна модель кастомного ендпоінта має тримати префікс openai:, бо "openai" тут називає протокол, а не постачальника. Ембедінги тихо слідують за перевизначенням. Типовий EMBEDDING — модель у формі OpenAI, тож щойно OPENAI_BASE_URL вказує на шлюз, запити ембедінга теж туди йдуть. Якщо шлюз не обслуговує цю модель ембедінга, дослідницькі прогони провалюються під час обробки джерел, а не на першому виклику чату, що вводить в оману й змушує налагоджувати не той слот. Встановіть EMBEDDING явно, і симптом зникає. Звинувачення ендпоінта в збоях рітрівера. Відсутній чи вичерпаний TAVILY_API_KEY ламає фазу пошуку, і результуючі помилки порожніх джерел поверхово виглядають як збої LLM. Рітрівер — окремий сервіс з окремим ключем; перевіряйте його окремо. Застаріле середовище між прогонами. Файл .env зчитується з робочої директорії. Запуск веб-застосунку з однієї директорії й Python API з іншої означає дві різні конфігурації, і "працює в застосунку, але не в моєму скрипті" майже завжди саме це. Налаштування ліміту токенів окремі від можливостей моделі. gpt-researcher несе власні ліміти токенів на слот (FAST_TOKEN_LIMIT, SMART_TOKEN_LIMIT і суміжні налаштування) з консервативними значеннями за замовчуванням. Спрямування SMART_LLM на модель з довгим контекстом само по собі не піднімає ці ліміти; налаштуйте їх свідомо, якщо хочете довших генерацій.

Хто спрямовує gpt-researcher через шлюз.

• Команди, що генерують регулярні звіти (огляди ринку, огляди літератури, конкурентні брифи), де видимість вартості на прогін по трьох слотах моделей важливіша за стосунки з одним постачальником.
• Дослідники, що порівнюють моделі-автори. Тримання FAST і STRATEGIC фіксованими, поки SMART міняється між id Claude, GPT і DeepSeek, — це три редагування .env, а не три облікові записи постачальника.
• Будівники, що вбудовують gpt-researcher у продукти, де один ключ шлюзу на середовище заміняє пакет секретів постачальників у конвеєрі деплою.
• Користувачі, що хочуть, щоб Claude чи Gemini писали звіт, лишаючи стандартну конфігурацію gpt-researcher у формі OpenAI недоторканою.
• Розробники без доступу до білінгу певного постачальника. Доступ на основі поповнення без вимоги картки прибирає залежність від реєстрації в кожного провайдера.

Перевірте ендпоінт і налагодьте перший звіт.

Спершу перелічіть моделі шлюзу; рядок після openai: у кожному слоті має точно збігатися з обслуговуваним id, включно з суфіксами версій. Збої першого прогону сортуються чисто. 401 означає, що OPENAI_API_KEY відсутній у середовищі, яке процес насправді бачить; файли .env завантажуються з робочої директорії, тож запускайте звідти, де живе файл, або експортуйте змінні глобально. Помилка model-not-found називає слот з одруківкою. Збій під час обробки джерел, а не на етапі планування, вказує на ембедінги чи рітрівер, а не на слоти чату: перевірте EMBEDDING і TAVILY_API_KEY, перш ніж чіпати конфігурацію LLM. Повний дослідницький прогін — це сплеск з десятків запитів по всіх трьох слотах, тож щойно він завершиться, вигляд на кожен запит у консолі APIsRouter — найшвидший спосіб побачити поділ FAST/SMART/STRATEGIC у реальних токенах і реальних витратах і впіймати слот, що споживає більше, ніж заслуговує його роль.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

Поширені запитання