HERMES AGENT — COST & MEMORY PROFILE (sanitized — no keys, no IPs, no accounts, no personal identifiers) Generated from real local usage DB + config. All token figures are actual, not estimates, unless marked "(est.)". ==================================================================== 1. SETUP ==================================================================== - Agent framework : Hermes Agent (open-source agent harness; gateway + CLI, persistent memory files + skill library + cron jobs) - Main model : DeepSeek-V4.1 Flash ("deepseek-flash"), native multimodal - Provider : DeepSeek official API, direct (not a reseller), automatic prefix prompt caching - Price (CNY per 1M tokens, official, since 2026-09-10): cache hit 0.02 | cache miss 1.00 | output 4.00 off-peak = half price (weekdays 18:00-09:00 local + all weekend) - Auxiliary model : same cheap family, for: context compression, background review, approval classification, title generation - No other paid services attached to this agent. ==================================================================== 2. MEMORY FILES (injected into every request) ==================================================================== - MEMORY.md : 230,285 bytes / 567 lines (~117,600 chars) hard cap = 131,072 chars -> 89.7% full - USER.md : 32,416 bytes / 106 lines (~13,000 chars), same cap - Structure : roughly 150 entries separated by a delimiter; entry length ranges from ~100 to ~2,500 chars; a few entries are long tables/lists. - Retrieval : whole file is always injected (no selective retrieval, no vector search, no summarization of the file itself). Samples (3 excerpts, heavily rewritten/paraphrased so no real detail survives): (a) "User is a student in [city], prefers concise answers, dislikes emoji-heavy and over-formatted replies; uses a domestic chat platform." (b) "Home machine runs an agent harness; updating it killed the host process once, so updates must be done from an external terminal." (c) "A fine-tuning experiment: 800 conversational windows from exported chat logs; two SFT runs produced no visible style transfer; root cause turned out to be an adapter-loading bug, not the data." ==================================================================== 3. SKILL LIBRARY (only name+description injected per request) ==================================================================== - 145 skill files, ~32 MB on disk. - Per request, only each skill's name + first-line description (~40 tokens each) is injected; the body is loaded on demand when a skill is used. - Estimated fixed overhead of the skill index: ~5-8K tokens per request (est.) ==================================================================== 4. FIXED PER-REQUEST OVERHEAD (est.) ==================================================================== memory files (MEMORY.md + USER.md) ~ 60-80K tokens skill index (145 entries) ~ 5-8K tokens tool schemas (~20 core tools) ~ 5-8K tokens ------------------------------------------------ fixed prefix, every single request ~ 70-95K tokens (this prefix is stable, so it is normally a cache hit at 0.02/1M) ==================================================================== 5. REAL TOKEN USAGE ==================================================================== Lifetime (local DB, all sessions): 13,700 API calls | input 114.3M | output 15.1M | cache-read 3.27B | reasoning 10.1M Last 30 days, by call type: type calls input(uncached) cache-read output hit% note main chat 10,581 71.6M 2,780M 10.4M 97.5% user conversation background_review 1,045 28.0M 303.8M 2.6M 91.6% periodic self-review approval 583 0.31M 0.09M 0.14M 22.2% command-approval checks compression 19 1.40M 0.008M 0.32M 0.6% context summarization vision 49 0.03M 0 0.19M 0% image calls title_generation 19 0.003M 0.003M 0.006M 50.5% session titles Representative single main-chat call: prompt ~280K tokens (of which ~97% cached), output ~1K tokens. Measured monthly spend: CNY 120-240 (off-peak vs peak mix). Computed structure (off-peak prices): uncached input 71.6M * 1.00 = ~72 cache read 2,780M * 0.02 = ~56 output 10.4M * 4.00 = ~42 ------ ~170 CNY / 30 days at off-peak (peak-hours volume roughly doubles the first and third rows) ==================================================================== 6. RELEVANT CONFIG VALUES ==================================================================== memory.char_limit 131072 (both MEMORY.md and USER.md) memory.nudge_interval 10 compression.enabled true compression.threshold 0.55 (of context window) compression.target_ratio 0.15 compression.protect_last_n 5 (turns never compressed) compression.protect_first_n 3 compression.proactive_prune_tokens 120000 (tool results pruned above this) - min tool-result size to prune : 8000 chars - min reclaim to bother : 20000 tokens tools.tool_search.enabled auto (loads tool schemas on demand) skills.inline_shell false skills.write_approval false ==================================================================== 7. USAGE PATTERN ==================================================================== - One long-lived session is typical; the current one has 831 API calls with an average prompt of ~309K tokens per call. - Heavy tool use (shell, file read/write, web fetch). Tool outputs are the main source of *uncached* input. - Always-on background activity: periodic background review, approval classification on command execution, title generation, and (rare) context compression. - Sessions are archived by a cron job every 14 days; memory files are edited manually/periodically, and every edit invalidates the cached prefix once. ==================================================================== 8. QUESTIONS FOR THE ADVISOR ==================================================================== 1. Given a stable ~70-95K token fixed prefix that is 97% cached, where is the best remaining saving: shrinking the prefix, shrinking uncached input, or changing the call pattern? 2. Is ~150 entries / 117K chars of always-injected memory the right design, or would tiering (always-injected core + retrieved long tail) pay off — given the prefix is already cached at 0.02/1M? 3. Uncached input is the largest single cost bucket (~72 of ~170 CNY). What are the standard techniques for an agent to reduce uncached input besides summarizing tool output? 4. background_review is 1,045 calls and 28M uncached input (~28 CNY/30d) — is that a reasonable price for its value, or should its frequency be cut? 5. Any config-level changes you would make to the compression settings above?