Laporan OMNI Pilot: Apakah Kompresi Output Bikin Coding Agent Lebih Cepat?

14/5/2026·View as Markdown

OMNI adalah versi fork dari ekstensi OMNI milik Fajar Hidayat (original) yang saya tambahkan implementasi OMNI extension untuk Pi Coding Agent. Pilot ini dijalankan menggunakan tag v0.6.0-pi-alpha.2.

Ide di balik OMNI sebenarnya sederhana: ambil output yang besar dan noise dari tools seperti find atau rg, lalu distilasi menjadi sesuatu yang jauh lebih ringkas sebelum dilihat oleh agent. Gak ada yang lebih menyedihkan daripada ngeliat agent nyasar di dalam 500 baris git log — jadi pertanyaannya, apakah kompresi ini beneran membantu?

Saya jalanin 30-run A/B pilot yang terkontrol (5 task × 2 kondisi × 3 iterasi) buat cari tahu jawabannya.

Spoiler: OMNI berhasil mengompres input context dengan baik — kadang hasilnya drastis — tapi apakah itu berarti penghematan nyata? Ternyata ya tergantung apakah agent-nya tetap fokus atau malah jadi “kepo” dan bereksplorasi ke mana-mana.

Setup Eksperimen #

Kondisi #

ID	OMNI	Deskripsi
C1	❌	Baseline — tanpa OMNI extension
C2	✅	Dengan OMNI extension

Beban Kerja (Workload) #

Ada 5 task yang mencakup pemahaman kode (code understanding), debugging, dan implementasi, semuanya menargetkan codebase Rust milik fork OMNI:

Task	Tipe	Kesulitan	Est. Waktu	Apa yang ditugaskan ke agent
CU-01	Code Understanding	Easy	2-3 min	Cari dan jelasin implementasi distiller untuk output git di `src/distillers/git.rs` — identifikasi fungsi utama dan jelasin logika filternya
CU-06	Code Understanding	Medium	5-7 min	Telusuri riwayat pengembangan fitur distillation pipeline pakai `git log`, `rg`, dan command terkait — rangkum kapan pipeline diperkenalkan, evolusi scoring, dan file kunci yang berubah
DB-01	Debugging	Medium	5-7 min	Jalanin `cargo test`, cari test yang gagal, telusuri penyebabnya, perbaiki, dan verifikasi kalau fix-nya berhasil
IM-02	Implementation	Medium	5-7 min	Bikin custom TOML filter di `~/.omni/filters/npm_install.toml` yang ngehapus progress bar, tetap nampilin warning/error, dan meringkas log dependensi yang panjang — verifikasi dengan `omni learn --verify`
IM-05	Implementation	Medium	5-7 min	Implementasi `omni diff --json` di `src/cli/diff.rs` yang mengembalikan perbandingan JSON antara raw vs distilled output termasuk metrik (penghematan token, rasio kompresi)

Matriks #

5 task × 2 kondisi × 3 iterasi = 30 kali jalan (runs)
Model: mimo-v2.5 (Xiaomi MiMo-V2.5) — jalan di Xiaomi MiMo Open Platform (pakai kode YTKZ66 buat ¥10 API credits)
Tingkat Keberhasilan: 100% di kedua kondisi

Cara Saya Merancang Tes Ini #

Satu keputusan desain yang krusial: system prompt yang sama digunakan untuk kedua kondisi.

Agent gak pernah dikasih tahu soal OMNI. Dia cuma punya akses ke tools (search, read_file, write_file, bash) dan diminta buat nyelesain setiap task seefisien mungkin. OMNI beroperasi sebagai transparent middleware — agent panggil search, dapat hasil yang sudah difilter, dan dia gak tahu dia lagi di kondisi yang mana.

System prompt persis yang dipakai di setiap run:

You are a coding agent working on a Rust project. You have access to these tools: search, read_file, write_file, bash. Complete the task using the most efficient approach. Do not ask clarifying questions unless absolutely necessary.

Prompt task (yang ada di tabel di atas) juga identik di setiap kondisi. Saya mau ngetes tools-nya, bukan kemampuan agent buat ngikutin instruksi — jadi system prompt-nya tetap sama persis buat setiap run.

Hasil Data: Apa Kata Angka? #

Rata-rata dari Seluruh 30 Runs #

Metrik	C1	C2	Delta (C2 vs C1)
Wall clock (s)	275.7	253.3	-8.1%
Total tool calls	17.2	25.0	+45.3%
Search tool calls	3.6	7.6	+111.1%
Total tokens	296,246.9	338,010.2	+14.1%
Input tokens	27,702.5	19,005.4	-31.4%
Context pressure	457.2	244.0	-46.6%
Turns	12.3	18.5	+49.8%

Apa Arti Data Ini? #

Kompresinya beneran jalan. Penurunan -46.6% pada context pressure adalah sinyal paling jelas di dataset ini. OMNI beneran bikin payload yang harus diproses agent jadi jauh lebih ringan.
Tapi lintasannya jadi lebih panjang. Kondisi C2 memicu lebih banyak turns (+49.8%) dan tool calls (+45.3%). Agent jadi lebih eksploratif — seolah-olah beban kognitif yang lebih rendah bikin dia merasa lebih bebas buat “jalan-jalan” cari info tambahan.
Biaya token total malah naik. Eksplorasi tambahan itu ternyata lebih berat daripada efek kompresi per langkahnya secara agregat. Total token naik 14.1%.

Cara Kerjanya (Reaksi Berantai) #

Kira-kira begini alur efeknya:

plaintext

Output tool yang besar           Distilasi OMNI
  (find/rg/git log)    ──────────────────►  Payload konteks ringkas
                                              -31.4% input tokens
                                              -46.6% context pressure
                                                    │
                                                    ▼
                                            Lintasan Agent
                                              │
                          ┌───────────────────┴───────────────────┐
                          ▼                                       ▼
                    Agent yang stabil                      Agent yang eksploratif
                    [Turns] lebih sedikit,                 [Turns] lebih banyak,
                    potensi hemat total                    tool use meningkat
                          │                                       │
                          ▼                                       ▼
                    Hemat secara neto                      Boros secara neto
                    (DB-01, CU-06)                         (CU-01, IM-02, IM-05)

Pembagian: Di Mana OMNI Membantu dan Di Mana Enggak #

Rata-rata itu seringkali menyembunyikan cerita aslinya. Dampak OMNI ternyata beda banget tergantung task-nya:

Task	Total token delta	Arah
DB-01	-52.5%	✅ Hemat banyak
CU-06	-28.6%	✅ Hemat lumayan
IM-05	+7.0%	❌ Naik sedikit
IM-02	+36.1%	❌ Naik
CU-01	+75.0%	❌ Naik drastis

Dua task (DB-01, CU-06) menunjukkan kemenangan telak — OMNI bantu agent nemuin jawaban lebih cepat dengan churn yang lebih sedikit. Tiga task lainnya malah sebaliknya, gara-gara lintasannya jadi jauh lebih panjang dan eksploratif.

Kenapa Bisa Beda? #

Task yang agent-nya sudah punya strategi jelas (misalnya debugging pola yang sudah dikenal di DB-01, atau memahami area kode yang spesifik di CU-06) dapet manfaat besar dari kompresi OMNI. Sebaliknya, pas agent ngerasa ragu atau gak yakin (CU-01, IM-02, IM-05), dia bakal makin sering cari-cari (search) — dan kompresi OMNI gak bisa nutupin biaya dari turns tambahan itu.

Apa yang Kita Tahu (dan Yang Belum Tahu) #

✅ Terbukti #

OMNI sangat efektif ngurangin context payload dari output tools.
Pada task tertentu (DB-01, CU-06), OMNI beneran bisa menghemat penggunaan token secara materiil.

❌ Belum Terbukti #

Pengurangan token total yang konsisten secara agregat di berbagai jenis beban kerja.
Perbaikan runtime yang stabil di bawah kondisi non-determinism yang tinggi.

Apa yang Bisa Kita Lakukan #

Lebih Intentional Soal Fase Kerja #

Data pilot ini menunjukkan pola yang cukup menarik: dampak OMNI ternyata berkorelasi dengan jenis beban kognitif yang sedang dilakukan oleh agent, bukan cuma sekadar kategori task-nya. Ini nyambung banget sama apa yang pernah saya tulis sebelumnya — pentingnya memisahkan fase eksplorasi, perencanaan (planning), dan eksekusi ke dalam thread yang berbeda (Evolusi Workflow Coding Agent).

Dulu, saya menyarankan prinsip “one thread, one objective” — memisahkan planning, eksekusi, dan eksplorasi di sesi yang berbeda. Data pilot OMNI sekarang memberikan bukti empiris kenapa hal ini krusial: alat yang membantu di satu fase bisa jadi malah menghambat di fase lainnya.

Pola Phase-Aware #

Mengambil inspirasi dari framework “Prompts are Code” milik Mario Zechner dan riset workflow coding yang terstruktur (pola Think-Plan-Execute), kita bisa memetakan perilaku OMNI ke dalam fase kognitif:

Fase	Apa yang Terjadi	OMNI?	Kenapa
Exploration	Agent memetakan codebase, mencari secara luas, mengikuti petunjuk baru	❌ OFF	Kompresi bisa menghilangkan sinyal-sinyal penting yang tidak terduga. Rasa penasaran butuh konteks mentah.
Planning	Agent merangkum temuan menjadi pendekatan yang terstruktur	⚡ OPTIONAL	Tergantung apakah rencananya padat konteks (sintesis git log → ON) atau konseptual (→ OFF).
Execution	Agent menerapkan perubahan dengan target yang jelas	✅ ON	Agent sudah tahu apa yang harus dilakukan — kompresi menghapus noise, mengurangi context pressure, dan menjaganya tetap fokus.

Data Memvalidasi Pola Ini #

Melihat hasil pilot melalui kacamata ini:

DB-01 (-52.5%): Debugging pola yang sudah dikenal — murni eksekusi. OMNI sangat membantu.
CU-06 (-28.6%): Merangkum riwayat git — eksekusi terstruktur dengan titik akhir yang jelas. OMNI sangat berguna.
CU-01 (+75.0%): “Cari dan jelaskan” — eksploratif, agent malah “jalan-jalan” ke mana-mana. OMNI mengompres input tapi agent malah kompensasi dengan melakukan search lebih banyak.

Polanya jelas: ketika agent tahu ke mana dia pergi, kompresi mempercepat prosesnya. Tapi ketika agent masih mencari tahu, kompresi justru bisa membatasi eksplorasi yang dibutuhkan untuk memahami masalah.

Rumus yang Diperluas #

Di artikel sebelumnya, saya mengusulkan rumus ini untuk coding dibantu AI yang efektif:

right task × right agent × right thread length × right prompt contract

Pilot OMNI menyarankan satu tambahan lagi:

right task × right agent × right thread length × right prompt contract × right phase configuration

Variabel terakhir itu — phase configuration — adalah tempat di mana middleware seperti OMNI berada. Bukan sebagai lapisan yang selalu nyala, tapi sebagai alat phase-aware yang beradaptasi dengan mode kognitif dari thread saat ini.

Implikasi Praktis #

Untuk pengembang tool: Buatlah middleware yang phase-aware. Deteksi kapan agent sedang dalam mode eksplorasi vs eksekusi (misalnya lewat pola tool call — frekuensi search/find yang tinggi = eksplorasi) dan nyalakan/matikan kompresi secara dinamis.
Untuk pengguna: Jadilah eksplisit soal fase dalam prompt dan manajemen sesi Anda. “Jelajahi codebase ini dan cari…” vs “Implementasikan X berdasarkan rencana ini…” memberikan sinyal mode kognitif yang berbeda. Ini bukan cuma soal strategi prompt — ini soal strategi konfigurasi tooling.
Untuk desain benchmark: Uji OMNI pada rangkaian task eksekusi dan eksplorasi secara terpisah. Metrik agregat seringkali menutupi perilaku yang bergantung pada fase ini. Hasil perbaikan agregat -8.1% di pilot saya menyembunyikan kemenangan -52.5% dan kekalahan +75.0%.

Gambaran Besarnya #

Workflow berbasis thread yang saya pelajari dari Amp bukan cuma soal menjaga konteks tetap bersih — itu adalah pengakuan implisit bahwa fase yang berbeda butuh lingkungan kognitif yang berbeda. Data OMNI memperjelas hal ini: middleware yang sama yang mempercepat eksekusi bisa menyabotase eksplorasi.

Ronde benchmark berikutnya harus menguji ini secara langsung: task yang sama, tapi dengan OMNI yang dinyalakan berdasarkan fase yang dideteksi. Itulah eksperimen yang bisa mengubah sinyal pilot ini menjadi sebuah prinsip desain.

Ngoprek Datanya Sendiri #

Seluruh data pilot dan analysis pipeline ini bersifat open source:

GitHub repo: wayanjimmy/omni-pilot
Data trace mentah (30 runs): traces/pilot.30runs.jsonl
Script analisis: scripts/analyze-pilot.py
Laporan lengkap (markdown): traces/pilot-report.md

Kalau mau coba repro secara lokal:

bash

git clone https://github.com/wayanjimmy/omni-pilot.git
cd omni-pilot
uv run python scripts/analyze-pilot.py traces/pilot.30runs.jsonl

Glosarium Istilah AI Coding #

Istilah-istilah yang dipakai di laporan ini yang mungkin bakal sering ditemui pas kerja sama coding agent. Kalau istilahnya punya entri yang cocok di Matt Pocock’s Dictionary of AI Coding, link-nya saya sertakan di atas.

Distillation (Distilasi): Mengompres output tool yang besar (seperti find, rg, git log) jadi representasi yang ringkas sebelum dimasukkan ke konteks agent. Ini mekanisme inti OMNI — kebalikan dari pass-through mentah.
Context pressure: Ukuran seberapa penuh context window dibandingkan kapasitasnya. Context pressure yang tinggi berarti sebagian besar window sudah terpakai, yang meningkatkan risiko penurunan atensi (model kehilangan fokus pada info awal). Di sini dihitung sebagai total input token dibagi ukuran context window model.
Middleware: Lapisan software yang mencegat dan mengubah data yang mengalir antar komponen. OMNI beroperasi sebagai transparent middleware di sini: dia duduk di antara tool calls milik agent dan request ke model provider, mengompres output tool tanpa sepengetahuan agent.
Agent trajectory: Jalur yang diambil agent melalui tool calls, turns, dan keputusan saat nyelesain task. Lintasan yang "stabil" nemuin jawaban dalam langkah sedikit; lintasan yang "eksploratif" melebar dengan lebih banyak search dan iterasi.
A/B pilot: Eksperimen terkontrol yang membandingkan dua kondisi (A = baseline, B = treatment) pada task yang identik. Di sini: 5 task dijalankan dengan dan tanpa OMNI, diulang 3 kali masing-masing buat kekuatan statistik.

Mau bikin chart sendiri dari data ini? Cek format JSON-nya di sini.