Source: raw/reddit-1vhmb7f.md — r/hermesagent megathread by u/Jonathan_Rivera, 2026-08-07, ~20,700 words, synthesizing seven days of r/codex, r/OpenAI and r/OpenAICodex threads (week of Jul 31 – Aug 6, 2026) with a Hermes Agent translation layer. Every claim below traces to a linked source thread in the original.

A curated weekly digest of the OpenAI Codex community’s model-routing discourse, translated into Hermes equivalents. It is worth reading outside both ecosystems because the pattern it documents — a strong model plans and supervises, a cheap model implements — is vendor-neutral, and because it carries a controlled cost/quality trial whose headline result is counter-intuitive: on bounded implementation work, reasoning effort mattered more than model tier, by roughly 18× in cost.

The author’s own framing is the right caveat: “Treat specifics as a snapshot, not gospel… Given how this week went, half of this may be obsolete by next Thursday.”

The finding worth taking away

A controlled trial ran the same 3,378-word plan, 11 stories, 3 trials per configuration:

Model + effortDefect-free trialsAvg cost
Luna Medium0/3$0.14
Luna High1/3$0.47
Luna XHigh3/3$0.59
Luna Max3/3$0.82
Terra Medium0/3$1.06
Sol Medium0/3$11.01

The cheap model at high effort beat the expensive model at low effort, on both axes at once. Luna XHigh went 3/3 at 11.01 — about 18× the cost for strictly worse results on this task shape. Luna XHigh is also the knee: Max bought no additional reliability for a 39% cost increase.

This inverts the common instinct to buy capability by moving up a tier. For bounded implementation work with clear acceptance criteria, the cheaper purchase is effort on a small model. The scope condition matters — this was implementation against an already-written plan, not open-ended discovery, and it is a single trial at n=3 per cell.

The wiki’s independent corroboration: checker run reached the same conclusion in a different ecosystem — Fable 5 as foreman over four cheaper worker families, 85–105 all-Fable estimate. Two independent reports, two model families, same direction.

The canonical four-step pattern

  1. Plan with the top-tier model at the highest reasoning effort. Plan quality is the leverage point; everything downstream inherits its errors.
  2. Compact the context so the orchestrator does not carry planning residue into supervision. (Codex /compact; Hermes /compress, tuning compression.threshold / target_ratio.)
  3. Orchestrate with the strong model one notch down. Supervision is reading and judging, not discovering.
  4. Implement with the cheap model at xhigh, each task packaged as a small self-contained work package with explicit scope, context, and expected output.

Reported effect on usage: one report of Sol xhigh orchestrating Luna subagents on a from-scratch Next.js build at 2h 5m runtime for ~9% of a weekly limit; another of daily usage dropping from 60–70% to 20–25% after switching to a strong orchestrator with cheap high-effort workers.

Four subagent rules that cost people money to learn

  • Never fork parent context into children. Fresh context on every spawn. (Codex fork_turns="none"; Hermes isolates delegate_task conversations by default.)
  • Because the child starts blank, its first message must be the complete bounded task — all requirements, paths, symbols, evidence expectations, and output format. The child knows nothing about your conversation.
  • Pin worker roles to the cheap model. Never let a role inherit the parent’s expensive model. This is the single most expensive misconfiguration in the set.
  • Put delegation policy in AGENTS.md / skills so spawning is explicit rather than incidental.

The counter-case, which the source keeps

A 170-point dissent argues the orchestrator/subagent pattern over-engineers: “I cannot be bothered looking through mountains of slop from multiple subagents.” The recommendation is a single mid-tier agent whose usage moves in 1% increments over hours. Cited alongside two failure reports — an 11,000-line diff produced for a small backend change, and agents ignoring AGENTS.md rules while over-engineering.

The synthesis line is the useful one:

Orchestration wins on token economics; it loses on review burden unless you gate scope hard. If you can’t keep up with what the swarm is doing, you’ve inverted the bottleneck.

That is the same bottleneck-migration argument the wiki records in PR review risk-scoring: once generation is cheap, review becomes the constraint, and a routing change that multiplies output without addressing review has moved the problem rather than solved it.

Reasoning-effort defaults the community converged on

RoleEffortWhy
Planningxhigh / maxPlan quality is the leverage point
Orchestration / reviewhighSupervision is judging, not discovering
Implementationxhigh (max if budget allows)The defect-free knee in the trial above
Cheap discovery / testsmediumTriage, search, test-writing

Keep the orchestrator one notch below the planner, and pin implementation workers at the cheapest effort that still passes your acceptance criteria — which is a testable question, not a preference.

Prompt caching is real money

One Sol Max session recorded 11.52M cached input tokens against 416K uncached — roughly 5% of a Plus weekly allowance for 20 minutes of work. The operational rule: keep stable prefixes; do not churn your system prompt or toolset mid-session.

Worth connecting to a platform change from the same week: the mid-conversation tool changes beta exists specifically so tools can be swapped without invalidating the prompt cache — the vendor-side fix for the constraint this community learned empirically. Hermes applies config/tool changes on new session for the same reason.

Fast mode: buy speed on the cheap model, not the expensive one

  • Cost: roughly 2× usage burn for faster inference.
  • Where it works: cheap models. Luna Max + fast on a $20 plan reportedly ran 12h/day for 3 days at ~45% of the weekly limit — doubling a trivial burn is still trivial.
  • Where it disappoints: top-tier models. The promised ~750 tok/s tier has not materialized even for Pro 20× users; reports describe fast mode on the expensive model as still slow.
  • Most-requested missing feature: a “slow mode” at 0.5× burn for overnight/background runs. The source notes Hermes already has the equivalent in spirit — cron jobs and background processes on a cheap or local model, where marginal token cost is near zero.

Other tips with real content

  • Clarify before planning. Agents fill unclear details with plausible assumptions; a gate that surfaces consequential uncertainties before producing a plan removes a whole error class at its cheapest point.
  • Lean root AGENTS.md = routing rules only, with per-agent files, standards, and workflows split out. This is the same router-with-sub-routers shape documented in The New Rules of Context Engineering and the CLAUDE.md primer — now arrived at independently in a second ecosystem.
  • Do not paste a frontier model’s system prompt into a cheap model — the claim is that only ~4% of that content is portable. Write worker instructions natively for the worker: bounded execution contracts, explicit non-goals, minimal patches, deterministic validation.
  • The trust bottleneck has moved: “We’re not reviewing AI-generated code anymore — we’re reviewing AI’s reasoning.” Review the plan, check which parts of the repo it explored, interrogate architectural assumptions, optionally have a second model critique the plan — then let it write code.
  • Escape hatch: DeepSeek V4 Flash at max reasoning inside an agent harness at roughly **100–200. Corroborated the same week by a separate r/hermesagent report and by a Nous Research promotion — see Hermes Models, Providers & Plans.

Plans and limits (Codex-side, snapshot)

  • Plus ($20): Luna Max measured at ~1.5B tokens/week by one report. Common trick: use webchat for planning questions and reserve agent-side quota for implementation.
  • Pro ($200 / 20×): runs Luna Max as a daily driver with higher tiers reserved for debugging and heavy planning.
  • Referral rewards changed 2026-08-03: banked resets replaced by credits (250–500 credits ≈ $20–27 API-equivalent). Turn off auto-recharge or you will be billed when credits empty.
  • The dominant complaint is unpredictability, not limit size — forced resets overwrite allowance users would rather bank.

Key Takeaways

  • On bounded implementation, buy effort before you buy tier. Cheap-model-at-xhigh beat expensive-model-at-medium 3/3 vs 0/3 while costing ~18× less.
  • Find the knee, not the ceiling. Max effort bought no reliability over xhigh for 39% more cost.
  • The expensive misconfiguration is a worker inheriting the parent’s model. Pin it explicitly.
  • Fresh worker context is mandatory, which makes the task brief load-bearing — the child gets exactly one shot to be told everything.
  • Pay for speed on cheap models only. 2× burn on trivial is trivial; 2× on expensive is expensive, and the top-tier speedup reportedly under-delivers anyway.
  • Orchestration moves the bottleneck to review. If you cannot review the swarm’s output, a single mid-tier agent is a legitimate and defensible default.
  • Stable prompt prefixes are a cost lever, not hygiene — one session showed a 27:1 cached-to-uncached ratio.
  • This is a community snapshot, not a benchmark. Single trials, self-reported usage percentages, one week of threads, and an author who says half of it may be stale within days.

Try It

  1. Run the cheap-model-at-high-effort test on one real bounded task before restructuring anything. Take a plan you already trust, implement it three times at the cheap model’s high and xhigh settings, and count defects. The claim is falsifiable in an afternoon on your own task shape.
  2. Audit whether your workers inherit the parent model. In Hermes, set delegation.provider / delegation.model / delegation.reasoning_effort in config.yaml. In Claude Code, check subagent model configuration — note that v2.1.223 added a warning when a requested subagent model is restricted and the parent runs instead, which previously failed silently.
  3. Compact between planning and orchestration. Cheap, and it stops the expensive supervisor carrying planning residue for the rest of the run.
  4. Check your cached-vs-uncached ratio for one session before optimizing anything else about cost.
  5. Before scaling out workers, ask who reviews the output. If the answer is “nobody has time,” fix that first — see PR review risk-scoring.

Open Questions

  • The controlled trial is n=3 per cell on a single task, self-reported, with no repo published. The direction is corroborated by an independent run; the specific numbers are not verified.
  • Does the effort-over-tier result hold for open-ended work? Every framing here scopes it to bounded implementation against a written plan. Discovery, debugging, and architecture may invert it — the source does not test them.
  • Where is the “~4% of a frontier prompt is portable” figure from? Asserted in the Luna Forge thread with no stated methodology.
  • The usage percentages (9% of weekly, 60–70% → 20–25%) are individual self-reports with unstated task mixes, and are not comparable across plans.
  • Does the pattern transfer cleanly to Claude models? The Sol/Luna/Terra tiering has no exact Claude analogue, and Claude Code’s effort ladder (low/medium/high/xhigh/max) may not map onto the same cost curve. Untested here.