# Hermes token audit and model-routed workers

## Grounded token audit

Use the live Hermes session store rather than estimating from chat length:

- Database: `~/.hermes/state.db`
- `sessions` contains `source`, `model`, `api_call_count`, `tool_call_count`, `input_tokens`, `output_tokens`, `cache_read_tokens`, `cache_write_tokens`, `reasoning_tokens`, `estimated_cost_usd`, `system_prompt`, and timestamps.
- `messages` contains role/tool names and content; aggregate `length(content)` by `tool_name` to identify oversized tool outputs.
- First run `hermes insights --days 30`, then query SQLite with Python's stdlib `sqlite3` when the `sqlite3` CLI is unavailable.

Break down at least:

1. Last 7/30 days by `source` and model.
2. Cache-read vs non-cache tokens.
3. Top sessions by total and non-cache tokens.
4. API/tool calls per session.
5. Topic/project estimates from session titles.
6. Tool output characters by tool name.
7. Skill load counts and output size.
8. Agent cron vs `no_agent=True` script-only cron.

Key interpretation: very long interactive sessions with hundreds of model/tool rounds can dominate token use because the growing context and tool schemas are repeatedly read. Cronjobs may be frequent yet cheap when script-only. Do not optimize cron first without measuring its actual share.

## High-value optimizations

- Add an operational checkpoint rule: after about 100 toolcalls, a long debug/build loop, or a clear milestone, summarize state and prefer compression/new session.
- Batch 3+ similar reads/log/status checks with parallel calls or a deterministic script.
- Search first, then read small targeted line ranges.
- Keep `session_search` for genuine history needs.
- Bound tool output (`tool_output.max_bytes`, `max_lines`, `max_line_length`).
- Compress earlier and protect fewer recent messages, while verifying quality after the change.
- Make routine cronjobs `no_agent=True`; for remaining agent jobs, restrict `enabled_toolsets`, prompt size, and output length.
- Remove attached large skills from cronjobs when the job prompt plus live data is sufficient.

## Multi-model worker lanes

Native `delegate_task` workers inherit the parent model and cannot select a model per call. For task-specific models, create isolated Hermes profiles and invoke them through bounded wrappers.

Recommended governance:

- `default` / strongest model: main JARVIS, orchestration, final decisions, verification, commit/push/deploy/live approval.
- `code-review` / fast coding model: read-only diff review, test-log analysis, PR drafts.
- `code-worker` / fast coding model: small, explicit local edits only.

Profile pattern:

```bash
hermes profile create code-review --clone --description "Read-only code-review worker"
hermes --profile code-review config set model.provider openai-codex
hermes --profile code-review config set model.default <fast-coding-model>
hermes --profile code-review config set memory.memory_enabled false
hermes --profile code-review config set memory.user_profile_enabled false
```

Profile-creation pitfall: `hermes profile create --no-skills` is mutually exclusive with `--clone`, `--clone-from`, and `--clone-all`. If the worker needs the active profile's provider/auth/config, clone first and rely on lazy skill loading or later profile-scoped skill cleanup. If a truly empty skill library matters more, create the profile with `--no-skills` and configure provider/auth separately. Never delete another profile's copied skills without explicit user approval.

Use a profile-specific `SOUL.md` with hard limits. Worker wrappers should:

- accept repo path + bounded task;
- cap diff/log text before injecting it;
- enable only required toolsets;
- prohibit commits, pushes, deploys, releases, production DB changes, secrets, and live actions;
- require a compact report with changed files, checks, risks, and a recommendation to the main agent;
- leave final verification and all risky decisions to the strongest main model.

Useful wrapper classes:

- code review from bounded `git status`, `git diff --stat`, and a capped diff;
- test/build log analysis from the last bounded chunk of a logfile;
- PR/changelog drafting from status, name-status, stat, and capped diff;
- small code worker for narrow test, lint/type, docs, UI-copy, or simple bugfix tasks.

Always verify that the configured provider accepts the exact model ID on the first real worker run.