Конфигурация

Home / env: предпочитайте VIBEOS_HOME и vibeos. Legacy-пути остаются принятыми на время миграции.

Все настройки лежат в домашнем каталоге агента.

По умолчанию на Unix (VibeOS): ~/.vibeos/ Legacy-источник импорта: ~/.vibeos/; манифест миграции в репозитории описывает copy-only импорт. Переопределение — через VIBEOS_HOME. В коде предпочитайте get_vibeos_home() / display_vibeos_home(), а не хардкод пути.

Самый короткий путь к рабочему config.yaml

vibeos setup --portal — один OAuth даёт провайдера модели и все четыре tool'а Tool Gateway без ручного YAML. У подписчиков портала ещё 10% скидка на token-billed провайдеров. См. Nous Portal.

Структура каталогов

~/.vibeos/   # or ~/.vibeos on legacy installs
├── config.yaml     # Settings (model, terminal, TTS, compression, etc.)
├── .env            # API keys and secrets
├── auth.json       # OAuth provider credentials (Nous Portal, etc.)
├── SOUL.md         # Primary agent identity (slot #1 in system prompt)
├── memories/       # Persistent memory (MEMORY.md, USER.md)
├── skills/         # Agent-created skills (managed via skill_manage tool)
├── cron/           # Scheduled jobs
├── projects.db     # First-class Projects (named multi-folder workspaces)
├── kanban.db       # Default kanban board (see also kanban/boards/)
├── sessions/       # Gateway sessions
└── logs/           # Logs (errors.log, gateway.log — secrets auto-redacted)

Управление конфигурацией

vibeos config              # View current configuration
vibeos config edit         # Open config.yaml in your editor
vibeos config set KEY VAL  # Set a specific value
vibeos config check        # Check for missing options (after updates)
vibeos config migrate      # Interactively add missing options

# Examples:
vibeos config set model anthropic/claude-opus-4
vibeos config set terminal.backend docker
vibeos config set OPENROUTER_API_KEY sk-or-...  # Saves to .env

подсказка

Команда vibeos config set автоматически направляет значения в нужный файл — ключи API сохраняются в .env, все остальное — в config.yaml.

Приоритет конфигурации

Настройки выполняются в следующем порядке (сначала высший приоритет):

1. Аргументы CLI — например, vibeos chat --model anthropic/claude-sonnet-4 (переопределение для каждого вызова)
2. ~/.vibeos/config.yaml — основной файл конфигурации для всех несекретных настроек.
3. ~/.vibeos/.env — резерв для переменных окружения; требуется для секретов (ключи API, токены, пароли)
4. Встроенные настройки по умолчанию — жестко запрограммированные безопасные настройки по умолчанию, когда больше ничего не установлено.

Практическое правило

Секреты (ключи API, токены ботов, пароли) хранятся в .env. Все остальное (модель, серверная часть терминала, настройки сжатия, ограничения памяти, наборы инструментов) находится в config.yaml. Если установлены оба параметра, config.yaml выигрывает для несекретных настроек.

по развертыванию организаций

Администратор может закрепить определенные значения конфигурации и секрета, доступные обычному пользователю. не может переопределить через управляемый каталог системного уровня. См. Управляемая область.

Замена переменной среды

Вы можете ссылаться на переменные среды в config.yaml, используя синтаксис $\{VAR_NAME\}:

auxiliary:
  vision:
    api_key: ${GOOGLE_API_KEY}
    base_url: ${CUSTOM_VISION_URL}

delegation:
  api_key: ${DELEGATION_KEY}

Несколько ссылок в одном значении работают: url: "$\{HOST\}:$\{PORT\}". Если ссылочная переменная не установлена, заполнитель сохраняется дословно ($\{UNDEFINED_VAR\} остается как есть). Поддерживается только синтаксис $\{VAR\} — голый $VAR не расширяется.

Информацию о настройке поставщика ИИ (OpenRouter, Anthropic, Copilot, пользовательских конечных точек, автономных LLM, резервных моделей и т. д.) см. в разделе Поставщики ИИ.

Тайм-ауты поставщика

Вы можете установить providers.<id>.request_timeout_seconds для тайм-аута запроса на уровне всего провайдера, а также providers.<id>.models.<model>.timeout_secondsдля переопределения для конкретной модели. Применяется к основному клиенту очереди на каждом транспорте (OpenAI-wire, собственный Anthropic, Anthropic-совместимый), резервной цепочке, перестраивается после ротации учетных данных и (для OpenAI-wire) kwarg таймаута для каждого запроса — поэтому настроенное значение имеет преимущество перед устаревшей переменной envVIBEOS_API_TIMEOUT`.

Вы также можете установить providers.<id>.stale_timeout_seconds для непотокового детектора устаревших вызовов, а также providers.<id>.models.<model>.stale_timeout_secondsдля переопределения для конкретной модели. Это выигрывает у устаревшейVIBEOS_API_CALL_STALE_TIMEOUT` env var.

Если эти параметры не заданы, сохраняются устаревшие настройки по умолчанию (VIBEOS_API_TIMEOUT=1800s, VIBEOS_API_CALL_STALE_TIMEOUT=90s, родные Anthropic 900). Непотоковый детектор устаревания автоматически отключается для локальных конечных точек, если он оставлен неявно, и может масштабироваться вверх для очень больших контекстов. В настоящее время не подключен к AWS Bedrock (пути bedrock_converse и AnthropicBedrock SDK используют boto3 со своей собственной конфигурацией тайм-аута). См. пример с комментариями в cli-config.yaml.example.

Обновление поведения

Настройки vibeos update находятся в updates в config.yaml:

updates:
  pre_update_backup: false       # Create a full VIBEOS_HOME zip before every update
  backup_keep: 5                 # Keep this many pre-update backup zips
  non_interactive_local_changes: stash  # stash | discard

При установке git VibeOS автоматически сохраняет грязные отслеживаемые и неотслеживаемые файлы перед проверкой ветки обновления или извлечением. Интерактивные обновления терминала запрашивают перед восстановлением этого тайника. Неинтерактивные обновления (настольное приложение/чат, шлюз или --yes) используют updates.non_interactive_local_changes: stash восстанавливает изменения локального источника после успешного извлечения, а discard удаляет созданный обновлением тайник после успешного извлечения. Используйте discard только в управляемых установках, где изменения локального источника никогда не должны сохраняться.

Перед этим этапом хранения VibeOS также восстанавливает отслеживаемые различия package-lock.json, оставленные в результате обновления/сборки npm. Перед обновлением зафиксируйте или вручную сохраните намеренные изменения в файле блокировки.

Конфигурация серверной части терминала

VibeOS поддерживает шесть серверных частей терминала. Каждый из них определяет, где фактически выполняются команды оболочки агента — ваш локальный компьютер, контейнер Docker, удаленный сервер через SSH, модальная облачная песочница (напрямую или через шлюз, управляемый Nous), рабочее пространство Daytona или контейнер Singularity/Apptainer.

terminal:
  backend: local    # local | docker | ssh | modal | daytona | singularity
  cwd: "."          # Gateway/cron working directory (CLI always uses launch dir)
  timeout: 180      # Per-command timeout in seconds
  home_mode: auto   # auto | real | profile — subprocess HOME policy
  env_passthrough: []  # Env var names to forward to sandboxed execution (terminal + execute_code)
  singularity_image: "docker://nikolaik/python-nodejs:python3.11-nodejs20"  # Container image for Singularity backend
  modal_image: "nikolaik/python-nodejs:python3.11-nodejs20"                 # Container image for Modal backend
  daytona_image: "nikolaik/python-nodejs:python3.11-nodejs20"               # Container image for Daytona backend

Для облачных песочниц, таких как Modal и Daytona, container_persistent: true означает, что VibeOS будет пытаться сохранить состояние файловой системы при воссоздании песочницы. Это не гарантирует, что та же действующая песочница, PID-пространство или фоновые процессы будут работать позже.

Обзор серверной части

Бэкэнд	Где выполняются команды	Изоляция	Лучшее для
местный	Ваша машина напрямую	Нет	Разработка, личное использование
докер	Единый постоянный контейнер Docker (общий для сеанса, /new, субагентов)	Полный (пространства имен, ограничение)	Безопасная песочница, CI/CD
тсс	Удаленный сервер через SSH	Граница сети	Удаленная разработка, мощное оборудование
модальный	Модальная облачная песочница	Полная (облачная виртуальная машина)	Эфемерные облачные вычисления, оценки
дайтона	Рабочее пространство Дейтона	Полный (облачный контейнер)	Управляемые облачные среды разработки
необычность	Контейнер Singularity/Apptainer	Пространства имен (--containall)	Кластеры HPC, общие машины

Локальный бэкэнд

Значение по умолчанию. Команды выполняются непосредственно на вашем компьютере без изоляции. Никакой специальной настройки не требуется.

terminal:
  backend: local

По умолчанию подпроцессы локальных инструментов сохраняют вашего реального пользователя ОС HOME. Это позволяет внешние интерфейсы командной строки, такие как git, ssh, gh, az, npm, Claude Code и Codex. найдите учетные данные и конфигурацию, которые они уже используют в вашей обычной оболочке. VibeOS состояние по-прежнему ограничено профилем через VIBEOS_HOME; HOME — это не то, как профили выберите конфигурацию, память, сеансы или навыки.

VibeOS не изменяет общесистемные HOME, файлы запуска оболочки или домашняя учетная запись операционной системы. Этот параметр контролирует только среду передается в подпроцессы, которые VibeOS запускает с помощью таких инструментов, как terminal, фоновые терминальные процессы, execute_code и вспомогательные процессы ACP.

terminal.home_mode

Режим	Хост устанавливает	Контейнеры	Компромисс
auto	Сохраняйте настоящего пользователя ОС HOME	Используйте \{VIBEOS_HOME\}/home	Рекомендуемый вариант по умолчанию. Интерфейсы командной строки хоста продолжают работать; Состояние контейнера сохраняется.
real	Принудительно использовать реального пользователя ОС HOME	Принудительно указать реального пользователя ОС HOME, если он виден	Полезно, если родительский процесс случайно запустился с HOME, указывающим на домашний профиль.
profile	Используйте \{VIBEOS_HOME\}/home, если он существует	Используйте \{VIBEOS_HOME\}/home, если он существует	Строгая изоляция конфигурации CLI для каждого профиля, но обычные ~/.ssh, ~/.gitconfig, ~/.azure, ~/.config/gh, аутентификация Claude/Codex, состояние npm и т. д. не будут видны, если вы не инициализируете или не свяжете их внутри домашней страницы профиля.

Недостатком значения по умолчанию является то, что профили хостов имеют одинаковый обычный Учетные данные/конфигурация CLI уровня пользователя в разделе ~. Если вам нужен профиль с отдельный идентификатор git, ключи SSH, вход в интерфейс командной строки GitHub, конфигурация npm или облачный интерфейс командной строки войдите в систему, используйте home_mode: profile и инициализируйте эти инструменты внутри этого профиля. домой намеренно.

Если вы намеренно хотите строгую изоляцию конфигурации инструмента для каждого профиля, установите:

terminal:
  home_mode: profile

В этом режиме подпроцессы инструмента используют \{VIBEOS_HOME\}/home как HOME. VibeOS также устанавливает VIBEOS_REAL_HOME, чтобы сценарии могли найти фактический домашний адрес пользователя, когда им это нужно. Серверные части контейнеров продолжают использовать \{VIBEOS_HOME\}/home в режиме auto. потому что этот каталог находится на постоянном томе данных VibeOS.

Скрипты, которым необходимо отличать состояние профиля от реального дома пользователя, должны предпочитайте VIBEOS_HOME для данных VibeOS и VIBEOS_REAL_HOME для домашней учетной записи:

from pathlib import Path
import os

vibeos_home = Path(os.environ["VIBEOS_HOME"])
real_home = Path(os.environ.get("VIBEOS_REAL_HOME", os.environ["HOME"]))

предупреждение

Агент имеет тот же доступ к файловой системе, что и ваша учетная запись пользователя. Используйте vibeos tools, чтобы отключить ненужные инструменты, или переключитесь на Docker для изолированной программной среды.

Серверная часть Docker

Запускает команды внутри контейнера Docker с усилением безопасности (отменены все возможности, нет повышения привилегий, ограничения PID).

Единый постоянный контейнер, общий для всех процессов VibeOS. VibeOS запускает ОДИН долгоживущий контейнер при первом использовании и маршрутизирует каждый терминал, файл и вызов execute_code через docker exec в один и тот же контейнер — между сеансами, /new, /reset и delegate_task подагентами. Изменения рабочего каталога, установленные пакеты, файлы в /workspace и фоновые процессы переносятся от одного вызова инструмента к другому и от одного процесса VibeOS к другому. Когда вы закрываете сеанс TUI, запускаете /quit или запускаете новый вызов vibeos, контейнер продолжает работать, и следующий процесс VibeOS повторно использует его посредством помеченного поиска. Точные правила удаления см. в разделе Жизненный цикл контейнера ниже.

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_mount_cwd_to_workspace: false  # Mount launch dir into /workspace
  docker_run_as_host_user: false   # See "Running container as host user" below
  docker_forward_env:              # Host env vars to forward into container
    - "GITHUB_TOKEN"
  docker_env:                      # Literal env vars to inject (KEY=value)
    DEBUG: "1"
    PYTHONUNBUFFERED: "1"
  docker_volumes:                  # Host directory mounts
    - "/home/user/projects:/workspace/projects"
    - "/home/user/data:/data:ro"   # :ro for read-only
  docker_extra_args:               # Extra flags appended verbatim to `docker run`
    - "--gpus=all"
    - "--network=host"

  # Resource limits
  container_cpu: 1                 # CPU cores (0 = unlimited)
  container_memory: 5120           # MB (0 = unlimited)
  container_disk: 51200            # MB (requires overlay2 on XFS+pquota)
  container_persistent: true       # Persist /workspace and /root bind-mount dirs

  # Cross-process container reuse (defaults match the "one long-lived
  # container shared across sessions" contract — see Container lifecycle).
  docker_persist_across_processes: true   # Reuse container across VibeOS restarts
  docker_orphan_reaper: true              # Sweep abandoned Exited containers at startup

  # Cross-backend lifecycle settings (apply to docker as well)
  timeout: 180                     # Per-command timeout in seconds
  lifetime_seconds: 300            # Idle-reaper window; also feeds 2× orphan-reaper threshold

docker_env против docker_forward_env: первый вводит буквальные пары KEY=value, которые вы указываете в конфигурации (значения находятся в вашем config.yaml или передаются как JSON-диктант через TERMINAL_DOCKER_ENV='{"DEBUG":"1"}'). Последний пересылает значения из вашей оболочки или ~/.vibeos/.env, поэтому реальный секрет никогда не отображается в файле конфигурации. Используйте docker_forward_env для жетонов и docker_env для статических ручек, необходимых контейнеру.

terminal.docker_extra_args (также переопределяемый через TERMINAL_DOCKER_EXTRA_ARGS='["--gpus=all"]') позволяет передавать произвольные флаги docker run, которые VibeOS не отображает в качестве ключей первого класса — --gpus, --network, --add-host, альтернативные переопределения --security-opt и т. д. Каждая запись должна быть строкой; список добавляется последним к собранному вызову docker run, поэтому при необходимости он может переопределить значения по умолчанию VibeOS. Используйте с осторожностью — флаги, которые конфликтуют с усилением защиты в песочнице (снижение возможностей, --user, монтирование привязки рабочей области), незаметно ослабят изоляцию.

Требования: Docker Desktop или Docker Engine установлены и работают. VibeOS проверяет $PATH, а также общие места установки macOS (/usr/local/bin/docker, /opt/homebrew/bin/docker, пакет приложений Docker Desktop). Podman поддерживается «из коробки»: установите VIBEOS_DOCKER_BINARY=podman (или полный путь), чтобы включить его, когда оба установлены.

Жизненный цикл контейнера

Каждый контейнер, управляемый VibeOS, помечен тремя метками, чтобы последующие процессы (и потерянный жнец) могли его идентифицировать:

• vibeos-agent=1 — помечает его как управляемый VibeOS.
• vibeos-task-id=<sanitized task_id>` — включает проверку повторного использования для каждой задачи.
• vibeos-profile=<sanitized profile name>` — повторное использование областей и сбор данных для активного профиля VibeOS.

При запуске VibeOS запускает docker ps --filter label=vibeos-task-id=<id> --filter label=vibeos-profile=<profile> и **присоединяется к существующему контейнеру**, когда находит его. Если контейнер — exited` (например, после перезапуска демона Docker), он вызывается и используется повторно — состояние файловой системы и все установленные пакеты сохраняются, но фоновые процессы внутри контейнера — нет.

При завершении процесса VibeOS — /quit, закрытии сеанса TUI, завершении работы шлюза и даже SIGKILL — путь очистки является недействующим для контейнера в режиме по умолчанию. Контейнер продолжает работать. Следующий процесс VibeOS присоединяется к нему через миллисекунды через зонд метки. Это поведение, которого требует контракт «один долгоживущий контейнер, общий для всех сеансов»: это единственный способ, которым фоновые процессы (наблюдатели npm, серверы разработки, длительный pytest) выживают между сеансами.

Контейнер разбирается (остановляется и docker rm -f'd) только в следующих случаях:

Триггер	Когда он срабатывает
docker_persist_across_processes: false	Явная изоляция каждого процесса. Каждый cleanup() выполняет stop + rm -f. Соответствует поведению до выпуска № 20561.
Неработающий жнец (lifetime_seconds, по умолчанию 300 с)	Только когда env равен persist_across_processes=false. Окружающие среды в постоянном режиме не работают; контейнер выдерживает холостой ход.
Сиротский жнец при следующем запуске	Очищает контейнеры с меткой VibeOS Exited старше 2 × lifetime_seconds (по умолчанию 600 с = 10 минут), ограниченные текущим профилем. Работающие контейнеры никогда не трогаются — безопасность родственных процессов. Установите docker_orphan_reaper: false для отключения.
Прямое действие пользователя	docker rm -f, docker system prune, перезапуск Docker Desktop. Мы не устанавливаем --restart=always, поэтому при перезагрузке хоста контейнер Exited покидает контейнер (его слой CoW сохраняется и повторно используется при следующем запуске, но процессы bg исчезают).

Пограничные случаи, которые стоит знать:

• OOM kill PID 1 в контейнере переводит контейнер в Exited. Следующее повторное использование приведет к docker start; состояние файловой системы сохраняется, а процессы bg — нет.
• Переключение профилей изолирует контейнеры друг от друга — контейнер с меткой vibeos-profile=work невидим для процесса VibeOS, работающего под управлением vibeos-profile=research. Сиротский сборщик также имеет область действия профиля, поэтому контейнеры между профилями не будут случайно извлечены, но они также не будут очищены автоматически, пока вы снова не запустите VibeOS под их исходным профилем.

Параллельные субагенты, порожденные через delegate_task(tasks=[...]), совместно используют этот контейнер — одновременные cd, мутации env и записи по одному и тому же пути будут конфликтовать. Если субагенту требуется изолированная песочница, он должен зарегистрировать переопределение образа для каждой задачи через register_task_env_overrides(), что RL и тестовые среды (TerminalBench2, VibeOSSweEnv и т. д.) делают автоматически для своих образов Docker для каждой задачи.

Усиление безопасности:

• --cap-drop ALL, обратно добавлены только DAC_OVERRIDE, CHOWN, FOWNER.
• --security-opt no-new-privileges
• --pids-limit 256
• tmpfs с ограниченным размером для /tmp (512 МБ), /var/tmp (256 МБ), /run (64 МБ)

Пересылка учетных данных: Переменные Env, перечисленные в docker_forward_env, сначала разрешаются из среды вашей оболочки, а затем ~/.vibeos/.env. Навыки также могут объявлять required_environment_variables, которые автоматически объединяются.

Переопределение переменных среды

Каждый ключ в terminal: имеет переопределение env-var формы TERMINAL_<KEY_UPPERCASE>`. Наиболее полезные для бэкенда Docker:

Конверт вар	Карты	Заметки
TERMINAL_DOCKER_IMAGE	docker_image	Базовое изображение
TERMINAL_DOCKER_FORWARD_ENV	docker_forward_env	Массив JSON: '["GITHUB_TOKEN","OPENAI_API_KEY"]'
TERMINAL_DOCKER_ENV	docker_env	JSON-диктант: '{"DEBUG":"1"}'
TERMINAL_DOCKER_VOLUMES	docker_volumes	JSON-массив строк "host:container[:ro]"
TERMINAL_DOCKER_EXTRA_ARGS	docker_extra_args	Массив JSON
TERMINAL_DOCKER_MOUNT_CWD_TO_WORKSPACE	docker_mount_cwd_to_workspace	true / false
TERMINAL_DOCKER_RUN_AS_HOST_USER	docker_run_as_host_user	true / false
TERMINAL_DOCKER_PERSIST_ACROSS_PROCESSES	docker_persist_across_processes	true / false — true по умолчанию
TERMINAL_DOCKER_ORPHAN_REAPER	docker_orphan_reaper	true / false — true по умолчанию
TERMINAL_CONTAINER_CPU	container_cpu	Ядра процессора
TERMINAL_CONTAINER_MEMORY	container_memory	МБ
TERMINAL_CONTAINER_DISK	container_disk	МБ
TERMINAL_CONTAINER_PERSISTENT	container_persistent	true / false — управляет каталогами рабочей области для привязки, в отличие от docker_persist_across_processes
TERMINAL_LIFETIME_SECONDS	lifetime_seconds	Неработающее окно жнеца
TERMINAL_TIMEOUT	timeout	Таймаут для каждой команды
VIBEOS_DOCKER_BINARY	нет	Принудительно указать определенный двоичный путь docker/podman

SSH-бэкэнд

Запускает команды на удаленном сервере через SSH. Использует ControlMaster для повторного использования соединения (поддержание активности в режиме ожидания в течение 5 минут). Постоянная оболочка включена по умолчанию — состояние (cwd, env vars) сохраняется при выполнении команд.

terminal:
  backend: ssh
  persistent_shell: true           # Keep a long-lived bash session (default: true)

Обязательные переменные среды:

TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=ubuntu

Необязательный:

Переменная	По умолчанию	Описание
TERMINAL_SSH_PORT	22	SSH-порт
TERMINAL_SSH_KEY	(системное значение по умолчанию)	Путь к закрытому ключу SSH
TERMINAL_SSH_PERSISTENT	true	Включить постоянную оболочку

Как это работает: Во время инициализации подключается к BatchMode=yes и StrictHostKeyChecking=accept-new. Постоянная оболочка сохраняет работоспособность одного процесса bash -l на удаленном хосте, обмениваясь данными через временные файлы. Команды, которым требуется stdin_data или sudo, автоматически переходят в одноразовый режим.

Модальный бэкэнд

Запускает команды в Модальной облачной песочнице. Для каждой задачи выделяется изолированная виртуальная машина с настраиваемым процессором, памятью и диском. Файловую систему можно сделать снимок/восстановить между сеансами.

terminal:
  backend: modal
  container_cpu: 1                 # CPU cores
  container_memory: 5120           # MB (5GB)
  container_disk: 51200            # MB (50GB)
  container_persistent: true       # Snapshot/restore filesystem

Обязательно: Либо переменные среды MODAL_TOKEN_ID + MODAL_TOKEN_SECRET, либо файл конфигурации ~/.modal.toml.

Постоянство. Если этот параметр включен, файловая система песочницы создается при очистке и восстанавливается при следующем сеансе. Снимки отслеживаются в ~/.vibeos/modal_snapshots.json. При этом сохраняется состояние файловой системы, а не текущие процессы, пространство PID или фоновые задания.

Файлы учетных данных: Автоматически монтируются из ~/.vibeos/ (токены OAuth и т. д.) и синхронизируются перед каждой командой.

Серверная часть Daytona

Выполняет команды в управляемой рабочей области Daytona. Поддерживает остановку/возобновление для постоянства.

terminal:
  backend: daytona
  container_cpu: 1                 # CPU cores
  container_memory: 5120           # MB → converted to GiB
  container_disk: 10240            # MB → converted to GiB (max 10 GiB)
  container_persistent: true       # Stop/resume instead of delete

Обязательно: DAYTONA_API_KEY переменная среды.

Постоянство. Если этот параметр включен, песочницы останавливаются (не удаляются) при очистке и возобновляются при следующем сеансе. Имена песочниц следуют шаблону vibeos-{task_id}.

Ограничение по диску: Daytona устанавливает максимальный размер в 10 ГиБ. Запросы выше этого уровня ограничиваются предупреждением.

Серверная часть Singularity/Apptainer

Запускает команды в контейнере Singularity/Apptainer. Предназначен для кластеров HPC и общих компьютеров, где Docker недоступен.

terminal:
  backend: singularity
  singularity_image: "docker://nikolaik/python-nodejs:python3.11-nodejs20"
  container_cpu: 1                 # CPU cores
  container_memory: 5120           # MB
  container_persistent: true       # Writable overlay persists across sessions

Требования: apptainer или singularity в двоичном формате $PATH.

Обработка изображений. URL-адреса Docker (docker://...) автоматически преобразуются в файлы SIF и кэшируются. Существующие файлы .sif используются напрямую.

Скретч-каталог: Разрешается в следующем порядке: TERMINAL_SCRATCH_DIR → TERMINAL_SANDBOX_DIR/singularity → /scratch/$USER/vibeos-agent (соглашение HPC) → ~/.vibeos/sandboxes/singularity.

Изоляция: Использует --containall --no-home для полной изоляции пространства имен без монтирования домашнего каталога хоста.

Распространенные проблемы с серверной частью терминала

Если команды терминала немедленно завершаются сбоем или инструмент терминала сообщается как отключенный:

• Локальный — особых требований нет. Самый безопасный вариант по умолчанию при начале работы.
• Docker — запустите docker version, чтобы убедиться, что Docker работает. Если не получается, исправьте Docker или vibeos config set terminal.backend local.
• SSH — Должны быть установлены как TERMINAL_SSH_HOST, так и TERMINAL_SSH_USER. VibeOS регистрирует явную ошибку, если что-то отсутствует.
• Модальный — требуется MODAL_TOKEN_ID env var или ~/.modal.toml. Запустите vibeos doctor для проверки.
• Daytona — Требуется DAYTONA_API_KEY. Daytona SDK управляет настройкой URL-адреса сервера.
• Сингулярность — Требуется apptainer или singularity в $PATH. Обычно используется в кластерах HPC.

В случае сомнений верните terminal.backend в local и убедитесь, что команды сначала выполняются там.

Синхронизация файлов между удаленным компьютером и хостом при демонтаже

Для бэкэндов SSH, Modal и Daytona (везде, где рабочее дерево агента находится на другом компьютере, чем хост, на котором работает VibeOS), VibeOS отслеживает файлы, к которым обращался агент, внутри удаленной песочницы и при удалении сеанса/очистке песочницы синхронизирует измененные файлы обратно с хостом в разделе ~/.vibeos/cache/remote-syncs/<session-id>/.

• Срабатывает при: закрытии сеанса, /new, /reset, тайм-ауте сообщения шлюза, завершении субагента delegate_task, когда дочерний элемент использовал удаленный бэкэнд.
• Охватывает все дерево, измененное агентом, а не только файлы, которые он явно открыл. Все добавления, изменения и удаления фиксируются.
• Удаленная песочница могла быть уже разобрана к тому времени, как вы отправитесь ее искать; локальная копия ~/.vibeos/cache/remote-syncs/… является достоверной записью того, что изменил агент.
• Большие двоичные выходные данные (контрольные точки модели, наборы необработанных данных) ограничены размером — при синхронизации файлы пропускаются через file_sync_max_mb (по умолчанию 100). Ударьте по этому поводу, если ожидаете возвращения более крупных артефактов.

terminal:
  file_sync_max_mb: 100     # default — sync files up to 100 MB each
  file_sync_enabled: true   # default — set false to skip the sync entirely

Таким образом вы восстанавливаете результаты из эфемерных облачных песочниц, которые уничтожаются после завершения сеанса, без необходимости явно указывать агенту scp или modal volume put для каждого артефакта.

Монтирование томов Docker

При использовании бэкэнда Docker docker_volumes позволяет вам делиться каталогами хоста с контейнером. Каждая запись использует стандартный синтаксис Docker -v: host_path:container_path[:options].

terminal:
  backend: docker
  docker_volumes:
    - "/home/user/projects:/workspace/projects"   # Read-write (default)
    - "/home/user/datasets:/data:ro"              # Read-only
    - "/home/user/.vibeos/cache/documents:/output" # Gateway-visible exports

Это полезно для:

• Предоставление файлов агенту (наборы данных, конфигурации, справочный код)
• Получение файлов от агента (сгенерированный код, отчеты, экспорт)
• Общие рабочие пространства, где и вы, и агент имеют доступ к одним и тем же файлам.

Если вы используете шлюз обмена сообщениями и хотите, чтобы агент отправлял сгенерированные файлы через MEDIA:/..., отдайте предпочтение выделенному, видимому хосту экспортному монтированию, например /home/user/.vibeos/cache/documents:/output.

• Запись файлов внутри Docker в /output/....
• Укажите путь к хосту в MEDIA:, например: MEDIA:/home/user/.vibeos/cache/documents/report.txt
• Не генерировать /workspace/... или /output/..., если только этот точный путь также не указан. существует для процесса шлюза на хосте

предупреждение

Дублирующиеся ключи YAML автоматически переопределяют предыдущие. Если у вас уже есть Блок docker_volumes:, объединяйте новые средства передвижения в один список вместо добавления еще один ключ docker_volumes: позже в файле.

Также можно установить через переменную среды: TERMINAL_DOCKER_VOLUMES='["/host:/container"]' (массив JSON).

Пересылка учетных данных Docker

По умолчанию сеансы терминала Docker не наследуют произвольные учетные данные хоста. Если вам нужен конкретный токен внутри контейнера, добавьте его в terminal.docker_forward_env.

terminal:
  backend: docker
  docker_forward_env:
    - "GITHUB_TOKEN"
    - "NPM_TOKEN"

VibeOS сначала разрешает каждую указанную переменную из текущей оболочки, а затем возвращается к ~/.vibeos/.env, если она была сохранена с vibeos config set.

предупреждение

Все, что перечислено в docker_forward_env, становится видимым для команд, выполняемых внутри контейнера. Пересылайте только те учетные данные, которые вам удобно использовать в сеансе терминала.

Запуск контейнера от имени пользователя хоста

По умолчанию контейнеры Docker запускаются как root (UID 0). Файлы, созданные внутри /workspace или других привязок, в конечном итоге становятся собственностью root на хосте, поэтому после сеанса вам необходимо sudo chown их, прежде чем вы сможете редактировать их в редакторе хоста. Флаг terminal.docker_run_as_host_user исправляет это:

terminal:
  backend: docker
  docker_run_as_host_user: true   # default: false

Если этот параметр включен, VibeOS добавляет --user $(id -u):$(id -g) к команде docker run, поэтому файлы, записанные в каталоги, смонтированные с помощью привязки (/workspace, /root, все, что находится в docker_volumes), принадлежат пользователю вашего хоста, а не root. Компромисс: контейнер больше не может apt install или записывать в корневые пути, такие как /root/.npm — используйте базовый образ, HOME которого принадлежит пользователю без полномочий root (или добавьте необходимые инструменты во время сборки образа), если вам нужно и то, и другое.

Оставьте это значение false (по умолчанию) для обеспечения обратной совместимости. Включите его, если ваш рабочий процесс в основном состоит из «редактирования смонтированных файлов хоста» и вы устали от sudo chown -R.

Необязательно: смонтируйте каталог запуска в /workspace.

Песочницы Docker по умолчанию остаются изолированными. VibeOS не передает текущий рабочий каталог хоста в контейнер, если вы явно не разрешите это сделать.

Включите его в config.yaml:

terminal:
  backend: docker
  docker_mount_cwd_to_workspace: true

Когда включено:

• если вы запускаете VibeOS из ~/projects/my-app, этот каталог хоста привязывается к /workspace.
• серверная часть Docker запускается в /workspace
• файловые инструменты и команды терминала видят один и тот же смонтированный проект

Если отключено, /workspace остаётся принадлежащим песочнице, если только вы явно не смонтируете что-либо через docker_volumes.

Компромисс безопасности:

• false сохраняет границу песочницы
• true предоставляет песочнице прямой доступ к каталогу, из которого вы запустили VibeOS.

Используйте это согласие только в том случае, если вы намеренно хотите, чтобы контейнер работал с активными файлами хоста.

Постоянная оболочка

По умолчанию каждая команда терминала выполняется в своем собственном подпроцессе — рабочем каталоге, переменных среды и переменных оболочки, сбрасываемых между командами. Когда включена постоянная оболочка, один долгоживущий процесс bash сохраняется при вызовах execute(), так что состояние сохраняется между командами.

Это наиболее полезно для бэкэнда SSH, поскольку оно также устраняет накладные расходы на соединение для каждой команды. Постоянная оболочка включена по умолчанию для SSH и отключена для локального бэкэнда.

terminal:
  persistent_shell: true   # default — enables persistent shell for SSH

Чтобы отключить:

vibeos config set terminal.persistent_shell false

Что сохраняется в командах:

• Рабочий каталог (cd /tmp сохраняется для следующей команды)
• Экспортированные переменные среды (export FOO=bar)
• Переменные оболочки (MY_VAR=hello)

Приоритет:

Уровень	Переменная	По умолчанию
Конфигурация	terminal.persistent_shell	true
Переопределение SSH	TERMINAL_SSH_PERSISTENT	следует конфигурации
Локальное переопределение	TERMINAL_LOCAL_PERSISTENT	false

Переменные среды для каждой серверной части имеют наивысший приоритет. Если вам нужна постоянная оболочка и на локальном бэкэнде:

export TERMINAL_LOCAL_PERSISTENT=true

примечание

Команды, требующие stdin_data или sudo, автоматически переходят в одноразовый режим, поскольку стандартный ввод постоянной оболочки уже занят протоколом IPC.

См. Выполнение кода и раздел «Терминал» в README для получения подробной информации о каждом бэкэнде.

Настройки навыков

Навыки могут объявлять свои собственные настройки конфигурации через свой интерфейс SKILL.md. Это несекретные значения (пути, предпочтения, настройки домена), хранящиеся в пространстве имен skills.config в config.yaml.

skills:
  config:
    myplugin:
      path: ~/myplugin-data   # Example — each skill defines its own keys

Как работают настройки навыков:

• vibeos config migrate сканирует все включенные навыки, находит ненастроенные настройки и предлагает вам подсказать
• vibeos config show отображает все настройки навыков в разделе «Настройки навыков» с указанием навыка, которому они принадлежат.
• Когда навык загружается, его разрешенные значения конфигурации автоматически вводятся в контекст навыка.

Установка значений вручную:

vibeos config set skills.config.myplugin.path ~/myplugin-data

Подробную информацию об объявлении настроек конфигурации в ваших собственных навыках см. в разделе Создание навыков — Настройки конфигурации.

Защита от записи навыков, созданных агентом

Когда агент использует skill_manage для создания, редактирования, исправления или удаления навыка, VibeOS может дополнительно сканировать новый/обновленный контент на наличие опасных шаблонов ключевых слов (сбор учетных данных, внедрение очевидных подсказок, инструкции по удалению). Сканер по умолчанию выключен — рабочие процессы реальных агентов, которые законно затрагивают ~/.ssh/ или упоминают $OPENAI_API_KEY, слишком часто нарушали эвристику. Включите его снова, если хотите, чтобы сканер выдавал вам подсказку до того, как навык агента запишет:

skills:
  guard_agent_created: true   # default: false

Если эта функция включена, любая помеченная skill_manage запись отображается в виде запроса на одобрение с обоснованием сканера. Принято пишет землю; Отказ в записи возвращает агенту поясняющую ошибку.

Напишите одобрение для записи навыков

Независимо от описанного выше сканера контента, skills.write_approval блокирует каждую запись навыков агента (создание/редактирование/исправление/удаление/поддержку файлов) за вашим явным одобрением — тот же механизм одобрения/отклонения, что и опасные команды:

skills:
  write_approval: false   # false = write freely (default) | true = stage every write for review

Когда эта функция включена, записи навыков выполняются в соответствии с ~/.vibeos/pending/skills/ и проверяются с помощью /skills pending, /skills diff <id>, /skills approve <id>, /skills reject <id> — из CLI или любой платформы обмена сообщениями. Переключайтесь во время выполнения с помощью /skills approval on|off. Память имеет те же ворота (memory.write_approval`, ниже). Полное пошаговое руководство: Запись навыков агента Gating.

Конфигурация памяти

memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200   # ~800 tokens
  user_char_limit: 1375     # ~500 tokens
  context_max_chars: 6000   # лимит вспоминаемого контекста на один ход
  write_approval: false     # true = require approval before any memory write

При использовании memory.write_approval: true запись в память требует вашего одобрения, прежде чем она произойдет: интерактивный интерфейс командной строки превращает подсказку в строку; сеансы обмена сообщениями и фоновая проверка самосовершенствования составляют этап записи для проверки /memory pending → /memory approve <id> / /memory reject <id>. Переключайтесь во время выполнения с помощью /memory approval on|off. См. Управление записью в память.

context_max_chars ограничивает динамически добавляемое воспоминание от провайдеров памяти, прошлых сессий и заметок проекта на один ход (по умолчанию: 6 000 символов). Это контекст хода, поэтому его изменение не пересобирает замороженный системный промпт и не сбрасывает кэш промпта во время разговора.

Усечение файла контекста

Управляет объемом содержимого, загружаемым VibeOS из каждого файла автоматического контекста перед применением усечения начала и конца. Это относится к файлам, введенным в системную подсказку, таким как SOUL.md, .vibeos.md, AGENTS.md, CLAUDE.md и .cursorrules. Это не влияет на инструмент read_file.

context_file_max_chars: 20000  # default

Поднимите его, когда вы намеренно сохраняете файлы идентификации или контекста проекта большего размера и запускаете модели с достаточным контекстным окном для их переноса:

context_file_max_chars: 25000

Безопасность чтения файлов

Управляет объемом контента, который может вернуть один вызов read_file. Чтения, превышающие лимит, отклоняются с ошибкой, сообщающей агенту использовать offset и limit для меньшего диапазона. Это предотвращает заполнение контекстного окна при однократном чтении мини-пакета JS или большого файла данных.

file_read_max_chars: 100000  # default — ~25-35K tokens

Поднимите его, если вы используете модель с большим контекстным окном и часто читаете большие файлы. Уменьшите его для моделей с небольшим контекстом, чтобы сохранить эффективность чтения:

# Large context model (200K+)
file_read_max_chars: 200000

# Small local model (16K context)
file_read_max_chars: 30000

Агент также автоматически выполняет дедупликацию операций чтения файлов — если одна и та же область файла читается дважды и файл не изменился, вместо повторной отправки содержимого возвращается упрощенная заглушка. Это сбрасывается при сжатии контекста, поэтому агент может повторно прочитать файлы после суммирования их содержимого.

Пределы усечения выходных данных инструмента

Три связанных ограничения контролируют, сколько необработанных выходных данных может вернуть инструмент, прежде чем VibeOS усекает их:

tool_output:
  max_bytes: 50000        # terminal output cap (chars)
  max_lines: 2000         # read_file pagination cap
  max_line_length: 2000   # per-line cap in read_file's line-numbered view

• max_bytes — Когда команда terminal выдает больше, чем указанное количество символов комбинированного стандартного вывода/стандартного вывода, VibeOS сохраняет первые 40% и последние 60% и вставляет между ними уведомление [OUTPUT TRUNCATED]. По умолчанию 50000 (≈12–15 тыс. токенов в типичных токенайзерах).
• max_lines — Верхняя граница параметра limit одного вызова read_file. Запросы выше этого уровня ограничиваются, поэтому одно чтение не может заполнить контекстное окно. По умолчанию 2000.
• max_line_length — ограничение на строку применяется, когда read_file выдает представление с нумерацией строк. Строки длиннее этого числа обрезаются до указанного количества символов, за которыми следует ... [truncated]. По умолчанию 2000.

Увеличьте ограничения на модели с большими контекстными окнами, которые могут обеспечить больше необработанных результатов за вызов. Уменьшите их для моделей с небольшим контекстом, чтобы результаты инструмента были компактными:

# Large context model (200K+)
tool_output:
  max_bytes: 150000
  max_lines: 5000

# Small local model (16K context)
tool_output:
  max_bytes: 20000
  max_lines: 500

Отключить глобальный набор инструментов

Чтобы подавить определенные наборы инструментов в CLI и каждой платформе шлюза в одном место, перечислите их имена в разделе agent.disabled_toolsets:

agent:
  disabled_toolsets:
    - memory       # hide memory tools + MEMORY_GUIDANCE injection
    - web          # no web_search / web_extract anywhere

Это применяется после конфигурации инструмента для каждой платформы (platform_toolsets, написанной vibeos tools), поэтому указанный здесь набор инструментов всегда удаляется, даже если в сохраненной конфигурации платформы он все еще указан. Используйте это, если вам нужен один переключатель «Выключить X везде» вместо редактирования более 15 строк платформы в пользовательский интерфейс vibeos tools.

Оставить список пустым или пропустить ключ — это пустая операция.

Изоляция рабочего дерева Git

Включите изолированные рабочие деревья git для параллельного запуска нескольких агентов в одном репозитории:

worktree: true    # Always create a worktree (same as vibeos -w)
# worktree: false # Default — only when -w flag is passed

Если этот параметр включен, каждый сеанс CLI создает новое рабочее дерево под .worktrees/ со своей собственной ветвью. Агенты могут редактировать файлы, фиксировать, отправлять и создавать PR, не мешая друг другу. Чистые рабочие деревья удаляются при выходе; грязные сохраняются для ручного восстановления.

По умолчанию новое рабочее дерево разветвляется от только что полученной удаленной подсказки (вышестоящей ветки, в противном случае — от ветки по умолчанию для удаленной версии), поэтому оно начинается с текущей версии проекта, а не с возможно устаревшего HEAD локального клона. Это сохраняет область различий PR в соответствии с фактическими изменениями, а не наследует все, что было от локального клона. Вместо этого установите worktree_sync: false для ветвления от локального HEAD — полезно в автономном режиме или когда вы намеренно хотите, чтобы точное текущее состояние клона было базовым. Если удаленный доступ недоступен, он автоматически возвращается к локальному HEAD.

worktree_sync: true    # Default — branch from the fetched remote tip
# worktree_sync: false # Branch from local HEAD (offline / pinned base)

Вы также можете перечислить файлы gitignored для копирования в рабочие деревья через .worktreeinclude в корне вашего репо:

# .worktreeinclude
.env
.venv/
node_modules/

Сжатие контекста

VibeOS автоматически сжимает длинные разговоры, чтобы оставаться в пределах контекстного окна вашей модели. Сумматор сжатия — это отдельный вызов LLM — вы можете указать его на любого провайдера или конечную точку.

Все настройки сжатия хранятся в config.yaml (без переменных среды).

Полная ссылка

compression:
  enabled: true                                     # Toggle compression on/off
  threshold: 0.50                                   # Compress at this % of context limit
  target_ratio: 0.20                                # Fraction of threshold to preserve as recent tail
  protect_last_n: 20                                # Min recent messages to keep uncompressed
  protect_first_n: 3                                # Non-system head messages pinned across compactions (0 = pin nothing)
  hygiene_hard_message_limit: 5000                  # Gateway safety valve — see below

# The summarization model/provider is configured under auxiliary:
auxiliary:
  compression:
    model: ""                                       # Empty = use main chat model. Override with e.g. "google/gemini-3-flash-preview" for cheaper/faster compression.
    provider: "auto"                                # Provider: "auto", "openrouter", "nous", "codex", "main", etc.
    base_url: null                                  # Custom OpenAI-compatible endpoint (overrides provider)

Миграция устаревшей конфигурации

Старые конфигурации с compression.summary_model, compression.summary_provider и compression.summary_base_url автоматически переносятся в auxiliary.compression.* при первой загрузке (версия конфигурации 17). Никаких ручных действий не требуется.

hygiene_hard_message_limit — это шлюзовой предохранительный клапан предварительного сжатия. Он существует для того, чтобы разорвать смертельную спираль: когда вызовы API продолжают отключаться в слишком большом сеансе, шлюз никогда не получает данные об использовании токена, поэтому порог на основе токена не может сработать, поэтому расшифровка продолжает расти, а отключения ухудшаются. Этот основанный на подсчете нижний предел срабатывает только на основании количества сообщений (всегда известное, независимо от сбоев API) для принудительного сжатия и восстановления сеанса. По умолчанию 5000 — намного выше любого обычного сеанса, включая модели с большим контекстом (1M+), выполняющие тысячи коротких оборотов, которые сжимаются на пороге токена задолго до этого. Поднимите его еще больше для необычных платформ и опустите, чтобы обеспечить более агрессивное сжатие. Изменение этого значения на работающем шлюзе вступит в силу в следующем сообщении (см. ниже).

protect_first_n контролирует, сколько несистемных заголовочных сообщений закрепляется при каждом сжатии. По умолчанию 3 — вводный обмен пользователем/помощником сохраняется при каждом проходе сумматора, поэтому исходная цель остается видимой. В длительных сеансах уплотнения, когда первый поворот больше не важен, установите protect_first_n: 0, чтобы не закреплять ничего, кроме системного приглашения + сводки + хвоста. Само системное приглашение всегда сохраняется независимо от этой настройки.

Горячая перезагрузка шлюза сжатия и длины контекста

Начиная с последних выпусков, редактирование model.context_length или любого ключа compression.* в config.yaml на работающем шлюзе вступает в силу для следующего сообщения — ни перезапуска шлюза, ни /reset, ни ротации сеансов не требуется. Подпись кэшированного агента включает эти ключи, поэтому шлюз прозрачно перестраивает агент, когда видит изменение. Ключи API и конфигурация инструментов/навыков по-прежнему требуют обычных путей перезагрузки.

Общие настройки

По умолчанию (автоопределение) — настройка не требуется:

compression:
  enabled: true
  threshold: 0.50

Использует вашего основного поставщика и основную модель. Переопределите каждую задачу (например, auxiliary.compression.provider: openrouter + model: google/gemini-2.5-flash), если вы хотите использовать более дешевую модель сжатия, чем ваша основная модель чата.

Принудительно указать конкретного поставщика (на основе OAuth или ключа API):

auxiliary:
  compression:
    provider: nous
    model: gemini-3-flash

Работает с любым провайдером: nous, openrouter, codex, anthropic, main и т. д.

Пользовательская конечная точка (автономное размещение, Ollama, zai, DeepSeek и т. д.):

auxiliary:
  compression:
    model: glm-4.7
    base_url: https://api.z.ai/api/coding/paas/v4

Указывает на пользовательскую конечную точку, совместимую с OpenAI. Использует OPENAI_API_KEY для аутентификации.

Как взаимодействуют три ручки

auxiliary.compression.provider	auxiliary.compression.base_url	Результат
auto (по умолчанию)	не установлено	Автоматическое определение наилучшего доступного провайдера
nous / openrouter / и т. д.	не установлено	Принудительно использовать этого провайдера, использовать его авторизацию
любой	набор	Использовать пользовательскую конечную точку напрямую (поставщик игнорируется)

Требование к длине контекста сводной модели

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

Механизм контекста

Механизм контекста управляет тем, как управляются разговоры при приближении к пределу токенов модели. Встроенный механизм compressor использует суммирование с потерями (см. Сжатие контекста). Плагины могут заменить его альтернативными стратегиями.

context:
  engine: "compressor"    # default — built-in lossy summarization

Чтобы использовать подключаемый модуль (например, LCM для управления контекстом без потерь):

context:
  engine: "lcm"          # must match the plugin's name

Механизмы плагинов никогда не активируются автоматически — вы должны явно указать context.engine для имени плагина. Доступные движки можно просмотреть и выбрать через vibeos plugins → Плагины провайдера → Механизм контекста.

См. Поставщики памяти для получения информации об аналогичной системе единого выбора для плагинов памяти.

Давление на бюджет итерации

Когда агент работает над сложной задачей с множеством вызовов инструментов, он может израсходовать свой бюджет итераций (по умолчанию: 90 ходов), не осознавая, что он заканчивается. Бюджетное давление автоматически предупреждает модель, когда оно приближается к пределу:

Порог	Уровень	Что видит модель
70%	Внимание	[BUDGET: 63/90. 27 iterations left. Start consolidating.]
90%	Предупреждение	[BUDGET WARNING: 81/90. Only 9 left. Respond NOW.]

Предупреждения вводятся в JSON последнего результата инструмента (в виде поля _budget_warning), а не в отдельные сообщения — это сохраняет кэширование подсказок и не нарушает структуру диалога.

agent:
  max_turns: 90                # Max iterations per conversation turn (default: 90)
  api_max_retries: 3           # Retries per provider before fallback engages (default: 3)

Бюджетное давление включено по умолчанию. Агент естественным образом воспринимает предупреждения как часть результатов работы инструмента, что побуждает его консолидировать свою работу и предоставить ответ до того, как иссякнут итерации.

Когда бюджет итерации полностью исчерпан, CLI отображает пользователю уведомление: ⚠ Iteration budget reached (90/90) — response may be incomplete. Если во время активной работы бюджет исчерпан, агент перед остановкой генерирует сводку о том, что было выполнено.

agent.api_max_retries контролирует, сколько раз VibeOS повторяет вызов API поставщика при временных ошибках (ограничения скорости, разрывы соединения, 5xx) до переключения резервного поставщика. По умолчанию — 3 — всего четыре попытки. Если у вас настроены резервные поставщики и вы хотите выполнить аварийное переключение быстрее, отмените это значение до 0, чтобы первая временная ошибка на вашем основном сервере немедленно перешла к резервному, вместо того, чтобы постоянно повторять попытки обращения к нестабильной конечной точке.

Тайм-ауты API

VibeOS имеет отдельные уровни тайм-аута для потоковой передачи, а также детектор устаревших вызовов для непоточных вызовов. Детекторы устаревания автоматически настраиваются на местных поставщиков только в том случае, если вы оставляете для них неявные значения по умолчанию.

Тайм-аут	По умолчанию	Местные провайдеры	Конфиг/окр
Тайм-аут чтения сокета	120-е	Автоматически повышен до 1800-х годов	VIBEOS_STREAM_READ_TIMEOUT
Обнаружение устаревшего потока	180-е годы	Автоотключение	VIBEOS_STREAM_STALE_TIMEOUT
Устаревшее непотоковое обнаружение	300-е годы	Автоматически отключается, если оставить неявным	providers.<id>.stale_timeout_seconds или VIBEOS_API_CALL_STALE_TIMEOUT
Вызов API (без потоковой передачи)	1800-е годы	Без изменений	providers.<id>.request_timeout_seconds / timeout_seconds или VIBEOS_API_TIMEOUT

Тайм-аут чтения сокета определяет, как долго httpx ожидает следующего фрагмента данных от поставщика. Локальным LLM может потребоваться несколько минут для предварительного заполнения в больших контекстах перед созданием первого токена, поэтому VibeOS увеличивает это время до 30 минут, когда обнаруживает локальную конечную точку. Если вы явно задали VIBEOS_STREAM_READ_TIMEOUT, это значение будет использоваться всегда независимо от обнаружения конечной точки.

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

Обнаружение устаревшего непотока уничтожает непотоковые вызовы, которые слишком долго не отвечают. По умолчанию VibeOS отключает это на локальных конечных точках, чтобы избежать ложных срабатываний во время длительных предварительных заполнений. Если вы явно задали providers.<id>.stale_timeout_seconds, providers.<id>.models.<model>.stale_timeout_secondsилиVIBEOS_API_CALL_STALE_TIMEOUT`, это явное значение учитывается даже на локальных конечных точках.

Предупреждения о давлении контекста

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

Прогресс	Уровень	Что происходит
≥ 60% до порогового значения	Информация	CLI показывает голубой индикатор выполнения; шлюз отправляет информационное уведомление
≥ 85% до порогового значения	Предупреждение	CLI показывает жирную желтую полосу; шлюз предупреждает, что уплотнение неизбежно

В CLI контекстное давление отображается в виде индикатора выполнения в выходной ленте инструмента:

  ◐ context ████████████░░░░░░░░ 62% to compaction  48k threshold (50%) · approaching compaction

На платформах обмена сообщениями отправляется текстовое уведомление:

◐ Context: ████████████░░░░░░░░ 62% to compaction (threshold: 50% of window).

Если автоматическое сжатие отключено, предупреждение сообщит вам, что вместо этого контекст может быть усечен.

Контекстное давление происходит автоматически — настройка не требуется. Он срабатывает исключительно как уведомление для пользователя и не изменяет поток сообщений и не вводит ничего в контекст модели.

Стратегии пула учетных данных

Если у вас есть несколько ключей API или токенов OAuth для одного и того же провайдера, настройте стратегию ротации:

credential_pool_strategies:
  openrouter: round_robin    # cycle through keys evenly
  anthropic: least_used      # always pick the least-used key

Опции: fill_first (по умолчанию), round_robin, least_used, random. Полную документацию см. в разделе Пулы учетных данных.

Быстрое кэширование

VibeOS автоматически включает межсессионное кэширование подсказок, если активный поставщик поддерживает это — пользовательская настройка не требуется.

Для Claude в native Anthropic, OpenRouter и Nous Portal VibeOS присоединяет точки останова cache_control с 1-часовым сроком жизни (ttl: "1h") в системных подсказках и блоках навыков. Первая отправка в течение нового часа оплачивается по полной ставке; последующие отправки в рамках любого сеанса в течение того же часа извлекаются из кэша со сниженной скоростью чтения из кэша. Это означает, что системное приглашение, загруженное содержимое навыков и начальная часть любого длинного контекста будут повторно использоваться в сеансах vibeos и между разветвленными субагентами в течение первого часа.

Восходящее облако Qwen Cloud (Alibaba DashScope) ограничивает TTL кэша на уровне 5 минут, поэтому VibeOS вместо этого использует 5-минутный TTL точки останова. Другие пути Claude-через сторонние организации (AWS Bedrock, Azure Foundry) возвращаются к собственным настройкам кэширования поставщика по умолчанию. xAI Grok использует отдельный механизм идентификатора разговора, закрепленный за сеансом — см. кэширование подсказок xAI.

Не существует ручки, позволяющей отключить это — кэширование всегда включено и экономит деньги даже при одноразовых разговорах, поскольку одно только системное приглашение составляет значительную часть количества входных токенов.

Вспомогательные модели

VibeOS использует «вспомогательные» модели для дополнительных задач, таких как анализ изображений, обобщение веб-страниц, анализ снимков экрана браузера, генерация заголовка сеанса и сжатие контекста. По умолчанию (auxiliary.*.provider: "auto") VibeOS направляет все вспомогательные задачи в вашу основную модель чата — того же провайдера/модель, который вы выбрали в vibeos model. Для начала вам не нужно ничего настраивать, но имейте в виду, что в дорогих моделях рассуждения (Opus, MiniMax M2.7 и т. д.) вспомогательные задачи увеличивают значительную стоимость. Если вам нужны дешевые и быстрые побочные задачи независимо от вашей основной модели, явно установите auxiliary.<task>.provider и auxiliary.<task>.model (например, Gemini Flash на OpenRouter для машинного зрения и веб-извлечения).

Почему «авто» использует вашу основную модель

Ранее пользователи раздельного агрегатора (OpenRouter, Nous Portal) создавались на основе дешевого дефолта на стороне провайдера. Это было удивительно — пользователи, оплатившие подписку на агрегатор, увидели другую модель обработки их вспомогательного трафика. auto теперь использует основную модель для всех, а переопределения для каждой задачи в config.yaml по-прежнему имеют преимущество (см. Полную ссылку на вспомогательную конфигурацию ниже).

Интерактивная настройка вспомогательных моделей

Вместо редактирования YAML вручную запустите vibeos model и выберите в меню "Настроить вспомогательные модели". Вы получите интерактивный инструмент выбора каждой задачи:

$ vibeos model
→ Configure auxiliary models

[ ] vision               currently: auto / main model
[ ] web_extract          currently: auto / main model
[ ] title_generation     currently: openrouter / google/gemini-3-flash-preview
[ ] tts_audio_tags       currently: auto / main model
[ ] compression          currently: auto / main model
[ ] approval             currently: auto / main model
[ ] triage_specifier     currently: auto / main model
[ ] kanban_decomposer    currently: auto / main model
[ ] profile_describer    currently: auto / main model

Выберите задачу, выберите провайдера (потоки OAuth открывают браузер; подсказка поставщиков API-ключей), выберите модель. Изменение сохраняется до auxiliary.<task>.* в config.yaml. Тот же механизм, что и у средства выбора основной модели — не нужно изучать дополнительный синтаксис.

Видеоурок

Универсальный шаблон конфигурации

В каждом слоте модели в VibeOS — вспомогательные задачи, сжатие, резерв — используются одни и те же три ручки:

Ключ	Что он делает	По умолчанию
provider	Какой провайдер использовать для аутентификации и маршрутизации	"auto"
model	Какую модель запросить	по умолчанию провайдера
base_url	Пользовательская конечная точка, совместимая с OpenAI (переопределяет поставщика)	не установлено

Если установлен base_url, VibeOS игнорирует провайдера и вызывает эту конечную точку напрямую (используя api_key или OPENAI_API_KEY для аутентификации). Если задан только provider, VibeOS использует встроенную аутентификацию и базовый URL-адрес этого провайдера.

Доступные провайдеры для вспомогательных задач: auto, main, плюс любой провайдер в реестре провайдеров — openrouter, nous, openai-codex, copilot, copilot-acp, anthropic, gemini, qwen-oauth, zai, kimi-coding, kimi-coding-cn, minimax, minimax-cn, minimax-oauth, deepseek, nvidia, xai, xai-oauth, ollama-cloud, alibaba, bedrock, huggingface, arcee, xiaomi, kilocode, opencode-zen, opencode-go, azure-foundry — или любой именованный пользовательский поставщик из вашего списка custom_providers (например, provider: "beans").

MiniMax OAuth

minimax-oauth входит в систему через OAuth браузера (ключ API не требуется). Запустите vibeos model и выберите MiniMax (OAuth) для аутентификации. Вспомогательные задачи автоматически используют MiniMax-M2.7-highspeed. См. Руководство MiniMax OAuth.

xAI Grok OAuth

xai-oauth входит в систему через OAuth браузера для подписчиков SuperGrok и X Premium+ (ключ API не требуется). Запустите vibeos model и выберите xAI Grok OAuth (SuperGrok / Premium+) для аутентификации. Один и тот же токен OAuth повторно используется для каждой поверхности прямого доступа к xAI (чат, вспомогательные задачи, TTS, генерация изображений, генерация видео, транскрипция). См. руководство по OAuth xAI Grok, а если VibeOS находится на удаленном хосте, см. OAuth через SSH/удаленные хосты.

"main" предназначено только для вспомогательных задач.

Опция поставщика "main" означает «использовать любого поставщика, который использует мой основной агент» — она действительна только внутри auxiliary:, compression: и основных резервных записей (fallback_providers: или устаревших fallback_model:). Это не допустимое значение для настройки model.provider верхнего уровня. Если вы используете собственную конечную точку, совместимую с OpenAI, установите provider: custom в разделе model:. См. раздел Поставщики ИИ для получения информации обо всех основных вариантах поставщиков моделей.

Полная ссылка на вспомогательную конфигурацию

auxiliary:
  # Image analysis (vision_analyze tool + browser screenshots)
  vision:
    provider: "auto"           # "auto", "openrouter", "nous", "codex", "main", etc.
    model: ""                  # e.g. "openai/gpt-4o", "google/gemini-2.5-flash"
    base_url: ""               # Custom OpenAI-compatible endpoint (overrides provider)
    api_key: ""                # API key for base_url (falls back to OPENAI_API_KEY)
    timeout: 120               # seconds — LLM API call timeout; vision payloads need generous timeout
    download_timeout: 30       # seconds — image HTTP download; increase for slow connections

  # Web page summarization + browser page text extraction
  web_extract:
    provider: "auto"
    model: ""                  # e.g. "google/gemini-2.5-flash"
    base_url: ""
    api_key: ""
    timeout: 360               # seconds (6min) — per-attempt LLM summarization

  # Dangerous command approval classifier
  approval:
    provider: "auto"
    model: ""
    base_url: ""
    api_key: ""
    timeout: 30                # seconds

  # Gemini 3.1 TTS hidden audio-tag insertion
  tts_audio_tags:
    provider: "auto"
    model: ""                  # empty = main chat model
    base_url: ""
    api_key: ""
    timeout: 30

  # Context compression timeout (separate from compression.* config)
  compression:
    timeout: 120               # seconds — compression summarizes long conversations, needs more time
    # fallback_chain:           # Optional — providers to try on rate-limit / connectivity failure
    #   - provider: nous
    #     model: deepseek/deepseek-chat
    #   - provider: openrouter
    #     model: google/gemini-2.5-flash
    #     base_url: ""
    #     api_key: ""

  # Auto-generated session titles. Empty language follows the conversation;
  # set e.g. "English" or "Japanese" to pin titles to one language.
  title_generation:
    provider: "auto"
    model: ""
    base_url: ""
    api_key: ""
    timeout: 30
    language: ""

  # Skills hub — skill matching and search
  skills_hub:
    provider: "auto"
    model: ""
    base_url: ""
    api_key: ""
    timeout: 30

  # MCP tool dispatch
  mcp:
    provider: "auto"
    model: ""
    base_url: ""
    api_key: ""
    timeout: 30

  # Kanban triage specifier — `vibeos kanban specify <id>` (or the
  # dashboard's ✨ Specify button on Triage-column cards) uses this
  # slot to expand a one-liner into a concrete spec and promote the
  # task to `todo`. Cheap fast models work well here; spec expansion
  # is short and doesn't need reasoning depth.
  triage_specifier:
    provider: "auto"
    model: ""
    base_url: ""
    api_key: ""
    timeout: 120

подсказка

Каждая вспомогательная задача имеет настраиваемый timeout (в секундах). По умолчанию: Vision 120 с, web_extract 360 с, утверждение 30 с, сжатие 120 с. Увеличьте их, если вы используете медленные локальные модели для вспомогательных задач. Vision также имеет отдельный download_timeout (по умолчанию 30 с) для загрузки изображений по HTTP — увеличьте это значение для медленных соединений или автономных серверов изображений.

к сведению

Сжатие контекста имеет собственный блок compression: для пороговых значений и блок auxiliary.compression: для настроек модели/провайдера — см. Сжатие контекста выше. Основная резервная цепочка использует список fallback_providers: верхнего уровня — см. Резервные поставщики. Все три следуют одному и тому же шаблону поставщика/модели/base_url.

Резервная цепочка для каждой задачи для вспомогательных задач

Для каждой вспомогательной задачи можно дополнительно определить fallback_chain — список записей поставщика/модели, которые VibeOS пытается использовать в случае сбоя основного вспомогательного поставщика из-за ограничений скорости, проблем с подключением или ограничений платежей:

auxiliary:
  compression:
    provider: openrouter
    model: openai/gpt-4o-mini
    fallback_chain:
      - provider: nous
        model: deepseek/deepseek-chat
      - provider: openrouter
        model: google/gemini-2.5-flash

Когда основной вспомогательный провайдер (openrouter / openai/gpt-4o-mini) возвращает ограничение скорости, время ожидания соединения или ошибку, требующую платежа, VibeOS проходит fallback_chain по порядку. Он пропускает записи, поставщик которых совпадает с поставщиком, который уже потерпел неудачу, и пробует каждую оставшуюся запись до тех пор, пока одна из них не будет успешной или цепочка не будет исчерпана. Если все резервные варианты оказываются неудачными, VibeOS возвращается к модели основного агента в качестве последней системы безопасности.

Каждая запись поддерживает те же три ручки, что и любая конфигурация вспомогательной задачи:

Ключ	Описание
provider	Имя провайдера (nous, openrouter, anthropic, gemini, main и т. д.)
model	Название модели для этого поставщика
base_url	(Необязательно) Пользовательская конечная точка, совместимая с OpenAI

fallback_chain доступен для любой вспомогательной задачи — compression, vision, web_extract, approval, skills_hub, mcp и т. д.

Маршрутизация OpenRouter и код Парето для вспомогательных задач

Когда вспомогательная задача разрешается OpenRouter (явно или через provider: "main", когда ваш основной агент находится на OpenRouter), настройки provider_routing и openrouter.min_coding_score основного агента не распространяются — по замыслу каждая вспомогательная задача независима. Чтобы установить настройки провайдера OpenRouter или использовать маршрутизатор с кодом Парето для конкретной дополнительной задачи, установите их для каждой задачи через extra_body:

auxiliary:
  compression:
    provider: openrouter
    model: openrouter/pareto-code         # use the Pareto Code router for this task
    extra_body:
      provider:                            # OpenRouter provider routing prefs
        order: [anthropic, google]         # try these providers in order
        sort: throughput                   # or "price" | "latency"
        # only: [anthropic]                # restrict to a specific provider
        # ignore: [deepinfra]              # exclude specific providers
      plugins:                             # OpenRouter Pareto Code router knob
        - id: pareto-router
          min_coding_score: 0.5            # 0.0–1.0; higher = stronger coders

Форма отражает то, что OpenRouter принимает в теле запроса на завершение чата. VibeOS пересылает весь extra_body дословно, поэтому любое другое поле тела запроса OpenRouter, задокументированное в openrouter.ai/docs, работает таким же образом.

Изменение модели видения

Чтобы использовать GPT-4o вместо Gemini Flash для анализа изображений:

auxiliary:
  vision:
    model: "openai/gpt-4o"

Или через переменную среды (в ~/.vibeos/.env):

AUXILIARY_VISION_MODEL=openai/gpt-4o

Параметры провайдера

Эти параметры применяются к конфигурациям вспомогательных задач (auxiliary:, compression:) и основным резервным записям (fallback_providers: или устаревшим fallback_model:), а не к основной настройке model.provider.

Провайдер	Описание	Требования
"auto"	Лучшее из доступных (по умолчанию). Vision пробует OpenRouter → Nous → Codex.	—
"openrouter"	Force OpenRouter — маршруты на любую модель (Gemini, GPT-4o, Claude и т.д.)	OPENROUTER_API_KEY
"nous"	Портал Форс Ноус	vibeos auth
"codex"	Принудительно использовать OAuth Кодекса (учетная запись ChatGPT). Поддерживает зрение (gpt-5.3-codex).	vibeos model → Кодекс
"minimax-oauth"	Принудительно использовать MiniMax OAuth (вход в браузер, без ключа API). Для вспомогательных задач использует MiniMax-M2.7-высокоскоростной.	vibeos model → MiniMax (OAuth)
"xai-oauth"	Принудительно использовать xAI Grok OAuth (вход в браузер для подписчиков SuperGrok или X Premium+, без ключа API). Тот же токен OAuth охватывает чат, TTS, изображения, видео и транскрипцию.	vibeos model → xAI Grok OAuth (SuperGrok / Premium+)
"main"	Используйте активную пользовательскую/основную конечную точку. Это может быть получено из OPENAI_BASE_URL + OPENAI_API_KEY или из пользовательской конечной точки, сохраненной через vibeos model / config.yaml. Работает с OpenAI, локальными моделями или любым API-интерфейсом, совместимым с OpenAI. Только вспомогательные задачи — недействительно для model.provider.	Пользовательские учетные данные конечной точки + базовый URL-адрес

Здесь также работают прямые поставщики API-ключей из основного каталога провайдеров, если вы хотите, чтобы побочные задачи обходили ваш маршрутизатор по умолчанию. gmi действителен после настройки GMI_API_KEY:

auxiliary:
  compression:
    provider: "gmi"
    model: "anthropic/claude-opus-4.6"

Для вспомогательной маршрутизации GMI используйте точный идентификатор модели, возвращаемый конечной точкой /v1/models GMI.

Общие настройки

Использование прямой пользовательской конечной точки (яснее, чем provider: "main" для локальных/автономных API):

auxiliary:
  vision:
    base_url: "http://localhost:1234/v1"
    api_key: "local-key"
    model: "qwen2.5-vl"

base_url имеет приоритет над provider, поэтому это наиболее явный способ маршрутизации вспомогательной задачи к определенной конечной точке. Для прямого переопределения конечной точки VibeOS использует настроенный api_key или возвращается к OPENAI_API_KEY; он не использует повторно OPENROUTER_API_KEY для этой пользовательской конечной точки.

Использование ключа OpenAI API для зрения:

# In ~/.vibeos/.env:
# OPENAI_BASE_URL=https://api.openai.com/v1
# OPENAI_API_KEY=sk-...

auxiliary:
  vision:
    provider: "main"
    model: "gpt-4o"       # or "gpt-4o-mini" for cheaper

Использование OpenRouter для машинного зрения (переход к любой модели):

auxiliary:
  vision:
    provider: "openrouter"
    model: "openai/gpt-4o"      # or "google/gemini-2.5-flash", etc.

Использование OpenAI ChatGPT (учетная запись ChatGPT Pro/Plus — ключ API не требуется):

auxiliary:
  vision:
    provider: "codex"     # использует ваш токен ChatGPT
    # model defaults to gpt-5.3-codex (supports vision)

Использование MiniMax OAuth (вход через браузер, ключ API не требуется):

model:
  default: MiniMax-M2.7
  provider: minimax-oauth
  base_url: https://api.minimax.io/anthropic

Запустите vibeos model и выберите MiniMax (OAuth), чтобы войти в систему и установить это автоматически. Для региона Китая базовым URL-адресом будет https://api.minimaxi.com/anthropic. Полное описание см. в Руководстве MiniMax OAuth.

Использование локальной/автономной модели:

auxiliary:
  vision:
    provider: "main"      # uses your active custom endpoint
    model: "my-local-model"

provider: "main" использует любого поставщика, который VibeOS использует для обычного чата — будь то именованный пользовательский поставщик (например, beans), встроенный поставщик, такой как openrouter, или устаревшая конечная точка OPENAI_BASE_URL.

подсказка

Если вы используете OpenAI ChatGPT в качестве основного поставщика моделей, Vision работает автоматически — дополнительная настройка не требуется. Маршрут ChatGPT включен в цепочку автоопределения по зрению.

предупреждение

Для Vision требуется мультимодальная модель. Если вы установите provider: "main", убедитесь, что ваша конечная точка поддерживает мультимодальность/видение — в противном случае анализ изображения не удастся.

Переменные среды (устаревшие версии)

Вспомогательные модели также можно настроить с помощью переменных среды. Однако config.yaml является предпочтительным методом: им проще управлять, и он поддерживает все варианты, включая base_url и api_key.

Настройка	Переменная среды
Поставщик видения	AUXILIARY_VISION_PROVIDER
Модель видения	AUXILIARY_VISION_MODEL
Конечная точка зрения	AUXILIARY_VISION_BASE_URL
Ключ API Vision	AUXILIARY_VISION_API_KEY
Поставщик веб-выдержек	AUXILIARY_WEB_EXTRACT_PROVIDER
Модель веб-извлечения	AUXILIARY_WEB_EXTRACT_MODEL
Конечная точка веб-извлечения	AUXILIARY_WEB_EXTRACT_BASE_URL
API-ключ веб-извлечения	AUXILIARY_WEB_EXTRACT_API_KEY

Настройки сжатия и резервной модели доступны только в config.yaml.

подсказка

Запустите vibeos config, чтобы увидеть текущие настройки вспомогательной модели. Переопределения отображаются только в том случае, если они отличаются от значений по умолчанию.

Усилие рассуждения

Контролируйте, сколько «думает» модель, прежде чем ответить:

agent:
  reasoning_effort: ""   # empty = medium (default). Options: none, minimal, low, medium, high, xhigh (max)

Если параметр не установлен (по умолчанию), усилие рассуждения по умолчанию равно «среднему» — сбалансированному уровню, который хорошо подходит для большинства задач. Установка значения переопределяет его: более высокие усилия по рассуждению дают лучшие результаты в сложных задачах за счет большего количества токенов и задержки.

на модели адаптивного мышления (Claude 4.6+, класс Fable/Mythos) через OpenRouter

Эти модели используют адаптивное мышление и не принимают обычные reasoning.effort. поле — OpenRouter игнорирует его для них. VibeOS прозрачно маршрутизирует ваши Вместо этого reasoning_effort используется параметр verbosity OpenRouter (который соответствует output_config.effort от Anthropic), то же самое low/medium/high/xhigh Ручка продолжает работать — дополнительная настройка не требуется. none (или не установлен) оставляет модель по собственному адаптивному умолчанию. (max принимается в проводном режиме, но не является выбираемое значение reasoning_effort; xhigh — это настраиваемый потолок.) Родной поставщик Anthropic уже напрямую контролирует усилия и на него это не влияет.

Вы также можете изменить усилие рассуждения во время выполнения с помощью команды /reasoning:

/reasoning           # Show current effort level and display state
/reasoning high      # Set reasoning effort to high
/reasoning none      # Disable reasoning
/reasoning show      # Show model thinking above each response
/reasoning hide      # Hide model thinking

Контроль за использованием инструментов

Некоторые модели иногда описывают предполагаемые действия в виде текста вместо вызова инструментов («Я бы запускал тесты...» вместо фактического вызова терминала). Контроль за использованием инструментов вводит системные подсказки, которые возвращают модель к фактическому вызову инструментов.

agent:
  tool_use_enforcement: "auto"   # "auto" | true | false | ["model-substring", ...]

Значение	Поведение
"auto" (по умолчанию)	Включено для соответствия моделей: gpt, codex, gemini, gemma, grok. Отключено для всех остальных (Claude, DeepSeek, Qwen и т. д.).
true	Всегда включен, независимо от модели. Полезно, если вы заметили, что ваша текущая модель описывает действия, а не выполняет их.
false	Всегда отключен, независимо от модели.
["gpt", "codex", "qwen", "llama"]	Включено только в том случае, если имя модели содержит одну из перечисленных подстрок (без учета регистра).

Что он вводит

Если эта функция включена, в системную подсказку могут быть добавлены три уровня указаний:

1. Общее обеспечение использования инструментов (все соответствующие модели) — предписывает модели немедленно вызывать инструменты, а не описывать намерения, продолжать работу до тех пор, пока задача не будет завершена, и никогда не заканчивать ход обещанием будущих действий.

2. Дисциплина выполнения OpenAI (только модели GPT и Codex) — дополнительные рекомендации по устранению режимов сбоев, специфичных для GPT: отказ от работы с частичными результатами, пропуск обязательных поисков, галлюцинации вместо использования инструментов и объявление «выполнено» без проверки.

3. Руководство Google (только для моделей Gemini и Gemma) — краткость, абсолютные пути, параллельные вызовы инструментов и шаблоны проверки перед редактированием.

Они прозрачны для пользователя и влияют только на системное приглашение. Модели, которые уже надежно используют инструменты (например, Claude), не нуждаются в этом руководстве, поэтому "auto" их исключает.

Когда его включать

Если вы используете модель, отсутствующую в автоматическом списке по умолчанию, и заметили, что она часто описывает то, что она будет делать, вместо того, чтобы делать это, установите tool_use_enforcement: true или добавьте подстроку модели в список:

agent:
  tool_use_enforcement: ["gpt", "codex", "gemini", "grok", "my-custom-model"]

Конфигурация TTS

tts:
  provider: "edge"              # "edge" | "elevenlabs" | "openai" | "minimax" | "mistral" | "gemini" | "xai" | "neutts"
  speed: 1.0                    # Global speed multiplier (fallback for all providers)
  edge:
    voice: "en-US-AriaNeural"   # 322 voices, 74 languages
    speed: 1.0                  # Speed multiplier (converted to rate percentage, e.g. 1.5 → +50%)
  elevenlabs:
    voice_id: "pNInz6obpgDQGcFmaJgB"
    model_id: "eleven_multilingual_v2"
  openai:
    model: "gpt-4o-mini-tts"
    voice: "alloy"              # alloy, echo, fable, onyx, nova, shimmer
    speed: 1.0                  # Speed multiplier (clamped to 0.25–4.0 by the API)
    base_url: "https://api.openai.com/v1"  # Override for OpenAI-compatible TTS endpoints
  minimax:
    speed: 1.0                  # Speech speed multiplier
    # base_url: ""              # Optional: override for OpenAI-compatible TTS endpoints
  mistral:
    model: "voxtral-mini-tts-2603"
    voice_id: "c69964a6-ab8b-4f8a-9465-ec0925096ec8"  # Paul - Neutral (default)
  gemini:
    model: "gemini-2.5-flash-preview-tts"   # or gemini-3.1-flash-tts-preview
    voice: "Kore"               # 30 prebuilt voices: Zephyr, Puck, Kore, Enceladus, etc.
    audio_tags: false           # Hidden Gemini 3.1 TTS audio-tag insertion
    persona_prompt_file: ""      # Optional Markdown/text file with Gemini voice direction
  xai:
    voice_id: "eve"             # xAI TTS voice
    language: "en"              # ISO 639-1
    sample_rate: 24000
    bit_rate: 128000            # MP3 bitrate
    # base_url: "https://api.x.ai/v1"
  neutts:
    ref_audio: ''
    ref_text: ''
    model: neuphonic/neutts-air-q4-gguf
    device: cpu

Это управляет как инструментом text_to_speech, так и голосовыми ответами в голосовом режиме (/voice tts в интерфейсе командной строки или шлюзе обмена сообщениями).

Иерархия резервных скоростей: скорость, зависящая от поставщика (например, tts.edge.speed) → глобальная tts.speed → 1.0 по умолчанию. Установите глобальный параметр tts.speed, чтобы применить единую скорость для всех провайдеров, или переопределите каждого провайдера для детального контроля.

Настройки дисплея

display:
  tool_progress: all      # off | new | all | verbose
  tool_progress_command: false  # Enable /verbose slash command in messaging gateway
  platforms: {}           # Per-platform display overrides (see below)
  tool_progress_overrides: {}  # DEPRECATED — use display.platforms instead
  interim_assistant_messages: true  # Gateway: send natural mid-turn assistant updates as separate messages
  skin: default           # Built-in or custom CLI skin (see user-guide/features/skins)
  personality: "kawaii"  # Legacy cosmetic field still surfaced in some summaries
  compact: false          # Compact output mode (less whitespace)
  resume_display: full    # full (show previous messages on resume) | minimal (one-liner only)
  bell_on_complete: false # Play terminal bell when agent finishes (great for long tasks)
  show_reasoning: false   # Show model reasoning/thinking above each response (toggle with /reasoning show|hide)
  streaming: false        # Stream tokens to terminal as they arrive (real-time output)
  show_cost: false        # Show estimated $ cost in the CLI status bar
  timestamps: false       # When true, prefixes user and assistant labels with [HH:MM] timestamps in the CLI / TUI transcript
  tool_preview_length: 0  # Max chars for tool call previews (0 = no limit, show full paths/commands)
  runtime_footer:         # Gateway: append a runtime-context footer to final replies
    enabled: false
    fields: ["model", "context_pct", "cwd"]
  file_mutation_verifier: true    # Append an advisory footer when write_file/patch calls failed this turn
  credits_notices: true   # Nous credits status-bar notices (usage bands, grant-spent, depleted). false = silence them; /usage still works
  language: en            # UI language for static messages (approval prompts, some gateway replies). en | zh | zh-hant | ja | de | es | fr | tr | uk | af | ko | it | ga | pt | ru | hu

Верификатор мутации файла

Если display.file_mutation_verifier имеет значение true (по умолчанию), VibeOS добавляет однострочную рекомендацию к окончательному ответу помощника всякий раз, когда вызов write_file или patch терпит неудачу во время хода и никогда не заменяется успешной записью по тому же пути. Это улавливает класс чрезмерного утверждения «пакет параллельных патчей, половина молча терпит неудачу, модель суммирует успех», не требуя от вас вручную запускать git status после каждого редактирования.

Пример нижнего колонтитула:

⚠️ File-mutation verifier: 3 file(s) were NOT modified this turn despite any wording above that may suggest otherwise. Run `git status` or `read_file` to confirm.
  • concepts/automatic-organization.md — [patch] Could not find match for old_string
  • concepts/lora.md — [patch] Could not find match for old_string
  • concepts/rag-pipeline.md — [patch] Could not find match for old_string

Установите file_mutation_verifier: false (или VIBEOS_FILE_MUTATION_VERIFIER=0), чтобы подавить нижний колонтитул. Верификатор срабатывает только тогда, когда в конце хода возникают реальные сбои — модель, которая повторяет неудачный патч и добивается успеха в течение того же хода, не будет активировать его для этого файла.

Язык пользовательского интерфейса для статических сообщений

Параметр display.language преобразует небольшой набор статических сообщений, обращенных к пользователю — запрос на одобрение CLI, несколько ответов на команды шлюза (например, уведомления о перезапуске-сливе, «утверждение истекло», «цель достигнута»). Он не переводит ответы агентов, строки журнала, выходные данные инструмента, обратные трассировки ошибок или описания slash-команд — они остаются на английском. Если вы хотите, чтобы сам агент ответил на другом языке, просто сообщите об этом в подсказке или системном сообщении.

Поддерживаемые значения: en (по умолчанию), zh (упрощенный китайский), zh-hant (традиционный китайский), ja (японский), de (немецкий), es (испанский), fr (французский), tr (турецкий), uk (украинский), af (африкаанс), ko (корейский), it (итальянский), ga (ирландский), pt (португальский), ru (русский), hu (венгерский). Неизвестные значения возвращаются к английскому языку.

Вы также можете установить это значение для каждого сеанса с помощью переменной env VIBEOS_LANGUAGE, которая переопределяет значение конфигурации.

display:
  language: zh   # CLI approval prompts appear in Chinese

Режим	Что вы видите
off	Молчание — лишь последний ответ
new	Индикатор инструмента только при смене инструмента
all	Каждый вызов инструмента с кратким предварительным просмотром (по умолчанию)
verbose	Полные аргументы, результаты и журналы отладки

В CLI циклически переключайте эти режимы с помощью /verbose. Чтобы использовать /verbose на платформах обмена сообщениями (Telegram, Discord, Slack и т. д.), установите tool_progress_command: true в разделе display выше. Затем команда переключит режим и сохранит его в конфигурации.

Для прогресса инструмента требуется адаптер шлюза, который может безопасно отображать обновления хода выполнения. Платформы без поддержки редактирования сообщений, включая Signal, подавляют всплывающие сообщения о ходе работы инструмента, даже если /verbose сохраняет режим, отличный от off.

Нижний колонтитул метаданных среды выполнения (только шлюз)

При display.runtime_footer.enabled: true VibeOS добавляет небольшой нижний колонтитул контекста времени выполнения к последнему сообщению каждого поворота шлюза. Текущий нижний колонтитул может отображать модель, процент контекстного окна и текущий рабочий каталог. По умолчанию выключено; выберите настройку для каждого шлюза, если ваша команда хочет, чтобы каждый ответ включал это происхождение.

display:
  runtime_footer:
    enabled: true
    fields: ["model", "context_pct", "cwd"]   # supported fields: model, context_pct, cwd

Команда /footer переключает это во время выполнения в любом сеансе.

Пример нижнего колонтитула, добавленного к ответу Telegram/Discord/Slack:

— claude-opus-4.7 · 12 tool calls · 2m 14s · $0.042

Только последнее сообщение хода попадает в нижний колонтитул; промежуточные обновления остаются чистыми.

Переопределение прогресса для каждой платформы

Разные платформы имеют разные потребности в многословии. Используйте display.platforms для установки режимов для каждой платформы:

display:
  tool_progress: all          # global default
  platforms:
    signal:
      tool_progress: 'off'    # Signal cannot currently display tool-progress bubbles
    telegram:
      tool_progress: verbose  # detailed progress on Telegram
    slack:
      tool_progress: 'off'    # quiet in shared Slack workspace

Платформы без переопределения возвращаются к глобальному значению tool_progress. Действительные ключи платформы: telegram, discord, slack, signal, whatsapp, matrix, mattermost, email, sms, homeassistant, dingtalk, feishu, wecom, weixin, bluebubbles, qqbot. Устаревший ключ display.tool_progress_overrides по-прежнему загружается для обратной совместимости, но считается устаревшим и переносится в display.platforms при первой загрузке.

Signal указан как действительный ключ платформы, поскольку настройку можно сохранить для каждой платформы, но текущий адаптер Signal не может редактировать отправленные сообщения и не отображает пузырьки прогресса инструмента. Оставьте для сигнала tool_progress значение off; используйте интерфейс командной строки или платформу обмена сообщениями с возможностью редактирования, если вам нужно наблюдать за каждым вызовом инструмента в реальном времени.

interim_assistant_messages предназначен только для шлюза. Если этот параметр включен, VibeOS отправляет завершенные обновления помощника в середине хода в виде отдельных сообщений чата. Это не зависит от tool_progress и не требует потоковой передачи через шлюз.

Конфиденциальность

privacy:
  redact_pii: false  # Strip PII from LLM context (gateway only)

Если redact_pii имеет значение true, шлюз редактирует личную информацию из системного приглашения перед отправкой ее в LLM на поддерживаемых платформах:

Поле	Лечение
Номера телефонов (идентификатор пользователя в WhatsApp/Signal)	Хэшировано в user_<12-char-sha256>
Идентификаторы пользователей	Хэшировано в user_<12-char-sha256>
Идентификаторы чата	Числовая часть хеширована, префикс платформы сохранен (telegram:<hash>`)
Идентификаторы домашних каналов	Числовая часть хешируется
Имена пользователей / имена пользователей	Не затронуто (выбирается пользователем, общедоступно)

Поддержка платформ: Редактирование распространяется на WhatsApp, Signal и Telegram. Discord и Slack исключены, поскольку их системы упоминаний (<@user_id>) требуют реального идентификатора в контексте LLM.

Хэши детерминированы — один и тот же пользователь всегда сопоставляется с одним и тем же хешем, поэтому модель по-прежнему может различать пользователей в групповых чатах. При маршрутизации и доставке внутри используются исходные значения.

Преобразование речи в текст (STT)

stt:
  provider: "local"            # "local" | "groq" | "openai" | "mistral"
  local:
    model: "base"              # tiny, base, small, medium, large-v3
  openai:
    model: "whisper-1"         # whisper-1 | gpt-4o-mini-transcribe | gpt-4o-transcribe
  # model: "whisper-1"         # Legacy fallback key still respected

Поведение провайдера:

• local использует faster-whisper, работающий на вашем компьютере. Установите его отдельно с помощью pip install faster-whisper.
• groq использует конечную точку Groq, совместимую с Whisper, и читает GROQ_API_KEY.
• openai использует речевой API OpenAI и читает VOICE_TOOLS_OPENAI_KEY.

Если запрошенный провайдер недоступен, VibeOS автоматически возвращается в следующем порядке: local → groq → openai.

Переопределения моделей Groq и OpenAI зависят от среды:

STT_GROQ_MODEL=whisper-large-v3-turbo
STT_OPENAI_MODEL=whisper-1
GROQ_BASE_URL=https://api.groq.com/openai/v1
STT_OPENAI_BASE_URL=https://api.openai.com/v1

Голосовой режим (CLI)

voice:
  record_key: "ctrl+b"         # Push-to-talk key inside the CLI
  max_recording_seconds: 120    # Hard stop for long recordings
  auto_tts: false               # Enable spoken replies automatically when /voice on
  beep_enabled: true            # Play record start/stop beeps in CLI voice mode
  silence_threshold: 200        # RMS threshold for speech detection
  silence_duration: 3.0         # Seconds of silence before auto-stop

Используйте /voice on в интерфейсе командной строки, чтобы включить режим микрофона, record_key, чтобы начать/остановить запись, и /voice tts, чтобы включить голосовой ответ. См. Голосовой режим для полной настройки и поведения в зависимости от платформы.

Стриминг

Передавайте токены на терминал или платформы обмена сообщениями по мере их поступления, вместо ожидания полного ответа.

Потоковая передача через CLI

display:
  streaming: true         # Stream tokens to terminal in real-time
  show_reasoning: true    # Also stream reasoning/thinking tokens (optional)

Если этот параметр включен, ответы отображаются по токенам внутри поля потоковой передачи. Вызовы инструментов по-прежнему фиксируются автоматически. Если провайдер не поддерживает потоковую передачу, он автоматически возвращается к нормальному отображению.

Потоковая передача через шлюз (Telegram, Discord, Slack)

streaming:
  enabled: true           # Enable progressive message editing
  transport: edit         # "edit" (progressive message editing) or "off"
  edit_interval: 0.3      # Seconds between message edits
  buffer_threshold: 40    # Characters before forcing an edit flush
  cursor: " ▉"            # Cursor shown during streaming
  fresh_final_after_seconds: 0    # Opt in to fresh final (Telegram) when preview is this old

Если эта функция включена, бот отправляет сообщение на первый токен, а затем постепенно редактирует его по мере поступления новых токенов. Платформы, которые не поддерживают редактирование сообщений (Signal, Email, Home Assistant), обнаруживаются автоматически с первой попытки — потоковая передача корректно отключается для этого сеанса без потока сообщений.

Для отдельных естественных обновлений помощника в середине хода без прогрессивного редактирования токенов установите display.interim_assistant_messages: true.

Обработка переполнения. Если передаваемый текст превышает ограничение длины сообщения платформы (~4096 символов), текущее сообщение завершается и автоматически запускается новое.

Новый финал (Telegram): editMessageText Telegram сохраняет временную метку исходного сообщения, поэтому длительный потоковый ответ будет сохранять временную метку первого токена даже после завершения. Установите fresh_final_after_seconds > 0, чтобы разрешить доставку старых предпросмотров в виде совершенно новых финальных сообщений с возможностью удаления предпросмотра. По умолчанию используется 0, который всегда завершает потоковые ответы на месте и позволяет избежать короткой последовательности дублирования сообщений/удаления на клиентах, на которых показаны обе операции.

настройки потоковой передачи по умолчанию для каждой платформы

Главный переключатель streaming.enabled по умолчанию — false — ничего не передается, пока вы его не переключите. После включения потоковая передача определяется для каждой платформы: Telegram поставляется с display.platforms.telegram.streaming: true (потоки), а Discord с display.platforms.discord.streaming: false (нет). Таким образом, после включения потоковой передачи Telegram выполняет потоковую передачу прямо из коробки, а Discord продолжает отвечать на все сообщения, пока вы не измените его переключатель. Вы можете настроить эти переключатели для каждой платформы с помощью переключателей Каналы на панели управления или непосредственно в ~/.vibeos/config.yaml.

Изоляция сеанса группового чата

Ограничьте количество сеансов чата, которые могут быть активно открыты через CLI, TUI/панель управления, и шлюз обмена сообщениями:

max_concurrent_sessions: null  # null/0 = unlimited; positive integer = active session cap

При достижении ограничения VibeOS возвращает прямое сообщение об ограничении новых сеансов. Существующие активные сеансы сохраняют нормальное поведение.

Канонический ключ — это max_concurrent_sessions верхнего уровня. VibeOS также принимает gateway.max_concurrent_sessions как запасной вариант, но ключ верхнего уровня выигрывает, когда оба установлены.

Ограничение обеспечивается с помощью локального файла аренды среды выполнения и является максимально возможным: VibeOS не открывается, если реестр не может быть прочитан или заблокирован, чтобы пользователи не оказались в затруднительном положении. Он предназначен для выполнения одного хоста/профиля, а не общего $VIBEOS_HOME. устанавливается на несколько машин.

Управляйте тем, будут ли в общих чатах вестися по одному разговору на комнату или по одному разговору на каждого участника:

group_sessions_per_user: true  # true = per-user isolation in groups/channels, false = one shared session per chat
thread_sessions_per_user: false  # false = one shared lane per thread (default); true = per-user inside threads

• group_sessions_per_user: true — это рекомендуемая настройка по умолчанию. В каналах Discord, группах Telegram, каналах Slack и подобных общих контекстах каждый отправитель получает свой собственный сеанс, когда платформа предоставляет идентификатор пользователя.
• group_sessions_per_user: false возвращается к старому поведению в общей комнате. Это может быть полезно, если вы явно хотите, чтобы VibeOS рассматривала канал как один совместный разговор, но это также означает, что пользователи разделяют контекст, стоимость токенов и состояние прерывания.
• Прямые сообщения не затронуты. VibeOS по-прежнему управляет личными сообщениями по идентификатору чата/DM, как обычно. – Темы/темы всегда отделены от родительского канала, но участники одной темы по умолчанию делят один сеанс (thread_sessions_per_user: false). Установите thread_sessions_per_user: true, когда каждому человеку в ветке Discord/Slack/Telegram требуется линия частного агента.
• Ни один флаг не меняется terminal.cwd — шлюз обмена сообщениями по-прежнему использует один рабочий каталог уровня процесса для команд инструмента.

Подробности и примеры поведения см. в Сессии и Руководство Discord.

Несанкционированное поведение DM

Управляйте действиями VibeOS, когда неизвестный пользователь отправляет личное сообщение:

unauthorized_dm_behavior: pair

whatsapp:
  unauthorized_dm_behavior: ignore

• pair используется по умолчанию для платформ DM в стиле чата. VibeOS запрещает доступ, но отвечает одноразовым кодом сопряжения в личных сообщениях.
• ignore автоматически отбрасывает неавторизованные DM.
• По умолчанию для электронной почты используется ignore, если не установлен platforms.email.unauthorized_dm_behavior: pair, поскольку входящие почтовые ящики могут содержать несвязанную непрочитанную почту.
• Разделы платформы переопределяют глобальные настройки по умолчанию, поэтому вы можете широко включать сопряжение, одновременно делая одну платформу тише.

Быстрые команды

Определите пользовательские команды, которые либо запускают команды оболочки без вызова LLM, либо присваивают одну slash-команду другой команде. Быстрые команды Exec не требуют токенов и полезны на платформах обмена сообщениями (Telegram, Discord и т. д.) для быстрой проверки сервера или служебных сценариев.

quick_commands:
  status:
    type: exec
    command: systemctl status vibeos-agent
  disk:
    type: exec
    command: df -h /
  update:
    type: exec
    command: cd ~/.vibeos/vibeos-agent && git pull && pip install -e .
  gpu:
    type: exec
    command: nvidia-smi --query-gpu=name,utilization.gpu,memory.used,memory.total --format=csv,noheader
  restart:
    type: alias
    target: /gateway restart

Использование: введите /status, /disk, /update, /gpu или /restart в CLI или на любой платформе обмена сообщениями. Команды exec выполняются локально на хосте и возвращают выходные данные напрямую — без вызова LLM и без потребления токенов. Команды alias переписываются в настроенную slash-цель.

• 30-секундный тайм-аут — длительные команды завершаются с сообщением об ошибке.
• Приоритет — быстрые команды проверяются перед командами навыков, поэтому вы можете переопределить названия навыков.
• Автозаполнение — быстрые команды обрабатываются во время отправки и не отображаются во встроенных таблицах автозаполнения slash-команд.
• Тип — поддерживаются типы exec и alias; другие типы показывают ошибку
• Работает везде — CLI, Telegram, Discord, Slack, WhatsApp, Signal, электронная почта, Home Assistant.

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

Человеческая задержка

Имитируйте человеческую скорость ответа на платформах обмена сообщениями:

human_delay:
  mode: "off"                  # off | natural | custom
  min_ms: 800                  # Minimum delay (custom mode)
  max_ms: 2500                 # Maximum delay (custom mode)

Выполнение кода

Настройте инструмент execute_code:

code_execution:
  mode: project                # project (default) | strict
  timeout: 300                 # Max execution time in seconds
  max_tool_calls: 50           # Max tool calls within code execution

mode управляет рабочим каталогом и интерпретатором Python для сценариев:

• project (по умолчанию) — сценарии запускаются в рабочем каталоге сеанса с активным Python окружения virtualenv/conda. Данные проекта (pandas, torch, пакеты проектов) и относительные пути (.env, ./data.csv) разрешаются естественным образом в соответствии с тем, что видит terminal().
• strict — сценарии выполняются во временном промежуточном каталоге с помощью sys.executable (собственный Python VibeOS). Максимальная воспроизводимость, но данные проекта и относительные пути не будут решены.

Очистка среды (полосы *_API_KEY, *_TOKEN, *_SECRET, *_PASSWORD, *_CREDENTIAL, *_PASSWD, *_AUTH) и белый список инструментов применяются одинаково в обоих режимах — переключение режима не меняет состояние безопасности.

Серверы веб-поиска

Инструменты web_search и web_extract поддерживают пять серверных поставщиков. Настройте серверную часть в config.yaml или через vibeos tools:

web:
  backend: firecrawl    # firecrawl | searxng | parallel | tavily | exa

  # Or use per-capability keys to mix providers (e.g. free search + paid extract):
  search_backend: "searxng"
  extract_backend: "firecrawl"

Бэкэнд	Конверт Вар	Поиск	Экстракт
Firecrawl (по умолчанию)	FIRECRAWL_API_KEY	✔	✔
ИскатьXNG	SEARXNG_URL	✔	—
Параллельно	PARALLEL_API_KEY	✔	✔
Тавили	TAVILY_API_KEY	✔	✔
Экса	EXA_API_KEY	✔	✔

Выбор серверной части: Если web.backend не установлен, серверная часть автоматически определяется по доступным ключам API. Если установлен только SEARXNG_URL, используется SearXNG. Если установлен только EXA_API_KEY, используется Exa. Если установлен только TAVILY_API_KEY, используется Tavily. Если установлен только PARALLEL_API_KEY, используется Параллельный режим. В противном случае Firecrawl используется по умолчанию.

SearXNG — это бесплатная, автономная, уважающая конфиденциальность метапоисковая система, которая запрашивает более 70 поисковых систем. Ключ API не требуется — просто установите SEARXNG_URL для своего экземпляра (например, http://localhost:8080). SearXNG предназначен только для поиска; web_extract требует отдельного поставщика извлечений (установите web.extract_backend). Инструкции по настройке Docker см. в Руководстве по настройке веб-поиска.

Самостоятельный Firecrawl: Установите FIRECRAWL_API_URL так, чтобы он указывал на ваш собственный экземпляр. Если задан пользовательский URL-адрес, ключ API становится необязательным (задайте на сервере `USE_DB_AUTHENTICATION=***, чтобы отключить аутентификацию).

Режимы параллельного поиска: Установите PARALLEL_SEARCH_MODE для управления поведением поиска — fast, one-shot или agentic (по умолчанию: agentic).

Пример: Установите EXA_API_KEY в ~/.vibeos/.env. Поддерживает фильтрацию category (company, research paper, news, people, personal site, pdf) и фильтры домена/даты.

Браузер

Настройте поведение автоматизации браузера:

browser:
  inactivity_timeout: 120        # Seconds before auto-closing idle sessions
  command_timeout: 30             # Timeout in seconds for browser commands (screenshot, navigate, etc.)
  record_sessions: false         # Auto-record browser sessions as WebM videos to ~/.vibeos/browser_recordings/
  # Optional CDP override — when set, VibeOS attaches directly to your own
  # Chromium-family browser (via /browser connect) rather than starting a headless browser.
  cdp_url: ""
  # Dialog supervisor — controls how native JS dialogs (alert / confirm / prompt)
  # are handled when a CDP backend is attached (Browserbase, local Chromium-family
  # browser via /browser connect). Ignored on Camofox and default local agent-browser mode.
  dialog_policy: must_respond    # must_respond | auto_dismiss | auto_accept
  dialog_timeout_s: 300          # Safety auto-dismiss under must_respond (seconds)
  camofox:
    managed_persistence: false   # When true, Camofox sessions persist cookies/logins across restarts
    user_id: ""                  # Optional externally managed Camofox userId
    session_key: ""              # Optional session key sent when VibeOS creates a tab
    adopt_existing_tab: false    # Reuse an existing tab for this identity before creating one

Политики диалога:

• must_respond (по умолчанию) — захватить диалог, передать его в browser_snapshot.pending_dialogs и дождаться, пока агент вызовет browser_dialog(action=...). После dialog_timeout_s секунд отсутствия ответа диалоговое окно автоматически закрывается, чтобы предотвратить вечное зависание потока JS страницы.
• auto_dismiss — захватить, немедленно уволить. Агент по-прежнему видит запись диалога в browser_snapshot.recent_dialogs с closed_by="auto_policy" постфактум.
• auto_accept — захватить, принять немедленно. Полезно для страниц с агрессивными подсказками beforeunload.

См. страницу функций браузера для полного процесса работы с диалогом.

Набор инструментов браузера поддерживает несколько поставщиков. См. страницу функций браузера для получения подробной информации о базе браузеров, использовании браузера и локальной настройке CDP семейства Chromium.

Часовой пояс

Переопределить локальный часовой пояс сервера с помощью строки часового пояса IANA. Влияет на временные метки в журналах, планирование cron и ввод времени системных подсказок.

timezone: "America/New_York"   # IANA timezone (default: "" = server-local time)

Поддерживаемые значения: любой идентификатор часового пояса IANA (например, America/New_York, Europe/London, Asia/Kolkata, UTC). Оставьте пустым или не указывайте локальное время сервера.

Discord

Настройте поведение шлюза обмена сообщениями, специфичное для Discord:

discord:
  require_mention: true          # Require @mention to respond in server channels
  free_response_channels: ""     # Comma-separated channel IDs where bot responds without @mention
  auto_thread: true              # Auto-create threads on @mention in channels

• require_mention — если true (по умолчанию), бот отвечает в каналах сервера только при упоминании @BotName. Директ всегда работает без упоминания.
• free_response_channels — список идентификаторов каналов, разделенных запятыми, где бот отвечает на каждое сообщение, не требуя упоминания.
• auto_thread — если true (по умолчанию), упоминания в каналах автоматически создают цепочку для разговора, сохраняя каналы чистыми (аналогично тредированию в Slack).

Безопасность

Сканирование безопасности перед выполнением и секретное редактирование:

security:
  redact_secrets: true           # Redact API key patterns in tool output and logs (on by default)
  tirith_enabled: true           # Enable Tirith security scanning for terminal commands
  tirith_path: "tirith"          # Path to tirith binary (default: "tirith" in $PATH)
  tirith_timeout: 5              # Seconds to wait for tirith scan before timing out
  tirith_fail_open: true         # Allow command execution if tirith is unavailable
  website_blocklist:             # See Website Blocklist section below
    enabled: false
    domains: []
    shared_files: []

• redact_secrets — когда true автоматически обнаруживает и редактирует шаблоны, которые выглядят как ключи API, токены и пароли в выходных данных инструмента, прежде чем они войдут в контекст разговора и зарегистрируются. Включено по умолчанию. Устанавливайте false явно только в том случае, если вам нужны необработанные строки, подобные учетным данным, для отладки или разработки редактора.
• tirith_enabled — когда true, команды терминала сканируются Тиритом перед выполнением для обнаружения потенциально опасных операций.
• tirith_path — путь к тиритному двоичному файлу. Установите это значение, если Тирит установлен в нестандартном месте.
• tirith_timeout — максимальное количество секунд ожидания тиритового сканирования. Команды продолжают выполняться, если время сканирования истекло.
• tirith_fail_open — если true (по умолчанию), команды могут выполняться, если тирит недоступен или произошел сбой. Установите false, чтобы блокировать команды, когда Тирит не может их проверить.

Черный список веб-сайтов

Заблокируйте доступ к определенным доменам для веб-инструментов агента и браузера:

security:
  website_blocklist:
    enabled: false               # Enable URL blocking (default: false)
    domains:                     # List of blocked domain patterns
      - "*.internal.company.com"
      - "admin.example.com"
      - "*.local"
    shared_files:                # Load additional rules from external files
      - "/etc/vibeos/blocked-sites.txt"

Если этот параметр включен, любой URL-адрес, соответствующий шаблону заблокированного домена, отклоняется до запуска веб-инструмента или браузера. Это относится к web_search, web_extract, browser_navigate и любому инструменту, осуществляющему доступ к URL-адресам.

Правила домена поддерживают:

• Точные домены: admin.example.com
• Субдомены с подстановочными знаками: *.internal.company.com (блокирует все поддомены).
• Подстановочные знаки TLD: *.local.

Общие файлы содержат по одному правилу домена в каждой строке (пустые строки и комментарии # игнорируются). Отсутствующие или нечитаемые файлы регистрируют предупреждение, но не отключают другие веб-инструменты.

Политика кэшируется на 30 секунд, поэтому изменения конфигурации вступают в силу быстро, без перезапуска.

Умные утверждения

Контролируйте, как VibeOS обрабатывает потенциально опасные команды:

approvals:
  mode: manual   # manual | smart | off

Режим	Поведение
manual (по умолчанию)	Запрашивайте у пользователя перед выполнением любой помеченной команды. В интерфейсе командной строки отображается интерактивное диалоговое окно утверждения. При обмене сообщениями ставит в очередь ожидающий запрос на утверждение.
smart	Используйте вспомогательный LLM, чтобы оценить, действительно ли помеченная команда опасна. Команды с низким уровнем риска утверждаются автоматически с сохранением на уровне сеанса. Действительно рискованные команды передаются пользователю.
off	Пропустите все проверки одобрения. Эквивалент VIBEOS_YOLO_MODE=true. Использовать с осторожностью.

Интеллектуальный режим особенно полезен для снижения усталости от одобрения — он позволяет агенту более автономно работать над безопасными операциями, при этом перехватывая действительно деструктивные команды.

предупреждение

Настройка approvals.mode: off отключает все проверки безопасности для команд терминала. Используйте это только в надежных изолированных средах.

Контрольно-пропускные пункты

Автоматические снимки файловой системы перед разрушительными файловыми операциями. Подробности см. в разделе Проверочные точки и откат.

checkpoints:
  enabled: false                 # Enable automatic checkpoints (also: vibeos chat --checkpoints). Default: false (opt-in).
  max_snapshots: 20              # Max checkpoints to keep per directory (default: 20)

Делегирование

Настройте поведение субагента для инструмента делегирования:

delegation:
  # model: "google/gemini-3-flash-preview"  # Override model (empty = inherit parent)
  # provider: "openrouter"                  # Override provider (empty = inherit parent)
  # base_url: "http://localhost:1234/v1"    # Direct OpenAI-compatible endpoint (takes precedence over provider)
  # api_key: "local-key"                    # API key for base_url (falls back to OPENAI_API_KEY)
  # api_mode: ""                            # Wire protocol for base_url: "chat_completions", "codex_responses", or "anthropic_messages". Empty = auto-detect from URL (e.g. /anthropic suffix → anthropic_messages). Set explicitly for non-standard endpoints the heuristic can't detect.
  max_concurrent_children: 3                # Parallel children per batch (floor 1, no ceiling). Also via DELEGATION_MAX_CONCURRENT_CHILDREN env var.
  max_spawn_depth: 1                        # Delegation tree depth cap (1-3, clamped). 1 = flat (default): parent spawns leaves that cannot delegate. 2 = orchestrator children can spawn leaf grandchildren. 3 = three levels.
  orchestrator_enabled: true                # Global kill switch. When false, role="orchestrator" is ignored and every child is forced to leaf regardless of max_spawn_depth.

Поставщик субагента:переопределение модели: По умолчанию субагенты наследуют поставщика и модель родительского агента. Установите delegation.provider и delegation.model для маршрутизации субагентов к другой паре поставщик:модель — например, используйте дешевую/быструю модель для подзадач с узким охватом, в то время как ваш основной агент выполняет дорогостоящую модель рассуждения.

Прямое переопределение конечной точки: Если вам нужен очевидный путь к пользовательской конечной точке, установите delegation.base_url, delegation.api_key и delegation.model. При этом подагенты отправляются непосредственно в эту конечную точку, совместимую с OpenAI, и имеют приоритет над delegation.provider. Если delegation.api_key опущен, VibeOS возвращается только к OPENAI_API_KEY.

Протокол проводной связи (api_mode): VibeOS автоматически определяет проводной протокол из delegation.base_url (например, пути, заканчивающиеся на /anthropic → anthropic_messages; имена хостов Codex/родного антропного кодирования/Kimi сохраняют существующее обнаружение). Для конечных точек, которые эвристика не может классифицировать — например, прокси-серверы Azure AI Foundry, MiniMax, Zhipu GLM или LiteLLM, выходящие на серверную часть в форме Anthropic, — явно задайте для delegation.api_mode одно из chat_completions, codex_responses или anthropic_messages. Оставьте это поле пустым (по умолчанию), чтобы сохранить автоматическое обнаружение.

Поставщик делегирования использует то же разрешение учетных данных, что и запуск CLI/шлюза. Поддерживаются все настроенные провайдеры: openrouter, nous, copilot, zai, kimi-coding, minimax, minimax-cn. Когда поставщик настроен, система автоматически определяет правильный базовый URL-адрес, ключ API и режим API — привязка учетных данных вручную не требуется.

Приоритет: delegation.base_url в конфигурации → delegation.provider в конфигурации → родительский поставщик (наследуется). delegation.model в конфигурации → родительская модель (унаследованная). Установка только model без provider изменяет только имя модели, сохраняя при этом учетные данные родителя (полезно для переключения моделей в пределах одного поставщика, например OpenRouter).

Ширина и глубина: max_concurrent_children ограничивает количество субагентов, работающих параллельно в одном пакете (по умолчанию 3, нижний уровень — 1, без потолка). Также может быть установлено через переменную окружения DELEGATION_MAX_CONCURRENT_CHILDREN. Когда модель отправляет массив tasks, длина которого превышает ограничение, delegate_task возвращает ошибку инструмента, объясняющую ограничение, а не молчаливое усечение. max_spawn_depth управляет глубиной дерева делегирования (ограничено 1–3). По умолчанию 1 делегирование является плоским: дети не могут порождать внуков, а передача role="orchestrator" автоматически деградирует до leaf. Поднимите до 2, чтобы дочерние элементы оркестратора могли порождать внуков листьев; 3 для трехуровневых деревьев. Агент включает оркестрацию для каждого вызова через role="orchestrator"; orchestrator_enabled: false заставляет каждого дочернего элемента вернуться на лист независимо от того. Стоимость масштабируется мультипликативно: при max_spawn_depth: 3 и max_concurrent_children: 3 дерево может достигать 3×3×3 = 27 одновременных конечных агентов. См. Делегирование субагента → Ограничение глубины и вложенная оркестрация для получения информации о шаблонах использования.

Объяснить

Настройте поведение подсказки разъяснения:

clarify:
  timeout: 120                 # Seconds to wait for user clarification response

Контекстные файлы (SOUL.md, AGENTS.md)

VibeOS использует две разные области контекста:

Файл	Цель	Область применения
SOUL.md	Основной идентификатор агента — определяет, кем является агент (слот № 1 в системном приглашении)	~/.vibeos/SOUL.md или $VIBEOS_HOME/SOUL.md
.vibeos.md / VIBEOS.md	Инструкции по конкретному проекту (высший приоритет)	Переход к git root
AGENTS.md	Инструкции для конкретного проекта, соглашения по кодированию	Рекурсивный обход каталогов
CLAUDE.md	Контекстные файлы Claude Code (также обнаружены)	Только рабочий каталог
.cursorrules	Правила курсора IDE (также обнаружены)	Только рабочий каталог
.cursor/rules/*.mdc	Файлы правил курсора (также обнаружены)	Только рабочий каталог

• SOUL.md — это основной идентификатор агента. Он занимает слот №1 в системной подсказке, полностью заменяя встроенный идентификатор по умолчанию. Отредактируйте его, чтобы полностью настроить агента.
• Если файл SOUL.md отсутствует, пуст или не может быть загружен, VibeOS возвращается к встроенному идентификатору по умолчанию.
• Файлы контекста проекта используют систему приоритетов — загружается только ОДИН тип (побеждает первое совпадение): .vibeos.md → AGENTS.md → CLAUDE.md → .cursorrules. SOUL.md всегда загружается независимо.
• AGENTS.md является иерархическим: если подкаталоги также имеют AGENTS.md, все они объединяются.
• VibeOS автоматически создает SOUL.md по умолчанию, если он еще не существует.
• Все загруженные файлы контекста ограничены символами context_file_max_chars (по умолчанию 20 000) с интеллектуальным усечением.

См. также:

• Personality & SOUL.md
• Контекстные файлы

Рабочий каталог

Контекст	По умолчанию
CLI (vibeos)	Текущий каталог, в котором вы запускаете команду
Шлюз обмена сообщениями	terminal.cwd из ~/.vibeos/config.yaml; если не установлено, домашний каталог ~
Docker/Singularity/Модальный/SSH	Домашний каталог пользователя внутри контейнера или удаленного компьютера

Переопределить рабочий каталог:

# In ~/.vibeos/config.yaml:
terminal:
  cwd: /home/myuser/projects

MESSAGING_CWD и прямые записи TERMINAL_CWD в ~/.vibeos/.env являются резервными вариантами совместимости с устаревшими версиями. В новых конфигурациях следует использовать terminal.cwd.