Выбор модели и глубины рассуждения - это баланс качества, скорости и стоимости, и начинается он с честного правила: доступные модели и уровни effort зависят от каталога моделей, аккаунта и поверхности. Не фиксируйте старый скриншот как контракт: то, что было верно вчера или у коллеги, может быть неверно у вас. Актуальный набор смотрят вживую - командой /model и проверкой /status, - а не переносят из чужого конфига как данность.

Базовая настройка модели живёт в config.toml и читается как явный профиль. Ключи model и model_reasoning_effort задают, какая модель и с какой глубиной рассуждения работает по умолчанию, а personality влияет на стиль ответа. Полезно один раз увидеть такой фрагмент целиком: он делает выбор воспроизводимым и объяснимым. Но и здесь действует прежнее правило - конкретное имя модели проверяют вживую, потому что каталог меняется быстрее любого записанного примера.

Reasoning effort стоит понимать по назначению, а не по ощущению "чем больше, тем лучше". Высокий effort оправдан там, где задача действительно требует рассуждения: неоднозначная архитектура, обзор безопасности, сложный debugging. Там он окупается качеством. Но для read-heavy сканирования или механической правки высокий effort может только увеличить задержку и расход, ничего не добавив к результату. Уровень выбирают под характер задачи, а не выкручивают на максимум на всякий случай.

Полезно один раз увидеть осознанный профиль модели в config.toml. Ниже - фрагмент с моделью, уровнем effort и personality. К этой форме возвращаются, настраивая поведение под задачу: она задаёт поведение явно, а не оставляет его на случайный выбор прошлой сессии. Комментарий рядом напоминает главное: конкретную модель и доступные уровни effort сверяют через /model и /status, потому что они зависят от аккаунта и поверхности.

Fast tier - это отдельный переключатель скорости со своими последствиями. Команда /fast ускоряет работу там, где это поддерживается, но быстрее не всегда значит дешевле или точнее: у ускоренного режима может быть своя цена и свои ограничения. Его включают осознанно, под задачу, где важна отзывчивость, а не по умолчанию. Как и с моделью, эффект проверяют, а не предполагают: то, что ускоряет один сценарий, не обязано улучшать другой.

Personality меняет стиль ответа, а не ограничения задачи, и это различение важно. Поддерживаемые значения в текущем руководстве по config - friendly, pragmatic и none. Они влияют на тон и подачу, но не на то, что агенту разрешено делать и как он проверяет результат. Для обзора кода качество определяется контрактом обзора, а не "строгим характером": нельзя заменить чёткое требование найти поведенческий риск выбором более сурового тона ответа.