Proses Memigrasikan Agen AI Produksi ke GPT-5.6 hingga 2,2x Lebih Cepat dan 27% Lebih Murah

 (ploy.ai)
1 poin oleh GN⁺ 7 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Ploy memigrasikan agen yang merencanakan, membangun, dan memvalidasi situs web marketing produksi dari Claude Opus 4.8 ke GPT-5.6 Sol, lalu menetapkannya sebagai model default untuk semua workspace
  • Setelah memperbaiki asumsi per model dalam evaluation harness, pada tugas membangun ulang homepage, rata-rata waktu eksekusi turun dari 8 menit menjadi 3 menit 42 detik, biaya turun 27% dari $3.06 menjadi $2.22, dan skor visual juga naik menjadi 0.970
  • GPT-5.6 mengisi semua 25 parameter opsional dalam pemanggilan tool dengan nilai arbitrer, sehingga 52–64% pembacaan file mengembalikan hasil kosong. Namun setelah field opsional diubah menjadi wajib dan nullable, pembacaan kosong turun menjadi 0% dan pemanggilan tool juga berkurang sekitar 30%
  • Karena perbedaan cakupan cache dan struktur throughput antara OpenAI dan Anthropic, GPT-5.6 awalnya terukur sekitar 50% lebih mahal. Namun dengan menerapkan cache key per workspace dan breakpoint per lapisan, hit rate pada panggilan pertama naik dari 0% menjadi 83,7% dan token input tanpa cache berkurang 28%
  • Biaya dan performa penggantian model tidak hanya bergantung pada model itu sendiri, tetapi juga pada anggaran evaluasi, skema tool, struktur cache, dan cara replay reasoning. Karena itu, untuk mendapatkan perbandingan yang tepercaya dan operasi yang stabil, asumsi spesifik provider yang sudah disesuaikan dengan model lama perlu ditemukan dan diperbaiki terlebih dahulu

GPT-5.6 Sol yang Menggantikan Claude Opus

  • Agen Ploy merencanakan halaman untuk situs web marketing produksi, membaca codebase, menghasilkan komponen dan gambar, memeriksa hasilnya melalui screenshot, lalu menentukan apakah pekerjaan sudah selesai
  • Selama beberapa bulan, tidak ada model yang memenuhi kriteria untuk menggantikan Claude Opus, dan model default dipertahankan selama 4 bulan berturut-turut sebagai Opus 4.7 lalu 4.8
  • GPT-5.6 Sol menjadi model pertama yang mengungguli Opus dalam evaluasi head-to-head pada tugas yang sama, dan menjadi model default untuk semua workspace Ploy
  • Bahkan dalam evaluasi awal, waktu eksekusi untuk build yang selesai kurang dari separuh, biayanya 27% lebih rendah, dan skornya sama atau lebih tinggi dibanding model lama, sehingga menjadi dasar untuk melakukan migrasi
  • Ploy menggunakan Vercel AI SDK, tetapi selama proses pergantian model, mereka menemukan bahwa asumsi spesifik provider terkait penyusunan argumen tool, prompt caching, dan replay reasoning antar-turn masih tersisa di seluruh stack
  • Migrasi dilakukan dengan memperbaiki evaluation harness, skema tool, prompt caching, lalu replay reasoning, secara berurutan

Perbaiki Harness Sebelum Memercayai Angka Evaluasi

  • Rangkaian evaluasi menjalankan agen produksi di workspace pengujian tetap, mencakup ratusan kasus mulai dari membangun homepage dari nol hingga menilai apakah permintaan penyalinan dapat dijalankan dengan aman
  • Pada kasus build, penilai visual melakukan 10 pemeriksaan biner dengan membandingkan hasil terhadap desain acuan
    • Memeriksa apakah area hero berupa adegan foto yang memenuhi seluruh lebar layar
    • Memastikan CTA utama berbentuk persegi panjang bersudut membulat, bukan berbentuk pill
  • Pemeriksaan konten, pemeriksaan jalur eksekusi tool, dan asersi file juga dilakukan; saat gagal, jejak eksekusi lengkap yang mencakup pemanggilan tool dan teks model ditinjau

  • Batasan yang Disesuaikan dengan Cara Pemanggilan Model Lama

    • Anggaran pemanggilan tool yang lama disesuaikan dengan cara Opus memanggil secara sekuensial, tetapi GPT-5.6 menggunakan pemanggilan paralel sehingga melewati anggaran bahkan pada kasus yang diselesaikan dengan benar
    • Runner evaluasi tidak mendukung pembacaan file batch, yang hampir tidak pernah digunakan Opus tetapi sering digunakan GPT-5.6
    • Sekitar sepertiga kegagalan mentah pada run pertama berasal dari asumsi harness, bukan perilaku model, dan distribusinya juga tidak merata antar model
    • Jika jejak eksekusi model penantang dan model lama tidak diklasifikasikan terlebih dahulu, evaluasi akan makin menguntungkan model baru ketika ia makin mirip perilaku model lama

  • Ambang Skor Implisit

    • Dataset yang tidak memiliki minScore mewarisi nilai default 1.0 tanpa peringatan apa pun
    • Akibatnya, GPT-5.6 diperlakukan gagal meski mendapat skor hero 0.98, dan Opus juga dinilai gagal pada kasus yang lulus semua pemeriksaan individual
    • Kedua hasil tersebut merupakan desain yang dapat dipertanggungjawabkan, tetapi tersingkir karena ambang implisit, bukan karena modelnya

Hasil Benchmark yang Sudah Diperbaiki

  • Setelah memperbaiki harness, Ploy menjalankan ulang rangkaian evaluasi untuk membangun ulang homepage brand agar sesuai dengan desain acuan
Rata-rata per build selesai Claude Opus 4.8 (n=11) GPT-5.6 (n=10)
Biaya $3.06 $2.22
Waktu eksekusi 8 menit 00 detik 3 menit 42 detik
Token input 2,6 juta 1,7 juta
Token output 33.000 17.100
Skor visual 0.936 0.970
  • GPT-5.6 menyelesaikan halaman 2,2x lebih cepat, dengan biaya 27% lebih rendah, serta menggunakan token output sekitar separuhnya
  • Jumlah kode yang dihasilkan juga lebih sedikit
    • Dalam satu pasangan kasus perbandingan, Opus menghasilkan 174 variabel CSS dan globals.css sepanjang 17.957 karakter, termasuk sebagian besar kelompok warna yang tidak digunakan
    • GPT-5.6 menggunakan 45 variabel CSS dan 2.508 karakter, tetapi menghasilkan rendering yang serupa atau lebih baik

  • Kualitas dan Konsistensi Desain

    • GPT-5.6 kuat dalam layout yang bersih dengan grid rapat, tetapi cenderung konvergen ke gaya tersebut jika tidak diarahkan dengan kuat
    • Pada harness lama yang dirancang untuk Opus 4.8, model ini sering menghasilkan hasil yang bersih tetapi biasa saja sambil mengabaikan sistem desain yang ada
    • Setelah tim desain dan engineering memperbaiki cara mengarahkan model, hasilnya memenuhi standar kepatuhan brand yang diperlukan untuk produksi

Penanganan Parameter Opsional dalam Pemanggilan Tool

  • Tool code milik agen memiliki 25 parameter tingkat atas; hanya action yang wajib, sedangkan sisanya opsional
  • Claude hanya mengirim 2–3 parameter yang digunakan, tetapi GPT-5.6 mengirim semua 25 parameter pada setiap panggilan, dan mengisi field yang tidak digunakan dengan nilai yang tampak masuk akal seperti offset: 0, timeout: 120000, siteId: "00000000-0000-0000-0000-000000000000"
  • Pola yang sama muncul dalam jejak eksekusi code(read) produksi yang dikumpulkan selama 3 hari
Model Jumlah panggilan Panggilan yang menyertakan semua 25 properti
gpt-5.6 6.635 6.635 panggilan, 100%
claude-opus-4.8 2.898 4 panggilan, 0,1%
claude-sonnet-5 1.933 0 panggilan

  • Penyebab Terjadinya Pembacaan File Kosong

    • Masalahnya bukan sekadar argumen yang verbose, tetapi implementasi pembacaan file tidak dapat membedakan nilai yang dibuat model secara arbitrer dari nilai yang dimaksud pengguna
    • Implementasi memperlakukan offset: 0 sebagai argumen nyata, dan 52–64% pembacaan file oleh GPT-5.6 mengembalikan hasil kosong
    • Tool mengembalikan success: true baik untuk pembacaan valid maupun pembacaan kosong, sehingga model tidak dapat mengetahui bahwa ia sedang membaca file kosong
    • Untuk mengompensasi hasil kosong, model melakukan lebih banyak panggilan, dan kualitas hasil ikut memburuk

  • Masalah yang Tidak Selesai dengan Prompt dan Strict Mode

    • Meski deskripsi tool diberi instruksi untuk menghilangkan parameter yang tidak digunakan, semua 25 parameter tetap dihasilkan
    • Menambahkan OPTIONAL, omit if unused pada tiap properti juga tidak mengubah perilaku
    • Hasil yang sama terjadi pada mode strict OpenAI, dan untuk mengadopsinya, semua skema harus menghapus pattern, format, serta validasi ukuran array
    • Karena perilaku ini berasal dari cara model menghasilkan function calling, skema diubah alih-alih prompt

  • Transformasi Skema di Batas Provider

    • Untuk model keluarga OpenAI, semua properti opsional ditulis ulang menjadi properti wajib dan nullable dalam bentuk anyOf: [T, null]
    • Model mengisi parameter yang tidak digunakan dengan null eksplisit, lalu null dihapus sebelum validasi di batas pemanggilan tool bersama
    • Implementasi tool tidak diubah; hanya skema untuk model yang dibuat mampu mengekspresikan nilai yang tidak digunakan
    // Sebelum perubahan: semua 25 key diisi dengan nilai arbitrer
{ "action": "read", "file_paths": ["..."], "offset": 0, "timeout": 120000 }

// Setelah perubahan: mengirim 4 nilai nyata dan 21 null, lalu null dihapus sebelum eksekusi tool
{ "action": "read", "file_paths": ["..."], "offset": null, "timeout": null }
    • Setelah perubahan, pembacaan file kosong turun dari 52% menjadi 0%
    • Jumlah pemanggilan tool yang dibutuhkan untuk tugas yang sama juga berkurang sekitar 30%, karena perilaku membaca hasil kosong berulang kali hilang

Prompt Caching yang Disesuaikan dengan Cara OpenAI

  • Kedua provider menyediakan prompt caching, tetapi cara implementasinya berbeda
  • Sebelum perbedaan ini diperhitungkan, GPT-5.6 tampak sekitar 50% lebih mahal daripada Opus, tetapi penyebabnya adalah konfigurasi cache, bukan harga model

  • Cache Tingkat Organisasi Anthropic

    • Prompt agen dimulai dengan prefiks statis sekitar 29.000 token yang terdiri dari skema tool dan prompt sistem inti, dan sama di semua percakapan
    • Di Claude, breakpoint cache ditandai dengan cache_control, dan prefiks dibagikan di seluruh organisasi
    • Percakapan dari workspace mana pun dapat menggunakan satu item bersama, dan tidak ada batas throughput per key
    • Hit rate cache berada di 92–96%

  • Perilaku Cache yang Berubah di GPT-5.6

    • Model GPT sebelumnya secara implisit melakukan cache pada kecocokan prefiks parsial, tetapi GPT-5.6 menghapus kecocokan prefiks parsial
    • Cache implisit membuat item prompt lengkap berdasarkan pesan terbaru, sehingga percakapan baru yang membagikan prefiks statis 29.000 token yang sama pun memiliki hit rate cache 0% pada panggilan pertama
    • Akibatnya, seluruh prefiks ditagih ulang sebagai biaya tanpa cache untuk setiap percakapan
    • Terlepas dari apakah aplikasi menggunakan cache atau tidak, GPT-5.6 menerapkan biaya tambahan penulisan cache 1,25x pada semua prompt tanpa cache

  • Batasan Cache Key Eksplisit

    • Caching eksplisit memerlukan prompt_cache_breakpoint dan prompt_cache_key wajib
    • Key juga menjadi bagian dari identitas cache, sehingga prompt yang sama tidak akan hit jika key-nya berbeda
    • Setiap key dipetakan ke node cache yang menangani sekitar 15 request per menit; jika melewati itu, OpenAI mendistribusikan traffic ke node lain dengan cold cache independen
    • Karena itu, menentukan unit untuk key menjadi keputusan desain utama
    • Key per percakapan: percakapan baru tidak dapat hit prefiks bersama, sehingga hit rate pada panggilan pertama 0%
    • Satu key global: semua request di-hash ke satu node, dan ketika traffic produksi melebihi 15 rpm, request melimpah ke node cold
    • Key per workspace: semua percakapan dalam workspace pelanggan berbagi item, sekaligus menjaga traffic per key tetap rendah

  • Cache Hierarkis per Workspace

    • Konfigurasi aktual menggunakan key per workspace dalam bentuk ws:{workspaceId} dan membagi prompt sistem menjadi lapisan breakpoint
    • Item A berisi tool dan prefiks statis untuk mengurangi biaya panggilan pertama dalam sesi
    • Item B menambahkan konteks workspace ke prefiks statis
    • Item C adalah rantai prompt lengkap per sesi dari turn pertama hingga pesan terbaru
    • Ketika memori workspace berubah, item B miss, tetapi item A tetap hit, sehingga yang ditulis ulang hanya ukuran konteks yang berubah, bukan seluruh 29.000 token
    • Item C memanfaatkan rantai prompt lengkap implisit OpenAI di dalam sesi, karena prompt memiliki struktur append-only yang ketat
    • Karena key partitioning OpenAI, prefiks statis tidak dapat dibagikan antar workspace
    • Sebaliknya, Anthropic menggunakan cache tingkat organisasi tanpa key partitioning, sehingga prefiks dapat dibagikan
    • Pada GPT-5.6, setiap workspace melakukan cold write 29.000 token sekali per periode idle, dengan biaya sekitar $0.18
    • Biaya ini cakupannya terbatas dan dapat diprediksi

  • Hasil Perbaikan Cache

    • Hit rate cache panggilan pertama naik dari sekitar 0% menjadi 83,7%
    • Total token input tanpa cache berkurang 28%
    • Biaya GPT-5.6 per rangkaian evaluasi menjadi lebih rendah daripada Opus, dan seluruh selisih biaya awal berasal dari konfigurasi cache yang salah
    • Perbandingan biaya antar model yang dilakukan saat hanya satu model dimulai dengan cold cache tidak valid

Mengubah Replay Reasoning Menjadi Self-Contained

  • GPT-5.6 Responses API secara default me-replay reasoning dari turn sebelumnya sebagai referensi item di sisi server, dan dalam percakapan produksi sesekali muncul error Item 'rs_...' not found
  • Dengan mengatur store: false, SDK meminta konten reasoning terenkripsi dan me-replay blob self-contained, bukan pointer ke state server
  • Meskipun byte yang dikirim aplikasi memiliki struktur append-only, state reasoning di sisi server dapat mengubah prompt efektif
  • Setelah evaluation harness, skema tool, prompt cache, dan replay reasoning semuanya diperbaiki, GPT-5.6 Sol kini beroperasi sebagai model default produksi Ploy

Bacaan terkait

1 komentar

 
GN⁺ 7 jam lalu
Pendapat Hacker News

  • Frasa seperti “dengan angka seperti itu, model ini memang layak dimigrasikan secara nyata” terdengar terlalu konyol. Akan lebih baik kalau orang yang menyuruh tulisan ini dibuat setidaknya merapikan gaya khas LLM yang sangat kentara
    Cara menyambung frasa-frasa pendek dengan titik dua, koma, dan titik juga buruk dan melelahkan. Ada insight bagus, seperti bahwa cache kecocokan prefiks parsial hilang di GPT-5.6, tetapi ini bukan tulisan yang nyaman dibaca

    • Karena itu saya selalu menaruh WRITING.md di samping AGENTS.md atau CLAUDE.md. Kebanyakan orang hanya memberi tahu model apa yang harus dibuat, dan hampir tidak pernah memberi tahu bagaimana harus menulis, padahal LLM mengikuti instruksi gaya yang eksplisit dengan sangat baik
      Saya menuliskan aturan agar menghindari titik dua yang tidak perlu, tanda pisah panjang, fragmen kalimat yang menyamar sebagai penekanan, serta kesalahan tata bahasa yang sering saya lakukan. Saya juga memasukkan Brian Kernighan dan Rob Pike sebagai rujukan untuk tulisan teknis yang jelas, bernada percakapan, dan tidak sok. Dokumen tidak hanya harus mudah dibaca, tetapi juga harus membuat orang ingin membacanya
      Jika Anda sering membuat dokumen, sangat layak membuat agen merujuk ke WRITING.md. Keterbacaan sering kali meningkat jauh lebih besar dibanding sekadar mengganti ke model terbaru, dan gaya bisa tetap konsisten meski modelnya berubah
    • Terutama kalau itu perusahaan AI, kesannya lebih buruk. Artinya bisa jadi mereka tidak cukup banyak memakai model sehingga tidak mengenali gaya khasnya, atau tidak sadar bahwa itu penting, atau tidak memahami situasi secara keseluruhan, atau tidak menghormati pembaca; tidak ada satu pun yang bagus
    • Cara membacanya yang keliru. Minta saja LLM membaca dan merangkum sesuai preferensi gaya Anda. Lebih jauh lagi, jangan membaca apa pun secara langsung; minta agen mengubahnya menjadi file skill untuk dirujuk nanti
    • Jika saya curiga sebuah tulisan dibuat dengan LLM, saya langsung berhenti membaca dan meminta tool LLM yang saya pakai untuk merangkum atau menulis ulang. Dengan begitu setidaknya gaya output bisa saya kendalikan sampai batas tertentu
    • Di claude.md yang saya pakai sekarang, saya melarang ungkapan “load-bearing”, dan Claude benar-benar tidak menyukainya. Kadang ia sampai menggoda di komentar dengan sesuatu seperti “load-be…most specific”, saking sukanya pada ungkapan itu

  • Saya memindahkan berbagai workflow kecil dan sederhana yang dulu berjalan di 5.4-nano dan mini ke 5.6, dan secara umum peningkatannya berada dalam kisaran yang disebutkan tulisan itu; beberapa tugas klasifikasi juga membaik kualitasnya
    Di banyak perusahaan, upgrade model seperti ini pada dasarnya hanya perubahan satu baris kode. Untuk workflow inti kami memakai arsitektur router model yang sangat baik, tetapi tidak ada gunanya menyusun hal seperti itu untuk tugas sederhana, dan masalah stabilitas juga harus dipertimbangkan

    • Inti tulisan ini justru bahwa upgrade model bukan perubahan satu baris kode
    • SDK apa yang dipakai? Atau implementasi sendiri?
    • Tujuan awal memakai Sol adalah mengevaluasi 5.6 dalam workflow kami. Sebelumnya kualitas model sederhana tidak memadai sehingga kami memakai 5.5 untuk semua tugas, dan sekarang kami menganalisis teks bersama gambar untuk mengekstrak data terstruktur eksplisit dan implisit dari data sumber yang berantakan
      Secara umum bekerja seperti yang diiklankan. Dengan mengalihkan sebagian besar pekerjaan saat ini ke terra, biaya turun setengah dan waktu respons juga membaik 50%. luna dipakai untuk melengkapi hasil deteksi OpenCV; fiturnya sangat terbatas, tetapi cepat dan hampir gratis. Sol hanya sedikit lebih baik daripada terra untuk pekerjaan kami
      Sol ultra juga melakukan evaluasinya sendiri dengan sangat baik. Ia membuat paket besar berisi rekomendasi yang masuk akal, daftar output yang perlu dicek dan dibandingkan secara langsung, data mentah dan terproses, serta CPM per kueri. Tanpa biaya tambahan di luar langganan Pro, hasil menjalankannya beberapa jam adalah patokan biaya turun 50% dan throughput naik 100%

  • Pengalaman saya juga mirip. Layanan yang mengedepankan failover seperti OpenRouter hampir tidak berguna di luar pengujian sandbox. Model produksi pada praktiknya tidak dapat saling dipertukarkan, dan lingkungan eksekusi yang menjalankan pekerjaan agen serius bergantung pada karakteristik spesifik model jauh lebih banyak daripada yang diperkirakan
    Meski model lain berjalan tanpa error, performa dan efisiensi adalah perkara berbeda. Ada model seperti keluarga Claude yang membutuhkan penyesuaian system prompt agar sesuai dengan pola ekspresi yang dibiasakan selama pelatihan, sementara model lain bekerja lebih baik dengan delimiter berbeda. Jika performa optimal penting, lingkungan eksekusi, prompt, dan model harus dilihat sebagai satu sistem, bukan sebagai komponen yang bisa diganti bebas seperti suku cadang

    • Sebagai bagian dari LLMOps, perlu membangun rencana failover yang benar-benar memeriksa jalur eksekusi tool dan sebagainya. Dengan begitu Anda bisa menempatkan model yang cukup baik dari urutan murah ke mahal dan mewujudkan failover yang diinginkan
      Saya pernah melihat orang membuat tabel pemetaan berbentuk model -> {{prompts}, {tools descriptions}, ...}, tetapi itu terlalu ekstrem. Pada titik tertentu, model harus beradaptasi dengan prompt kita; jika tidak bisa, model itu cukup dikeluarkan dari kandidat failover dan tidak perlu dikirimi request API
    • OpenRouter tidak melakukan failover ke model lain, melainkan beralih ke penyedia lain yang menawarkan model yang sama

  • Ironis bahwa di bawah tulisan yang penuh insight infrastruktur mendalam, separuh komentarnya hanya mengkritik gaya penulisan yang dipaksakan. Kalaupun Claude membantu memoles kalimat, bukankah lebih penting bahwa tulisan itu memuat cetak biru yang bisa langsung dipakai untuk memangkas anggaran API 30% dan memperbaiki pembacaan file kosong?

    • Mungkin ada orang yang membenci apa pun terkait AI lalu mencari-cari kesalahan, tetapi mungkin juga ada orang yang benar-benar tidak tahan dengan gaya itu dan terpaku hanya pada hal tersebut
      Secara pribadi, mengomel soal gaya terlihat konyol bagi saya. Mungkin karena saya lemah dalam tata bahasa dan ejaan, saya lebih fokus pada isi inti seperti konsep, fakta, dan argumen daripada cara penyampaian. Tata bahasa dan ejaan hanyalah pohon; hutannyalah yang penting
      Alasan tulisan saya tidak penuh kesalahan adalah berkat dikte dan shortcut buatan sendiri. Teks yang dipilih dikoreksi oleh LLM lokal lalu diganti; tidak ada yang meningkatkan kualitas hidup dan kualitas tulisan saya sebesar dua tool ini

  • “Mulai hari ini, agen Ploy menggunakan GPT-5.6 Sol yang dirilis pagi ini”—jadi mereka beralih hanya berdasarkan hasil pengujian setengah hari? Apakah perusahaan ini dijalankan oleh para remaja?

    • Kenyataannya, komposisi karyawannya lebih dekat ke level Staff dan Senior Staff. Melalui hubungan dengan YC, mereka menguji model pratinjau GPT-5.6 selama sekitar seminggu sambil memberikan umpan balik
      Evaluasi dijalankan di GitHub CI, dan set evaluasi berisi lebih dari 115 tugas desain web dan pemasaran yang menjadi spesialisasi ploy.ai dapat dijalankan seluruhnya dalam sekitar 15 menit. Setelah model diaktifkan lewat feature flag PostHog, mereka memantau kegagalan secara aktif
      Mereka berusaha memindahkan sebanyak mungkin pengetahuan dari menjalankan Webflow, yang mendukung lebih dari 1% internet, ke Ploy agar bisa mendukung lebih banyak bagian internet
    • Sangat mungkin mereka mendapat akses awal sampai taraf tertentu agar bisa mengevaluasi dan menulis artikel seperti ini
    • Sekarang membuat evaluasi dan benchmark lalu menjalankannya pada model terbaru sudah cukup mudah. Karena LLM mudah diganti, set evaluasi yang bagus sangat berguna, dan kadang peningkatannya terlalu jelas sampai evaluasi pun tidak diperlukan
    • Saya menduga mereka punya dataset berbasis produksi untuk membandingkan model baru

  • Katanya agen Ploy membuat dan mengubah situs web pemasaran sungguhan, termasuk menyusun rencana, membaca codebase, menulis komponen, membuat gambar, mengambil tangkapan hasilnya sendiri, dan memutuskan apakah tugas selesai. Meski belum melakukan pengujian ketat, saya memperkirakan Fable akan jauh lebih baik daripada Opus dalam membuat situs pemasaran. Untuk pembuatan materi presentasi, jelas jauh lebih baik

    • Dalam desain, GPT-5.6 jauh lebih baik daripada Fable
    • 4.7 cenderung mengikuti instruksi terlalu harfiah, jadi hasil pada tulisan aslinya juga cukup masuk akal

  • Solusi yang hanya untuk model keluarga OpenAI mengubah semua properti opsional menjadi wajib tetapi mengizinkan null dengan anyOf: [T, null] terasa ada yang tidak beres. Saya hanya pernah memakai bentuk MCP yang dimodifikasi, tetapi tidak jelas mengapa definisi tipe TypeScript memengaruhi JSON Schema yang dikirim dari agen ke backend inferensi
    Dalam spesifikasi MCP ada field eksplisit untuk menunjukkan parameter opsional, jadi tampaknya ada bug di suatu tempat antara lapisan TypeScript dan deskripsi alat yang benar-benar dikirim. Bisa jadi backend inferensi berubah dari “membuat respons alat yang valid” menjadi “membuat respons valid yang sesuai JSON Schema tanpa parameter opsional”, tetapi tanpa melihat request sebenarnya sulit menilainya

    • Ini bukan bug pembuatan skema atau bug TypeScript, melainkan perilaku internal pemanggilan fungsi OpenAI. Bobot yang di-fine-tune untuk penggunaan alat berusaha mengeluarkan struktur data selengkap mungkin. Jika model melihat nama parameter dalam konteks system prompt, ia cenderung mengisi nilainya meski tidak ada di array required
    • Model frontier terbaru termasuk Fable, Opus, dan 5.6 cukup longgar dalam tool calling dan sering kali tidak mengikuti skema dengan tepat. Contoh model Claude yang membuat properti yang tidak ada dalam panggilan alat edit/substitusi Pi dapat dilihat di https://lucumr.pocoo.org/about/
      Sebagian penyebabnya tampaknya terkait dengan fenomena bahwa penggunaan constrained decoding menurunkan kecerdasan. Validitas skema memang terjamin, tetapi kemampuannya turun besar, jadi masih oke untuk klasifikasi, ringkasan, dan perbaikan prompt, tetapi perlu hati-hati dalam eksekusi berulang oleh agen
      Lingkungan eksekusi seperti Claude Code melakukan banyak preprocessing, pemulihan, pembersihan, dan sebagainya, tetapi biasanya tidak terlihat. Dalam praktik, lebih mudah dan lebih baik membuat lingkungan eksekusi lebih longgar dan menyesuaikannya dengan karakteristik tiap model, ketimbang mengasumsikan dan memaksakan akurasi sempurna. Model juga berubah setiap satu atau dua bulan. Inilah AI aplikasi yang dibuat berdasarkan vibe

  • Saya ingin tahu perkiraan nominal biaya sebenarnya untuk membuat satu situs dengan Opus dan Sol masing-masing

  • Setelah memindahkan workflow ke Reasonix dan memanfaatkan cache hit di DeepSeek, biaya request menjadi nyaris gratis meski memakai penyedia AS yang tidak disubsidi

    • Pengaturan apa yang dipakai, dan bagaimana dibandingkan dengan Pi?

  • Alih-alih menjadikan GPT-5.6 Sol sebagai default untuk semua workspace Ploy, Luna layak dipertimbangkan untuk sebagian pekerjaan yang menangani alat sungguhan. Ia sangat mampu dan cepat
    Sol unggul dalam berbicara dengan manusia dan mengoordinasikan pemanggilan agen, tetapi terlalu mahal untuk dipakai pada semua pekerjaan. Dengan harga satu kali Sol, Luna bisa dijalankan lima kali, dan secara statistik perbedaan antara satu sampel dan lima sampel cukup besar

    • Jika setiap langkah eksekusi Luna benar dengan probabilitas 90%, peluang kelima langkah semuanya benar adalah 0.9^5 = 0.59, yaitu 59%. Akurasi satu kali Sol mungkin sekitar 95%. Angka sebenarnya bisa berbeda, tetapi bisa jadi lebih murah memverifikasi dengan Sol di akhir
    • Masalah yang selalu muncul adalah subagen saling terisolasi. Ada keuntungan karena konteks tetap kecil dan mereka bisa fokus, tetapi untuk melanjutkan tugas masing-masing sering harus meneliti ulang sehingga menghabiskan token yang tidak tercache
      Bergantung pada berapa banyak agen yang dipakai untuk suatu tugas, biayanya bisa lebih mahal sementara hasilnya justru lebih buruk