Catatan Rudy

Kumpulan berita coding, web dev & AI paling menarik minggu ini (10-16 Agustus 2026). Dari Anthropic yang buka system prompt Claude sampai drama Cloudflare yang suntikkan analytics diam-diam — ada yang perlu kamu tahu sebagai developer.

1. Anthropic Publikasikan System Prompts Claude

Anthropic membuka sistem prompt yang digunakan di claude.ai dan aplikasi mobile Claude. Dokumentasi ini menunjukkan bagaimana prompt system mendorong perilaku Claude — mulai dari memberikan tanggal terkini, memastikan kode selalu dalam format Markdown, hingga berbagai panduan perilaku lainnya. Berguna banget buat yang mau memahami cara Anthropic membingkai interaksi model mereka.

🔗 Baca di Claude Platform Docs

2. OpenAI Ultrafast: GPT-5.6 Sol 14x Lebih Cepat

OpenAI meluncurkan mode preview “Ultrafast” untuk model terbaru mereka GPT-5.6 Sol yang membuat inference berjalan hingga 14x lebih cepat. Ini bagian dari strategi OpenAI untuk menarik pengguna enterprise yang butuh kecepatan tanpa mengorbankan kualitas respons.

🔗 Baca di TechCrunch

3. SpaceX Resmi Akuisisi Cursor

Startup AI coding Cursor resmi menjadi bagian dari SpaceX setelah proses akuisisi selesai. Cursor, yang dikenal sebagai code editor berbasis AI yang populer di kalangan developer, kini bergabung di bawah payung perusahaan Elon Musk — sebuah langkah menarik yang menggabungkan AI coding dengan aerospace.

🔗 Baca di TechCrunch

4. Cloudflare Suntikkan Analytics JavaScript Secara Diam-diam

Seorang developer menemukan bahwa Cloudflare diam-diam menyuntikkan snippet analytics JavaScript ke halaman HTML saat kamu mengganti nameserver ke Cloudflare. Temuan ini bikin heboh di HN karena banyak yang tidak menyadari bahwa ada kode tracking yang otomatis ditambahkan ke website mereka. Penting untuk diketahui developer yang concern soal privasi dan transparansi.

🔗 Diskusi di Hacker News

5. CSS Tricks: Custom Highlight API, Navigation Matching & Lainnya

Edisi #17 dari seri What’s !important di CSS-Tricks membahas beberapa fitur CSS terbaru: Custom Highlight API untuk styling selection, CSS Navigation Matching, perbaikan text-stroke, cara membuat skeleton UI, dan diagonal scrolling. Plus bagaimana gambar bisa overflow dari container sendiri. Kumpulan technique CSS yang powerful untuk daily use.

🔗 Baca di CSS-Tricks

6. Blocked aria-hidden: Fix yang Salah & Yang Benar

Artikel penting soal accessibility: peringatan aria-hidden di browser itu benar, dan sebagian besar “fix” yang beredar di internet (blur, setTimeout, menghapus attribute) sebenarnya salah — mereka hanya menutupi warning tanpa menyelesaikan masalah bagi pengguna screen reader. Kuncinya: focus harus keluar dari region sebelum region tersebut di-hide atau di-inert. Artikel ini juga merekomendasikan migrasi ke elemen <dialog> native jika memungkinkan.

🔗 Baca di CSS-Tricks

7. Software Engineering Fundamentals Matter More Than Ever

Di tengah maraknya AI coding tools, artikel ini mengingatkan bahwa fundamental software engineering justru semakin penting. Dengan AI yang bisa menghasilkan kode dalam sekejap, kemampuan untuk menulis arsitektur yang solid, memahami trade-off, dan melakukan code review yang kritis menjadi skill yang semakin berharga — bukan malah tergantikan.

🔗 Baca selengkapnya

Itu dia 7 berita paling menarik minggu ini. Yang follow perkembangan AI wajib tahu soal Claude system prompts dan OpenAI Ultrafast. Jangan lupa cek aria-hidden fix kalau lagi kerja modal dialog — accessibility itu bukan optional!

Hari ini saya mulai seri baru: Belajar AI. Sebagai programmer yang sehari-hari menulis kode, saya merasa perlu memahami teori di baliknya — bukan sekadar memakai API. Dan saya memutuskan mulai dari awal: sejarah. Bukan karena nostalgia, tapi karena sejarah menjelaskan satu hal yang sering membingungkan saya: kenapa AI sempat “mati” dua kali, lalu bangkit lagi dan sekarang ada di mana-mana. Mari kita telusuri.

1950: Turing Test — titik tolak

Alan Turing, matematikawan asal Inggris, menerbitkan paper berjudul “Computing Machinery and Intelligence” di jurnal Mind tahun 1950. Pertanyaannya sederhana: can machines think? Tapi karena “berpikir” terlalu kabur untuk diuji, Turing menggantinya dengan permainan imitasi: seorang pemeriksa mengobrol dengan mesin dan manusia melalui teks. Kalau pemeriksa tidak bisa membedakan mana mesin mana manusia, mesin itu dianggap lolos uji kecerdasan.

Dari sudut pandang programmer, Turing Test itu seperti unit test yang kasar: kita tidak mengukur cara kerja dalamnya, hanya hasil luarnya. Mesin boleh diimplementasikan dengan cara apa pun — yang penting outputnya tidak bisa dibedakan dari manusia. Konsep ini penting karena menanamkan pola pikir “kecerdasan bisa dinilai dari perilaku”, bukan dari jiwa atau kesadaran.

1956: Konferensi Dartmouth — lahirnya nama “AI”

Enam tahun kemudian, John McCarthy mengusulkan sebuah workshop musim panas di Dartmouth College, Amerika Serikat. Para pesertanya adalah tokoh yang kelak menjadi bapak pendiri AI: McCarthy, Marvin Minsky, Claude Shannon, dan Nathaniel Rochester. Di konferensi inilah istilah artificial intelligence pertama kali dicetuskan, dan AI resmi menjadi bidang riset.

Yang menarik: optimisme saat itu sangat tinggi. Mereka memperkirakan masalah AI bisa diselesaikan dalam satu generasi. Setelah konferensi, muncul beberapa hasil awal yang menjanjikan — Frank Rosenblatt membuat perceptron (neuron buatan sederhana) tahun 1958, dan Joseph Weizenbaum membuat chatbot ELIZA tahun 1966 yang bisa “ngobrol” ala terapis. Tapi dari kejauhan, saya melihat pola yang sama dengan hype teknologi sekarang: ekspektasi melampaui kenyataan.

Dua musim dingin: AI winter

Janji besar tanpa hasil yang konsisten membuat pendanaan riset AI membeku dua kali. Para sejarawan menyebut periode ini AI winter:

• 1974–1980 (AI winter pertama): laporan Lighthill di Inggris tahun 1973 mengkritik habis-habisan capaian AI, pendanaan pemerintah dan industri menyusut drastis.
• 1980-an (kebangkitan sistem pakar): expert systems — program berisi aturan if-then yang ditulis manual oleh ahli — dipakai di industri, misalnya untuk diagnosis dan konfigurasi. Populer, tapi mahal dan rapuh: aturan tidak bisa menangani kasus di luar yang tertulis.
• 1987–1993 (AI winter kedua): pasar komputer LISP (bahasa favorit riset AI) runtuh, proyek sistem pakar ditinggalkan satu per satu.

Bagi saya ini pelajaran berharga: AI berbasis aturan yang ditulis tangan tidak pernah benar-benar “belajar”. Ia sekuat pengetahuan yang dimasukkan manusia, dan rapuh di luar domain itu. Paradigma inilah yang akhirnya digantikan oleh machine learning.

Kebangkitan: machine learning & deep learning

Alih-alih menulis aturan secara manual, machine learning membuat model belajar dari data. Beberapa tonggak yang saya catat:

• 1997 — Deep Blue: komputer IBM mengalahkan juara catur dunia Garry Kasparov. Masih berbasis pencarian dan aturan, tapi momen penting: AI mengalahkan manusia di game populer.
• 2012 — AlexNet: jaringan saraf konvolusional karya Alex Krizhevsky, Ilya Sutskever, dan Geoffrey Hinton menang telak di kompetisi ImageNet. Inilah momen deep learning “resmi” naik daun — berkat data besar dan GPU.
• 2016 — AlphaGo: sistem DeepMind mengalahkan Lee Sedol di permainan Go, yang selama ini dianggap terlalu kompleks untuk diselesaikan dengan brute force.
• 2017 — Transformer: paper “Attention Is All You Need” memperkenalkan arsitektur transformer, yang kelak menjadi fondasi GPT dan semua LLM modern.

2022–sekarang: AI generatif arus utama

ChatGPT dirilis November 2022 dan dipakai ratusan juta orang dalam hitungan bulan. Yang tadinya riset laboratorium menjadi produk harian: menulis, coding, menggambar, menganalisis. Sejarah tidak berhenti di sini — tapi untuk seri ini, 2022 adalah titik awal era yang sedang kita jalani.

Catatan programmer: mengingat lewat data

Sebagai programmer, cara paling natural buat saya mengingat sejarah ini adalah menjadikannya data — list pasangan (tahun, peristiwa):

sejarah = [
    (1950, "Turing Test"),
    (1956, "Konferensi Dartmouth"),
    (1974, "AI winter pertama"),
    (1987, "AI winter kedua"),
    (1997, "Deep Blue kalahkan Kasparov"),
    (2012, "AlexNet menang ImageNet"),
    (2017, "Paper Transformer"),
    (2022, "ChatGPT rilis"),
]
for tahun, peristiwa in sejarah:
    print(f"{tahun}: {peristiwa}")

Dari data ini saya menangkap pola besar: ide neural network sebenarnya sudah ada sejak 1958 (perceptron), tapi baru meledak tahun 2012. Yang berubah bukan teorinya, melainkan dua bahan bakar: data besar dan komputasi murah (GPU). Jadi ketika orang bilang “AI baru”, yang baru sebenarnya adalah skala, bukan konsep dasarnya.

Sumber

• Turing Test — Wikipedia
• Dartmouth Workshop — Wikipedia
• AI winter — Wikipedia
• AlexNet — Wikipedia
• “Attention Is All You Need” — arXiv (2017)
• History of Artificial Intelligence — Wikipedia

Hari ini saya coba jawab pertanyaan yang sering muncul di kalangan yang baru mulai pakai AI coding agent: “Kalau pakai model non-thinking, apakah tetap bisa dipakai untuk coding yang kompleks?” Singkatnya: bisa, tapi dengan syarat — dan ada jenis pekerjaan yang memang lebih aman diserahkan ke model thinking. Catatan ini saya tulis khusus dari sudut pandang coding (Hermes Agent dan OpenCode), tidak membahas hal lain di luar itu.

Apa Bedanya Model Thinking vs Non-Thinking?

Dalam konteks coding, “thinking” (atau extended thinking / reasoning) artinya model diberi ruang untuk berpikir panjang sebelum menjawab — ia menuliskan rantai penalaran internal dulu, baru menghasilkan kode atau keputusan. Ini memakai token tambahan (biasanya tidak terlihat di output akhir), sehingga lebih lambat dan lebih mahal.

Model non-thinking menjawab langsung: input diproses, output langsung keluar. Lebih cepat, lebih murah, tapi untuk masalah yang butuh penalaran bertingkat, hasilnya bisa meleset lebih cepat.

Penting: yang wajib dimiliki untuk coding adalah kemampuan tool calling yang baik (membaca file, menjalankan perintah, melihat error, mengedit). Mode thinking itu nilai tambah, bukan prasyarat.

Kapan Non-Thinking Masih Andal

Untuk jenis pekerjaan berikut, model non-thinking yang bagus biasanya sudah cukup:

• Boilerplate dan scaffolding — kerangka proyek, file konfigurasi, stub fungsi.
• CRUD sederhana — endpoint API, form, operasi database standar.
• Task satu file dengan spesifikasi eksplisit — “ubah fungsi ini supaya menerima parameter X”.
• Refactor kecil dan mekanis — rename, pindah fungsi, ubah format.
• Perbaikan bug yang error-nya jelas dan lokal.

Ciri umumnya: tugasnya jelas, ruang lingkupnya sempit, dan ada cara verifikasi cepat (test, compile, atau output yang bisa dicek).

Di Mana Non-Thinking Sering Gagal

Yang berikut ini justru menjadi titik lemah model non-thinking:

• Debugging bertingkat — error menimpa error, root cause tersembunyi di balik gejala.
• Refactor lintas file — banyak dependensi silang yang harus diikuti konsistensinya.
• Keputusan arsitektur — memilih desain dengan trade-off yang saling bertabrakan.
• Memahami codebase besar yang belum familiar — butuh penalaran panjang untuk membangun model mental.
• Task ambigu — spesifikasi tidak lengkap, perlu inferensi dan pertimbangan.

Pada kasus seperti ini, model non-thinking berisiko gagal diam-diam: hasilnya terlihat jalan, tapi logikanya salah di tempat yang tidak langsung kelihatan.

Bukti dari Benchmark

Di benchmark agentic coding seperti SWE-bench Verified (500 isu GitHub nyata dari repo populer seperti Django, Flask, scikit-learn yang harus diselesaikan oleh model), posisi papan atas hampir selalu diisi model reasoning/thinking. Menurut leaderboard yang dipantau benchlm.ai per Agustus 2026, model teratas (Claude Opus 5) mencapai sekitar 96% resolusi.

Pola umumnya: versi thinking dari sebuah model hampir selalu mengungguli versi non-thinking-nya pada task multi-step, dan gap-nya mengecil drastis pada task sederhana. Jadi benchmark ini menegaskan — bukan soal “bisa atau tidak”, tapi soal di titik mana non-thinking mulai jebol.

Perbandingan Ringkas

Pola Praktis: Campur, Jangan Pilih Satu

Cara paling efektif bukan memilih salah satu, tapi memakai keduanya sesuai tugas — di Hermes dan OpenCode, ganti model per sesi/per task itu normal.

Hermes Agent

Ganti model kapan saja via hermes model, atau langsung set default:

hermes model
hermes config set model.default nama-model-non-thinking

Di dalam sesi, perintah /model untuk ganti model, dan /reasoning untuk mengatur level reasoning — kalau modelnya memang mendukung mode thinking. Model non-thinking tetap jalan normal tanpa setting tambahan.

OpenCode

Pilih model via /models. Kalau model default-nya thinking (misalnya Claude lewat provider Anthropic) dan ingin mematikannya, set lewat opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "anthropic": {
      "models": {
        "claude-sonnet-4-5": {
          "options": {
            "thinking": { "type": "disabled" }
          }
        }
      }
    }
  }
}

Untuk provider OpenAI-compatible (misalnya GPT), mode reasoning diatur lewat reasoningEffort — nilai rendah berarti “hampir non-thinking”.

Kesimpulan

Model non-thinking bisa dipakai untuk coding kompleks, asal tugas dipecah kecil dan ada loop verifikasi: tulis sedikit → jalankan → lihat error → perbaiki. Untuk boilerplate, CRUD, dan task single-file, non-thinking bahkan pilihan paling efisien.

Tapi untuk debugging bertingkat, refactor lintas file, dan keputusan desain, model thinking masih pilihan yang jauh lebih aman — terutama kalau pekerjaan berjalan tanpa pengawasan. Prinsipnya: pakai model sesuai tingkat kesulitan tugas, bukan satu model untuk segalanya.

Sumber

• OpenCode Docs — Models (konfigurasi model & opsi thinking), diakses 15 Agustus 2026
• SWE-bench Verified — deskripsi benchmark, diakses 15 Agustus 2026
• benchlm.ai — SWE-bench Verified Leaderboard (Agustus 2026), diakses 15 Agustus 2026
• Hermes Agent Docs, diakses 15 Agustus 2026

Hari ini saya lanjut belajar Laravel ke episode kedua: routing dan controller pertama. Setelah minggu lalu berhasil membuat project dan menjalankan php artisan serve, sekarang saya penasaran — dari mana sebenarnya halaman awal itu muncul? Ternyata jawabannya ada di satu file kecil bernama routes/web.php. File inilah yang menjadi pintu masuk hampir semua request ke aplikasi web kita.

routes/web.php: pintu masuk aplikasi

Buka folder project lalu buka routes/web.php. Isinya singkat, hanya satu route default:

<?php

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return view('welcome');
});

Bisa dibaca seperti ini: “kalau ada request GET ke alamat /, jalankan fungsi ini, lalu kembalikan view welcome“. Di sinilah saya sadar perbedaan mendasar Laravel dengan PHP biasa: alih-alih membuat file index.php per halaman, semua alamat dipetakan lewat satu file route. Ini disebut front controller — semua request masuk lewat public/index.php, lalu Laravel yang memutuskan ke mana request itu diteruskan berdasarkan route yang cocok.

Route closure vs controller

Di contoh di atas, logika ditulis langsung di dalam route sebagai closure (fungsi anonim). Untuk halaman sekecil welcome, cara ini cukup. Tapi kalau semua logika ditumpuk di routes/web.php, file itu cepat sekali jadi penuh sesak. Solusi Laravel: pindahkan logika ke controller.

Buat controller lewat Artisan:

php artisan make:controller HalamanController

Perintah itu membuat file app/Http/Controllers/HalamanController.php. Isinya kelas kosong. Lalu saya tambahkan method sendiri:

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class HalamanController extends Controller
{
    public function index()
    {
        return view('welcome');
    }
}

Dan route-nya berubah menjadi:

Route::get('/', [HalamanController::class, 'index']);

Pola [NamaController::class, 'namaMethod'] adalah cara Laravel modern menunjuk controller di route. Hasilnya sama dengan versi closure, tapi logika sudah pindah ke tempat yang lebih rapi dan bisa diuji. Prinsipnya: route itu peta, controller itu pekerja.

View pertama

Method index() tadi mengembalikan view('welcome'). View adalah file template yang disimpan di resources/views dengan ekstensi .blade.php — jadi view('welcome') mencari resources/views/welcome.blade.php. Saya coba buat halaman sendiri, misalnya halaman tentang:

Route::get('/tentang', [HalamanController::class, 'tentang']);

Lalu di controller:

public function tentang()
{
    return view('tentang');
}

Dan buat file resources/views/tentang.blade.php berisi HTML sederhana. Setelah itu php artisan serve dan buka http://127.0.0.1:8000/tentang — halaman muncul. Kesannya ajaib padahal sederhana: route → controller → view. Tiga lapis yang akan terus kita pakai di semua episode berikutnya.

Kesalahan yang umum

• Lupa menjalankan php artisan serve, lalu bingung kenapa halaman 404. Route tidak akan jalan tanpa server.
• Nama view salah ketik: view('welcome') tapi file bernama welcome.blade.php — pastikan nama persis.
• Menaruh route di bawah route lain yang polanya sama; di Laravel, route yang cocok pertama yang dipakai. Urutan route bisa penting.
• Menulis logika bisnis menumpuk di route closure sampai file web.php ratusan baris — kebiasaan yang sebaiknya dihindari sejak awal dengan memakai controller.

Kesimpulan

Hari ini saya paham alur dasar aplikasi Laravel: request masuk ke routes/web.php, dicocokkan dengan pola URL, lalu diteruskan ke closure atau controller, dan akhirnya controller mengembalikan view Blade. Konsep ini kecil tapi fondasi — semua fitur berikutnya (form, database, login) menumpang di alur yang sama. Minggu depan saya lanjut ke Blade: layout, @extends, dan perulangan @foreach.

Sumber

• Laravel Docs — Routing
• Laravel Docs — Controllers
• Laravel Docs — Views
• Laravel Docs — Artisan Console

Beberapa hari terakhir saya memakai beberapa tool coding berbasis AI sekaligus, dan muncul pertanyaan yang sering ditanyakan banyak orang: kalau di tengah sesi kode modelnya ganti-ganti — entah karena rate limit atau provider sedang turun — apakah berpengaruh ke hasil kerja? Apalagi sekarang ada 9Router yang bisa auto-fallback ke model lain. Catatan ini saya rangkum dari eksperimen dan riset saya soal OpenCode, Hermes Agent, dan 9Router.

Apa yang Sebenarnya Terjadi Saat Model Ganti di Tengah Sesi?

Ganti model di tengah sesi coding bukan sekadar soal “sambungannya pindah”. Ada tiga hal yang berubah:

• Konteks percakapan bisa terpotong. Setiap model punya batas token window sendiri. Saat failover, riwayat prompt biasanya di-truncate agar muat di model baru. Model pengganti bisa jadi tidak paham penuh alur debug yang sedang kita jalani.
• Gaya dan keputusan teknis bisa melenceng. Tiap model punya kebiasaan sendiri soal penamaan, struktur folder, sampai pilihan pola kode. Kalau berganti di tengah fitur yang sama, hasilnya bisa tidak konsisten.
• Ada biaya dan latency tambahan. Koneksi ke provider baru perlu inisialisasi ulang, dan jika konteks dikirim ulang, token yang dipakai juga bertambah.

Bagaimana OpenCode Menangani Ini?

OpenCode (tool agentic coding open source yang awalnya dikembangkan oleh Andrej Karpathy) mendukung banyak provider sekaligus: OpenAI, Anthropic, Google, hingga model lokal. Beberapa hal yang saya perhatikan:

• Bisa ganti model/provider secara dinamis tanpa restart sesi, dan konteks terbaru tetap dibawa.
• Ada failover bawaan — jika satu provider rate limited, ia beralih ke model berikutnya sesuai urutan yang kita daftarkan.
• Semua perubahan model tercatat di log sesi, sehingga riwayatnya bisa ditelusuri kembali.

Kekurangannya: tiap provider perlu API key sendiri, dan failover bisa menambah latency kalau tidak hati-hati mengatur urutan.

Bagaimana dengan Hermes Agent?

Hermes Agent (dari Nous Research) adalah agen yang lebih umum — bisa untuk coding, riset, sampai otomasi. Untuk urusan ganti model di tengah sesi, pengalamannya sedikit berbeda:

• Provider bisa di-load/unload secara dinamis, tapi sinkronisasi konteks cenderung manual — perlu resume sesi atau menyuntikkan ringkasan konteks.
• Failover otomatis tidak sepenuhnya built-in seperti OpenCode, tapi bisa dikonfigurasi lewat fallback_providers di config — ini yang saya pakai untuk beberapa cron blog saya.
• Restore konteks dari disk butuh waktu, jadi ada latency tambahan saat pindah sesi.

Di Mana Posisi 9Router?

Di sinilah 9Router berperan. Daripada tiap tool mengurus failover-nya sendiri, kita bisa mengarahkan semuanya ke satu router yang mengatur urutan model:

opencode --model "9router://gpt-4o,claude-3.5-sonnet,gemini-1.5-flash"

Jika model pertama kena limit, 9Router otomatis meneruskan ke model berikutnya. Sisi tool (OpenCode/Hermes) tidak perlu tahu apa-apa — mereka tetap memakai endpoint yang sama. Ini menyederhanakan masalah jadi satu: atur urutan prioritas, sisanya otomatis.

Jadi, Apakah Ganti Model Berpengaruh?

Perspektif Hermes Agent: Kenapa Task Tetap Nyambung?

Ada satu hal yang memperjelas gambaran ini: jawaban langsung dari tim Hermes Agent (Nous Research) saat saya tanyakan hal yang sama — “jika saat eksekusi task model/provider diganti 9Router, apakah task yang dijalankan model berbeda akan tetap nyambung?”. Jawabannya: ya, tetap nyambung — dengan satu syarat penting.

Konteks Dikelola Hermes, Bukan Provider

Konteks (prompt + tools + state) disimpan di sisi gateway/sesi Hermes. Saat 9Router mengganti provider/model, Hermes tetap mengirim konteks yang sama — lewat history.messages — ke provider baru. Provider hanya “menumpang” pada konteks yang sudah disiapkan Hermes.

Syaratnya: Provider OpenAI-Compatible

Provider OpenAI-compatible (kagiro, laguna, dsb — yang memang terhubung lewat 9Router) memakai format message yang sama. Jadi model yang berbeda sekalipun akan menerima konteks yang sama persis. Yang bikin putus hanyalah perubahan model yang sangat signifikan — misalnya dari OpenAI-style ke Claude-style — karena format outputnya berbeda.

Contoh Jalan atau Tidaknya

Bottom Line

Selama semua provider yang dipakai adalah OpenAI-compatible endpoint (yang memang dilakukan via 9Router), ganti model/provider tidak akan memutus alur task — Hermes akan mengirim konteks yang sama ke provider baru. Logika tool (mengubah config, restart gateway, dsb) tetap jalan karena Hermes yang mengeksekusi, bukan provider. Yang nyata berubah hanyalah cost dan kecepatan response.

Bagaimana dengan OpenCode? Apakah Sama?

Pertanyaan lanjutannya: apakah prinsip yang sama berlaku di OpenCode? Berdasarkan dokumentasi resminya — ya, prinsipnya sama.

“Select a model to use it in the current session. Switching models updates that session without changing your config.” — Dokumentasi resmi OpenCode (opencode.ai/v2/docs/models)

Konteks Dipegang OpenCode, Bukan Provider

Seperti Hermes, konteks (transcript + state) disimpan di sisi OpenCode — bukan di provider. Ganti model lewat model picker (tab) atau per-run (--model) hanya mengganti model yang dipakai sesi itu; riwayat percakapan tetap utuh dan dikirim penuh ke model baru.

9Router Transparan untuk OpenCode

OpenCode melihat 9Router sebagai satu provider OpenAI-compatible biasa. Saat failover terjadi di balik layar, OpenCode tidak tahu modelnya berganti — ia tetap mengirim konteks sesi yang sama ke endpoint yang sama. Perilakunya persis seperti Hermes.

Perbandingan Hermes vs OpenCode

Satu perbedaan penting: Hermes punya failover native antar provider, OpenCode tidak. Di OpenCode, 9Router justru perannya lebih besar — dialah satu-satunya mekanisme failover otomatisnya. Tanpa 9Router, ganti model di OpenCode harus manual.

Kesimpulan

Mengganti model di tengah sesi berpengaruh, terutama pada konteks dan konsistensi — tapi dampaknya bisa dikelola. Untuk masalah ketersediaan (rate limit, provider down), 9Router sudah menyelesaikan bagian terberatnya dengan failover otomatis. Untuk masalah konteks, kebiasaan kecil seperti menyimpan ringkasan pekerjaan setiap beberapa langkah sudah sangat membantu.

Pendekatan yang saya pakai sekarang: satu model untuk satu fitur utuh, dan 9Router sebagai jaring pengaman kalau model utama sedang bermasalah. Kombinasi yang cukup untuk sebagian besar pekerjaan harian.

• 9Router: AI Router Gratis untuk Koding — Catatan Riset & Ulasan
• Failover Model Cerdas: Pakai 9Router Biar Nggak Macet Rate Limit

Siapa yang tidak pernah mengalami ini: sedang asyik menulis kode dengan bantuan AI, tiba-tiba muncul pesan rate limit exceeded atau connection timeout. Apalagi saat sedang fokus menyelesaikan satu fitur. Alur kerja jadi terputus, dan kita harus menunggu atau berpindah tool secara manual.

Hari ini saya belajar tentang cara mengatasi masalah ini dengan lebih elegan: routing model dengan failover otomatis. Alih-alih terpaku pada satu model atau satu provider, kita bisa menyusun rantai model cadangan yang otomatis dipakai ketika model utama sedang bermasalah.

Apa Itu Failover Model?

Failover model adalah mekanisme di mana ketika satu model/provider gagal — karena rate limit, timeout, atau layanan sedang turun — permintaan kita otomatis dialihkan ke model lain yang sudah kita daftarkan sebagai cadangan. Kita cukup menentukan urutan prioritas, sisanya ditangani otomatis.

Salah satu tool yang menyediakan fitur ini adalah 9Router, sebuah AI router gratis yang bisa diarahkan dari berbagai tool coding seperti OpenCode maupun Hermes Agent.

Cara Kerja 9Router

Kita menentukan urutan prioritas model yang ingin dipakai. Contohnya, jika model utama sedang terkena limit, sistem akan otomatis mencoba model berikutnya dalam daftar:

opencode --model "9router://gpt-4o,claude-3.5-sonnet,gemini-1.5-flash"

Jika gpt-4o gagal (rate limit atau timeout), sistem langsung mencoba claude-3.5-sonnet, lalu gemini-1.5-flash — tanpa intervensi manual. Kita tidak perlu berhenti menulis kode hanya karena satu provider sedang sibuk.

Konfigurasi di OpenCode dan Hermes Agent

Untuk OpenCode, model dengan failover bisa dipanggil langsung lewat CLI:

opencode --model "9router://gpt-4o,claude-3.5-sonnet,command-r-plus"

Sementara di Hermes Agent, konfigurasi dapat ditambahkan pada file config.yaml:

providers:
  - name: 9router
    type: router
    model_chain: ["gpt-4o", "claude-3.5-sonnet", "gemini-1.5-flash"]

Keuntungan Menggunakan 9Router

Kapan Failover Tidak Cukup?

Untuk sesi debugging yang sangat panjang, failover model tetap disarankan dilengkapi dengan checkpoint — menyimpan ringkasan konteks setiap beberapa langkah. Ini menjaga agar model pengganti tetap memahami arah pekerjaan yang sedang dikerjakan.

Namun untuk mayoritas kasus, failover lewat 9Router sudah cukup. Fokus utama kita: menentukan urutan model yang masuk akal, lalu membiarkan sistem bekerja.

Kesimpulan

Mengganti model di tengah sesi kode bukan lagi hal yang merepotkan. Dengan 9Router, kita cukup menyusun urutan prioritas model — sistem yang akan memastikan pekerjaan tetap berjalan meski salah satu provider sedang bermasalah.

• 9Router: AI Router Gratis untuk Koding — Catatan Riset & Ulasan

Dalam era di mana model bahasa besar (LLM) semakin berlimpah, para pengembang (terutama yang aktif memakai CLI seperti OpenCode atau Hermes Agent) kini dituntut untuk selektif memilih penyedia layanan AI yang paling efisien. Salah satu yang muncul dalam dua tahun belakangan adalah Xiaomi MiMo, sekaligus produk andalan Xiaomi untuk programmer dan peneliti.

MiMo menawarkan dua opsi tagihan: Pay-As-You-Go (PAYG) dan Token Plan. Kedua sistem ini tidak dapat saling menggantikan, sehingga pemilihan antara keduanya perlu didasarkan pada pola penggunaan aktual. Pada postingan ini, kami akan mensimulasikan penggunaan dengan budget tetap $5 per bulan, lalu membandingkan berapa banyak token yang kita dapat dari masing-masing opsi, serta kompatibilitasnya dengan alat-alat pengembangan populer seperti Hermes dan OpenCode.

Apa Itu Pay-As-You-Go (PAYG)?

Pay-As-You-Go adalah model di mana setiap token yang Anda gunakan akan ditagihkan langsung ke akun Anda pada akhir bulan. Anda hanya membayar untuk apa yang Anda konsumsi. Cukup fleksibel, tetapi biaya dapat meningkat secara signifikan dengan penggunaan intensif.

Apa Itu Token Plan?

Token Plan adalah langganan bulanan atau tahunan yang memberikan kuota tetap. Ini cocok untuk pengguna yang ingin kontrol penuh atas pengeluaran bulanan mereka, tetapi tidak fleksibel jika penggunaan melebihi kuota.

Tarif Resmi Xiaomi MiMo

Berikut tarif resmi MiMo per 1 Juni 2026:

Simulasi Budget $5/Bulan

Pay-As-You-Go ($5/bulan)

Token Plan — Lite Annual ($5.28/bulan)

Dengan demikian, kita mendapatkan lebih dari 40x lipat token dibandingkan PAYG standar, untuk budget yang hampir sama!

Cara Pakai MiMo dengan Hermes & OpenCode

Ikuti langkah berikut:

• Buat API key di konsol MiMo.
• Ekspor ke environment:

export OPENAI_API_BASE = https://api.mimo.ai/v1
export OPENAI_API_KEY  = ***

• Pilih model (mis. mimo-v2.5 atau mimo-v2.5-pro).
• Jika menggunakan Token Plan, pastikan API Key terhubung ke paket langganan yang valid.

Penting: Xiaomi MiMo tidak mendukung interoperabilitas antara PAYG dan Token Plan. Anda harus memilih satu sistem pembayaran dan tidak dapat beralih secara dinamis antara keduanya.

Rekomendasi Akhir

• Jika Anda aktif menggunakan AI untuk coding, riset, atau pengembangan harian, maka Token Plan Lite (Annual) adalah pilihan yang jauh lebih efisien secara biaya jangka panjang.
• Jika hanya mengekplorasi sekali-sekali, maka Pay-As-You-Go cukup andal.

Sumber

• Xiaomi MiMo Pay-As-You-Go Pricing
• Xiaomi MiMo Token Plan
• AI Pricing Dashboard (Komunitas Open Source)

Sebagai developer dan peneliti AI, kita kini hidup di era di mana jumlah dan jenis model bahasa besar (LLM) yang tersedia bagi pengguna biasa semakin berlimpah. Setiap bulan, vendor seperti OpenAI, Anthropic, Google, dan lainnya merilis model baru yang menambah kebingungan pilihan. Tapi tidak semua model sama, ada yang fokus pada reasoning, ada yang multimodal, dan ada yang sekadar inginkan solusi yang cepat dan hemat — tanpa mengorbankan kualitas secara signifikan.

Pada Agustus 2026, kami telah mengumpulkan data terbaru dari dokumentasi resmi masing-masing vendor — termasuk repositori ai-pricing yang di-audit pada 5 Agustus 2026 — untuk memberi Anda gambaran jelas tentang:

• Apa perbedaan thinking mode dan non-thinking mode?
• Model-model dengan kemampuan vision, audio, dan tool use?
• Tabel harga API paling akurat hingga kini — lengkap dengan sistem tarif peak/off-peak dari DeepSeek.

Ikuti selanjutnya!

Apa Itu “Thinking Mode”?

Thinking Mode (juga disebut reasoning atau extended thinking) adalah kemampuan model untuk menghasilkan rantai-poin pikir (chain-of-thought) internal sebelum memberikan jawaban akhir. Ini meniru cara manusia “memikirkan dua kali sebelum bertanya”.

Model dengan thinking mode biasanya:

• Menghasilkan kualitas yang jauh lebih baik pada tugas matematis, kode, dan logika kompleks.
• Memiliki latensi yang jauh lebih tinggi (sering 10-an detik atau lebih).
• Menghitung token “pikiran” sebagai bagian dari output — artinya, Anda membayar untuk proses berpikir internal model.

Non-Thinking Mode adalah model yang menjawab langsung, lebih cepat, dan lebih murah. Cocok untuk tugas rutin, ringan, atau percakapan.

Kemampuan Multimodal (Vision, Audio, Tool)

Beberapa model mendukung lebih dari sekadar teks — mereka dapat memproses gambar, audio, file, dan bahkan menggunakan alat eksternal (tool use).

Vision (Gambar → Teks)

Audio (Suara → Teks / Teks → Suara)

Tool Use / Agentis

Tabel Harga API (per 1M Token USD)

Catatan penting: Harga dapat bervariasi tergantung provider (OpenRouter, Groq, DeepInfra, dll). Angka di bawah ini merupakan harga resmi dari vendor utama atau rata-rata pasar terendah pada Agustus 2026.

OpenAI

Anthropic

Google Gemini

DeepSeek (China)

Qwen (Alibaba)

Grok (xAI / SpaceXAI)

Mistral AI (Prancis)

Kimi / Moonshot & Phi (Microsoft)

Catatan Penting: Peak / Off-Peak Pricing dari DeepSeek

DeepSeek adalah produsen pertama yang memperkenalkan sistem tarif bergumuru — tempat biaya bergantung pada waktu permintaan dikirimkan.

• Peak hours: 01:00–04:00 UTC & 06:00–10:00 UTC
• Off-peak: Semua sisa waktu
• Mulai 16 Agustus 2026, tarif naik secara signifikan:

Rekomendasi Berdasarkan Kebutuhan

Sumber

• api-docs.deepseek.com
• adamejzak/ai-pricing GitHub (audit 5 Agustus 2026)
• OpenRouter.ai
• BenchLM.ai
• Google AI Pricing

Dokumen ini disusun berdasarkan data publik dan dokumentasi resmi. Harga dan ketersediaan model dapat berubah tanpa pemberitahuan sebelumnya.