Hasil Browser-Agent 76x GPT-6.1 Sol: Apa yang Sebenarnya Diukur oleh Asana

Asana menerbitkan studi biaya agen browser pada 8 Oktober 2026, dan pengembang GPT-6.1 Sol menuliskannya keesokan harinya dengan judul "Asana memangkas biaya model 76x dalam uji browser dengan GPT-6.1 Sol." Angka 76x itu nyata dalam arti seseorang mengukurnya, tetapi itu bukan fakta tentang harga GPT-6.1 Sol. Itu adalah fakta tentang apa yang terjadi ketika Anda memperbaiki cache prompt yang rusak pada agen browser lalu menukar model yang berada di baliknya. Optimasi yang sama, dijalankan pada model yang sudah digunakan Asana di produksi — model yang disebutnya Model B — memangkas biaya 29x dengan sendirinya. GPT-6.1 Sol menyumbang 2,6x sisanya. Eksperimennya dijalankan oleh GPT-6 Astra yang bekerja di Codex, dan model di balik baseline adalah model pesaing yang disebut Asana sebagai Model B, jadi dua tier dari vendor yang sama dan satu pesaing tanpa nama semuanya muncul dalam cerita ini. Berikut ini memisahkan bagian hasil yang dapat Anda salin pada hari Senin dari bagian yang menjadi milik stack khusus Asana.

Perbandingan, dinyatakan persis

Stack Asana untuk ini adalah StackAI, platform otomatisasi alur kerja yang diakuisisinya, yang menjalankan agen peramban yang menavigasi situs web, mengisi formulir, dan mengumpulkan informasi tanpa kode. Tugas pengujiannya sempit dan konkret: kumpulkan enam bidang untuk masing-masing dari 32 buku dari katalog demo publik. Itu mewakili apa yang dijalankan sebagian pelanggan, dan juga cukup kecil sehingga studi dengan 144 eksekusi dapat diselesaikan dalam satu minggu.

Desainnya adalah enam kebijakan caching dan screenshot pada dua anggaran riwayat, tiga percobaan per kondisi, di empat model — 144 percobaan, ditambah tindak lanjut 12 percobaan. Biaya dihitung dari penghitung token milik masing-masing penyedia, dan setiap jawaban dinilai terhadap referensi yang disiapkan secara independen. Keempat model itu adalah tiga model frontier tanpa nama (Model A, B, dan C) dan GPT-6.1 Sol. Model A adalah model yang lebih kecil dan lebih murah dari laboratorium lain, dirilis musim gugur 2025, dengan harga setengah dari GPT-6.1 Sol. Model B adalah model yang digunakan dalam produksi, berasal dari laboratorium yang sama dengan A, dirilis musim panas 2026, dengan harga yang sama dengan GPT-6.1 Sol. Model C adalah versi yang lebih baru dari Model B, dirilis musim gugur 2026, juga dengan harga yang sama dengan GPT-6.1 Sol. Ketiganya tidak disebutkan namanya di kedua tulisan, sehingga perbandingannya tidak dapat direproduksi oleh pembaca — layak diketahui sebelum Anda menganggap 29x sebagai angka tentang model orang lain. Ini adalah angka yang dipublikasikan oleh Asana dan OpenAI, bukan angka yang diaudit secara independen.

Tangga hasil, semuanya angka Asana sendiri:

• Produksi baseline pada Model B — setidaknya $36,21 per proses, setidaknya 22,5 menit per proses. Beberapa proses baseline mencapai batas langkah sebelum selesai, sehingga nilai rata-ratanya adalah batas bawah, bukan rata-rata yang sebenarnya.

• Model B, agen yang dioptimalkan — $1,24 per eksekusi, 4x lebih cepat dari baseline, pemotongan biaya 29x.

• GPT-6.1 Sol, agen yang dioptimalkan sama — $0,47 per proses, sekitar empat menit, pemotongan biaya 76x dan 5x lebih cepat.

• GPT-6.1 Sol, sebelum vs setelah perbaikan — $1.97 menjadi $0.47 per eksekusi, pengurangan 4x hanya dari perubahan cache dan pruning.

Karena baseline adalah batas bawah, 76x sendiri merupakan nilai terendah. Pembacaan yang jujur adalah "setidaknya 76x," bukan "76x."

Apa yang sebenarnya berubah, dan mengapa ini bukan fitur model

Mekanismenya adalah mekanika cache prompt, dan ini layak dipahami karena berlaku untuk agen apa pun yang Anda jalankan di model apa pun. Agen browser mengirim ulang alatnya, prompt sistemnya, dan riwayat teks halaman serta tangkapan layar yang terus bertambah pada setiap panggilan model. Caching prompt memberi diskon untuk bagian yang berulang, tetapi hanya pada prefiks terpanjang yang tidak berubah — begitu ada sesuatu di tengah permintaan berubah, penggunaan ulang terputus sejak titik itu.

Agen produksi Asana memiliki dua kesalahan yang saling memperburuk. Agen itu menyimpan cache untuk instruksi tetap dan definisi alatnya, tetapi tidak untuk riwayat penjelajahannya. Dan agen itu mengedit riwayat tersebut pada hampir setiap langkah: ia membuang tangkapan layar sebelumnya setiap kali dan memangkas teks yang lebih lama agar sesuai dengan anggaran riwayat. Setiap pengeditan membatalkan prefiks, sehingga cache nyaris tidak berguna bahkan jika cache diaktifkan. Catatan Asana menyebutkan bahwa pada model yang diuji, pembacaan cache berbiaya 0,05x hingga 0,1x harga input standar — jadi imbalannya besar dan agen itu secara sistematis menolaknya.

Perbaikannya terdiri dari dua bagian. Pertama, cache juga riwayatnya, dengan penanda cache pada hasil tool terbaru. Kedua, berhenti mengeditnya setiap panggilan: simpan screenshot dan pangkas secara batch dengan rasio 20 banding 1, sehingga agen menampung hingga 20 lalu memangkasnya kembali ke yang paling baru. Sekitar 19 panggilan berturut-turut kemudian menggunakan kembali prefiks yang tidak berubah. Naikkan anggaran riwayat dari 120.000 menjadi 480.000 karakter agar teks lama tidak lagi dipangkas, dan hitungannya pun sesuai: pada GPT-6.1 Sol, biaya setiap panggilan kurang lebih 3x lebih murah karena 89% input berasal dari cache.

Temuan yang paling penting di sini adalah temuan negatif. Meng-cache riwayat tanpa pemangkasan batch, pada anggaran yang lebih besar, biayanya lebih mahal daripada tidak melakukan cache sama sekali pada tiga dari empat model — cache terus-menerus ditulis ulang dan jarang dibaca. Infrastruktur cache yang diaktifkan tanpa disiplin riwayat append-only adalah cara membayar premi tulis tanpa hasil. Mode kegagalan itu tidak bergantung pada model, dan itulah alasan perbaikan yang sama menggerakkan Model B sebesar 29x.

Di mana pilihan model benar-benar membuahkan hasil

Keluarkan perbaikan alur kerja dan bandingkan hal yang setara dengan yang setara: pada agen yang sama yang telah dioptimalkan, GPT-6.1 Sol berjalan 2,6x lebih murah daripada Model B, pada harga terdaftar yang sama. Faktor tambahannya adalah perilaku cache hit, bukan kartu tarif. Sol membaca 89% inputnya dari cache; Asana tidak menerbitkan proporsi yang setara untuk Model B, jadi 2,6x itu adalah hasil terukur tanpa pemecahan yang dipublikasikan. Anggap itu sebagai "model ini, pada beban kerja ini, menggunakan cache-nya lebih baik," bukan sebagai keunggulan 2,6x secara umum atas model yang tidak dapat kami sebutkan namanya.

Sisi runtime tidak ambigu: 5x lebih cepat daripada baseline, dengan alur kerja Sol yang dioptimalkan sekitar empat menit dibandingkan baseline setidaknya 22,5 menit. Kecepatan berpengaruh pada biaya dalam agen yang menagih berdasarkan token, karena model lambat yang melakukan loop membayar untuk loop-nya.

Bagi siapa pun yang menghitung biayanya: tarif API standar GPT-6.1 Sol adalah $2,00 per juta token input, $0,10 per juta token input yang di-cache, dan $10,00 per juta token output, dan diskon pembacaan cache-nya adalah 0,05x tarif input — yang paling dalam di kartu harga OpenAI saat ini. GPT-6 Astra, model yang melakukan pekerjaan rekayasa di Codex, dikenakan biaya $10,00 untuk input dan $50,00 untuk output, yakni selisih lima kali lipat yang menjadi andalan narasi peluncuran OpenAI. Alasan studi tersebut menghasilkan eksekusi $0,47 alih-alih $2 per eksekusi bukanlah kartu tarifnya; melainkan karena 89% dari permintaan yang sangat repetitif ditagih sebesar seperdua puluh dari tarif input. Pada agen yang berat caching, baris diskon lebih berperan daripada harga utamanya, dan pada katalog kami sendiri harga daftar penyedia diteruskan dengan markup 0%, jadi vendor yang mengubah meteran input yang di-cache akan mengubahnya di tagihan Anda pada hari yang sama.

Angka lain dalam studi ini: anggaran riwayat menentukan apakah agen itu menjawab sama sekali

Biaya per proses adalah angka yang dikutip semua orang, tetapi hasil studi yang lebih berguna berkaitan dengan keandalan, dan itulah yang sebaiknya dibaca lebih dahulu oleh seorang operator.

• Pada anggaran 120.000 karakter, Model C tidak menjawab pada satu pun dari 18 percobaannya dan GPT-6.1 Sol menjawab pada 3 dari 18 — sebagian besar percobaan mencapai batas langkah tanpa menghasilkan jawaban.

• Pada 480.000 karakter, setiap eksekusi pada kedua model menjawab, masing-masing dengan jawaban yang benar.

• Model yang lebih baru menghabiskan anggaran yang lebih kecil lebih cepat: Model C pertama kali memangkas riwayatnya pada panggilan 10, Model A pada panggilan 64.

• Dalam alur kerja yang dioptimalkan, setiap eksekusi menyelesaikan tugas dan mengembalikan jawaban yang benar, serta setiap eksekusi pada kondisi terbaik di setiap model menjumpai semua fakta yang seharusnya dikumpulkannya.

Itu argumen yang berbeda dari "lebih murah." Anggaran riwayat yang terlalu kecil pada model yang cakap menghasilkan agen yang gagal karena kehabisan ruang, dan gagal karena mencapai batas langkah, yang merupakan cara paling mahal untuk gagal — Anda membayar untuk seluruh proses dan tidak mendapatkan apa pun. Menaikkan anggaran menaikkan biaya per panggilan dan menurunkan biaya per jawaban, yang merupakan satu-satunya angka yang harus dilacak oleh pemilik produksi. Jika Anda mengevaluasi model yang belum terbukti untuk agen seperti ini, pola berisiko rendah adalah menjaga rute produksi Anda pada model yang Anda percayai dan menempatkan model baru di balik failover atau rute terpisah, sehingga kegagalan batas langkah muncul sebagai fakta perutean alih-alih insiden. Setiap model dalam perbandingan ini dapat diakses melalui satu API untuk 200+ model dengan harga daftar penyedia diteruskan tanpa perubahan, yang juga membuat diskon baca cache dapat dibandingkan antar vendor pada invoice yang sama alih-alih lima dasbor.

Apa yang harus diambil dari ini, secara berurutan

Jika Anda menjalankan browser atau agen penggunaan komputer, tiga tuas dalam studi Asana layak ditarik sebelum Anda melihat kartu tarif:

• Buat prefiks permintaan bersifat hanya-menambah (append-only). Setiap penyuntingan per panggilan di bagian tengah riwayat akan meniadakan penggunaan ulang cache mulai dari titik itu dan seterusnya.

• Pangkas dalam batch. Tindak lanjut Asana menemukan bahwa menyimpan setiap tangkapan layar memakan biaya 1,2x lebih sedikit per panggilan dibandingkan kondisi pemangkasan terbaik pada Model B dan GPT-6.1 Sol, dan sekitar 5% lebih sedikit pada Model C. Pemangkasan tetap penting untuk tugas panjang, jendela konteks kecil, dan pembacaan cache yang mahal — tetapi alasan untuk rasio batch 20:1 adalah tentang stabilitas cache, bukan tentang tangkapan layar itu sendiri.

• Tetapkan anggaran riwayat per model, lalu periksa kesesuaiannya dengan batas langkah Anda. Anggaran yang cukup untuk satu model bisa membuat model berikutnya kekurangan.

Dua guardrail dari studi ini mudah untuk dilewatkan, dan seharusnya tidak. Tidak ada run yang mencapai anggaran 480.000 karakter, jadi anggaran itu tidak pernah membatasi run-run ini — tetapi agen yang melenceng akan tumbuh mendekati batas konteksnya, dan jika cache rusak, setiap panggilan membayar harga penuh. Batas maksimum pada langkah, token, dan biaya per run itulah yang membatasi run yang buruk. Secara terpisah, studi ini menggunakan tiga atau empat run per kondisi dengan jumlah panggilan yang bervariasi, yang menurut Asana sendiri cukup untuk menunjukkan pola-pola yang luas dan tidak cukup untuk memisahkan kondisi yang terpaut beberapa persen. Jangan membaca delta 5% dari ini lalu membangun ulang pipeline Anda berdasarkan itu.

Bagian yang benar-benar baru, dan bagian yang tidak

Kaveat pada penyiapan ini layak dinyatakan secara gamblang: empat model, tiga di antaranya tanpa nama, satu tugas sempit dengan 32 buku, penghitung terinstrumentasi milik Asana sendiri, dan tulisan vendor sendiri yang memuat hasilnya. Tidak ada apa pun di sini yang telah direproduksi di luar Asana. Namun mekanismenya dijelaskan sepenuhnya — riwayat append-only, penanda cache pada hasil alat terakhir, pemangkasan batch, anggaran lebih besar, pengukuran pembacaan cache dengan penghitung penyedia — dan ini adalah jenis temuan yang tetap bertahan ketika diatribusikan ke lab yang salah. Angka 76x adalah angka Asana pada beban kerja Asana. Alasan ini layak dibaca adalah bahwa ini menunjukkan aturan yang dapat Anda uji dalam satu sore: agen yang mengedit riwayatnya sendiri pada setiap langkah sedang membayar harga penuh untuk percakapan yang sudah pernah dilakukannya.