‘Я наконец-то решил проблему 5-часовых лимитов в OpenCode. Подключил его к локальному proxy, который использует общий пул ChatGPT Plus аккаунтов из Hermes. Теперь один аккаунт упирается в лимит и OpenCode сам переключается на следующий без браузера, ручного выбора аккаунта и перезапуска.’
Типа такого подхода на массе аккаунтов.
Комментарии (37)
а у китайских поставщиков каждый новый вызов с нуля с чистого листа
так вот получается каждый вызов китайской Астра = сброс кэша, а значит по новой заново читает чат, контекст и историю и заново настраивает веса
Astra использует скрытые механизмы оптимизации контекста (сжатие истории, фоновое суммаризирование агентов и сохранение промежуточных рассуждений Reasoning). Эти фоновые оптимизации привязаны к сессии аккаунта. Смена ключа заставит систему анализировать огромный массив текста заново, без учета уже сделанных моделью внутренних выводов
Если модель на шаге А (под Ключом №1) вызвала внешнюю функцию, вы не сможете передать результат этой функции на шаге Б под Ключом №2. Связующие идентификаторы (tool_call_id) жестко изолированы внутри конкретного аккаунта
Поэтому, когда мы дёргаем разные API мы теряем все, ради чего инженеры создали Астро со всеми ее возможностями, оставляя только LLM в сухом остатке и нам чтобы добиться от китайской реальной Астры надо просто повторить все то что уже сделали инженеры OpenAI. Но постараться конечно можно и нужно. Для этого нужны свои собственные алгоритмы управления контекстом
Если да, то это проблема масштабирования и приватности, так как вывод инструментов это пользовательские данные
То есть человек-программист всё-таки нужен.
Чтобы связывать разовые задачи для дешевых китайских бомж-моделей
В цепочки
Мы в чате русский ИТ уже делаем такой движок. В него взято лучшее, что удалось собрать из открытых источников: алгоритмы Cursor, алгоритмы Крюкова (основатель Рамблер), программы Архивариус 3000
Context Runtime — это Go-движок для управления контекстом в агентных системах. Он не про «скинул документы в векторную базу и забыл», а про то, чтобы каждая единица контекста имела происхождение, версию и обоснование. Умеет гибридный поиск (exact, FTS, dense, морфология, операторы запросов), собирать ContextPack — выверенный набор контекста для модели с учётом бюджета токенов, запускать агентов (в том числе фоновые задачи по расписанию), работать с типизированными тулами и трейсить каждый шаг. Всё завязано на проектную изоляцию, иммутабельные снапшоты индекса и заменяемые провайдеры (модели, эмбеддеры, ранжировщики). API v1 заморожен, ядро стабилизировано
хранить на севере что было отправлено небольшая техническая задача.
да все переписки сохраняются логируются и потом используются для обучения.
Compaction бывает двух видов, и оба контролируешь ты. Серверный включается параметром context_management с compact_threshold: когда счётчик токенов переходит порог, сервер запускает сжатие — и элемент компакции приходит тебе прямо в стриме ответа. Есть и отдельный эндпоинт /responses/compact, который полностью безсостоянийный и ZDR-совместимый: ты отправляешь целое окно контекста, получаешь новое сжатое, которое подставляешь в следующий вызов.
То есть сжатая выжимка — это объект в твоих руках, а не невидимое состояние на сервере. Более того, серверный compaction тоже ZDR-friendly, если ставить store=false
Для безсостоянийных запросов к reasoning-моделям нужно сохранять каждый элемент массива output: Responses API по умолчанию возвращает зашифрованные reasoning-элементы, и проигрывание полного output сохраняет их нетронутыми. Модели с persisted reasoning дополнительно умеют reasoning.context: "all_turns", чтобы подтянуть рассуждения прошлых ходов в следующий сэмпл.
Рассуждения едут в твоём массиве input как зашифрованные блобы. Ключ ты меняешь — блобы остаются.
И контрольный по деньгам: даже при использовании previous_response_id все входные токены предыдущих ответов в цепочке тарифицируются как входные. Так что «серверное состояние избавит вас от повторной обработки массива текста» — неправда даже в исходной формулировке: платишь ты в обоих случаях
Responses API спроектирован так, что серверное состояние (store: true) является лишь опцией для ленивых. Весь низкоуровневый функционал (зашифрованный reasoning, machine compaction, tool-state) выражен в виде переносимых объектов данных (opaque data items). Вы можете свободно жонглировать этими объектами, перекидывая их из аккаунта в аккаунт на каждый отдельный запрос
Но это не так, ты управляешь всем этим у себя, а ротация ключей это обычное дело.
Если передавать параметр store: true или использовать previous_response_id, сервер OpenAI делает всю грязную работу сам: ищет старые логи, склеивает историю и подтягивает рассуждения
Чтобы получить этот доступ - OpenAI перечисляет три равноправных способа: через previous_response_id, привязку ответа к conversation, либо ручное воспроизведение полной истории ответов
Механика выигрыша при tool-вызовах в рекомендациях OpenAI описана так: передача reasoning-элементов обратно означает, что модели не приходится перезапускать рассуждение, когда вы отвечаете на вызов функции, - отсюда лучшее function-calling и меньший расход токенов. Но там же сказано, что добиться этого можно либо через previous_response_id, либо взяв все output-элементы старого запроса и передав их как input-элементы нового
На токенах это не экономит
Самое приземлённое: даже при использовании previous_response_id все входные токены предыдущих ответов в цепочке тарифицируются как входные.
Так что «сервер делает грязную работу» = экономит тебе код и трафик, а не деньги за токены. Дешевле выходит за счёт попаданий в кэш, а не за счёт того, что история не пересчитывается
все остальное кэш и он рассчитывается отдельно
в общем, ты рассуждаешь со стороны бэкенда и инженера и это отдельная, большая интересная работа для команды 1APP
когда Макс тебе будет Астро раздавать по 0.03 копейки за миллион токенов
1) обеспечить ли 100% совместимое API OpenAI
2) китайские провайдеры обеспечат ли 100% API OenAI
https://t.me/Russian_IT_Business/494953
и именно в этом контексте я и сравнил: личный аккаeнт с кэшем против китайского без кэша
А чтобы китайскому прикрутить кэш - да. нужна 100% совместимость шлюза с OpenAI. Так что ты не зря старался и подсветил ключевую проблему всех шлюзов
1. OpenRouter - Уровень несовместимости: Критический (для продвинутых фич Astra)
2. VseLLM - Уровень несовместимости: Высокий (Работает в режиме совместимости)
3. AITUNNEL - Уровень несовместимости: Средний (Ближе всех к адаптации)
4. RAGArena - Уровень несовместимости: Полная изоляция концепта
5. 1APP 100% будем в это верить и надеяться
Суть-то вопроса- теряется ли что-то при процессинге на сервере при переходе от одного аккаунта к другому
а если по инженерному это как получить современный кроссовер без бортового компьютера. поедет? некоторые поедут
для кодинга идеально использовать Астро китайскую для плана, разбора и т д то, что она решит за раз
Но там экономика хуже сходится. Стоит это гораздо дороже