Hermes Agent 0.20.5 Rilis: Keyless Web, Cron Memory, dan Update Receipt

Hermes Agent 0.20.5 bukan patch kecil dalam arti biasa. Tag v2026.8.19 dipublikasikan di GitHub pada 21 Agustus 2026 dan mengemas sekitar 323 pull request sejak 0.20.4. Upstream mencatat sekitar 746 commit yang menyentuh lebih dari 1.250 file.

Angka sebesar itu membuat satu hal jelas: jangan menilai rilis ini hanya dari perubahan tampilan Desktop. Dampak operasional yang paling terasa justru ada di web search tanpa API key, cron yang sekarang membawa persistent memory, pengaturan reasoning per job, bukti hasil update, serta pengelolaan worktree.

Rekomendasi awalnya: 0.20.5 layak masuk canary untuk Linux atau macOS, tetapi jangan langsung didorong serentak ke semua host. Pengguna Windows Desktop perlu lebih hati-hati karena masih ada laporan updater dan verifikasi fleet yang belum benar-benar fail-closed.

Status rilis yang perlu dipahami

Nama tag resminya adalah v2026.8.19, sedangkan nama produknya Hermes Agent 0.20.5. Release note menyebut 19 Agustus sebagai release date, tetapi halaman GitHub mencatat tag dipublikasikan pada 21 Agustus 2026.

Versi ini adalah stable tagged release untuk fresh install, Docker image, dan deployment yang mengikuti tag. Upstream belum menerbitkan curated release notes lengkap. Dokumentasi lengkap untuk seluruh perubahan sejak 0.20.0 dijanjikan masuk ke 0.21.0.

Artinya, operator tidak cukup membaca satu paragraf release note. Audit perlu turun ke pull request dan issue yang benar-benar menjelaskan kontrak perubahan.

Web search sekarang bisa jalan tanpa API key

Perubahan paling langsung terasa ada di web tools. Fresh install Hermes kini dapat memakai web_search dan web_extract tanpa credential web tambahan.

Jalur zero-config memakai endpoint gratis milik Parallel dan Exa. Setelah perluasan berikutnya, Hermes juga mendukung rotasi lima vendor: Exa, Parallel, Tavily, Firecrawl, dan Keenable. Bila salah satu free tier mengembalikan error yang bentuknya rate limit, request dapat dicoba sekali ke peer dalam ring. Hasil juga mencatat vendor yang benar-benar melayani request melalui field served_by.

Ada beberapa guardrail yang penting:

• backend dan API key yang sudah dikonfigurasi tetap mendapat prioritas;
• keyless tier adalah fallback terakhir, bukan pengganti diam-diam untuk setup berbayar;
• Tavily dan Firecrawl keyless perlu dipilih secara eksplisit;
• failover hanya berlaku untuk error yang terdeteksi sebagai throttle, bukan semua kegagalan;
• operator dapat mematikan fallback melalui web.keyless_fallback: false.

Dari sisi privasi, implementasi upstream menyatakan request keyless tidak membawa user identifier. Session ID Parallel dibuat acak per proses, tidak disimpan, dan berubah saat restart. Meski begitu, query tetap dikirim ke provider eksternal. Jangan gunakan jalur gratis ini untuk pencarian yang memuat data client, credential, atau informasi internal sensitif.

Secara operasional, fitur ini bagus untuk onboarding, riset publik, dan fallback ringan. Untuk workload produksi yang butuh SLA, audit log, atau kebijakan data yang ketat, backend berbayar dan terkontrol masih lebih masuk akal.

Cron sekarang membawa memory seperti agent lain

Di 0.20.5, cron agent tidak lagi dipaksa berjalan dengan skip_memory=True. MEMORY.md dan USER.md dapat dimuat ke system prompt, sedangkan memory tool mengikuti resolusi toolset normal.

Sebelumnya, scheduler menolak memory secara hard-coded. Job terjadwal tidak dapat memakai preferensi pengguna yang durable atau menyimpan pembelajaran untuk run berikutnya. Bahkan konfigurasi per-job yang secara eksplisit mengaktifkan toolset memory akan dibuang.

Kontrak barunya lebih konsisten, tetapi blast radius juga berubah. Job yang dulu dianggap stateless sekarang bisa membaca konteks jangka panjang. Bagi operator, ini bukan detail kecil.

Setelah upgrade, audit tiga hal:

1. apakah prompt cron memang boleh membaca MEMORY.md dan USER.md;
2. apakah isi memory aman untuk seluruh job dalam profile tersebut;
3. apakah job yang harus stateless sudah menonaktifkan memory melalui konfigurasi user-level yang sesuai.

Perubahan ini juga menjelaskan kenapa review prompt cron perlu dilakukan ulang. Sebuah job lama dapat menghasilkan output berbeda setelah mendapat konteks yang sebelumnya tidak pernah tersedia.

Reasoning effort dapat dipatok per cron job

Cron kini punya opsi CLI untuk menentukan reasoning effort per job. Nilai tersebut mengalahkan konfigurasi global dan override per model pada saat job dijalankan.

Contoh penggunaannya tersedia melalui hermes cron create atau hermes cron edit dengan flag --reasoning-effort <level>. Nilai kosong dipakai untuk menghapus pin.

Desain upstream sengaja menjaga opsi ini tetap CLI-only. Model dapat melihat nilai tersebut saat daftar job dibaca, tetapi tidak diberi schema untuk mengubahnya sendiri. Keputusan biaya dan kedalaman reasoning tetap berada di tangan operator.

Ini berguna untuk memisahkan workload:

• audit mingguan yang kompleks dapat memakai reasoning tinggi;
• health check rutin dapat memakai level minimal;
• job yang mahal tidak perlu memaksa seluruh profile memakai konfigurasi yang sama.

Tetap ukur dampaknya. Reasoning lebih tinggi dapat menaikkan latency dan biaya. Jangan menaikkan semua job hanya karena opsinya tersedia.

hermes update mendapat plan dan receipt

Perubahan updater adalah salah satu bagian terbaik di 0.20.5. Command update sekarang menulis receipt terstruktur ke direktori log Hermes. Receipt mencatat identitas kode sebelum dan sesudah update, langkah yang dijalankan, langkah yang dilewati beserta alasannya, hasil restart gateway, dan snapshot fleet.

Gateway juga menulis code_sha dan code_version ke status runtime. Setelah restart, updater membandingkan kode yang benar-benar dijalankan setiap gateway dengan checkout terbaru. Gateway yang terbukti masih memakai kode lama dapat membuat update gagal, bukan sekadar mencetak pesan sukses.

Selain itu, hermes update --plan memberi inventory read-only sebelum mutation. Plan dapat menampilkan:

• jenis instalasi;
• profile dan service Hermes yang sedang hidup;
• supervisor yang mengelola proses;
• versi kode yang sedang dijalankan;
• cara tiap service akan direstart.

Ini perbaikan yang tepat. Update agent produksi memang seharusnya menghasilkan bukti, bukan hanya exit code dan kalimat "update complete".

Namun jangan membaca keberadaan receipt sebagai bukti absolut. Ada bug watch penting pada jalur verifikasi tersebut.

Bug watch: fleet kosong masih bisa dianggap sukses

Issue #93406 dibuat terhadap Hermes Agent 0.20.5. Laporan itu menunjukkan post-update fleet check dapat menghasilkan nol baris pada gateway Windows yang sebenarnya sudah restart dan kembali melayani Telegram.

Masalahnya ada pada success path. Jika kolektor fleet gagal atau tidak menemukan baris, beberapa exception hanya masuk debug log. Matrix tidak dicetak, tetapi update tetap dapat exit 0. Operator akhirnya tidak bisa membedakan dua kondisi:

• semua gateway sudah diverifikasi memakai kode baru;
• tidak ada gateway yang berhasil diverifikasi.

Laporan tersebut diberi label P2 dan masih terbuka saat audit ini dilakukan. Upstream sudah punya perlakuan lebih ketat pada sebagian failure path, tetapi empty matrix di success path belum memakai kontrak fail-closed yang sama.

Implikasinya sederhana: setelah hermes update, jangan hanya melihat exit code 0. Pastikan output benar-benar memuat fleet version matrix dan setiap runtime yang diharapkan muncul di sana. Jika inventory sebelum update berisi gateway aktif tetapi hasil verifikasi sesudah update kosong, perlakukan update sebagai belum terverifikasi.

Untuk Windows Desktop, ada risiko tambahan pada ZIP fallback. Issue #90495 melaporkan fallback tersebut dapat menghapus packaged Desktop app dan asset dashboard, lalu update berikutnya lupa bahwa Desktop pernah terpasang. Sampai ada fix bertag yang jelas, simpan backup dan siapkan jalur recovery sebelum menjalankan updater di mesin Windows produksi.

Worktree tidak lagi dibiarkan tumbuh tanpa batas

Hermes 0.20.5 menambah hermes worktree list dan hermes worktree prune. Tujuannya bukan kosmetik. Pull request upstream lahir dari instalasi yang menumpuk 35 worktree, memakai sekitar 15 GB, dan menyimpan 244 branch lokal.

Command list menampilkan umur, ukuran, verdict, dan alasan per worktree. Prune dapat dijalankan dalam dry-run serta dibatasi ke tree atau branch saja. Startup juga memberi warning ketika jumlah worktree melewati 10 atau footprint melampaui 5 GB.

Guardrail penghapusannya cukup konservatif:

• tracked modification tidak dihapus;
• commit unik yang belum didorong tidak dihapus;
• worktree yang masih memiliki lock dibiarkan;
• untracked scratch diarsipkan sebelum tree dihapus;
• branch baru dihapus setelah worktree terkait berhasil dibersihkan;
• timeout Git berujung keep, bukan delete.

Tetap mulai dari dry-run. Worktree cleanup menyentuh hasil kerja developer, jadi bukti klasifikasi perlu dibaca sebelum prune nyata dijalankan.

Bot Mode dan Desktop makin kaya

Bot Mode mendapat group-room thread, ringkasan percakapan lama yang dapat dibuka kembali, attachment gambar, PDF, dan file melalui picker, paste, atau drag-and-drop. File dipasang ke turn tiap member, lalu referensi artifact ikut masuk ke prompt agar file tool dapat membacanya.

CLI juga menerima fuzzy model picker, command palette Ctrl+P, dan tampilan status yang lebih kaya. Untuk operator yang bekerja langsung dari Desktop, perubahan ini membuat Bot Mode lebih dekat ke workspace kolaborasi daripada sekadar chat antar-agent.

Tetapi fitur baru menambah state yang harus diuji: owner koneksi, routing lintas gateway, session member, attachment staging, dan resume behavior. Uji group kecil lebih dulu, restart salah satu gateway, lalu pastikan thread, file, dan tujuan balasan tetap benar.

Checklist upgrade 0.20.5

Sebelum upgrade:

• backup state database, profile, memory, cron job, skill, plugin, dan konfigurasi;
• jalankan inventory atau catat semua gateway yang sedang hidup;
• cek ruang disk, terutama bila banyak worktree;
• untuk Windows, pastikan jalur rebuild Desktop sudah dipahami.

Saat canary:

• upgrade satu host non-kritis;
• pastikan receipt benar-benar dibuat;
• cocokkan fleet matrix dengan inventory sebelum update;
• uji web search tanpa key dan dengan backend ber-key;
• uji satu cron yang boleh memakai memory dan satu cron yang harus stateless;
• jalankan worktree list, lalu gunakan prune dry-run;
• uji Bot Mode dengan attachment dan restart gateway.

Sesudah canary:

• pantau satu siklus cron penuh;
• periksa apakah job lama berubah perilaku setelah memory aktif;
• pastikan tidak ada gateway yang tetap menjalankan SHA lama;
• audit log error provider keyless dan fallback;
• rollout bertahap hanya jika bukti runtime lengkap.

Keputusan operasional

Hermes Agent 0.20.5 membawa fondasi yang lebih matang untuk operasi agent sehari-hari. Keyless web mempercepat onboarding, cron memory membuat job berulang lebih kontekstual, reasoning per job membantu mengendalikan biaya, dan update receipt memberi jejak yang selama ini kurang.

Tetapi rilis ini terlalu besar untuk diperlakukan sebagai patch rutin. Updater baru masih punya celah verifikasi saat fleet matrix kosong, terutama pada Windows. Jalur aman tetap sama: backup, plan, canary, baca receipt, verifikasi runtime, lalu rollout bertahap.

Untuk Linux atau macOS dengan deployment sederhana, 0.20.5 layak diuji sekarang. Untuk Windows Desktop produksi, tunggu atau canary dengan recovery plan yang jelas.

Referensi resmi

• Hermes Agent 0.20.5 / v2026.8.19
• Perbandingan resmi v2026.8.18 ke v2026.8.19
• PR #90313: keyless web pada fresh install
• PR #90572: rotasi lima vendor dan failover keyless
• PR #91447: persistent memory untuk cron
• PR #91244: reasoning effort per cron job
• PR #91283: update receipt dan fleet verification
• PR #91462: hermes update --plan
• PR #90599: worktree list dan prune
• PR #89540: PDF dan file attachment untuk group chat
• Issue #93406: fleet verification dapat menghasilkan nol baris
• Issue #90495: ZIP fallback dapat menghapus build Desktop
• Hermes Agent Security Policy