Writer’s AI Ciptakan Efisiensi, Pangkas Pengeluaran Token Hampir 40% Tanpa Mengorbankan Akurasi

AI untuk perusahaan saat ini menghadapi paradoks dalam pengembalian investasi (ROI). Walaupun menambah komputasi pada model dasar yang kuat berjalan baik dalam eksperimen produk, biayanya menjadi sangat tinggi saat produk diterapkan di lapangan.

Sebuah penelitian baru yang dilakukan oleh para peneliti di Writer memberikan solusi yang bisa diakses oleh tim teknik. Studi ini menganalisis secara sistematis cara mengoptimalkan berbagai komponen dari lapisan orkestra yang melingkupi model dasar, atau yang dikenal sebagai AI harness.

Dengan mengoptimalkan harness, peneliti menunjukkan penurunan dramatis dalam token per tugas, penurunan biaya per tugas yang berhasil hingga 61 persen, dan kualitas tetap stabil, semua tanpa mengubah model dasar yang mendasarinya.

Karenanya, harness sepenuhnya berada di bawah kendali pengembang dan tidak memerlukan penyesuaian model, sehingga tim teknik dapat menerapkan temuan ini untuk membangun aplikasi AI yang sangat efisien dalam hal biaya.

Krisis ROI dari tokenmaxxing

Kondisi saat ini dalam teknik AI dibayangi oleh fenomena “tokenmaxxing,” suatu tren dalam industri di mana pengembang mengandalkan jendela konteks yang besar dan penggunaan token secara paksa sebagai pengganti desain sistem yang baik.

Alih-alih merancang alur kerja yang elegan, pengembang malah mengadopsi refleks dari pengembangan perangkat lunak tradisional: menghasilkan, menjalankan, gagal, menyuntikkan kesalahan dan lebih banyak konteks ke dalam jendela, kemudian mencoba lagi.

“Tim melakukan tokenmaxx karena ini adalah perbaikan termurah saat ini, dan karena memang begitulah cara sebagian besar insinyur bekerja hari ini,” ungkap Waseem AlShikh, CTO dan salah satu pendiri Writer. Karena pendekatan ini sering berhasil dalam tugas pengkodean, hal ini telah menjadi refleks default untuk setiap beban kerja. Bahayanya adalah penurunan harga per-token menutupi ketidakefisienan yang mendasarinya.

“Faktur Anda adalah token-per-tugas dikali harga-per-token, dan kebanyakan tim hanya memperhatikan angka kedua,” lanjut AlShikh. “Dalam beban kerja yang bersifat otonom, token-per-tugas terkumpul—setiap iterasi loop memperbaharui konteks yang semakin besar—dan ini terakumulasi lebih cepat dibandingkan turunnya harga. Pemotongan harga justru menjadi obat bius. Ini menutupi fakta bahwa loop itu sendiri mengalami kebocoran.”

Tokenmaxxing mengarah pada beberapa mode kegagalan perusahaan. Tim secara default mengarahkan tugas sederhana ke model frontier premium. Mereka menggunakan LLM sebagai indeks pencarian yang malas, mengisi jendela konteks dengan dokumen mentah daripada mengambil jawaban yang tepat. Yang paling merusak, mereka membangun loop otonom yang tidak terpengaruh yang bisa menjadi tidak terkendali saat model mengalami kesalahan. Karena output token jauh lebih mahal dibandingkan input token di semua penyedia model utama, pelaksanaan tugas yang tidak efisien berfungsi sebagai pembunuh anggaran yang diam-diam.

Industri ini sudah memperkenalkan berbagai teknik efisiensi untuk menekan biaya, tetapi upaya ini seringkali tidak berhasil karena mereka memperlakukan model secara terpisah:

• Pemadatan prompt memang mengurangi teks input untuk menghemat ruang, tetapi mengabaikan bagaimana sistem mengurutkan input tersebut dalam alur kerja yang kompleks.
• Penalaran berbasis anggaran membatasi langkah komputasi yang bisa diambil oleh model, yang seringkali menurunkan kualitas output jika alur kerja tidak diarahkan dengan cerdas.
• Pemrograman singkat memaksa model untuk mengeluarkan kode minimal untuk menghemat output token, tetapi tidak menyelesaikan masalah panggilan alat yang tidak efisien.
• Decoding spekulatif menggunakan model draft yang lebih kecil untuk mempercepat generasi teks model yang lebih besar, mengoptimalkan kecepatan inferensi sambil gagal menangani arsitektur agen yang bengkak.

Semua upaya ini gagal karena mereka mengoptimalkan mesin sambil mengabaikan transmisi. Mereka tidak melihat lapisan orkestra, yang meninggalkan ketidakefisienan arsitektur yang mendasarinya tidak terselesaikan.

Membongkar harness: pengungkit efisiensi

Harness adalah lapisan orkestra yang mengarahkan, memformat, dan mengubah LLM yang mendasari menjadi sistem yang dapat berfungsi.

Pengungkit inti dari optimisasi harness mencakup caching prompt sistem, kompresi riwayat interaksi, manajemen alat, strategi penarikan, dan manajemen kesalahan. Ini adalah titik intervensi yang paling dapat diakses untuk tim teknik yang mencari cara untuk meningkatkan kinerja AI.

Seperti yang dicatat para peneliti Writer dalam studi tersebut: “Jika harness adalah lapisan yang menyusun panggilan model menjadi kerja, maka itu juga lapisan yang menentukan harga kerja.”

Sejarahnya, pengembang telah memperlakukan harness sebagai kode lem yang sekadar menghubungkan API ke antarmuka pengguna. Studi ini mengisyaratkan bahwa harness kini harus diperlakukan sebagai objek kelas satu: artefak perangkat lunak utama yang memerlukan pengujian, versi, dan desain yang ketat.

Untuk perusahaan, ini merubah keputusan “kepemilikan vs sewa”.

“Perusahaan menghabiskan waktu berbulan-bulan dalam evaluasi model, lalu menyewa orkestrasi mereka dari rak — yang berarti mereka mengoptimalkan pengungkit yang lebih kecil dan mengalihkan pengganda yang lebih besar,” ungkap AlShikh. “Siapa pun yang memiliki harness memiliki ekonomi unit Anda, dan kerangka terbuka yang disetel untuk demo tidak disesuaikan untuk faktur Anda.”

Eksperimen di dalamnya

Untuk memisahkan dampak dari lapisan orkestra, para peneliti menjalankan eksperimen pada enam model dasar yang mencakup berbagai vendor dan kelas berat: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, dan model milik Writer, Palmyra X6.

Eksperimen mereka membandingkan loop agen produksi konvensional yang dibekukan dengan Harness Writer yang sudah selesai pada 22 tugas perusahaan yang terkunci, mencakup kemampuan seperti grounding dan retrieval, alur kerja multi-langkah, penggunaan alat, dan generasi konten. Dengan menjaga model dan tugas tetap konstan, mereka bisa memisahkan efek dari lapisan orkestra itu sendiri.

Harness yang dioptimalkan menghasilkan penurunan biaya yang signifikan, memotong biaya campuran per tugas sebesar 41 persen, dari 21 sen menjadi 12 sen. Ini terutama dicapai dengan memangkas penggunaan token, di mana jumlah token per tugas turun 38 persen, dari 14.2k menjadi 8.8k.

Harness dirancang untuk mendelegasikan tugas seperti pencarian kepada sub-agen khusus. Sub-agen hanya menerima alat dan kueri tertentu yang dibutuhkan, mengambil data yang tepat, dan mengembalikan ringkasan bersih yang terbatas kepada agen utama — menjaga jendela konteks utama agar tidak terisi dengan hasil pencarian mentah.

Rasio keberhasilan tugas tetap stabil meskipun penggunaan token menurun — bergerak dari 78 persen menjadi 81 persen, peningkatan yang dijelaskan para peneliti sebagai bersifat arah ketimbang signifikan secara statistik pada ukuran sampel mereka, artinya kualitas tidak terganggu walau biaya menurun.

Latency tugas end-to-end juga turun secara signifikan, mengurangi waktu rata-rata dinding sebesar 44 persen, dari 48 detik menjadi 27 detik, berkat caching prompt dan penghapusan loop penalaran yang tidak produktif.

Namun, peneliti juga menemukan batasan dari orkestrasi multi-agen. Model-model yang lebih kecil seperti Gemini Flash 3.5 dan Qwen 3.6 mencetak nilai jauh di bawah ambang batas keandalan yang dapat digunakan pada tugas delegasi sub-agen (0.45 dan 0.42, masing-masing) — kemampuan ini memang belum dapat diandalkan pada model-model ringan. Orkestrasi sub-agen hanya melewati ambang batas keandalan yang dapat digunakan pada dua model terkuat yang diuji: Palmyra X6 milik Writer (0.86) dan Claude Sonnet 4.6 (0.85).

Playbook pengembang: langkah tindakan dan pertimbangan

Temuan dari studi ini diterjemahkan menjadi playbook untuk pengembang perusahaan yang membangun alur kerja otonom secara besar-besaran. Langkah pertama adalah menerapkan apa yang AlShikh sebut sebagai “Prompt Dua Zona” dan “Pengalihan Konteks.”

Struktur untuk caching prompt sistem (Prompt Dua Zona): API LLM modern menawarkan caching prompt, tetapi pengembang harus menyusun payload mereka dengan benar untuk mengaktifkan fitur ini. Pengembang harus memisahkan “zona stabil” dari “zona fluktuatif.” Tempatkan elemen-elemen statis yang tidak berubah (misalnya, aturan inti, skema alat yang besar, dan prosedur operasi standar) di bagian atas prompt. Elemen dinamis, seperti kueri pengguna spesifik atau status tugas percakapan terbaru, harus ditambahkan di bagian bawah. Pengurutan ini memungkinkan harness untuk menggunakan kembali prefiks yang di-cache di seluruh serangkaian panggilan. “Pemisahan ini membuat caching prompt bekerja dan mencegah Anda membayar kembali untuk instruksi yang sama pada setiap langkah agen yang sama,” ungkap AlShikh.

Kelola konteks dengan Pengalihan Konteks: Hindari pengisian konteks, di mana setiap putaran loop ditambahkan ke dalam prompt monolitik sampai mencapai maksimum. Sebaliknya, pindahkan riwayat dan artefak antara ke penyimpanan yang dapat diambil, dan ambil hanya apa yang dibutuhkan dalam langkah saat ini. Jika memungkinkan, delegasikan tugas kepada sub-agen berorientasi tunggal untuk menghindari pembengkakan konteks. Seperti yang dikatakan AlShikh, “item terbesar dalam pengeluaran agen bukanlah penalaran — tetapi mengirim ulang hal-hal yang telah dilihat model sebelumnya.”

Membangun loop yang tangguh dan mendefinisikan KPI: Loop agen yang tidak terkelola cepat menguras anggaran API. Tim harus mulai melacak Penyelesaian Per Juta token (CPM) untuk memahami biaya tugas mereka yang sebenarnya, tetapi harness itu sendiri harus memiliki pengaman fisik. “Prinsip inti adalah Anda tidak boleh meminta model untuk mengawasi pengeluarannya sendiri,” ungkap AlShikh. “Pagarnya harus ada di bawah model, dalam kode, di sisi Anda dari API.” Ini memerlukan tiga pemeriksaan ketat:

• Anggaran per tugas token yang ketat: Proses berhenti ketika anggaran habis, tanpa pengecualian.
• Pembatasan produksi: Pembatasan pada langkah, panggilan alat, dan kedalaman rekursi untuk menghentikan agen yang tidak konvergen.
• Pemerintahan pengeluaran kegagalan: Pembatasan apa yang bisa dihabiskan dalam eksekusi setelah validasi pertama yang gagal agar tugas yang gagal tidak menjadi yang termahal.

Hindari kompleksitas yang tidak perlu: Mengoptimalkan lapisan orkestra memang membawa beban teknik. Jika Anda berada dalam tahap prototyping dan eksplorasi, beban tersebut tidak dibenarkan — iterasi dengan cepat menggunakan model yang kuat dan harness ringan. Setelah Anda mulai meningkatkan hingga jutaan permintaan per hari, penghematan dari optimisasi harness menjadi signifikan.

Namun, tim juga harus menyadari “leverage harness”. Menambah kerangka struktural memerlukan model untuk menahan dan mematuhi konteks tersebut. Jika model terlalu kecil, maka akan menghabiskan kapasitasnya yang terbatas untuk memproses kerangka tersebut daripada menjalankan tugas, yang menyebabkan penurunan akurasi dan penggunaan token yang meningkat. Aturan menambah fitur orkestra yang kompleks adalah matematis: “Jika suatu fitur menambah lebih banyak token koordinasi daripada yang dihapus token tugas untuk model spesifik itu, buang,” tegas AlShikh. “Tidak ada yang gratis di dalam harness.”

Masa depan harness perusahaan

Era tokenmaxxing dan memperlakukan jendela konteks sebagai ember yang tidak ada batasnya akan segera berakhir. Mengandalkan lebih banyak komputasi pada sistem yang dirancang buruk bukanlah strategi yang layak bagi perusahaan yang perlu menunjukkan pengembalian dari investasi AI mereka.

Seiring model dasar berkembang untuk menyerap perencanaan, pemilihan alat, dan penalaran multi-langkah ke dalam bobotnya, peran harness akan beralih dari mengompensasi kelemahan model menjadi menegakkan kebijakan perusahaan.

“Apa pun yang tidak bergerak ke dalam model adalah ‘yang diizinkan’: anggaran, izin, batas data, jejak audit, dan sakelar pemutus deterministik,” kata AlShikh. “Lima tahun ke depan, harness akan lebih ramping tetapi lebih penting. Akan ada lebih sedikit kerangka dan lebih banyak pengawasan. Meskipun model menjadi sangat kapabel, seseorang yang berada di luar model tetap harus menentukan apa yang bisa dibelanjakan, dilihat, dan disentuh. Lapisan tersebut adalah milik perusahaan, dan seharusnya tidak pernah disewa.”