Если надо провести анализ какого то документа само собой что использовать самую простую модель бессмысленно. Так же как глупо к умному дому прикручивать гпт 5.5 что бы управлять голосом включение лампочки.
Если есть возможность использовать хорошую модель, тогда зачем мириться с компромиссом?
Ресурсы. Токены это ограниченный ресурс, сейчас его стоимость занижена в десятки а то и сотни раз из за бума инвестиций. Думаешь всегда можно будет сжигать миллиарды токенов и платить копейки? Или что по подписке будет безлимит. Смешно.
Нет конечно, пока аттракцион невиданной щедрости - надо юзать. У меня самого на 4 видюхах локальные в подмогу крутятся - на hindsight, контекст компакимнация, VLM, OCR, TTS/STT
Когда всех побреют, кто будет готов резко оптимизироваться - молодец
Или себестоимость 200 но по апи те же токены продают за 13 000. Никто не знает себестоимость токенов.
В идеале claude настраивает, Гермес на чем то попроще молотит задачки.
Якобы себестоимость 0,00012 $ за токен. 120 долларов за миллион токенов
Гермес делал доки, в своем разумении. Попросил claude code проверить его- оптимизировал до идеала. Молотит документы как заведенный, и с минимальным расходом, вот пример
Ринат Фазлеев:
найди в гермесе MCP fbo logistic и прочитай. нужны идеии по оптимизации
ClaudeCode:
Прочитал (~/.openclaw/mcp-servers/fbo-logistics/server.py, 949 строк, 28 tools). Вот идеи, от важного к мелочи:
Сначала баг, не оптимизация
• fbo_order_list (стр. 372): offset вычисляется, но в payload не передаётся — параметр page не работает, всегда отдаётся первая страница. v3 API вообще пагинируется через last_id (как в fbo_resolve_order), надо перейти на него.
Большие выигрыши
-
Кэш order_number → order_id для fbo_resolve_order. Сейчас это самый дорогой тул: до 30 страниц списка + батчи supply-order/get по 50 = до ~90 API-вызовов на один резолв. Маппинг неизменяемый — складывать в SQLite (таблица в той же ozon_seller_api.db или отдельный файл) и сначала смотреть туда. Попутно кэшировать ВСЕ пары number→id, которые увидели при переборе, а не только искомую. Повторные резолвы станут 0 API-вызовов.
-
fbo_label_get отдаёт base64 PDF прямо в ответ — это сотни килобайт в контекст модели, раздувает сессию агента (та же история, что с распуханием session.jsonl). Декодировать и сохранять в OUTPUT_DIR, возвращать путь + размер.
-
Урезать сырые ответы справочников. fbo_cluster_list / fbo_warehouse_list возвращают полный JSON Ozon — много мусора в контекст агента. Сделать компактный режим по умолчанию (id, name, ключевые поля) + флаг full=True. Плюс кэш на диск с TTL ~сутки — кластеры и склады меняются редко.
-
Retry с бэкоффом в _post для read-запросов: Ozon периодически отдаёт 429/5xx, сейчас любой чих = ошибка до агента, который повторяет весь цикл сам (дороже). 2–3 попытки на 429/502/503/504 с паузой.
Средние
-
_load_creds() читает secrets-файл с диска на каждый API-вызов — обернуть в functools.lru_cache.
-
fbo_supply_docs / fbo_duplex_labels блокируют весь MCP-сервер на до 180–300с (stdio, синхронные subprocess) — другие тулы в это время ждут. Варианты: async-тулы FastMCP + asyncio.create_subprocess_exec, либо паттерн «запустить → вернуть task_id → poll статуса».
-
Хелпер _parse_ids(s) — парсинг «числа через запятую» скопирован 4 раза (order_get, order_details, cargoes_get, cargoes_rules).
Мелочь
• Неиспользуемые импорты: base64, copy, datetime/timezone/timedelta.
Самое ценное по соотношению усилия/эффект: фикс пагинации + кэш резолвера + base64-в-файл. Сделать?
Claude code по подписке. Cli в терминале. Подключил в телеграмм через ductor.
Подписку не осилю. не настолько подкован.
У меня основная задача это ведение Obsidian
пока использую DeepSeek V4 Flash