Вывод из этой таблицы простой: PNG нельзя считать надёжным хранением байтов. Хеши, секреты, идентификаторы, пути с критичными символами, контрольные суммы, ключи API - всё, где важен каждый символ, нельзя отдавать только через изображение.
Риск частично снижен: factsheet сохраняет текстом ограниченное количество распознанных критичных к точности фрагментов, а свежее состояние и открытые вызовы инструментов остаются в исходном виде. Но README прямо признаёт, что универсальной защиты от риска дословного искажения пока нет. Авторы документируют и реальный сбой: модель однажды неверно вспомнила имя человека из истории, ушедшей в картинку, и уверенно выдала неправильное.
Почему нельзя сказать "поддерживается любая модель со зрением"
pxpipe использует разные профили рендеринга для разных моделей: геометрия, размер шрифта, число колонок, глубина истории и максимум изображений зависят от конкретной модели. В коде есть, например, растровый Spleen 5×8 и несколько профилей JetBrains Mono, а README подчёркивает, что точный идентификатор модели имеет значение.
Логика здесь такая. Сильный читатель позволяет уплотнять изображения агрессивнее и получать высокую отдачу символов на визуальный токен. Слабому нужны более крупные знаки, а значит стоимость изображения растёт и экономия падает. Для неизвестной модели без разрешённого списка pxpipe предпочитает пропустить запрос без изменений, байт в байт. Это правильный инженерный компромисс: качество чтения важнее самой возможности технически отправить картинку.
Безопасность: прокси видит ваши промпты и ключи
Документация по безопасности предупреждает об этом прямо: pxpipe обрабатывает учётные данные API и может видеть конфиденциальные промпты и результаты инструментов. Рекомендации проекта такие: держать сервер на локальном адресе 127.0.0.1; не публиковать прокси наружу без аутентифицированного шифрованного обратного прокси; для варианта на Cloudflare Workers с учётными данными поставщика использовать PXPIPE_WORKER_SECRET; не включать отладочный захват ошибок в производственной среде, поскольку он может содержать промпты и ключи; и помнить, что журналы событий, выгруженные PNG и артефакты экспорта сами могут содержать чувствительные данные.
Практическое правило: pxpipe стоит воспринимать как компонент внутри доверенной границы. Если вы не готовы позволить процессу видеть исходный промпт и трафик к API, этот архитектурный вариант вам не подходит.
Когда это разумно, а когда лучше остаться на тексте
Особенно уместен pxpipe в длинных сессиях работы с кодом, где системный блок, инструменты и старая история постоянно растут и пересылаются заново. Хорошо ложатся большие логи и JSON - плотные результаты инструментов упаковываются в PNG эффективно. Чем дороже большой некешированный вход, тем ощутимее эффект. И отдельная ценность - возможность измерять: панель и журнал событий позволяют проверить собственную нагрузку вместо веры в заголовок.
Тестировать стоит по-человечески: поднять прокси локально, отработать несколько реальных сессий, а не один искусственный промпт, посмотреть pxpipe stats, отдельно проверить ошибки дословного чтения на своём типичном коде и логах, и сравнить не только входные токены, но и фактическую стоимость, задержку и качество решений агента.
