--- title: "Laporan OMNI Pilot: Apakah Kompresi Output Bikin Coding Agent Lebih Cepat?" description: "Saya sempat jalanin 30 tes terkontrol buat ngebuktiin apakah distilasi output dari OMNI beneran ngaruh ke performa coding agent. Spoiler: ya tergantung." publishedAt: 2026-05-14 locale: id urlSlug: omni-pilot-report isDraft: false defaultLocale: en --- [TOC] [OMNI](https://github.com/wayanjimmy/omni) adalah versi *fork* dari ekstensi OMNI milik Fajar Hidayat ([original](https://github.com/fajarhide/omni)) yang saya tambahkan implementasi OMNI extension untuk [Pi Coding Agent](https://pi.dev). Pilot ini dijalankan menggunakan tag [`v0.6.0-pi-alpha.2`](https://github.com/wayanjimmy/omni/releases/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](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Agent.md). 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](https://github.com/wayanjimmy/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](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Model.md): [`mimo-v2.5`](https://platform.xiaomimimo.com?ref=YTKZ66) (Xiaomi MiMo-V2.5) — jalan di [Xiaomi MiMo Open Platform](https://platform.xiaomimimo.com?ref=YTKZ66) (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](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/System%20prompt.md) yang sama digunakan untuk kedua kondisi.** Agent gak pernah dikasih tahu soal OMNI. Dia cuma punya akses ke [tools](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Tool.md) (`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](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Tool%20call.md) | 17.2 | 25.0 | **+45.3%** | | Search [tool calls](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Tool%20call.md) | 3.6 | 7.6 | **+111.1%** | | [Total tokens](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Token.md) | 296,246.9 | 338,010.2 | **+14.1%** | | [Input tokens](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Input%20tokens.md) | 27,702.5 | 19,005.4 | **-31.4%** | | Context pressure | 457.2 | 244.0 | **-46.6%** | | [Turns](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Turn.md) | 12.3 | 18.5 | **+49.8%** | ### Apa Arti Data Ini? 1. **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. 2. **Tapi lintasannya jadi lebih panjang.** Kondisi C2 memicu lebih banyak [turns](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Turn.md) (+49.8%) dan [tool calls](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Tool%20call.md) (+45.3%). Agent jadi lebih eksploratif — seolah-olah beban kognitif yang lebih rendah bikin dia merasa lebih bebas buat "jalan-jalan" cari info tambahan. 3. **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: ``` 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](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Turn.md) 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](https://github.com/mattpocock/dictionary-of-ai-coding/blob/main/dictionary/Non-determinism.md) 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](/id/posts/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 1. **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. 2. **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*. 3. **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`](https://github.com/wayanjimmy/omni-pilot) - **Data trace mentah (30 runs):** [`traces/pilot.30runs.jsonl`](https://github.com/wayanjimmy/omni-pilot/blob/main/traces/pilot.30runs.jsonl) - **Script analisis:** [`scripts/analyze-pilot.py`](https://github.com/wayanjimmy/omni-pilot/blob/main/scripts/analyze-pilot.py) - **Laporan lengkap (markdown):** [`traces/pilot-report.md`](https://github.com/wayanjimmy/omni-pilot/blob/main/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](https://github.com/mattpocock/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`](https://github.com/wayanjimmy/omni-pilot/blob/main/traces/pilot-report-data.json).*