Bug Hermes Agent 0.21.0: Desktop Bisa Mengirim Model ke Provider yang Salah

Hermes Agent 0.21.0 punya bug di Desktop yang dapat mencampur model dan provider ketika pengguna berpindah profile atau membuka chat baru. Model picker bisa menampilkan model DeepSeek di kelompok Xiaomi, lalu session benar-benar dibuat dengan pasangan xiaomi + deepseek-v4-pro. Request akhirnya dikirim ke endpoint Xiaomi dan ditolak sebagai model yang tidak didukung.

Ini bukan sekadar label UI yang salah. Pada laporan upstream, pasangan provider, model, dan base URL yang tidak cocok masuk ke runtime. Pada variasi lain, dua model masih berada di provider yang sama sehingga request selesai tanpa error, tetapi berjalan memakai model yang berbeda dari pilihan pengguna. Karena itu bug ini bisa tampil sebagai error yang jelas, atau lebih berbahaya: hasil normal yang diam-diam datang dari model yang keliru.

Laporan resminya ada di issue #101091, dibuat pada 2 September 2026 dan masih terbuka saat audit ini dilakukan. Pull request perbaikan #101796 sudah diajukan pada 3 September, tetapi belum di-merge dan belum menjadi bagian dari release stable.

Bug-nya terjadi di mana?

Hermes Desktop menyimpan pilihan composer, provider, dan sumber pilihan model. Saat profile lokal berpindah, state lama dapat terbawa karena penyimpanannya belum sepenuhnya terisolasi per profile. Session baru kemudian mengambil nilai yang stale sebelum profile tujuan selesai diaktifkan.

Laporan #101091 memberi contoh reproduksi dengan dua profile:

• profile default memakai provider DeepSeek dan model deepseek-v4-pro;
• profile dev memakai provider Xiaomi dan model mimo-v2.5-pro;
• pengguna berpindah profile ketika model picker atau pilihan manual masih aktif;
• chat baru dibuat pada profile Xiaomi;
• model DeepSeek dapat muncul di kelompok Xiaomi;
• ketika pesan dikirim, gateway menerima pasangan yang tidak cocok.

Dalam reproduksi tersebut, runtime tercatat memakai:

provider=xiaomi
model=deepseek-v4-pro
base_url=https://token-plan-cn.xiaomimimo.com/v1

Endpoint Xiaomi kemudian merespons HTTP 400: Unsupported model deepseek-v4-pro. Ketika model diganti menjadi mimo-v2.5-pro, request berhasil. Ketika deepseek-v4-pro dikembalikan ke provider DeepSeek, request juga berhasil. Bukti ini mempersempit masalahnya: model dan provider masing-masing dapat bekerja, tetapi pasangan yang dikirim oleh session tidak selalu konsisten.

Bukan hanya masalah saat pindah profile

Komentar lanjutan pada issue yang sama menambahkan variasi yang lebih sulit dideteksi. Dalam reproduksi independen, pengguna mengganti model.default di config.yaml dari model A ke model B pada provider yang sama. Setelah Desktop dibuka kembali, picker menampilkan model B, tetapi request session baru masih menggunakan model A.

Kondisi itu terjadi pada chat dengan history kosong. Artinya, model yang salah bukan berasal dari percakapan lama yang sedang dilanjutkan. Nilainya datang dari composer state yang masih tersimpan dan dikirim sebagai session override.

Perbedaan provider membuat bug lebih mudah terlihat karena endpoint biasanya mengembalikan error. Jika model lama dan model baru sama-sama dilayani provider yang sama, request dapat selesai seperti biasa. Pengguna baru akan mengetahuinya setelah memeriksa log atau metadata turn.

Akar masalah menurut laporan upstream

Analisis pada issue dan PR #101796 menunjuk kegagalan invariant di beberapa lapisan, bukan satu kesalahan renderer.

1. Composer lokal belum profile-scoped sepenuhnya

Pada koneksi lokal, scope state lama dapat memiliki suffix kosong. Model, provider, dan sumber pilihan disimpan sebagai key terpisah. Profile lokal akhirnya dapat melihat nilai yang ditinggalkan profile lain.

2. Session dibuat sebelum profile tujuan selesai disiapkan

Jalur pembuatan session mengambil model dan provider dari state composer sebelum proses memastikan gateway agent dan profile tujuan selesai. Saat perpindahan profile berlangsung cepat, nilai lama bisa lebih dulu dikirim sebagai override.

3. Gateway mempercayai pasangan explicit tanpa validasi yang cukup

session.create dapat menerima model dan provider yang dikirim Desktop, lalu menyimpannya sebagai model_override. Jalur ini tidak sepenuhnya memakai validasi yang sudah digunakan oleh pergantian model normal. Gateway kemudian menyelesaikan credential dan base URL berdasarkan provider yang diterima, tetapi tetap membawa model ID dari state lama.

4. Model inventory dapat membuat state yang salah terlihat sah

Setelah runtime terlanjur berada pada pasangan yang keliru, inventory model dapat memasukkan current model ke row provider aktif. Akibatnya, model yang salah bukan hanya dipakai di belakang layar, tetapi juga muncul kembali di menu provider tersebut.

5. Renderer hanya menampilkan data yang sudah tercemar

Model catalog menu Desktop mengelompokkan row yang diterima dari backend. Jadi memperbaiki tampilan picker saja belum cukup. Boundary antara composer, session creation, gateway, dan model inventory perlu dijaga bersama.

Dampaknya untuk operator

Issue ini diberi label P2, bug, Desktop, TUI, profile, serta risiko kompatibilitas dan session state. Label tersebut bukan berarti setiap instalasi pasti gagal. Dampaknya bergantung pada cara Hermes dipakai.

Risiko praktisnya lebih tinggi bila:

• satu Desktop memiliki beberapa profile dengan provider berbeda;
• operator sering berpindah profile lalu langsung membuat chat baru;
• model diganti melalui config sementara Desktop masih menyimpan state composer lama;
• hasil dari model tertentu memengaruhi keputusan bisnis, coding, atau review;
• provider yang berbeda memiliki kemampuan, context window, harga, atau kebijakan data yang berbeda.

Perlu dibedakan dua dampak. Pada contoh Xiaomi dan DeepSeek, request gagal dengan HTTP 400 sehingga availability terganggu. Pada variasi dengan provider yang sama, request dapat berhasil tetapi memakai model yang tidak dipilih. Laporan primer belum membuktikan bahwa bug ini membocorkan API key atau otomatis melanggar boundary credential. Ini adalah masalah konsistensi routing dan provenance model, bukan advisory keamanan credential.

Namun, hasil normal tidak otomatis berarti routing benar. Untuk workflow yang memerlukan model tertentu, provenance model adalah bagian dari correctness. Jawaban yang terlihat baik tetap bisa salah konteks bila dibuat oleh model yang berbeda dari yang dipilih operator.

Status perbaikan upstream

PR #101796 berjudul fix(desktop): prevent mismatched provider and model selections masih berstatus open saat audit dilakukan. PR tersebut mengusulkan lima perubahan:

1. menyimpan model, provider, dan sumber pilihan dalam state yang di-scope per profile;
2. mengambil parameter session dari profile tujuan, bukan dari composer state yang stale;
3. memvalidasi pasangan model/provider pada /model, session.create, dan agent construction;
4. mencegah current model yang tidak kompatibel masuk ke daftar provider native;
5. menambah regression test untuk perpindahan profile, session.create, dan pengelompokan model.

Deskripsi PR menyebut 14 focused Python tests, 453 focused Desktop tests, typecheck, ESLint, production build, serta E2E provider/profile yang lulus. PR juga mencatat E2E fleet profile rail yang masih intermittent. Catatan ini penting: test fitur yang relevan dilaporkan lulus, tetapi PR belum sama dengan patch stable dan masih menunggu review maintainer.

Release publik terbaru yang ditemukan pada audit adalah Hermes Agent 0.21.0 dengan tag v2026.8.31. Belum ada release bertag baru yang menyatakan bug ini sudah diperbaiki.

Mitigasi sebelum patch resmi tersedia

Sampai fix masuk ke release bertag, perlakukan pilihan provider dan model sebagai satu pasangan yang harus diverifikasi, terutama setelah perpindahan profile.

1. Jangan langsung mengirim pesan setelah pindah profile

Buka model picker pada profile tujuan dan pilih ulang model yang memang terdaftar di provider tersebut. Jangan hanya mengandalkan nama model yang sedang terlihat di composer karena issue ini justru melaporkan tampilan picker dapat ikut tercemar.

2. Mulai dari chat baru yang mudah diaudit

Untuk canary, buat chat baru setelah profile aktif sepenuhnya. Catat provider dan model yang dipakai pada turn pertama. Jika hasil penting, cocokkan metadata session atau log yang tersedia dengan pilihan di UI.

3. Waspadai perubahan config saat Desktop masih menyimpan state lama

Jika model.default atau provider diubah melalui konfigurasi, jangan berasumsi Desktop langsung membuang composer state sebelumnya. Setelah restart atau reload, validasi ulang model dari profile aktif sebelum menjalankan pekerjaan yang sensitif terhadap kualitas atau biaya.

4. Pisahkan profile yang memiliki konsekuensi berbeda

Hindari menjadikan satu profile sebagai tempat bergantian antara provider untuk pekerjaan production, eksperimen, dan data sensitif. Pemisahan profile tidak menghapus bug, tetapi mengurangi peluang state composer yang salah terbawa ke workflow lain.

5. Jangan menambal stable dengan PR secara manual

PR #101796 belum menjadi release. Mengambil sebagian commit dari branch PR ke instalasi aktif dapat menimbulkan konflik dengan perubahan lain. Jika perlu menguji patch, lakukan pada canary terisolasi dengan backup dan rollback yang jelas.

Mitigasi di atas bukan jaminan bahwa bug hilang. Tujuannya mengurangi silent misrouting sampai release resmi tersedia.

Checklist setelah patch masuk release

Saat release baru menyatakan perbaikan ini tersedia, uji minimal berikut memakai profile dan model yang tidak kritis:

• pilih model A pada provider A, kirim satu turn, dan catat metadata-nya;
• pindah ke profile provider B, buat chat baru, lalu pastikan model A tidak ikut terbawa;
• tampilkan model picker dan periksa setiap model berada di provider yang tepat;
• kirim request dengan pasangan native yang valid;
• pastikan pasangan native yang jelas tidak kompatibel ditolak sebelum request inference;
• ganti model.default, buka ulang Desktop, lalu cek model yang dikirim sesuai config terbaru;
• uji dua model pada provider sama untuk memastikan picker dan runtime tidak silent drift;
• verifikasi model inventory tidak menambahkan model provider lain ke row aktif;
• cocokkan versi aplikasi, tag release, dan commit aktif sebelum rollout lebih luas.

Keputusan operasional

Bug #101091 layak menjadi alasan untuk menahan rollout Hermes Agent 0.21.0 pada Desktop multi-profile, bukan alasan untuk menyimpulkan seluruh instalasi Hermes rusak. Masalah yang terbukti adalah pasangan model/provider dapat drift antara UI, session creation, gateway, dan runtime.

Untuk deployment yang hanya memakai satu profile dan satu provider, risikonya lebih kecil tetapi tetap ada pada variasi config dan composer state. Untuk deployment multi-profile, lakukan canary dan verifikasi metadata model pada turn pertama setelah setiap perpindahan profile. Jika model picker menampilkan model di kelompok provider yang tidak semestinya, jangan kirim pekerjaan penting dari session tersebut.

Tunggu release bertag yang membawa perbaikan final. Sampai saat itu, anggap tampilan picker sebagai indikasi, bukan satu-satunya bukti model yang benar-benar digunakan.

Sumber primer

• Hermes Agent issue #101091: Desktop menerima pasangan provider/model yang tidak cocok
• Komentar reproduksi independen pada issue #101091
• PR #101796: prevent mismatched provider and model selections
• Hermes Agent v0.21.0 / tag v2026.8.31