Opyt vs Hermes Agent + cron

Hermes runs MCP servers, so it can run Opyt. The question is where a cron job puts the result.

Writing this one as a head-to-head would be wrong. Hermes Agent is an MCP client that can “connect to any MCP server via stdio or HTTP transport”, so the correct configuration is Hermes with Opyt, not instead of it. It also already solves the two things that usually stop a hand-built ingest: a scheduler, and full browser automation including local Chrome over CDP. The logged-in session, which is what makes X and Substack hard, is available out of the box.

Where it stops is storage. Its built-in memory is two files with hard character limits: MEMORY.md at 2,200 characters and USER.md at 1,375, injected whole into the system prompt at session start and never changed mid-session. session_search is FTS5 over past conversations in state.db, which is keyword matching over transcripts. That is a good design for remembering how you like to work. It is 3,575 characters, and it is injected whole with no search over it. A knowledge base is not a note.

The scheduling semantics say the same thing. “Cron runs each job in a fresh agent session”, and “the prompt must contain everything the agent needs”; continuity=true injects the job’s own most recent output into the next run. So what carries between nightly runs is the last thing the job said, not a store. The store is still yours to build, and building it is the argument on the build-it-yourself page.

At a glance

Where Hermes Agent + cron is better

• Hermes hosts Opyt. Calling it a rival gets the relationship backwards, since Hermes connects any MCP server over stdio or HTTP, so Hermes with Opyt is a supported configuration and the one we would recommend.
• Its scheduler is better than anything Opyt has: natural language, intervals, standard cron expressions and ISO timestamps, with pause, resume, edit, and a per-job toolset restriction.
• Browser automation Opyt does not have at all: Browserbase, Browser Use, or local Chrome, Brave, Chromium and Edge driven over CDP.
• Skills that improve themselves during use, on the agentskills.io standard. Opyt has no equivalent and no plans for one.
• It runs on a $5 VPS and its scope is a general agent across 16+ messaging platforms. Opyt does one thing and has no interface of its own.

Where Opyt is better

• Somewhere for the result to live. Hermes’ built-in memory is 3,575 characters across two files, injected whole at session start. A corpus needs a store with a ranked scan over it, and Opyt is one.
• Re-running is safe. A re-emitted standing query hashes to the same row on its normalized text, so a re-spawned twin cannot reset it; papers dedup on a deterministic canonical id (arXiv id, then DOI, then Semantic Scholar id), so two versions of one paper become one document. The frontier deliberately re-asks a 6-hour overlap behind its cursor, because dedup absorbs it.
• The X loop terminates. It stops on ‘this page added no new item’ rather than on the cursor, because X returns a fresh bottom cursor forever; a 100-page cap is a runaway backstop that logs loudly and never stops silently.
• Failures skip rather than write. A partial vector list propagates so the caller drops that document whole, because a false ‘complete’ is permanent under dedup, and an unattended nightly job is exactly where that goes unnoticed.
• Retrieval is one embedding call of the query, about $0.000001, then BM25 and cosine over 8,095 stored vectors, 229 ms, 84 MB resident. A cron job that classifies each item with a model pays per item, on every run.

Which one

Run both. Hermes brings the scheduler and the hands, and Opyt brings somewhere for the output to land. The comparison that decides anything is a hand-written ingestion skill against Opyt, both of them inside Hermes, and that argument sits on the build-it-yourself page.

install Opyt free, MIT, five minutes