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

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

Коротко: что брать под сколько агентов

Цены — мои собственные счета на сентябрь 2026, а не прайс с витрины. Дальше — откуда взялись эти числа.

Агент ест от 90 до 680 МБ, и предсказать нельзя

Замер 9 сентября 2026, массовый перезапуск двадцати агентов на боевой машине. Разброс в семь с половиной раз.

Столько же весит разница между «агент ждёт сообщения» и «агент разбирает документ на сорок страниц». Средним числом тут пользоваться нельзя: планировать надо по верхней границе, иначе машина ляжет ровно в тот момент, когда несколько агентов возьмутся за работу одновременно.

Практическое правило, которое у меня работает: 680 МБ на агента, который может взяться за тяжёлое, и 150 МБ на агента‑дежурного, который только смотрит и отвечает коротко.

Пятнадцать агентов, поднятых подряд, кладут машину

Самая дорогая ошибка из трёх. Я перезапускал агентов циклом с паузой в секунду — и машина ушла целиком, вместе с теми, кто уже работал.

Причина простая. Подъём — это пик: агент читает свои файлы, поднимает сессию, разбирает настройки. Пятнадцать пиков в одну секунду складываются. Свопа на той машине не было, значит падать было некуда.

Как это чинится:

1. Поднимать по одному, а не циклом.

2. Между подъёмами смотреть свободную память — free -m.

3. Ниже 1200 МБ свободной — ждать, а не поднимать следующего.

4. Агента, который сейчас в работе, пропускать и брать вторым заходом.

У меня это теперь делает скрипт, но первые полгода я поднимал по три‑четыре руками с проверкой между ними. Работает так же.

Своп: на 4 ГБ обязателен, на 8 ГБ не нужен

На маленькой машине своп — это разница между «агент подтормозил» и «машина легла». Четыре гигабайта файлом, обычный swapfile, ставится один раз.

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

Потолки на агента — то, что ломается раньше памяти

Эта ошибка самая подлая, и я потерял на ней день.

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

Что было дальше:

• Сборщик мусора системы убил агента посреди ответа человеку.

• Одно ядро на двенадцать дало очередь 10.87 — это в десять раз больше нормы.

• Ответы шли по 10–18 минут вместо секунд.

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

Задушенный потолком агент не жалуется. Он просто медленно отвечает.

После пересчёта потолков под новое железо очередь стала 1.10. Те же двенадцать агентов, та же машина, разница только в двух числах в конфиге.

Правило, которое я записал себе после этого: меняешь железо — той же сессией правь потолки. Не «потом проверю», а в том же заходе.

Браузер добавляет 400 МБ к каждому запуску

Если агент умеет открывать страницы, считайте отдельно. Chromium при запуске берёт около 400 мегабайт.

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

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

Диск и процессор: что оказалось неважным

Восемьдесят гигабайт диска у меня заняты на 21% при двадцати агентах и полугоде журналов. Диск — последнее, о чём стоит думать.

Процессор важен, но не так, как кажется. Агент почти всё время ждёт ответа от внешнего сервиса, а не считает. Ядра нужны не под вычисления, а чтобы очередь не выстраивалась в моменты, когда несколько агентов проснулись разом. Четыре ядра на двадцать агентов — с запасом.

Где ставить: страна решает больше, чем железо

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

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

На чём это крутить

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

1. Российские площадки отпадают по стране, но у части российских хостеров есть Амстердам и Франкфурт — и платить за них можно рублями с обычной карты.

2. Заявленный в договоре SLA и фактическая доступность расходятся сильно. У одного из популярных вариантов за два месяца 2026 года набежало около 46 часов простоя в европейской зоне — по данным его же канала оповещений. Смотреть надо не обещание, а историю аварий.

Чек‑лист перед тем, как поднимать

1. Посчитать верхнюю границу: 680 МБ на тяжёлого агента, 150 на дежурного.

2. Добавить 400 МБ за каждого, кто может открыть браузер одновременно.

3. Меньше 8 ГБ — поставить своп файлом.

4. Задать потолок памяти и процессора на каждого агента.

5. Записать эти потолки рядом с размером машины, чтобы при следующем переезде их пересчитали, а не перенесли.

6. Поднимать по одному, проверяя свободную память между подъёмами.

Источники: откуда цифры

Все замеры мои, сняты на боевых машинах, а не на тесте.

Что я бы сделал иначе

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