Bug Hermes Agent 0.19.0 Bisa Membuat Pencatatan Token dan Biaya Tetap Nol

Hermes Agent 0.19.0 punya bug migrasi database yang bisa membuat seluruh pencatatan token dan biaya berhenti. Agent tetap dapat menjawab, tetapi dashboard dan insight menampilkan 0 token atau biaya nol terus-menerus. Restart, update biasa, atau install ulang aplikasi tidak otomatis memperbaikinya karena bentuk tabel yang salah tetap tersimpan di state.db.

Temuan ini dilaporkan pada issue #73823 tanggal 29 Juli 2026. Saat audit dilakukan, issue masih terbuka, belum memiliki label prioritas, dan belum ada patch atau release baru setelah Hermes Agent 0.19.0. Repository juga belum menerbitkan GitHub Security Advisory baru.

Status per 29 Juli 2026: laporan berasal dari satu instalasi nyata dan analisis schema upstream. Bug ini material untuk billing visibility, tetapi belum dikonfirmasi maintainer sebagai masalah yang mengenai semua instalasi 0.19.0.

Gejalanya terlihat seperti pemakaian gratis

Pada instalasi terdampak, setiap sesi baru tercatat memakai 0 token. Nilai input_tokens, output_tokens, estimated_cost_usd, dan actual_cost_usd tetap nol atau kosong. Tabel pemakaian per model juga tidak menerima row baru.

Agent sendiri masih dapat berjalan. Karena kegagalan ditangkap sebagai warning, pengguna tidak mendapat error fatal di UI atau CLI. Ini membuat angka nol mudah disalahartikan sebagai masalah tampilan, keterlambatan sinkronisasi, atau provider yang tidak mengirim usage.

Log memberi petunjuk yang lebih tegas:

ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint

Jika pesan itu muncul dari jalur token accounting, pencatatan biaya bukan sekadar terlambat. Transaksi penulisannya gagal.

Akar masalahnya ada pada primary key

Hermes menyimpan rincian penggunaan model di tabel session_model_usage. Schema baru mengharapkan primary key enam kolom:

• session_id;
• model;
• billing_provider;
• billing_base_url;
• billing_mode;
• task.

Sebagian database hasil upgrade masih membawa primary key lama yang hanya terdiri dari lima kolom. Kolom task memang sudah ada, tetapi ditambahkan sebagai kolom biasa dan tidak masuk primary key.

Kode penulisan kemudian menjalankan upsert dengan conflict target enam kolom. SQLite menolak operasi itu karena tidak menemukan primary key atau unique constraint yang cocok.

Hermes sebenarnya sudah memiliki blok migrasi untuk membangun ulang tabel. Masalahnya, blok tersebut hanya dijalankan ketika current_version < 22. Database yang sudah telanjur mencatat schema version 22 atau 23 melewati migrasi itu pada setiap startup. Bentuk tabel yang salah tidak self-heal.

Kenapa summary sesi ikut hilang

Bug ini lebih luas dari satu row detail yang gagal masuk.

Menurut laporan upstream, pencatatan per model berjalan di dalam transaksi yang sama setelah update summary pada tabel sessions. Ketika upsert session_model_usage gagal, transaksi ikut dibatalkan. Akibatnya, summary token dan biaya pada sesi juga tidak tersimpan.

Jadi ada dua lapisan data yang hilang sekaligus:

1. rincian penggunaan per model dan task;
2. total token serta biaya pada sesi.

Data historis selama periode gagal kemungkinan tidak dapat direkonstruksi hanya dengan memperbaiki schema. Patch nantinya dapat memulihkan pencatatan ke depan, tetapi tidak otomatis mengetahui token yang sudah dipakai pada sesi lama.

Cara cek tanpa mengubah database

Audit awal cukup read-only. Backup state.db lebih dulu dan pastikan pemeriksaan memakai database dari instalasi Hermes yang benar, bukan file salinan lama.

Jalankan query berikut melalui SQLite:

SELECT COUNT(*)
FROM pragma_table_info('session_model_usage')
WHERE name = 'task' AND pk > 0;

Interpretasinya:

• hasil 1: kolom task masuk primary key;
• hasil 0: bentuk tabel cocok dengan kondisi yang dilaporkan sebagai terdampak.

Lalu cocokkan dengan tiga bukti lain:

• schema version sudah 22 atau lebih tinggi;
• sesi baru selalu mencatat 0 token;
• log memuat error ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint.

Jangan mengambil keputusan dari satu indikator saja. Nilai token nol juga dapat berasal dari bug berbeda pada billing_provider, provider yang tidak mengirim usage, atau jalur model tertentu.

Jangan rebuild tabel produksi secara spontan

Issue upstream mengusulkan healer idempotent yang memeriksa bentuk schema lalu membangun ulang tabel bila diperlukan. Namun itu masih arah perbaikan, bukan patch resmi yang sudah direview dan dirilis.

Rebuild manual menyentuh foreign key ke tabel sessions, index, data lama, serta transaksi aktif. Kesalahan urutan dapat menyebabkan startup gagal atau merusak state yang sebelumnya masih dapat dipakai. Mengubah schema_version secara manual juga bukan solusi karena dapat memicu atau melewati migrasi lain yang tidak sesuai.

Langkah aman untuk operator saat ini:

1. backup database secara konsisten sebelum tindakan apa pun;
2. simpan hasil query schema dan potongan log tanpa membagikan isi sesi;
3. jangan menghapus state.db hanya untuk membuat dashboard kembali mencatat usage;
4. gunakan metering dari provider sebagai sumber biaya sementara;
5. pantau issue #73823 dan tunggu patch yang sudah diuji pada database upgrade;
6. setelah patch tersedia, uji pada salinan database dan pastikan sesi baru mulai mencatat token lagi.

Jika billing internal dipakai untuk chargeback atau pembatasan budget, tandai periode sejak pencatatan terakhir yang valid sebagai data tidak lengkap. Angka nol selama periode tersebut bukan bukti tidak ada pemakaian.

Apakah perlu downgrade?

Belum ada dasar untuk downgrade massal. Laporan menyebut kondisi upgrade tertentu, bukan semua database baru Hermes 0.19.0. Downgrade binary juga belum tentu mengubah primary key yang sudah tersimpan di state.db.

Keputusan yang lebih tepat adalah audit schema. Jika primary key sehat dan usage tercatat normal, tidak ada alasan mengubah instalasi karena issue ini saja. Jika kondisi terdampak terkonfirmasi, tahan perubahan database manual, pakai metering provider untuk rekonsiliasi biaya, dan siapkan restore point sebelum patch resmi diterapkan.

Kesimpulan operasional

Bug #73823 berbahaya karena Hermes tetap terlihat sehat saat akuntansi token dan biaya sudah mati. Untuk tim yang memantau budget model, chargeback, atau efisiensi agent, dashboard nol dapat menghasilkan keputusan yang salah.

Cek bentuk primary key, korelasikan dengan log dan sesi baru, lalu perlakukan data biaya pada window terdampak sebagai tidak lengkap. Sampai upstream menerbitkan perbaikan, audit read-only dan backup yang benar jauh lebih aman daripada melakukan schema surgery sendiri.