0.4.11
Поиск по документации… ⌘K
09 · Руководство пользователя

09. Побочные разговоры (/side)

/side — это «короткий вопрос рядом» во время основного разговора. Он не загрязняет основной контекст и не отвлекает модель от текущей задачи.

Зачем

Представьте: вы работаете над большой задачей с активной целью /goal. Внезапно нужно уточнить: - «Как в Rust работает Arc>?» - «Какая разница между cargo test и cargo nextest?» - «Что значит этот warning от clippy?»

Если задать в основном чате: - Контекст модели засоряется новым вопросом. - При /compact это резюме «съест» место. - Через 3 turn'а модель может «забыть» что вы делали до уточнения.

С /side: - Открывается временный sub-разговор. - Основной тред поставлен на паузу. - Закончили — Esc, возвращаетесь в main. - Sub-разговор не попадает в основную историю.

Использование

Без аргумента

text
/side

Откроется пустой sub-разговор. Можете печатать вопрос с нуля.

С inline-сообщением

text
/side как работает Arc<Mutex<T>> по сравнению с Rc<RefCell<T>>?

Сразу старт sub-разговора с этим сообщением.

Выход

Esc — закрыть side-разговор, вернуться в main. Основная задача продолжается с того места, где была.

Что вы видите внутри side

Когда /side активен, заголовок чата меняется:

text
┌─ [SIDE conversation] ──────────────────────────────┐
│                                                    │
│   You: как работает Arc<Mutex<T>>?                 │
│                                                    │
│   AstraCode: Arc — атомарный счётчик ссылок...    │
│                                                    │
└────────────────────────────────────────────────────┘
gpt-5 · 3.2k tokens · workspace-write · main · [SIDE]

Status line показывает [SIDE] — чтобы не забыть, где вы.

Ограничения внутри /side

Внутри side-разговора недоступны: - /goal (любые подкоманды). - /plan. - /model, /locale (нельзя менять модель в sub-разговоре). - /new, /clear, /resume. - Вложенный /side — нельзя.

Доступны: - /help, /copy, /diff, /mention, /status. - Обычные сообщения. - Tool-вызовы — модель может смотреть код, запускать команды.

Когда использовать

✓ Хорошие случаи

Уточнение языка/библиотеки:

text
/side что делает .iter().filter_map() — чем отличается от .iter().filter().map()?

Объяснение чужого кода:

text
/side объясни, что делает функция handle_message в @src/server.rs

Документация:

text
/side как в SQLx делается transaction? Покажи пример.

Sanity check:

text
/side если я в Rust возвращаю &str из функции — это вообще законно?

✗ Плохие случаи

Реальная задача: «реализуй фичу X» — это нужно в main, не в side.

Изменение состояния: «закоммить» — состояние не должно меняться из side.

Вопросы про текущий разговор: «что мы делали 5 turn'ов назад?» — модель в side не видит main-историю.

Типичный workflow

Сценарий: разработка с уточнениями

text
[main] /goal Реализовать OAuth-вход
[main] You: создай функцию verify_token
[main] AstraCode: создаёт, показывает
[main] You: используй const_time_eq для сравнения

[main] You: /side что такое const-time сравнение и почему оно нужно для tokens?
[side] AstraCode: объясняет timing attacks, показывает примеры
[side] You: понял, спасибо
[side] You: Esc

[main] AstraCode: (продолжает с того места) применяю const_time_eq...
[main] You: запусти тесты

Main-разговор «не заметил» вопроса про timing attacks — он знает только, что вы попросили const_time_eq. Это чисто и не разрастает контекст.

Сценарий: чтение чужого кода

Большая задача — разобраться в legacy-модуле:

text
[main] /goal Документировать модуль payments — какие функции что делают
[main] You: посмотри src/payments/ и составь предварительный список функций
[main] AstraCode: показывает список

[main] You: /side что делает legacy_charge_v3 в @src/payments/legacy.rs?
[side] AstraCode: объясняет
[side] You: а зачем там тот странный счётчик retries?
[side] AstraCode: разбирает
[side] You: Esc

[main] You: добавь в документацию: legacy_charge_v3 — для расчётов pre-2020, с механизмом retry
[main] AstraCode: пишет markdown файл

Каждое уточнение — отдельный side. Main остаётся чистым «процессом документирования».

Совместная работа с /goal

/side не тратит бюджет цели. Sub-разговор отдельно от цели; токены идут в общий счёт сессии, но goal-budget не уменьшается.

Это полезно: вы можете долго копаться в side-вопросах при наличии активной цели, не «съедая» её.

Side и память

Side-разговор пишется в отдельный rollout, не в main. Это значит: - При следующем /resume он не появится автоматически. - Long-term memory (Phase 1/2) не учитывает side-разговоры (по умолчанию) — чтобы не «загрязнять» память случайными вопросами.

Если хотите оставить заметку из side в main:

text
[side] AstraCode: объясняет что-то полезное
[side] You: /copy
[side] (текст в буфере)
[side] Esc

[main] You: [paste] я уточнил вот это: ...

Или попросите модель в side:

text
Сформулируй вкратце, что я могу сказать в main, чтобы продолжить с учётом этого ответа.

Side во время /review

Во время code review (/review) команда /side заблокирована — пока открыт отчёт ревью, начать побочный разговор нельзя.

Чтобы спросить про конкретную находку, сначала выйдите из ревью: нажмите Esc (закроется pager, вы окажетесь в main), и только потом запускайте /side:

text
Esc                          ← выйти из режима /review
/side объясни паттерн error context в Rust

После понимания — Esc, обратно в main, и сразу попросить fix:

text
По находке #3 — добавь error context.

Side в очень длинной сессии

При long-running session с большим контекстом, side — отличный способ не дать контексту разбухнуть. Лучше задать 10 уточнений в side, чем их всех в main.

Когда модель тратит много токенов на «вспомнить, что обсуждали 30 turn'ов назад» — половина из этих 30 могла быть в side.

Ограничения

  • Side не сохраняется явно при выходе — он пишется в отдельный rollout, но в UI вернуться к нему позже сложно.
  • Toolы внутри side: ограничены теми же правами sandbox, что и main. Можно запускать тесты, читать код. Но запись в файлы — лучше делать в main, чтобы было трекаемо.
  • MCP / skills внутри side: работают, но изменения состояния (например, обновление через MCP) — относятся к main.

Best practices

✓ Side для вопросов «как работает X» — идеальный кейс.
✓ Side для чтения unfamiliar кода — не загрязняет основной разговор.
✓ Side во время /goal — не тратит бюджет цели.
✗ Не делай в side изменения файлов — они потеряют контекст в main.
✗ Не делай вложенный side — невозможно.
✗ Не путай side и /new — /new стирает всё; /side — приостанавливает main и можно вернуться.

Альтернативы

Хочу... Команда
Уточнить, не отвлекая main /side
Начать сначала /new
Скопировать сессию для экспериментов /fork
Сжать историю /compact

Когда side НЕ нужен

  • Короткие сессии (< 5 turn'ов) — контекст не успеет разбухнуть.
  • Вопросы тесно связанные с текущей задачей — пусть будут в main.
  • Заметки на потом — лучше записать в AGENTS.md или комментарии в коде.
ESC