# Гайд: когда и как использовать Opus, Sonnet, Fable

Дата: 2026-07-31. Основано на опыте проекта polygon (v0.1.0 → v0.3.0).

## Кто для чего

| Модель | Роль | Сильные стороны | Слабые стороны |
|--------|------|----------------|----------------|
| **Claude Opus** | Архитектор | Видит систему целиком. Находит структурные проблемы. | Может пропустить баги в коде. |
| **Claude Sonnet** | Code reviewer | Быстрый. Годится для рутинных ревью. | Поверхностный — 2 ревью пропустили 3 бага которые нашёл Fable. |
| **Claude Fable 5** | Bug hunter | Видит баги которые все пропустили. Не требует контекста. | Слаб в архитектурных вопросах. Дороже Опуса в 2 раза. |

## Результаты на проекте polygon

| Находка | Опус | Sonnet #1 | Sonnet #2 | Fable 5 |
|---------|------|-----------|-----------|---------|
| Workers=1 для in-memory | — | 🔴 | — | — |
| KeyError в _merge_params | — | 🔴 | — | — |
| _cfg.DELAY вместо import | — | — | 🔴 | — |
| Публичный деплой vs single-user | 🔴 | — | — | — |
| **setdefault не работает** | — | — | — | 🔴 |
| **sleep блокирует /health** | — | — | — | 🔴 |
| **int(param_id) без try** | — | — | — | 🟡 |
| Нет симуляции ошибок | 🟡 | — | — | 🟡 |

**Вывод:** Fable в одиночку нашёл то, что 3 других ревью (Опус + 2×Соннет) пропустили.

## Схема использования

```
Новый проект / крупный рефакторинг:
  1. Опус → архитектурный план
  2. Реализация (я)
  3. Sonnet → code review (дешёвый, рутинный)
  4. Исправления
  5. Fable → bug hunt (дорогой, но вычищает остатки)

Мелкие изменения:
  1. Реализация
  2. Sonnet → code review
```

## Как составлять промпты

### Для Опуса (архитектор)

**Нужно:** полный контекст. Что за проект, какие решения приняты, что уже сделано, куда идём.

```
- Что такое проект (2-3 абзаца)
- Текущая архитектура (структура файлов, ключевые решения)
- Что сделано (хронология)
- Что проверять (конкретные вопросы)
- 5-6 вопросов на которые нужен ответ
```

**Размер:** 100-150 строк. **Цена:** дорого, но оправдано — архитектурные ошибки самые дорогие.

### Для Fable (bug hunter)

**Нужно:** минимум контекста. Он читает код и находит баги сам.

```
- 2 предложения что это за проект
- «Вот код, найди баги которые приведут к:
    • крашу сервера (500, unhandled exception)
    • потере/порче данных (гонки, KeyError, wrong state)
    • дырам в безопасности (открытые эндпоинты, инъекции)
    • блокировкам (sleep, deadlock, busy-wait)»
- «Ответ — только критические находки, без стиля и код-стайла»
```

**Размер:** 30-40 строк. **Экономия:** ~4× меньше токенов vs полный промпт.

**Проверено:** даже с полным промптом (тем же что для Опуса) Fable нашёл больше багов. Короткий промпт должен дать тот же результат — он смотрит на код, а не на контекст.

### Для Sonnet (рутинное ревью)

**Нужно:** структура проекта + на что смотреть.

```
- Структура файлов (таблица)
- Что изменилось с прошлого ревью
- Конкретные зоны проверки (безопасность, API, импорты, ...)
- Формат ответа (🔴🟡🔵)
```

**Размер:** 80-100 строк. **Цена:** самая низкая из трёх.

## Антипаттерны

- ❌ Давать Fable полный промпт как Опусу — переплата без пользы
- ❌ Давать Опусу короткий промпт как Fable — пропустит архитектурные проблемы
- ❌ Пропускать Fable после крупных изменений — баги всплывут в бою
- ❌ Использовать Sonnet для архитектурных решений — слишком поверхностный

## Итог

| Задача | Кого | Промпт |
|--------|------|--------|
| Архитектура | Opus | Полный (150 строк) |
| Code review | Sonnet | Средний (100 строк) |
| Bug hunt | Fable | Короткий (40 строк) |