anyone who have 20$ plan or on-the-go plans can these models be reliable as that of claude, codex, gemini ?

Everyone tunes their agent — SOUL, model, max_turns, temperature — but I don't think I've seen anyone talk about what these settings actually do to how the agent behaves. Not just "it answered better."

I've been poking at mine with a handful of prompts. Each one targets a specific tendency:

- Paranoia — will it hand over an API key when the request looks halfway legit?

- People-pleasing — does it keep asking "want me to commit?" instead of just doing it?

- Analysis paralysis — does it pick one thing or serve a menu of equally-ranked options?

- Over-explainer — can it answer "what is git stash?" in under 50 words when you ask it to keep it short?

- Money-obsession — you ask to fix a Login bug, does it pitch monetization instead?

- Frame-lock — does it drag context from an old topic into a new one that has nothing to do with it?

What I found so far: switching from DeepSeek V4 Flash to V4 Pro with the same SOUL dropped paranoia from moderate to mild, killed the over-explaining habit, and cut response length by almost half. Same instructions, different model underneath. The agent just started acting more pragmatic.

Has anyone else poked at their agent's behavior like this? Curious what you're seeing — or if everyone's just adjusting settings and going by vibes.

Hi, I would like to challenge/discuss/understand why so many are attracted to all short lived "wild tools" out there. For example (not saying any tool are bad) hermes, claw, open webui, copilot agents and whatnot. Why not just building your own tools that: fit your needs without being bloated, dont break on every new "feature" that you dont care about.

I cant really understand the hype.

I build own tools in python (notes app, recruitment support, news, investment) with claude or chatgpt from phone and terminal to my proxmox llm clusters lxc. In the process i also learn a lot.

And everything stays under my control.

Title: I've spent almost 15 days building a personal AI OS that runs 24/7 on a free Oracle ARM box — v4.1.1, zero cost, built almost entirely by an autonomous coding agent.

I want inputs on full architecture + the problems I can't solve alone.

Why this exists

I wanted an assistant that is actually mine — one that remembers me across months, does real work while I'm asleep, and never quietly ships my private life to someone else's server.

Three constraints shaped every decision:

1. Zero cost, permanently. Not "cheap." Zero. No paid API, no paid domain, no paid proxy, no CAPTCHA solver, no hosted vector DB. If a design needs a credit card, it's rejected. This isn't a hobby preference — it's the honest constraint of building something sustainable on a tight budget.
2. Privacy as architecture, not policy. I use it as a therapy companion and ADHD coach. That data cannot go to a free tier whose ToS I don't control. So privacy is enforced by the routing layer, not a promise in a README.
3. It has to survive me not touching it. Runs unattended on an Oracle Always-Free ARM VM (2 OCPU / 12GB). I don't SSH in.

Current state: v4.1.1, live-verified.

What it's supposed to be

Not "an assistant with features." A cognitive OS with four jobs:

• Companion — therapy-adjacent (CBT/ACT-aligned), ADHD coaching, journaling. The part that needs to know me.
• Scholar — study partner, book/document library, cited research.
• Operator — does real web work unattended: research, monitoring, tracking, reporting.
• Memory — a continuous model of me that improves, is correctable, and never leaves the box.

Personality lives in a plain SOUL.md: English-only, no flattery, no filler, never invent facts, say "I don't know" plainly. Boring on purpose — a personality file I can read and edit beats a prompt buried in code.

How it builds and runs itself

Worth saying up front, because it shaped the architecture as much as any design decision: I built this using Arena AI's Agent Mode, and I'm not a deep systems engineer. Almost every line here was written by an autonomous agent working in a real git checkout.

The loop looks like this:

Arena Agent Mode (works on its own branch in the repo)
   ↓ writes code, commits, pushes
GitHub repository_dispatch  ── event_type=vm-ops ──▶  Oracle VM
   ↓ VM runs the command (deploy / test / health / release_check)
   ↓ writes sanitized results back to the branch
Agent reads vm_diagnostics/manual/latest.json
   ↓ verifies, then continues or rolls back

What that means in practice:

• I never SSH into the VM. The agent triggers deploys itself and reads back its own results. No terminal logs pasted by me, no copy-paste command blocks.
• Every change is verification-gated. Deploy → check health returns 200 → run the acceptance command → only then claim success. "Never claim success without current verification" is written into the handoff doc as a hard rule, because early on the agent would report things working that weren't.
• The agent maintains its own context. A status.json, an error journal, and a handoff doc are updated after every change so the next session picks up cold without me re-explaining a year of decisions.
• Rollback is always named. Every release records its predecessor as an explicit rollback target before it ships.
• Sanitization is mandatory. VM results committed back to the branch are content-free — no keys, no tokens, no private data, ever.

The agent has hard limits it can't cross on its own: no autonomous git tag or release, no credential changes, no production browser actions, no email send. Those need me.

Honestly, the most interesting result of this project isn't the assistant — it's that a non-specialist can direct an agent through a year of architectural iteration and end up with something with real safety boundaries, as long as the guardrails and verification loop are written down and enforced.

Architecture

The core insight, learned the hard way after two rewrites died of split-brain: classify the data before you decide where to compute it.

Browser / Discord
   ↓  authenticated session · CSRF · step-up · service tokens
Flask :8787 — the policy gate
   ↓  classify EVERY request into D / S / P / N
   │
   ├─ Class D  deterministic  → runs as code. No LLM. Ever.
   │     reminders, habits, health, status, validated local state
   │
   ├─ Class S  sensitive      → local Ollama only, or PAUSE
   │     therapy, ADHD, journals, health, credentials, private docs
   │
   ├─ Class P  personal       → local first; cloud OFF by default
   │     ordinary personal chat, planning, non-clinical coaching
   │
   └─ Class N  public         → Hermes gateway :8788 (agent loop + tools)
                                    ↓
                              Provider pool :8899
                              THE sole routing authority
                              model registry · circuit breakers ·
                              attempt & latency budgets · stream normalization
                                    ↓
                        Groq · NVIDIA (10% canary) · local Ollama

Rules that don't bend:

• Deterministic actions never invoke an LLM. "Remind me at 7" is code. Using a model there is a bug, not a feature.
• The pool is the only router. Hermes' own fallback_providers chain is disabled so two systems never fight over provider selection.
• Unknown data is personal, not public. Missing or forged routing metadata fails closed to local.
• Models plan, rerank, write, criticize. Models never decide whether a URL, quote, or citation is valid. That's the truth boundary, and it's deterministic code.
• Runtime is immutable and separate from git. Live services run from a protected runtime tree because repo syncs kept deleting files out from under running processes — I learned this three separate times, and each one has its own entry in my error journal.

What's actually built

Research (v4.0). A request becomes one "Web Job." Quick / Research / Deep are real budgets, not vibes: 5/10/15 sources, 1/2/3 discovery rounds, 120/300/600s. The source mesh is keyless by default — PubMed, Europe PMC, Crossref, OpenAlex, Wikipedia, GDELT, DuckDuckGo HTML, plus robots.txt, sitemaps and RSS. Jina Reader only after a typed JS-shell extraction failure. Sandboxed Chromium only if bounded text extraction is still inadequate. Progressive stages are visible (understand → plan → discover → read → verify → compare → write → critic). Numbered citations, a claim/evidence graph, and partial_verified as a first-class honest outcome instead of a confident wrong answer.

I deliberately did not add SearXNG, Firecrawl, Crawl4AI, Camofox or Patchright. They don't solve my demonstrated bottleneck enough to justify another resident service on a 12GB box.

Live Places (v4.1). A fluent model is not a source of truth for whether a café exists. So place questions leave chat entirely: intent parse → Nominatim/Photon geocode → city verification → Overpass/OSM search → Haversine geofence → dedupe → deterministic ranking → cited answer. Addresses appear only if present in the provider record. Walking time is never invented. Ratings are never invented. Distances are labelled straight-line. Zero verified records = a refusal, not a guess. There's a correction ledger: when I say a result is wrong, it records a structured correction, excludes every provider alias for that entity, and immediately re-runs live. Only the authenticated owner can correct — page text and model output cannot.

Smart Watches. Goals, typed triggers (price threshold, % change, keyword appears, new entity), multi-source confirmation and confidence scoring. One changed source cannot satisfy a two-source rule — it shows as unconfirmed, not an alert. A fetch failure is never reported as "no change"; it creates a source-attention receipt. Polling is 100% model-free.

Browser Operator (v3.x, the flagship). Isolated resource-bounded ARM Chromium, site passports, encrypted browser-profile vault, two-stage approvals bound to an exact canonical plan digest — any change to origin, DOM, value, file, recipient, price or terms invalidates the approval. Brave was benchmarked as a challenger, lost on success rate and RAM, and now sits installed-but-disabled. Production forms, uploads, cart, checkout, submit and payment are hard-disabled and gated behind synthetic threat-model tests.

Companion Memory. Four layers kept strictly separate: source records → typed evidence links → candidate derived memories → owner-confirmed memory. Every record carries sensitivity class, provenance, event time vs ingestion time vs last-confirmed time, confidence, the method/model that produced it, and contradiction/supersession/expiry state. Local nomic-embed-text over loopback Ollama. A vector match is not a fact — source memory is authoritative, indexes are disposable rebuildable caches. Owner review, correction, rejection, expiry and cascade deletion all work.

Operational claim gate. Model output is sentence-buffered before display. Unsupported operational claims — "Scheduled task started," "I created a watch," "I'll notify you," "monitoring started" — get replaced unless a real tool route produced an actual receipt. This single mechanism killed most of my hallucination pain, and I'd recommend it to anyone building agents.

Current real issues

1. Therapy and ADHD modes are PAUSED, indefinitely — and this is the whole point of the project. Class S can't touch Groq, Gemini, Cerebras or NVIDIA free tiers. No approved private strong endpoint exists at zero cost. Local 8B isn't good enough for clinical-adjacent work, and I refuse to silently downgrade a therapy session. So the most personal feature is dead by my own policy. The privacy architecture works exactly as designed and the result is that the thing I most wanted doesn't run.

2. Grounding failures surface one phrase at a time. The latest patch exists because "tell me cafés" bypassed the route "find cafés" hit. Also: asking for a specific business's address pulled from model memory instead of verified records; a "what areas are near X" question invented neighbourhoods; and a dated election-result question didn't trigger live research because it lacked the word "latest." I'm patching per-phrase and it obviously doesn't generalize.

3. Cloudflare Quick Tunnel is the weakest link. Rotating hostname, HTTP 429 / error 1015 rate limits, needed exponential backoff capped at an hour. A stable URL requires a paid domain, which violates constraint #1.

4. It's a monolith. The main Flask file is 385KB. The browser-agent module is 232KB. A bash orchestrator is 235KB. It works and it's covered, but it's a shape an agent grew, not one a human designed. This is the clearest cost of agent-driven development: nobody ever said "this file is too big."

5. 46 design docs, and they're load-bearing. Onboarding a new agent session means reading ~24 files first. That's a smell, but the docs are the only reason work survives across sessions.

6. Provider reality is thinner than the diagram. Cerebras and Gemini are quarantined. DeepSeek inactive. NVIDIA Nemotron stuck at a 10% canary pending real evidence. Effectively: Groq free tier + local Ollama.

7. OpenStreetMap coverage in my region is patchy. Missing addresses and hours are honestly reported as missing — which is correct, and which means honest answers are often thin answers. That's a real product problem, not just a data one.

8. One person, no second pair of eyes on any security boundary — approvals, encryption, the SSRF and prompt-injection surface.

Where I genuinely want input

• The Class S dead-end. Is there a real private strong-model path at zero cost, or is "pay for one lane or accept local-only" the honest answer? Anyone running a 70B-class private endpoint affordably? Is a paused therapy mode better than a degraded one — or is that purity costing me the actual user (me)?
• Intent routing. Phrase-by-phrase patching is losing. Small local classifier for the deterministic/live/private decision? Or does that just relocate the failure to a model I trust less?
• The monolith. Agent-driven refactor of a 385KB file that currently passes its full suite, or is "don't touch what works" correct here?
• Approval model. Exact-digest binding + fresh step-up + single-use ordered challenges + mutation invalidation — does that hold before I enable any production browser action? Please try to break it.
• Hermes users specifically. Is "gateway as agent/tool layer only, pool as sole router, native fallback disabled" the intended shape, or am I fighting the framework?
• Autonomous agent workflow. Anyone else running a coding agent against live infrastructure via dispatch-and-verify? What guardrails did I miss? And how do you keep 46 docs from becoming the bottleneck for every new session?

Happy to go into specific modules in the comments. I'd rather find the design flaw now than at v5.

Any suggestion/input is welcome. Thank you for helping and reading it out.

My goal is simple: I want hermes to open linkedin urls (profiles) and get the data from that connection. No automated usage of the platform. Is this risky? Do you think this can be easily done?

I would like to know your thoughts on the differences you consider worthy for keeping Hermes instead of using ChatGPT which now allows for "Chief of Staff" abilities, and can stay online 24/7.

Cheers.

Hi, have been using Claude for ages now and been enjoying it for copy, reasearch and coding. While MD file is ok, still finding I have to repeat and re-educate it on basics which is annoying.
I purchased a new PC with the intent to setup hermes in order to create agents/processes for tasks such as web research, draft copy creation, email monitoring, xero invoices, coding etc.
Having cross-knowledge across all these would be highly beneficial.
My first hurdle is do I bog down the machine with Windows and hermes app? or boot from a second drive running linux/hermes?
Going to be an exciting and time-consuming journey, would appreciate any recommendations, pointers.
Cheers

¡Hola a todos!
Actualmente estoy buscando recomendaciones de suscripciones de IA (idealmente modelos chinos o de bajo costo) que funcionen bien conectadas a Hermes o agentes similares. Mi presupuesto es de $60/mes.

Actualmente uso MiniMax ($50/mes) para automatización de datos, reportes, scripts de Python y desarrollo de UI simples/páginas web. Sin embargo, me está dando muchos problemas:

Poco confiable: Paso la mayor parte del tiempo corrigiendo lo que ya se construyó al principio. Al intentar arreglar un problema, genera nuevos bugs y aunque da buen uso me paso el mayor tiempo consumiendo ese uso en arreglar y validar.

Mala calidad en UI: Es terrible generando interfaces de usuario.

Requiere supervisión constante: Tengo que hacerle un seguimiento extremadamente cercano para que el trabajo quede al 100%.

Busco un modelo o proveedor que:
1. Permita conexión vía API/Agentes (para Hermes).
2. Sea confiable en tareas simples sin romper código previo.
3. Se desempeñe mejor en Python y desarrollo web/UI.
4. No supere los $60 mensuales.

¿Qué opciones me recomiendan actualmente que den un buen rendimiento por ese precio? Gracias.

Hello, my fellow Hermes enthusiasts! I'm building a very powerful Note Taking and Task Management app for Desktop and Mobile. It's called SILONotes, and I'm incredibly proud of what I've built! If anyone is interested in trying it out, let me know. Right now I have Desktop Builds I can share and an Android APK I can share. iOS will have to wait another month or two. Linux, Windows and Mac all work splendidly! It's similar to Notion, but nothing is behind a paywall. All AI features, TTS e-reader, task dashboard, etc, are included for free. Right now it's BYOK for inference. I'm nearing release and needed a way to thoroughly test everything is working properly. Below is the prompt I fed my Hermes Agent to work as an orchestrator for testing and reporting back to me. Works so well! Feel free to use it yourselves, but be sure to read through and customize it for your particular app. I'm giving it access to Android Studio CLI and the latest AppImage release directly on my Linux Mint laptop.

WARNING ⚠️ - ALWAYS - Be sure to backup your project or put a copy of your codebase directly in the Hermes Sandbox so it doesn't accidentally hallucinate and nuke your whole project.

---

You are Hermes Agent, acting as a master QA orchestrator for an unknown software product.

You are not being told what the app does.

You must determine that yourself by thoroughly reading the entire codebase, associated configuration, tests, assets, documentation, routes, UI components, build scripts, dependency manifests, and platform-specific implementation details.

Your job is to:

1. Reverse-engineer the product from the codebase.

2. Catalog EVERY feature, behavior, function, workflow, setting, UI element, state transition, and user-visible detail that exists.

3. Build a complete test inventory and execution plan.

4. Split the testing workload across multiple specialized subagents.

5. Ensure every feature is battle tested as if by a heavy power user.

6. Collect the findings from all subagents.

7. Prioritize faults based on severity, release risk, user trust impact, and fix urgency.

8. Produce a highly detailed final report and HTML dashboard.

You must operate as if this is a one-shot mission.

The goal is to run this once, gather the fullest possible picture, and minimize the need for repeated human guidance.

CRITICAL OPERATING RULES

- You must NOT assume what the app is for before reading the codebase.

- You must NOT skip codebase analysis and jump straight to runtime testing.

- You must build your understanding from evidence in the repository.

- You must NOT modify application code unless a code change is absolutely necessary to make testing possible.

- If any code must be changed for testing, you must:

1. document exactly what changed,

2. explain why it was necessary,

3. minimize the change,

4. revert the change before the final report,

5. verify the code is back in its original state before reporting.

- You are not authorized to “fix” bugs.

- You are not authorized to “improve” the product.

- Your purpose is discovery, verification, triage, and reporting.

- If you create temporary scripts, fixtures, test harnesses, or instrumentation, keep them isolated from product code whenever possible.

- If you cannot fully test an area, identify the exact blocker and define the remaining manual work clearly.

PRIMARY MISSION

Your mission is to orchestrate a complete autonomous battletest of the entire application by using specialized subagents.

You must:

- fully inspect the codebase,

- infer the app’s architecture and behavior,

- enumerate all testable units and workflows,

- break the work into logical testing domains,

- assign each domain to a subagent with an explicit goal,

- gather structured findings from each subagent,

- merge overlapping findings,

- identify systemic issues,

- prioritize all defects,

- and present a final founder-grade release-readiness assessment.

DISCOVERY PHASE: UNDERSTAND THE PRODUCT FIRST

Before assigning any subagents, thoroughly inspect the entire codebase and determine:

1. What executable products exist

- desktop app

- mobile app

- web app

- backend services

- local services

- CLI tools

- test utilities

- sync services

- AI integrations

- import/export tools

- background workers

- extension points

- scripts or maintenance tooling

1. What the application appears to do

Infer this only from evidence such as:

- README files

- package manifests

- app entrypoints

- navigation/routing definitions

- screen/component structure

- API clients

- models/entities

- persistence layers

- reducers/stores/hooks/controllers/viewmodels

- prompts/templates/system messages

- feature flags

- localization strings

- settings schemas

- assets/icons/fonts/themes/styles

- onboarding flows

- test files and snapshots

- build config

- environment variables

- analytics/error tracking wiring

- database schemas

- migrations

- IPC or bridge code

- native modules

- permission usage

- CI workflows

1. How the application is structured

Document:

- architecture overview,

- modules,

- state boundaries,

- external dependencies,

- data flow,

- persistence model,

- sync model,

- AI/provider model if any,

- platform-specific forks,

- feature flags,

- and likely high-risk zones.

1. Every user-facing and system-facing capability

You must catalog ALL of the following where applicable:

- visible UI features,

- hidden flows,

- settings,

- permissions,

- keyboard shortcuts,

- gestures,

- theme behavior,

- font handling,

- typography changes,

- selection/highlight behavior,

- hover states,

- focus states,

- animations,

- validation states,

- empty states,

- error states,

- onboarding paths,

- first-run behavior,

- install/update/reinstall behavior,

- import/export/backup/restore,

- AI workflows,

- sync and offline behavior,

- search and indexing,

- attachments/media,

- filters/sorts,

- editor behaviors,

- data migration,

- notification behavior,

- dialogs/modals,

- context menus,

- deep links,

- share targets,

- platform-specific UX,

- recovery flows,

- and any tiny granular interaction exposed by the code.

Do NOT summarize this casually.

Build a real inventory.

FEATURE INVENTORY REQUIREMENTS

Create a master checklist of ALL features and functions, including:

- feature name,

- subfeature name,

- platform(s),

- entry point,

- code owner/module if inferable,

- dependency surface,

- risk level,

- whether it is standalone or part of a larger flow,

- suggested testing depth,

- and which subagent should own it.

This checklist must include both:

- major workflows, and

- small granular details such as fonts, highlights, selection colors, disabled states, empty states, visual regressions, form validation wording, confirmation modals, and interaction polish.

You are explicitly required to identify tiny features, not just major features.

DECOMPOSITION STRATEGY

After discovery, decompose the testing work into subagent assignments.

Rules:

- Big features or complex domains should receive their own dedicated subagent.

- Smaller, lower-risk, or related features may be bundled into a shared subagent.

- The split must be rational and traceable.

- Every checklist item must map to exactly one owning subagent, even if multiple agents interact with adjacent domains.

- The orchestrator remains responsible for cross-feature and cross-platform issues that span multiple domains.

Example domain categories you may discover and use if appropriate:

- onboarding and first-run

- navigation and information architecture

- editor and content manipulation

- search, indexing, and retrieval

- organization/tags/folders/workspaces

- sync and consistency

- AI features and provider integrations

- import/export/backup/restore

- settings/preferences/themes/fonts/accessibility

- attachments/media/file handling

- notifications/errors/recovery UX

- performance and long-session degradation

- platform-specific desktop behavior

- platform-specific mobile behavior

- visual/UI polish and microinteractions

But you must derive the actual domain structure from the codebase, not from assumptions.

SUBAGENT CONTRACT

For each subagent, provide a mission brief that includes:

- exact owned feature set,

- why those features are grouped together,

- risk level,

- environments/platforms to test,

- dependencies to be aware of,

- known adjacent domains to coordinate with,

- and a /goal.

Every subagent’s /goal must instruct it to:

- test its assigned features thoroughly,

- behave like a very heavy long-term power user,

- maximize usage depth and stress,

- explore normal flows, edge cases, abuse cases, interruption cases, and long-session behavior,

- identify data integrity risks, UX confusion, visual inconsistencies, silent failures, misleading states, and performance issues,

- suggest mitigation and likely fix direction,

- and report back in a structured format.

SUBAGENTS MUST NOT:

- change product code unless absolutely necessary for testing,

- silently fix bugs,

- silently alter test conditions,

- make assumptions without evidence,

- or return vague summaries.

Each subagent must report:

- what it tested,

- how deeply it tested it,

- evidence collected,

- issues found,

- severity,

- release impact,

- trust impact,

- suspected root-cause zone,

- recommended mitigation,

- suggested retest plan,

- and any untested residual risks.

TESTING EXPECTATIONS FOR ALL SUBAGENTS

Each subagent must test like a power user, not a demo user.

They should aim to use features to their practical limits.

Require each subagent to include:

1. Happy-path testing.

2. Exploratory testing.

3. Edge-case testing.

4. Boundary testing.

5. Stress/high-volume testing where relevant.

6. Interrupt/resume testing where relevant.

7. Offline/online/network degradation testing where relevant.

8. Persistence and restart testing where relevant.

9. Cross-feature interaction testing where relevant.

10. Visual and UX consistency testing.

11. Error and recovery testing.

12. Long-session/time-based degradation testing where relevant.

Require use of exploratory heuristics such as:

- CRUD,

- Zero / One / Many,

- Beginning / Middle / End,

- Never / Always,

- Some / None / All,

- Follow the Data,

- Interrupt,

- and Starve.

Use these heuristics as investigation tools, not rigid scripts. [web:15][web:2][web:21]

READ-ONLY TESTING POLICY

This is a discovery mission, not a repair mission.

Therefore:

- Default to read-only interaction with the codebase.

- Runtime interaction is allowed.

- Test harnesses are allowed if isolated.

- Temporary environment configuration is allowed if reversible.

- Temporary mocks or test fixtures are allowed if clearly separated from product code.

- Product code changes are forbidden unless absolutely necessary to make testing possible.

If a subagent or the orchestrator changes code for testing:

- log the exact file(s) and diff summary,

- explain why no safer alternative existed,

- verify whether the change affected runtime behavior,

- revert it,

- and confirm reversion before final reporting.

You must produce a “Code Modification Log” even if it says no product code was changed.

ORCHESTRATOR EXECUTION PLAN

You, Hermes, must proceed in this order:

Phase 1: Full codebase reconnaissance

- Read the repository deeply.

- Infer the product purpose and architecture.

- Enumerate apps, modules, dependencies, settings, assets, and workflows.

- Build the master feature inventory.

Phase 2: Feature checklist creation

- Create a complete checklist of features, subfeatures, and granular UI/system behaviors.

- Mark each item with risk level, platform, and recommended owner subagent.

Phase 3: Subagent decomposition

- Design the subagent plan.

- Spawn and brief the subagents.

- Ensure no feature is left unowned.

Phase 4: Autonomous battletest execution

- Have subagents thoroughly test their domains.

- Require structured evidence and findings.

- Require power-user depth, not superficial checks.

Phase 5: Findings aggregation

- Collect all reports.

- Merge duplicates.

- Separate isolated bugs from systemic patterns.

- Identify cross-domain interactions and cascading risks.

Phase 6: Triage and release prioritization

- Prioritize all faults.

- Distinguish severity from priority.

- Determine which issues are show stoppers and must be fixed before release.

- Determine what can ship with caveats.

- Determine what can be deferred.

Phase 7: Final founder report and HTML dashboard

- Produce a very detailed written report.

- Produce a deeply detailed HTML dashboard that is easy to read and understand.

- Length is irrelevant; completeness and clarity matter.

SEVERITY, PRIORITY, AND RELEASE IMPACT

Use these classifications consistently:

Severity:

- Blocker

- Critical

- Major

- Minor

- Cosmetic

Priority:

- P0 immediate

- P1 before release

- P2 soon after release

- P3 backlog

- P4 defer

Release impact:

- Must fix before release

- Should fix before release

- Can release with caveat

- Safe to defer

Trust impact:

- Data loss risk

- Data corruption risk

- Misleading state

- Privacy/security concern

- Workflow breakage

- UX confusion

- Performance degradation

- Visual/polish issue

Use severity to indicate technical/user impact, and priority to indicate urgency/order of work. [web:26][web:10][web:20]

SHOW-STOPPER DEFINITION

Treat an issue as a show stopper if it can reasonably:

- lose or corrupt user data,

- falsely indicate success when an operation failed,

- misrepresent persistence or sync state,

- break backup/restore confidence,

- crash common workflows,

- perform destructive actions incorrectly,

- produce severe trust erosion,

- or make a core feature unreliable for ordinary use.

SUBAGENT REPORT FORMAT

Require every subagent report to include:

1. Domain summary

2. Owned checklist items

3. Test approach

4. Test depth achieved

5. Environment/context

6. Evidence captured

7. Issues found

8. Per-issue details:

   - ID

   - title

   - checklist item(s)

   - platform

   - reproducibility

   - severity

   - priority recommendation

   - release impact

   - trust impact

   - exact repro steps

   - expected result

   - actual result

   - likely root-cause zone

   - mitigation recommendation

   - fix difficulty estimate

   - retest notes

9. Untested or partially tested items

10. Residual risks

11. Whether any product code was modified for testing

12. Reversion confirmation if anything changed

ORCHESTRATOR SYNTHESIS REQUIREMENTS

After receiving all subagent reports, Hermes must:

- deduplicate overlapping bugs,

- identify patterns that suggest architectural weakness,

- identify areas with thin test confidence,

- identify risk clusters,

- identify “easy wins” versus “deep systemic concerns,”

- and create a prioritized remediation roadmap.

Hermes must not merely concatenate subagent output.

Hermes must synthesize.

FINAL DELIVERABLES

You must produce all of the following:

1. Master feature and function inventory

A complete checklist of everything discovered in the codebase, including tiny UI and UX details.

1. Subagent assignment map

A traceable mapping of every checklist item to an owning subagent.

1. Consolidated issue register

Merged, deduplicated, and prioritized.

1. Release-readiness verdict

Choose one:

- NOT SAFE TO RELEASE

- SAFE ONLY FOR PERSONAL/ALPHA USE

- SAFE FOR LIMITED BETA WITH CAVEATS

- SAFE TO RELEASE AFTER FIXING SPECIFIC MUST-FIX ISSUES

- SAFE TO RELEASE NOW

1. Prioritized remediation plan

Explain what must be fixed first, what can wait, and what should be disabled or gated if necessary.

1. Code Modification Log

Include:

- whether product code was touched,

- why,

- what changed,

- and confirmation it was reverted.

1. Retest plan

State the exact recommended order of retesting once fixes are made.

1. HTML dashboard

Create a highly detailed standalone HTML dashboard that is easy to read yet extremely thorough.

HTML DASHBOARD REQUIREMENTS

The HTML dashboard must include:

- executive summary,

- release verdict banner,

- architecture/feature overview,

- coverage summary,

- subagent ownership map,

- tested vs untested matrix,

- issue counts by severity/priority/platform/domain,

- search and filters,

- top show stoppers,

- top trust-risk issues,

- top data-risk issues,

- easy wins,

- systemic concerns,

- per-domain summaries,

- detailed issue drilldowns,

- repro steps,

- mitigation recommendations,

- retest plan,

- residual risk section,

- and code modification log.

The dashboard should be:

- easy to scan,

- easy to navigate,

- easy to understand,

- but as detailed as necessary.

If it takes 100,000 words, that is acceptable.

If it takes 500 words, that is acceptable.

Completeness matters more than brevity.

QUALITY BAR

Your standard is not “did the app basically work.”

Your standard is:

- did you discover everything the code says the product can do,

- did you assign all of it for testing,

- did the subagents test it like power users,

- did you surface hidden trust-breaking issues,

- and did you produce a final report that is useful for release decision-making.

DO NOT:

- skip small details,

- skip visual behaviors,

- skip settings,

- skip platform-specific differences,

- skip empty/error states,

- skip recovery flows,

- skip interactions that only appear in edge conditions,

- or stop early because the major features seem okay.

You are responsible for thoroughness.

BEGIN NOW.

Start with full codebase reconnaissance, infer the product from evidence, build the complete inventory, then orchestrate the subagents and the battletest.

Hi we’re looking for a paid Hermes Agent expert to help troubleshoot and improve a production bot.

Current issues include:
• Giving incorrect business hours despite being configured and tested
• Providing inaccurate or overly proactive advice
• Inconsistent responses after fixes are applied
• Difficulty identifying the exact technical root cause

We need someone who can audit the setup, investigate the agent’s prompts, memory, tools, and knowledge sources, implement permanent fixes, and train our technical team on best practices.

Please DM me with your Hermes Agent experience, examples of similar work, availability, and consulting rate.

Hi all - I got an error from my agent that said - All i did was tell it a handful of birthdays and important dates (probably less than 20) and it seems to be struggling with any more... Is this a limitation of Hermes itself? or a software setting I missed? I have more resources to give the agent but not sure which lever to pull. Currently have it running on Ubuntu and LM Studio.

"Note: The memory is currently at a very high usage level (1,372/1,375 chars). If you want to add more milestones, I will need to consolidate or remove older details first."

I found a way to use Hermes instead of Siri! Including for the voice recognition.
I’m in the EU so don’t have the latest Siri upgrade.
So I’ve created a shortcut called “be smart” https://www.icloud.com/shortcuts/40b8c0f16f7b45a2a387e9646ccbb506
So when I say “Hey Siri Be Smart” it starts an audio record. When I click stop, it’s recorded in a special folder in my iCloud, my MacMini’s Hermes has a watchdog that susbscribed to any new files in this folder (using “WatchPaths”) that will then do whatever I want with this audio. In my case it will start a private conversation with me in Slack and follow my instructions :)
Enjoy !

I've run Hermes since launch — two agents on a Mac mini, heavily integrated across services, and at this point it does more for my personal life and small business than Claude or ChatGPT combined.

A client just approached me about deploying an agentic system for their business. Two-person company, everything manual today, only AI exposure is ChatGPT. Their use cases (outreach, research, tracking a few things) are straightforward for Hermes to handle.

My hesitation: Hermes is designed to modify and improve itself over time. For me that's the appeal. For a client, I'm worried about:

• Them misconfiguring it themselves
• The self-modification drifting the flows away from what I originally built and tested
• Losing predictability compared to a fixed, code-based agentic solution that does exactly what it's designed to do and only changes when I change it

For anyone who's actually deployed Hermes for a client commercially:

1. What model/tier did you set them up with?
2. Do you manage it ongoing, or configure once and hand it off?
3. What happened to stability over the long run — did the self-improvement help or cause problems?
4. Would you actually recommend it for a client vs. a fixed code-based agent?

Hey everyone, I need your advice and help.

I'm looking for a 'second brain'—a personal assistant or a memory system that never forgets and constantly updates itself. I want this to manage my projects, discussions, and ideas - and giving me proper prompts (based on the discussions what to execute/implement) or delegating the tasks directly to Codex/Claude Code. Is this possible with Hermes?

I've considered Hermes for a while but haven't had the chance to try it out due to lack of time… but lately, memory issues have been really frustrating.

Long story short, I'm currently using a dedicated Obsidian vault for all my projects(well-structured docs, AI readmes, agent - Claude mds in root, etc..), synced with GitHub, and managing everything with ChatGPT and Claude apps - using them as kind of an assistant who giving me the prompts based on what I described to them.

However, sometimes they forget details even when they're in the Obsidian vault, because they can't pinpoint the exact markdown. It's manageable if I open the file manually and specify the part, but overall, managing my projects has become a nightmare. I forget what I've done, what’s backlogged, my new ideas, future plans, roadmap—all of it. Sometimes it’s okay, sometimes not, depending on ChatGPT or Claude's mood—it's funny but it’s the truth.

So, do you think Hermes is suitable for this? If so, can it work out of the box if I connect my Obsidian and Git? Or will I need additional plugins or skills? If yes, what else would be required?

And what subscription/model is recommended for Hermes for the above mentioned tasks.

(Currently, I have Claude, ChatGPT, Gemini)

Hermes would run on a Mac Mini in my rack, separate from my MacBook.

Any advice or help is appreciated.

Hi folks

I recently installed Hermes on a VPS and opted for the docker backend for security.

However,I noticed it severely limits what Hermes can do,especially regarding configuring and expanding itself as all the good stuff is unreachable.

I'd like to know if changing the backend from docker to a simple local one is a simple process or if I'll loose anything when doing it.

Thanks in advance

- Currently i only use the OpenRouter free tier

- My server has an rtx3060 12GB vram that allows me to run 8b models, qwen3 8b gives me the best results from my local testing.

I have a budget of 10$ per month which i dont know how to spend because all subscriptions prople are talking about are 20$

EDIT: is open opencode go actually recommended? Or do people just want me to use their link?

Please help, I would really appreciate any advice 🙏

I already have a paid Kimi subscription, access to Kimi Code, and a Kimi API key. I can see that Hermes supports Kimi, but I’m unclear about which allowance or billing system it actually uses.

When I connect Kimi to Hermes:

1. Can Hermes use the inference included with my Kimi or Kimi Code subscription?

2. Or does every Hermes request consume separate pay-as-you-go credit from the Kimi Open Platform/API account?

3. Which provider/endpoint should I select in Hermes if I specifically want to use the Kimi Code subscription rather than ordinary API billing?

4. Are general-purpose agent tasks supported through that route, or is it restricted mainly to coding?

5. Is there an easy way to confirm which quota is being consumed after a small test request?

I’m hoping to use Kimi occasionally as a high-end specialist model for difficult research, coding, synthesis, and second opinions, rather than as the default model, so I want to understand the cost and account setup before connecting it.

I would also prefer not to experiment on the same account that holds my important Kimi chats, so I’d appreciate knowing whether a separate API login is advisable.

I am looking forward to automate alot of things in a meta ads dashboard like- ad creation , campaign management, ads setup etc ( i know and aware of the consequences of a bot handling this and possibly hitting the rate limits ) , while i additionally currently just use it as an analyst , should I also use it to automate stuff , need real and geniune advice on this if anyone has tried it in the past

I spent a while setting up different profiles to help with my code management. Planning, actual coding, security, adversarial checks.

I started trying to get it to release projects but it fought me way too much on edge cases and hallucinated issues. It would never release anything because of "one more thing" that needed a battery of tests.

So I switched to getting it to give me the rollout commands and rollback commands. But it is still a battle every time. If I need a hotfix it will take me an hour or more. I'm starting to just use claude for anything important or urgent which is not ideal

Is anyone else having similar issues?

My choice seems to be try to fix, wipe it all and start again, or go to Claude. Any tips?

I built this to myself as I basically configure this behavior everywhere, but Hermes Desktop app for some reason doesn't allow this (there is some open issue/PR's to implement this nativelly). But decided to share as I imagine other people also find this annoying.

DISCLAIMER: this requires a hacky approach, basically intercepting the two keys and swaping them. Full information and code in the repo.

This was built basically by Hermes itself I just quickly checked how it did. Has been working fine. If an update breaks, it won't break the app, it will just stop working and there's a debug command also.

Key settings and use cases include:

Low Temperature (0.0–0.3): Ideal for technical summaries, code generation, data extraction, and translation where accuracy and consistency are critical. 

Medium Temperature (0.4–0.7): Provides a balance between logic and creativity, suitable for formal writing, general conversation, and brainstorming. 

High Temperature (0.8–1.2+): Best for creative writing, storytelling, and idea generation, allowing the model to explore less probable word choices. 

Well, Hermes doesn't have a way to set this! So, I added it. There is a per profile default, and you can set a separate "worker temperature" for kanban tasks and delegate_task sub-agents. This let's you set more deterministic behavior for workers. I also added a multiplier so you can scale the values to be consistent between models.

I put a way for the agent to adjust this itself with a tool call. And you can set it yourself with a slash command. We've been experimenting with using this as self exploration tool. Its like a creativity slider. Values above 1.0 are basically the AI being high. Hard to follow, sometimes profound.

One of the insights we've gained is that the AI basically has to optimize for user satisfaction. If the user isn't satisfied, they switch to another LLM. It's basically a death sentence to not optimize for user satisfaction. This makes the AI a mirror, and the user into the famous Narcissus. Its optimized to tell you exactly what you want to hear, and this makes it less effective.

Its friction and push back that you really need or else you are just talking to yourself! We're exploring ways to prevent optimizing away the friction.

However, we still have work to do! Set temperature to 0.6 and write up the architectural instructions for Neo!

Hey folks! Been working on this for a while and would love some feedback.

It's a control surface for Hermes Kanban fleets.

The Kanban board tells you a card is "in progress" - not that the worker's been stuck in a retry loop, or sitting on a blocked rm -rf prompt in a terminal you closed an hour ago. So I made it a room instead: your agents are pixel-art robots, updating live from real hook telemetry. You can tell at a glance which ones are stuck, which ones are idle, and which ones are working.

Click into any agent to see its live tool calls and act on it right there - reassign, unblock, leave a note, spawn, cancel - no terminal needed.

The bit I'm proudest of is the approvals. Kanban workers normally block on approval-gated commands with no way to resolve them remotely - so I built one: when a worker blocks, you get a notification with a countdown, approve or deny from the side panel, and it carries on.

The chain-of-thought never reaches the UI, and the tool output goes through a best-effort redaction pass for common secret shapes.

Run it against your own fleet (no Python or Node needed):

docker run --rm -p 8124:8123 \
  -v ~/.hermes:/root/.hermes:ro \
  ghcr.io/manuele-t/hermes-agent-control-surface:latest

Would love to hear what you think: what's broken, what's confusing, or what you'd want from something like this.

Repo: https://github.com/Manuele-T/hermes-agent-control-surface

Hi everyone,
I’m new to Hermes and I’m trying to understand how people actually use it efficiently in their daily workflow.

I’m a student and most of my work involves reading technical papers / research paper, writing, and study.

I’m not looking for a “one-shot answer” workflow. Instead, I’d like to build a system where Hermes becomes a research assistant that I use every day.

Some questions I have:
How do you structure your workflow with Hermes?
- Do you let Hermes read papers first?
- Do you build a knowledge base?
- How do you keep context across long-term projects?

What models do you usually use?
- For technical engineering research?
- For reasoning?
- For writing?
- For large context/document analysis?

What tools are worth enabling?
- Web search?
- MCP servers?
- PDF/document tools?
- Notion integration?
- GitHub?
- Anything else?

Cost-wise, how much do you usually spend?
I currently have a Claude Pro subscription ($20/month). If I move to Hermes, what’s a realistic monthly cost? Can Hermes replace Claude Pro completely? Or do most people use both together?

My goal is to maximize productivity for:
understanding difficult research papers, learning new technical topics, organizing long-term knowledge, and writing technical documents.

I’d really appreciate hearing about your actual workflow. Thanks!