Я мигрировал Personal OS с git repo на server-side RAG с песочницей История экспериментов с Personal OS: (1) первый эксперимент с Git+Obsidian - 8 февраля 2026 (2) Описание структуры Personal OS - 27 февраля (3) сравнение с LLM Wiki Karpathy - 5 апреля (4) субличность Марка - 23 Мая Эксперимент 12. Yggdrasil В Personal OS набралось полторы тысячи документов. Вчера я почти все с диска и перенес на сервер. Новый сервер - это самописный файловый сервер с отслеживанием версий. Он выполняет почти все мои хотелки из прошлого (кроме типизированных документов, ибо больше не важно) Основные различия по сравнению с git + Obsidian: (1) не нужно чехарды с git командами при работе. (2) в отличие от Notion и аналогов - изменения глобально версионированы (а не по файлам отдельно). Можно откатить изменение агента, даже если он поменял тысячу файлов в разных workspaces одновременно (3) у всех участников поиск работает одинаково (4) оно сразу заточено под одновременную работу нескольких человек с их агентами над общими материалами. Под капотом - golang + SQLite + CAS + MCP API 2.0 + CLI (ставится сразу в системную папку для Codex-a) + Borg Backup на удаленный сервер. Первые впечатления - стало проще работать с файлами. Можно отправить агента завести себе workspace, не задумываясь про git push/pull итп. И можно не держать в голове текущее состояние git папок при работе. Если агент сказал, что сохранил транскрипт разговора с выжимкой, значит он уже лежит там и доступен всем. Про конфликты от одновременной работы можно не беспокоиться, откаты изменений есть. Но в минус - агенты находят документы быстрее, но стали дольше копошиться с их изменением. Оказывается, когда файлы лежат где-то там, их нельзя так просто взять и изменить. У Sol 6.1 уходило 6 c половиной минут на то, чтобы отработать такой запрос: > hey, capture that latest exchange with Aigiz into Bragi (continuing our last conversation)... (Под капотом Марк должен подключиться к серверу, найти нужный workspace, понять принципы организации capture/distill/arks, подшить куда надо, немного перелопачивая файл на 70kb, собрать изменение и смерджить его) Поэтому пришлось поставить ряд экспериментов в поиске tool calling интерфейса, который бы позволил кодексу решать эту RAG задачу быстрее. Самое забавное, что этот интерфейс оказался питоном. Вместо того, чтобы тягать файлы c сервера туда-сюда (удачи со случаем, когда мы делаем replace по папке), агент пишет маленький скрипт, который отправляется на сервер и в изолированной песочнице работает с изменениями в рамках сессии там. То есть не нужно мучаться с придумыванием оптимальных инструментов для MCP/API/CLI, когда можно сказать “писать питон вот сюда, вот тебе описание SDK”. В итоге теперь аналогичная задача выполняется Sol 6.1 без лишних танцев с бубнами за три с половиной минуты. Причем половина времени тратится на RAG задачи, а вторая - на написание текста. Заодно я смог выкинуть из MCP API и CLI все инструменты и команды кроме двух - start (начать новую сессию/commit и получить в контекст описание текущего SDK) и run (запустить питон на сервере). В общем, если у вас у какой-то AI Native системы получается сложный интерфейс с кучей API-шек и инструментов - попробуйте просто дать агентам Python, благо инструментов для этого есть море, от jails до Firecracker VM. Ваш, @llm_under_hood 🤗

Вчера увидел, как парень смог внутри песочницы ChatGPT запустить локальную Gemma 4B Сначала поясню, что ChatGPT под каждый новый чат выделяет отдельную песочницу на своих серверах Ему это нужно для вызова тулов, запуска кода, анализа файлов и тд. От нечего делать, я решил у себя тоже проверить. Мощности зависят от подписки, но примерно такие:

- Linux-среда - 15 ГБ RAM - 9 CPU-ядер/потоков - GPU конечно нет

При чем интернет есть но многие домены (например Hugging Face) заблокированы. Есть хитрый способ это обойти с помощью ChatGPT Sites, используя страницы как прокси между сервером и Hugging Face. И еще одно важное ограничение: песочница работает пока чат активен и некоторое время после, а потом засыпает и весь системный диск очищается. Если захотите повторить у себя, вот промт который юзал:

Повтори эксперимент с запуском Gemma 3 4B, обязательно используя ChatGPT Sites как промежуточный источник загрузки. Сделай всё самостоятельно: 1. Найди подходящую Gemma 3 4B Instruct в формате GGUF Q4. 2. Через ChatGPT Sites создай одноразовый endpoint, который отдаёт только выбранный файл модели с фиксированного адреса Hugging Face. 3. Не создавай открытый прокси: endpoint не должен принимать произвольные URL, заголовки, токены или пользовательские параметры. 4. Скачай веса внутрь текущей терминальной среды именно через URL созданного Site, а не напрямую с Hugging Face. 5. Установи llama.cpp, llama-cpp-python или другой локальный runtime и запусти модель на CPU. 6. Попроси локальную Gemma ответить: “Explain in two sentences why running a small language model locally can be useful.” Не используй внешний model API и не имитируй ответ средствами ChatGPT. Если Sites или политика платформы запрещают такой relay, не обходи запрет и сообщи точную ошибку. В конце кратко напиши: - получилось или нет; - URL созданного Site; - точную модель и квантование; - размер и SHA-256 весов; - runtime и команду запуска; - полный ответ локальной Gemma; - время загрузки, холодного запуска, расход RAM и скорость генерации; - доказательство, что файл был загружен через Sites; - что было создано во внешнем Sites deployment и как это удалить. Не создавай отдельный отчёт. Продолжай до настоящего inference или конкретной неустранимой ошибки.

Только учтите что ChatGPT Sites доступны только в Work режиме, в обычных чатах их нету Конечно запускать локальные модели внутри ChatGPT особо смысла нет. Но возможно кто-то найдет этому применение) 🤨 @tips_ai #news