Tmux в 2026 году: как держать 4–8 параллельных ИИ-агентов в одной консоли

Если у вас на ноутбуке крутится Claude Code, Codex CLI или Gemini, и вы дошли до точки, где хочется запустить второй такой же агент на соседней задаче — а потом третий — а потом перестать терять, кто из них что делал, — у вас уже есть нужный инструмент. Это tmux (терминальный мультиплексор), ему почти 20 лет. В 2026 году он внезапно оказался ровно тем, что нужно для нового способа разработки: разработчики, работающие с ИИ-агентами, переоткрыли его как самый дешёвый способ оркестрировать четыре–восемь параллельных «коллег» из одной консоли. Разбираем три практичных шаблона, которые сейчас обсуждают на Hacker News: Feature Designs от Мануэля Шиппера, agent forking от Каушика Гопала и Worktree-x-tmux от Сё Ито.

Почему tmux именно сейчас

Tmux разработал Николас Маррьотт в 2007 году — как BSD-лицензированную альтернативу GNU Screen с более чистой архитектурой клиент-сервер. Долгие годы он жил в нише: SSH-сессии, длинные сборки, серверная отладка. ИИ-инструменты типа Claude Code, Codex CLI и Gemini CLI всё это поменяли — каждый из них работает в терминале, каждый «жрёт» одно интерактивное окно, и у каждого есть состояние, которое жалко потерять.

Tmux умеет ровно то, что для этого нужно: каждое окно — отдельная сессия процесса, окна можно переключать одной клавишей, сессии переживают отключение SSH и закрытие крышки ноутбука, layout настраивается под конкретный проект. И главное — нет UI, нет vendor lock-in, нет лимита по количеству агентов.

Я намеренно не строю поверх существующих агентов. Я каждый день пользуюсь Claude Code, Codex CLI и Gemini, и они меняются достаточно быстро, чтобы любая толстая прослойка — например, UI — отставала по фичам. Поэтому: bash-скрипт и tmux. Это всё. Доступно практически на любом компьютере.

Каушик ГопалPrincipal Engineer в Instacart, автор kau.sh

Шаблон 1: Feature Designs (Шиппер)

Мануэль Шиппер, Staff AI Engineer в Snowflake, описал систему, в которой почти весь код за него пишут агенты — а его роль свелась к проектированию через Markdown-документы. Каждое окно tmux получает одну из трёх ролей:

• Planner — собирает Markdown-спеку для новой фичи или фикса. Здесь Шиппер проводит большую часть времени.
• Worker — реализует код по готовой спеке. Запускается с чистого контекста, чтобы compaction не мешал.
• PM — груминг бэклога и сброс новых идей в очередь.

Каждая спека — это Feature Design (FD) с фиксированной структурой: проблема, рассмотренные решения с плюсами и минусами, выбранное решение с планом имплементации (включая список файлов к изменению), шаги верификации. Пример настоящего FD из проекта Шиппера:

			FD-051: Multi-label document classification

Status: Open          Priority: Medium
Effort: Medium        Impact: Better recall for downstream filtering

## Problem
Incoming documents get a single category label, but many span
multiple topics. Downstream filters miss relevant docs.

## Solution
1. Use an LLM to assign confidence scores per category.
2. Accept all labels above 0.90 confidence.
3. For ambiguous scores (0.50–0.90), run a second LLM pass with few-shot examples.
4. Store all labels with scores so downstream queries can threshold flexibly.

## Files to Modify
- src/classify/multi_label.py (new: LLM-based multi-label logic)
- src/classify/prompts.py (new: few-shot templates for ambiguous cases)
- sql/01_schema.sql (add document_labels table with scores)

## Verification
1. Run classifier on staging document table
2. Verify no errors in operation log, run health checks
3. Spot-check: docs with known multi-topic content have expected labels
		

FD нумеруются последовательно (FD-001, FD-002…), хранятся в docs/features/ и проходят через 8 стадий жизненного цикла: Planned → Design → Open → In Progress → Pending Verification → Complete (плюс Deferred и Closed). Шесть слэш-команд автоматизируют переходы:

			/fd-new       — создать FD из идеи
/fd-status    — показать индекс активных FD
/fd-explore   — загрузить контекст проекта в новую сессию
/fd-deep      — запустить 4 параллельных Opus-агента на сложный design-вопрос
/fd-verify    — пруфридинг кода + план верификации + commit
/fd-close     — архивировать FD, обновить индекс и changelog
		

Главная фишка /fd-deep — параллельный исследовательский запуск четырёх агентов с разными «углами»: алгоритмический, структурный, инкрементальный, environmental. Шиппер вдохновлялся параллельным test-time compute из GPT Pro: вместо одного длинного раздумья — четыре независимых раздумья, потом синтез.

За месяцы работы Шиппер сделал в одном проекте больше 300 FD. Чтобы запускать ту же систему в новых репозиториях, он добавил команду /fd-init, которая создаёт всю инфраструктуру (директории, индекс, шаблон, шесть команд, секцию в CLAUDE.md) одной командой.

Шаблон 2: agent forking (Гопал)

Каушик Гопал из Instacart пошёл с другой стороны. Его мысль: параллельные агенты часто не нужны постоянно — нужны точечные форки. Запустил одну долгую сессию с агентом, наработал контекст, понял, что хочется отвлечься на гипотезу — отделил новый агент с тем же контекстом, поработал, скопировал нужные строки обратно в основную сессию.

Реализация — тонкий Bash-скрипт + tmux, никаких UI. Под капотом он берёт буфер текущей tmux-панели (`tmux capture-pane`), оборачивает его в теги <context>...</context> и запускает в новом окне выбранный CLI с этим текстом как первым промптом. Это не «форк процесса агента», а seed нового агента транскриптом предыдущего разговора. Скрипт лежит на GitHub Gist. Требования автора:

• Tool-agnostic forks: можно начать сессию с Codex CLI, форкнуть в Claude Code с тем же контекстом, потом ещё один форк в Gemini (например, для генерации диаграмм через MCP-сервер с Gemini Nano Banana — моделью генерации изображений Google).
• Interactive, not one-shot: форкнутая сессия — это полноценный диалог, а не headless-вызов с автоматическим возвратом результата. Копируете руками то, что нужно.
• Без слияния: не пытаемся «мерджить» результат форка обратно. Tmux позволяет выделить мышью и вставить в основное окно — этого достаточно.

Главный плюс такого подхода — низкий когнитивный оверхед: не нужно заранее спланировать «у меня будет четыре агента», просто форкаешь по мере необходимости. Минус — труднее держать долгую параллельную работу: если форк живёт час и накапливает свой контекст, вернуть его обратно в основной поток без потерь сложнее, чем у Шиппера с FD.

Шаблон 3: git worktree + tmux (Ито)

Сё Ито описал паттерн, который сейчас рекомендуют все, кто пробовал держать больше двух агентов параллельно: один worktree на агента, одно tmux-window на worktree.

Проблема, с которой он столкнулся: когда два агента работают в одном working directory, они конфликтуют по файлам. Один начал переименовывать функцию, второй параллельно правит тесты той же функции — git status показывает кашу, а имплементация теряется в неразрешимых merge-конфликтах. Возвращаешься к последовательному запуску, и весь смысл параллельности теряется.

Решение — git worktree, родная фича git с 2015 года, которая позволяет иметь несколько working directories из одного репозитория. Каждый worktree — отдельная директория, отдельная ветка, отдельный набор файлов. Агент в worktree A не видит изменений агента в worktree B, пока они оба не попадут в общую ветку.

Борис Чернисоздатель Claude Code, Anthropic

Ито предупреждает про второй уровень — pane hell: если делать один tmux-window на проект и сплитить панелями каждый worktree, очень быстро теряется ориентация. Особенно при 2–3 параллельных проектах с 5 worktree в каждом. Его решение — наоборот, один tmux-window на worktree, переключение между ними клавишей, имя окна = имя worktree. Pane-сплиты остаются для технических нужд (Claude Code + shell для команд + Vim для просмотра diff).

Чтобы не настраивать всё это руками каждый раз, Ито написал утилиту kage («тень» по-японски): она создаёт worktree, открывает tmux-window с правильным именем, поднимает в нём Claude Code и preset из shell + Vim. Аналогичные обёртки уже появились у других — например, agent-deck от Ашеша Гоплани и vibe-switch от Брайана Чжана.

Минимальный конфиг tmux под параллельных агентов

Если вы пришли в tmux с нуля — вот точка входа, которая хорошо работает с агентами в 2026-м. Файл ~/.tmux.conf:

			# Префикс на Ctrl-a (привычнее на home row, чем дефолтный Ctrl-b)
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Нумерация окон с 1, не с 0
set -g base-index 1
setw -g pane-base-index 1

# Mouse mode (выделять текст из агента и копировать в буфер)
set -g mouse on

# Длинная история скроллбэка — агенты выводят простыни логов
set -g history-limit 50000

# Vim-стиль навигации между панелями
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R

# Не рестартить нумерацию окон при закрытии
set -g renumber-windows on
		

Сценарии запуска агентов удобнее держать отдельным shell-скриптом — три-четыре строчки, которые создают окно с правильным именем и запускают в нём агент с нужным флагом. Минимальный пример для запуска воркера в worktree:

			#!/usr/bin/env bash
# ~/bin/agent-worker — создаёт worktree, открывает tmux-window, поднимает Claude Code
set -euo pipefail

WORKTREE_NAME="${1:?usage: agent-worker <name> <fd-number>}"
FD_NUMBER="${2:?}"
WT_PATH="$(git rev-parse --show-toplevel)/../${WORKTREE_NAME}"

git worktree add "$WT_PATH" -b "feat/${WORKTREE_NAME}"
tmux new-window -n "${WORKTREE_NAME}" -c "$WT_PATH" \
  "claude --permission-mode acceptEdits 'implement FD-${FD_NUMBER}'"
		

Практические лимиты и грабли

Все три автора независимо упёрлись в один и тот же потолок — 4–8 параллельных агентов. После восьми падает качество принимаемых решений: разработчик перестаёт помнить, что какой агент делает, и начинает соглашаться на их предложения, не вникая. Шиппер пишет про это прямо: «после 8+ агентов мне трудно держать ритм, и качество моих решений страдает». Симптомы, по которым можно поймать свой потолок: вы начинаете подписывать diff-ы по диагонали, забываете, на какой задаче был агент B, и обнаруживаете, что один из агентов уже полчаса генерит мусор в пустоту, потому что вы переключились в другое окно.

Грабли, на которые стоит наступить заранее:

• Pane hell: не сплитьте панели по worktree, делайте window-per-worktree. Иначе через два часа вы не вспомните, где какой агент.
• Compaction теряет планы: когда планировщик-агент уходит в /compact, он часто роняет важные детали FD. Шиппер просит агентов писать checkpoint вручную в Markdown между сессиями.
• Без worktree — конфликты: даже два агента в одном working directory гарантированно сломают друг другу промежуточный коммит. Worktree обязателен с третьего агента.
• Inline-аннотации в спеках лучше чата: для сложных FD Шиппер рекомендует править Markdown в редакторе и оставлять %% комментарии в нужных местах, потом просить агента «check %% notes». Точнее, чем «давай обсудим».
• Dev guide важнее разрастающегося CLAUDE.md: вместо одного бесконечного файла лучше держать docs/dev_guide/ с короткой сводкой при старте сессии и подробностями по запросу.

Что попробовать на этой неделе

Если у вас уже стоит хотя бы один coding-агент, попробуйте такой план на три дня. День 1: создайте ~/.tmux.conf из приведённого минимума (префикс, mouse on, base-index 1) и поработайте день в одном tmux-окне с одним агентом — просто чтобы привыкнуть к навигации. День 2: добавьте второй worktree через git worktree add и второе окно с агентом на параллельной задаче. День 3: третий agent в третьем worktree. Если на четвёртом начали путаться, кто из агентов что делает — вы нашли свой персональный потолок. Если зашло — добавьте FD-шаблон Шиппера на одном проекте, потом — agent-fork по Гопалу для тангенциальных гипотез.

Главное наблюдение всех трёх авторов простое: tmux никуда не девался, просто внезапно оказался ровно тем инструментом, который нужен для нового способа разработки. Толстые UI вокруг агентов отстают от самих агентов; тонкая прослойка из tmux + Bash-скриптов остаётся гибкой ровно настолько, насколько вы готовы её менять под себя.

Источники: Manuel Schipper — How I run 4–8 parallel coding agents with tmux and Markdown specs, Kaushik Gopal — Forking subagents in an AI coding session with tmux, Sho Ito — Parallel Coding Agents with Git Worktree x tmux, обсуждение на Hacker News.