Kompresi Konteks Hermes Mengalami Timeout: Perbaikan

"Context compression timed out before it could commit" berarti model ringkasan Hermes — model di bawah auxiliary.compression, bukan model utama Anda — tidak membuat kemajuan sebelum anggaran kompresi Hermes habis, dan giliran dihentikan tanpa panggilan utama dikirim. Ini bergantung pada versi: kami mereproduksi kedua pesannya pada Hermes Agent v0.21.3 dan pulih dari pesan tersebut dengan membuat peringkas merespons lalu mencoba lagi dalam sesi yang sama, sedangkan pada v0.21.5 kemacetan yang sama menghasilkan waktu tunggu panjang, bukan error. Diuji pada 1 Oktober 2026 terhadap stand-in perekaman untuk kedua model, bukan provider nyata.

Jika Anda menyiapkan Hermes untuk menggunakan endpoint sendiri, bukan men-debugnya, mulai dari Hermes Agent dengan API kustom.

Kedua pesan tersebut dan arti masing-masing

Yang Anda lihat	Saat muncul	Panggilan utama dikirim?
"Kompresi konteks kehabisan waktu sebelum dapat menyimpan hasilnya saat permintaan masih sekitar 83.485 token. Panggilan provider tidak dikirim. Jalankan /compress dan tunggu hingga selesai, lalu coba lagi."	v0.21.3, peringkas diam, permintaan (~83.485 token) lebih besar daripada window model sebesar 64.000 token	Tidak
"Kompresi konteks kehabisan waktu tanpa mengurangi percakapan ini. Tidak ada pesan yang dibuang. Mulai sesi baru dengan /new, atau periksa auxiliary.compression sebelum mencoba /compress lagi."	v0.21.3, peringkas diam, permintaan (~57.489 token) melewati pemicu kompresi 54.400 token tetapi masih berada dalam window	Tidak

Angka token dalam pesan pertama adalah estimasi Hermes sendiri atas permintaan yang akan dikirim. Kedua giliran berakhir di log sebagai reason=context_compression_timeout dengan api_calls=0, setelah peringatan berbentuk "Context compression made no progress for 5.0s" — lima detik karena pengujian menyetel compression.context_timeout_seconds: 5 agar proses tetap singkat; default-nya 120.

Versi yang Anda gunakan menentukan hasilnya

Status peringkas	v0.21.3 (14 September)	v0.21.5 (24 September)
Diam, permintaan berada dalam window	Giliran dihentikan — pesan kedua di atas	Menunggunya (jeda 30 d dan 90 d), mengompresi 9 pesan menjadi 5, lalu mengirim permintaan
Diam, permintaan melebihi window	Giliran dihentikan — pesan pertama di atas	Tidak dijalankan dengan peringkas diam; dokumentasi membatasi kasus ini dengan satu anggaran tidak aktif dan ringkasan fallback deterministik
Error jawaban (404)	Dua percobaan, kompresi dilewati, permintaan dikirim (diuji dalam window)	Sama; permintaan yang melebihi window juga dikirim, yang akan ditolak provider nyata
Responsif	Dikompresi dan dikirim	Dikompresi dan dikirim

Batasnya terdapat dalam source. Pada v0.21.4 (tag v2026.9.21), fungsi yang menghentikan giliran setelah kompresi timeout dipersempit menjadi permintaan di atas window model, dengan merujuk issue #113646 dan #114594; v0.21.3 menghentikan semuanya. Dokumentasi konfigurasi v0.21.5 kemudian menambahkan bahwa waktu tunggu kompresi “dibatasi paling rendah oleh timeout permintaan kompresi auxiliary itu sendiri (auxiliary.compression.timeout, minimum 300s)” — itulah sebabnya pengaturan lima detik kami tidak berdampak di sana. Jadi pada build terbaru, peringkas lambat menghabiskan waktu tunggu beberapa menit, bukan menghasilkan error, dan peringkas yang mati akan dilewati.

Diagnosis tercepat

Periksa versinya dengan hermes --version. Pada v0.21.3 atau lebih lama, kedua pesan di atas adalah perilaku yang diharapkan untuk peringkas yang macet.
Temukan peringkasnya di ~/.hermes/logs/agent.log: baris "Auxiliary compression: using <provider> (<model>) at <url>" menyebutkan model dan endpoint yang timeout. Tanpa blok auxiliary.compression, peringkas mewarisi model utama Anda.
Baca baris pemicunya, "Pre-API compression: ~N request tokens >= T threshold (context=W)". Jika N lebih besar daripada W, giliran tidak dapat dikirim tanpa diperkecil pada versi mana pun.
Periksa window peringkas. Dokumentasi Hermes mensyaratkan ukurannya setidaknya sama besar dengan model utama, karena peringkas dikirimi seluruh bagian tengah percakapan.

Pemulihan yang telah diverifikasi

Dalam setiap kasus v0.21.3 di atas, memulai ulang stand-in dengan peringkas yang merespons dan mengirim satu giliran lagi dalam sesi yang sama (--resume) menghasilkan balasan normal, dengan percakapan tetap utuh. Dalam praktiknya, artinya salah satu dari hal berikut: arahkan auxiliary.compression ke model cepat yang dapat Anda jangkau, perbaiki endpoint yang ditunjuknya, atau naikkan compression.context_timeout_seconds jika peringkas Anda lambat tetapi sehat — misalnya model lokal. Lalu coba lagi dalam sesi yang sama.

Mengarahkan kompresi ke peringkas yang responsif — pemulihan yang berhasil

# ~/.hermes/config.yaml — the summariser is its own model, with its own budget
auxiliary:
  compression:
    base_url: https://api.kunavo.com/v1   # overrides provider; any OpenAI-compatible endpoint
    api_key: sk-kn-...
    model: claude-haiku-4-5             # fast, and a context window >= your main model's
    timeout: 300

compression:
  context_timeout_seconds: 120   # inactivity budget for the summary (default)
  context_total_ceiling_seconds: 600

Dua hal tidak diuji: surface Hermes Desktop dan messaging-gateway, yang memiliki kompresi hygiene sendiri dengan anggaran berbeda, serta provider nyata yang menolak permintaan yang melebihi window. Proses yang dijalankan adalah giliran hermes chat -Q sekali jalan.

Biayanya

Giliran yang dihentikan tidak mengirim permintaan model utama, sehingga model utama tidak menagihkan biaya apa pun untuknya. Permintaan ringkasan telah dikirim — sekitar 19.000 karakter prompt dalam proses ini — dan provider menagihnya jika akhirnya selesai. Percobaan ulang kemudian membayar satu ringkasan dan satu panggilan utama. Peringkas kecil dan cepat mengurangi waktu tunggu serta overhead; di Kunavo, Claude Haiku 4.5 tercantum dengan harga $0,70 per juta token input dan $3,50 per juta token output, ditagihkan per token dari saldo prabayar. Tidak ada pihak di Kunavo yang menjalankan Hermes terhadap endpoint-nya; proses di sini menggunakan stand-in lokal.

Pertanyaan umum

Apa arti "Context compression timed out before it could commit" di Hermes?

Hermes mencoba memperkecil percakapan sebelum mengirim giliran Anda, model ringkasan yang digunakannya tidak membuat kemajuan dalam batas waktu yang tersedia, dan permintaan terlalu besar untuk dikirim tanpa diperkecil — sehingga Hermes menghentikan giliran tanpa memanggil model utama sama sekali. Direproduksi pada Hermes Agent v0.21.3 dengan peringkas yang macet dan permintaan 83.485 token terhadap window 64.000 token; baris log untuk giliran tersebut berbunyi api_calls=0. Model utama dan timeout API-nya bukan masalahnya. Masalahnya adalah peringkas: model di bawah auxiliary.compression dalam config.yaml.

Bagaimana cara memperbaiki timeout kompresi konteks Hermes?

Buat peringkas merespons, lalu coba lagi dalam sesi yang sama. Dalam reproduksi tersebut, mengarahkan auxiliary.compression ke model yang responsif dan mengirim giliran berikutnya dalam sesi yang sama berhasil setiap kali pada v0.21.3, dengan riwayat tetap utuh — pesan itu sendiri menyatakan tidak ada pesan yang dihapus. Memutakhirkan juga mengubah situasi: mulai v0.21.4, kompresi yang timeout tidak lagi menghentikan permintaan yang masih muat dalam window model, dan pada v0.21.5 waktu tunggu ringkasan memiliki batas bawah sebesar timeout permintaan peringkas itu sendiri, setidaknya 300 detik. Memulai sesi baru dengan /new juga berfungsi, dengan konsekuensi konteks percakapan hilang.

Apakah timeout kompresi Hermes sudah diperbaiki?

Sebagian, dan bentuknya berubah. Hingga v0.21.3 (14 September 2026), kompresi preflight yang timeout menghentikan giliran. v0.21.4 (21 September) hanya menghentikan permintaan yang melebihi window konteks model. Pada v0.21.5 (24 September), peringkas yang macet selama 30 lalu 90 detik tidak menghentikan giliran sama sekali: Hermes menunggu, melakukan kompresi, lalu mengirim permintaan — sehingga pada versi terbaru, gejala peringkas lambat adalah jeda panjang, bukan error ini. Peringkas yang mati, bukan lambat, berbeda: peringkas dicoba lagi, lalu dilewati, dan giliran dilanjutkan tanpa kompresi.

Apakah menaikkan HERMES_API_TIMEOUT membantu?

Tidak. Variabel tersebut mengatur panggilan model utama, dengan default 1.800 detik. Kompresi memiliki anggarannya sendiri dalam config.yaml: compression.context_timeout_seconds (anggaran tidak aktif, default 120 detik), compression.context_total_ceiling_seconds (default 600) dan auxiliary.compression.timeout untuk permintaan ringkasan itu sendiri. Dokumentasi Hermes menambahkan persyaratan yang sama pentingnya dengan kecepatan: window konteks model ringkasan harus setidaknya sebesar window model utama, karena model tersebut menerima seluruh bagian tengah percakapan.

Apakah giliran yang timeout menimbulkan biaya?

Not on the main model: the turn ended before the main call was sent. The summary request was sent, though, and a summariser that eventually finishes is billed by its provider like any other call — in the runs here the summary prompt was about 19,000 characters. The retry then pays for one summary and one main call. That is why pointing compression at a small, fast model is cheaper as well as quicker: on Kunavo, Claude Haiku 4.5 lists at $0,70 per million input tokens.

Direproduksi pada 1 Oktober 2026 dengan Hermes Agent v0.21.3 (tag v2026.9.14) dan v0.21.5 (tag v2026.9.24), dipasang dari source rilisnya, terhadap stand-in perekaman lokal yang melayani model utama dan model ringkasan (menahan respons untuk peringkas yang macet, 404 untuk yang gagal), dengan window 64.000 token dan empat giliran filler yang dilanjutkan sebelum giliran pengujian. Batas versi dibaca dari agent/turn_context.py pada tag v2026.9.14, v2026.9.21 dan v2026.9.24, dan anggaran dibaca dari dokumentasi konfigurasi setiap tag. Stand-in bukan model atau provider: stand-in menerima ukuran permintaan apa pun, sehingga error konteks dari sisi provider tidak direproduksi.