OpenRouter в Python: первый проверяемый запрос к модели

OpenRouter можно вызвать из Python обычным HTTP-клиентом: специальный framework для первого теста не нужен. Минимальная проверка должна подтвердить адрес, ключ, разрешённую модель и ожидаемую структуру ответа. После неё проще подключать очереди, инструменты и streaming.

Пример ниже использует стандартную библиотеку Python и Chat Completions. Перед запуском выберите доступную модель, проверьте её стоимость и задайте OPENROUTER_API_KEY и OPENROUTER_MODEL в окружении своего процесса.

Соберите минимальный запрос

Схема операции описана в OpenRouter API Overview, а передача ключа — в Authentication. Пример намеренно не содержит действующего идентификатора модели или секрета:

import json
import os
import urllib.request

payload = {
    "model": os.environ["OPENROUTER_MODEL"],
    "messages": [{"role": "user", "content": "Ответь одним словом: готово"}],
    "max_tokens": 32,
}
request = urllib.request.Request(
    "https://openrouter.ai/api/v1/chat/completions",
    data=json.dumps(payload).encode("utf-8"),
    headers={
        "Authorization": "Bearer " + os.environ["OPENROUTER_API_KEY"],
        "Content-Type": "application/json",
    },
    method="POST",
)
with urllib.request.urlopen(request, timeout=60) as response:
    result = json.load(response)
print(result.get("id"), result.get("model"))

Это контрольный фрагмент, а не готовый production-клиент. Например, обработку ошибок нужно добавить до включения регулярной нагрузки.

Проверьте окружение выполнения

Если переменная отсутствует, пример завершится локальной ошибкой до обращения к API. Это удобно для первичной проверки: пустой секрет не уходит наружу. При переносе в контейнер убедитесь, что переменные переданы именно контейнеру, а не только интерактивной оболочке пользователя.

Не печатайте весь объект request или его заголовки в общий журнал. Для диагностики достаточно имени операции, выбранной модели и признака наличия обязательных настроек. Пользовательский текст запроса также не нужен для доказательства, что авторизация настроена.

Отделите HTTP-отказ от ошибки программы

Для реального приложения перехватывайте urllib.error.HTTPError, читайте статус и безопасное описание ошибки. Сетевой сбой, неправильный JSON и отказ API должны попадать в разные состояния задачи. Повторять любую исключительную ситуацию одинаково опасно: неверный ключ не исправится от десяти попыток.

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

Подтвердите полезный результат

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

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

Если вместо JSON пришла HTML-страница, сохраните тип содержимого и путь обращения. Это может указывать на промежуточный прокси или неправильный маршрут. Не подменяйте такую ошибку пустым успешным результатом: следующий обработчик должен узнать, что проверка API не завершилась.

Переходите к сервису постепенно

После первого запроса сохраните пример входа, версию Python, выбранную модель и дату. Далее пригодятся разбор API URL и учёта токенов. Клиентский пример помогает проверить протокол, но подключение провайдера и условия работы обсуждаются отдельно.