У меня MacBook Pro 16 2019 года: шестиядерный Intel Core i7, 16 ГБ оперативной памяти и Radeon Pro 5300M с 4 ГБ VRAM. На нём уже стояли Ollama, gemma3:4b и gemma2:2b.

Идея казалась очевидной: зачем тратить облачный Codex на разбор короткого traceback, сводку лога или commit message? Пусть Codex отдаёт такую работу локальной модели, получает готовый результат и занимается только сложными задачами.

Я сделал MCP-сервер, подключил его к Codex, прогнал одинаковые задачи и посмотрел точный расход токенов. Интеграция заработала. Экономия — нет.

На одной простой задаче маршрут через локальную модель использовал примерно в два раза больше облачного input, чем прямой ответ Codex.

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

Переименование проекта в Docker Compose может создать новые пустые volumes, пока старые данные спокойно остаются на диске. Разбираю, какие внутренние идентификаторы нельзя менять через Replace All и как провести ребрендинг с возможностью отката.

Начну со спорного решения: я храню в базе готовый HTML с Tailwind-классами.

Не Markdown, не JSON-схему блоков, а буквально это:

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

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

Файл сохранялся. Строка появлялась в базе. Повторный GET тоже находил изображение. Но ответ самого запроса загрузки выглядел так:

У Telegram-бота может быть только один активный webhook. У меня при этом появились три независимых сценария: поддержка пользователей, управление небольшим магазином и внутренние административные команды. Склеивать их в один процесс не хотелось, заводить отдельного бота под каждый сервис — тоже.

Пока я выбирал архитектуру, переезд панели с одного домена на другой неожиданно провёл бесплатный chaos test: Telegram продолжил отправлять updates на старый адрес, получил 301 Moved Permanently и перестал доставлять сообщения. В очереди зависло шесть updates, а со стороны пользователей бот просто замолчал.

В статье разберу диагностику этого инцидента и устройство небольшого open-source router на FastAPI и Redis: с декларативными правилами, дедупликацией, надёжной очередью, retry и HMAC-подписью внутренних запросов.