2 poin oleh GN⁺ 2025-08-13 | 1 komentar | Bagikan ke WhatsApp
  • Claude Sonnet 4 dari Anthropic kini menyediakan konteks hingga 1 juta token, sehingga dapat memproses codebase besar atau banyak dokumen sekaligus
  • Dengan dukungan konteks yang lebih baik, kini dimungkinkan berbagai penggunaan seperti analisis kode skala besar, pemrosesan kumpulan dokumen yang sangat besar, dan pengembangan agen yang mempertahankan konteks
  • Untuk prompt yang melebihi 200 ribu token, biaya API meningkat, tetapi biaya dapat ditekan melalui prompt caching dan pemrosesan batch
  • Pelanggan nyata seperti Bolt.new dan iGent AI telah secara signifikan meningkatkan produktivitas dan kemampuan AI mereka dengan fitur ini
  • Saat ini, dukungan konteks panjang untuk Sonnet 4 tersedia dalam versi beta di Anthropic API dan Amazon Bedrock, dan akan segera hadir juga di Google Cloud

Dukungan konteks 1 juta token

  • Claude Sonnet 4 yang menggunakan Anthropic API kini mendukung konteks hingga 1 juta token
  • Dengan ini, dalam satu permintaan, model dapat menangani seluruh kode berisi lebih dari 75.000 baris atau beberapa makalah riset secara terpadu
  • Fitur beta konteks 1 juta token saat ini tersedia di Anthropic API dan Amazon Bedrock, dan Vertex AI di Google Cloud juga akan segera mendukungnya

Konteks yang lebih panjang, use case yang makin luas

  • Analisis kode skala besar: Seluruh codebase (termasuk source file, test, dan dokumentasi) dapat dimuat sekaligus, sehingga memungkinkan pemahaman struktur proyek, identifikasi keterkaitan antarfile, dan usulan perbaikan kode berdasarkan desain sistem
  • Ringkasan terpadu dokumen: Ratusan kontrak hukum, makalah, dan spesifikasi teknis dapat dianalisis sekaligus, lalu menghasilkan insight komprehensif sambil tetap mempertahankan hubungan antardokumen
  • Agen yang mempertahankan konteks: Bahkan dalam ratusan pemanggilan alat dan workflow multilangkah, dimungkinkan pengembangan agen percakapan yang mempertahankan status secara konsisten dengan menyertakan seluruh dokumentasi API, definisi alat, dan riwayat interaksi

Kebijakan harga API

  • Prompt hingga 200 ribu token: input $3/1 juta token, output $15/1 juta token
  • Prompt di atas 200 ribu token: input $6/1 juta token, output $22.5/1 juta token
  • Dengan menerapkan prompt caching, latensi dan biaya dapat dikurangi
  • Menggabungkan konteks 1 juta token dengan pemrosesan batch dapat memberikan penghematan biaya tambahan hingga 50%

Contoh penggunaan pelanggan

  • Bolt.new

    • Bolt.new mengintegrasikan Claude ke dalam platform pengembangan berbasis web dan mendorong inovasi dalam pengembangan web
    • "Dengan jendela konteks 1 juta token di Sonnet 4, developer kini dapat menangani proyek yang lebih besar dengan akurasi tinggi"
  • iGent AI

    • iGent AI yang berbasis di London, Inggris, mengubah isi percakapan menjadi kode yang dapat dijalankan melalui mitra AI bernama Maestro
    • "Kemampuan rekayasa perangkat lunak otonom yang sebelumnya tidak mungkin kini terwujud berkat konteks 1 juta token Sonnet 4, sehingga memungkinkan operasi sesi selama berhari-hari di atas codebase nyata"

Cara penggunaan dan rencana ke depan

  • Fitur konteks panjang saat ini tersedia dalam versi beta bagi pelanggan Tier 4 dan paket harga kustom di Anthropic API, dan direncanakan akan diperluas ke lebih banyak pengguna dalam beberapa minggu ke depan
  • Dukungan juga sudah tersedia di Amazon Bedrock, dan dukungan untuk Google Cloud Vertex AI juga akan segera hadir
  • Ada rencana untuk menghadirkan konteks panjang ke keluarga produk Claude lainnya juga
  • Informasi lebih rinci dapat dilihat di dokumentasi resmi dan halaman panduan harga

1 komentar

 
GN⁺ 2025-08-13
Komentar Hacker News
  • Saya merasa ada kebutuhan yang sangat mendesak agar LLM benar-benar mampu mempertahankan konteks dengan sangat baik dalam pekerjaan rekayasa perangkat lunak profesional; pengumuman bahwa model baru sedikit lebih baik tidak terlalu menarik di praktik nyata, tetapi harga adalah faktor penentu terbesar. Memang bagus kalau codebase saya bisa cukup masuk ke context window, tetapi karena harganya naik banyak, untuk saat ini saya pikir lebih masuk akal mengelola konteks dengan lebih baik. Fakta bahwa saya banyak memakai context window tentu menguntungkan penyedia layanan, tetapi saya merasa tetap perlu penilaian terpisah soal seberapa efektif Sonnet menjaga fokus, jadi sulit yakin pada nilai nyatanya.

    • Konteks itu ada di repo, dan kita harus menerima bahwa LLM tidak akan selalu bisa memiliki semua konteks yang dibutuhkan. Terutama repo besar bahkan tidak muat di satu mesin. Untuk menyelesaikan tugas tertentu, kita perlu menyingkirkan informasi yang tidak perlu agar bisa fokus; kalau semuanya dimasukkan justru fokusnya menurun. Dulu ukuran window memang terlalu kecil dan saya masih merasa sekarang pun masih kecil, tetapi pada akhirnya yang dibutuhkan adalah kemampuan memahami repo lewat pertanyaan yang tepat.

    • Kalau terlalu banyak konteks dimasukkan, risiko LLM membingungkan dirinya sendiri jadi lebih besar. Karena konteks yang panjang, kalau terus berjalan tanpa reset, fokusnya jadi buyar.

    • Menurut saya perlu melatih AI agar hanya menangani informasi yang sudah diabstraksikan, bukan seluruh codebase. Manusia nyata pun tidak bekerja dengan menyimpan seluruh kode di kepala, jadi LLM juga tidak harus begitu.

    • Setelah beberapa minggu bekerja dengan Claude Code belakangan ini, saya sampai pada kesimpulan bahwa nilai praktis AI agen justru negatif. Meski begitu, saya berencana mencobanya lagi 6-8 bulan lagi.

    • Menurut saya tujuan penggunaannya bukan sekadar memasukkan lebih banyak kode sekaligus ke dalam konteks. Untuk tugas tertentu memang ada konteks minimum yang dibutuhkan, tetapi model 1M context menuntut cara baru dalam memasukkan data. Kekuatan sebenarnya model ini ada pada masalah deep dive seperti eksplorasi iteratif dengan horizon panjang, in-context learning, dan rekonstruksi; misalnya ada pekerjaan yang bersifat lebar seperti menerapkan perubahan API ke 100 file, tetapi juga ada pekerjaan yang bersifat dalam seperti mencoba 15 pendekatan untuk menemukan solusi, dan Sonnet 1M tampak sangat unggul khususnya pada yang terakhir.

  • Mengusulkan beberapa tips untuk pengguna yang khawatir soal Claude Code dan pemakaian token

    1. Kumpulkan konteks yang dibutuhkan untuk tugas dan masukkan cukup banyak bagian codebase
    2. Di setiap titik henti logis, tekan double escape untuk kembali ke checkpoint yang konteksnya sudah penuh (tanpa memakai token itu lagi)
    3. Beri tahu Claude bahwa "developer telah menyelesaikan pekerjaan X", lalu masukkan itu ke konteks untuk mendapatkan umpan balik (ia cenderung menemukan lebih banyak masalah pada kode yang ditulis orang lain daripada kode yang ditulis developernya sendiri) Untuk memakai beberapa chat secara paralel, Anda bisa memanggil thread yang sama dengan /resume lalu double escape ke titik yang kaya konteks untuk mereset.
    • Saya memakai cara dengan memberi tahu Claude, “di sesi lain kamu menulis pekerjaan X”, lalu memakai konteks itu untuk bertanya atau meminta perubahan.

    • Saya juga sering begitu, tetapi tidak selalu berhasil. Kadang justru lebih membantu memakai Claude dengan tetap membawa konteks seluruh percakapan.

    • Latensinya jauh berkurang. Tidak perlu menunggu Claude baru memuat konteks lagi dari awal.

    • Proses ini terasa seperti astrologi untuk programmer (astrogy); kalau tidak diucapkan, kita tidak tahu apa yang akan terjadi saat agen mengerjakan codebase.

    • Menarik juga, saya penasaran kenapa Claude menemukan lebih banyak masalah ketika kode itu disebut seolah ditulis oleh developer lain.

  • Sejauh ini penggunaan yang paling membantu di Claude Code adalah langsung bertanya, "apakah ada bug di diff saat ini?". Lalu chatbot akan menganalisis perubahan itu dengan teliti, cepat menangkap bug halus yang biasanya butuh waktu lama dan banyak proses deploy untuk ditemukan, dan menjabarkan berbagai hal yang bisa meningkatkan ketepatan kode.

    • Menariknya, ia bekerja seperti yang saya inginkan bahkan tanpa diminta khusus untuk “berpikir lebih dalam”.

    • Dari pengalaman memakai ini juga di tugas non-coding, kreativitasnya kurang tetapi kemampuan sebagai pembaca yang kritis dan teliti sangat bagus.

    • Ada juga usulan agar fitur ini diimplementasikan secara konkret sebagai hook di Claude Code.

    • Saya sendiri memutuskan akan langsung mencoba cara ini mulai besok.

  • Pengalaman saya terhadap alat saat ini seperti berikut

    1. Sangat membantu saat memulai bahasa, framework, utilitas, atau proyek greenfield baru, meski setelah itu saya sambil parsing kode tetap bertanya-tanya apakah ini bisa dipercaya; tapi karena saya juga malas menafsirkannya sendiri, saya sering memilih percaya saja karena “toh jalan”
    2. Di bahasa atau framework yang sudah saya kuasai, justru produktivitas menurun. Waktu yang habis untuk menulis konteks yang cocok bagi prompt sama saja atau malah lebih besar daripada menulis langsung. Dalam situasi tertentu memang bekerja, tetapi sering keluar kode yang terasa seperti buatan junior dan agak nanggung. Orang yang kurang berpengalaman mungkin tidak akan langsung melihat masalahnya. Saya sudah memakainya untuk Typescript, Kotlin, Java, C++ di berbagai lingkungan seperti website, komponen ESPHome, backend API, node script, dan lain-lain. Kesimpulannya: bagus untuk hobi, script, dan prototipe, tetapi masih kurang untuk kode kelas enterprise.
    • Saya juga begitu (Cline + Sonnet & Gemini selama 1 tahun), lalu bertemu Claude Code, dan terutama setelah belajar cara benar-benar menjaga konteks tetap rapi, saya merasa ada terobosan nyata. Kuncinya adalah memperlakukan AI bukan sebagai generator kode melainkan sebagai arsitek dan implementer. Akhir-akhir ini saya selalu lebih dulu menyuruh CC menulis dokumen desain untuk pekerjaan yang akan kami lakukan, lalu menginstruksikannya agar merujuk pada kode dan dokumen itu. Saya meninjaunya sambil memastikan arah yang saya mau sudah jelas, lalu membagi langkah pekerjaan menjadi chunk, dan tiap chunk dipecah lagi. Setelah definisi awal selesai, saya hapus konteks, lalu untuk tiap langkah saya suruh ia membaca dokumen dan mengimplementasikannya. Jika perlu, saya arahkan revisi atau perbarui dokumennya lalu mulai lagi hanya untuk langkah itu. Tiap langkah dikomit, konteks dibersihkan, lalu lanjut ke langkah berikutnya. Dengan cara begini, fitur yang dulu butuh 2-3 hari bisa dibuat dalam sehari. Hasil akhirnya juga mencakup dokumen yang tervalidasi, unit test, Storybook, aksesibilitas (arai dan sebagainya), dan keluaran yang tertata. Di akhir saya juga minta code review dari model lain. Walau saat ini belum menghasilkan kecepatan yang benar-benar luar biasa, saya menganggap ini investasi masa depan atas kemampuan saya untuk menghadapi tool yang terus berkembang.

    • Menurut saya tool ini rasanya mirip scaffolding rails new pada Ruby on Rails dulu. LLM sangat pas untuk area yang cukup memahami dokumentasi resmi tool, yaitu membuat kerangka awal proyek. Sebaliknya, untuk sistem legacy atau proyek dengan banyak kebutuhan eksternal, manfaatnya lebih kecil. Untuk tool yang berubah cepat seperti Databricks, hampir tidak berguna. Kalau nama/sintaks/fitur berubah setelah data pelatihannya, kita harus sangat aktif memasukkan dokumentasi real-time ke prompt agar setidaknya ada peluang berhasil.

    • Workflow saya memakai Claude desktop dan filesystem dari server mcp bersama-sama. Saya beri tahu Claude path file terkait lalu memerintahkannya menyelesaikan task. Claude membaca dan menganalisis file langsung, lalu melakukan perubahan/penambahan yang dibutuhkan. Biasanya saya hanya menempelkan beberapa build error lalu ia memperbaikinya lagi. Saya juga terkesan karena ia menulis kode baru sambil mempertahankan gaya kode yang sudah ada. Saya sudah memakainya di Typescript dan C#. Dalam pengalaman saya, hasilnya tidak berhenti di level hobi.

    • Saya bukan programmer, tetapi pekerjaan saya memerlukan kode Python dan bash. Saya juga mengelola beberapa proyek pribadi dan website. Berkat Claude Code, saya bisa membuat proyek-proyek kecil yang dulu tidak bisa saya kerjakan karena keterbatasan kemampuan dan waktu. Sekarang saya bahkan bisa memperbaiki lingkungan emacs saya sendiri. Ia juga dengan lancar membuat fungsi lisp. Ini tool yang sempurna untuk saya. Hal-hal yang sebelumnya buntu sekarang bisa dibereskan dengan lancar dan hidup jadi lebih mudah.

    • Saya sudah memakainya di Typescript, Go, SQL, dan Rust. Rust terlalu kompleks sehingga hasilnya penuh error, dan saya ingin proyeknya cepat selesai (meski proyeknya sendiri memang sangat sulit). Go sangat sederhana sebagai bahasa sehingga sangat produktif, kecepatannya 2x. Typescript lumayan untuk komponen React/animasi. SQL/PostgreSQL juga sama. Saya tidak suka boilerplate untuk stored procedure, dan LLM menguranginya sehingga pergelangan tangan saya tidak terlalu pegal.

  • Jelas bagus kalau pilihan semakin banyak, tetapi di saat yang sama kalau terlalu banyak konteks dimasukkan, kualitas hasil LLM bisa turun karena LLM jadi lebih mudah terdistraksi. Kalau pengguna tidak memahami trade-off ini dan hanya bergantung pada mode otomatis, saya khawatir pada kualitas kode yang ditulis dengan Claude Code.

    • Ada beberapa tautan artikel yang layak dirujuk

    • Sampai sekarang long context belum terintegrasi ke Claude Code. Katanya mereka “sedang meninjau cara menerapkan long context ke produk lain” juga. Saya rasa mereka sudah menyadari ini sebagai masalah dan sedang memikirkan solusinya. Kelihatannya mereka ingin menyiapkan solusi sebelum para pengguna menimbulkan biaya tambahan di paket mahal.

    • Saya bertanya-tanya alternatif apa yang Anda rekomendasikan. Saya mulai terbiasa dengan Claude Code, tetapi masih belum mahir soal best practice.

    • Tim Chroma sedang meneliti masalah ini dan data kuantitatif akan segera keluar.

  • Ada yang bertanya apakah Opus tidak lebih baik; saat token habis dan sistem memaksa pindah ke Sonnet, perbedaannya terasa besar. Dari posisi seseorang yang kariernya sudah berkembang, ide berlimpah, tetapi coding terasa berat, sejak Claude muncul saya merasa bisa melesat dalam mewujudkan ide sekaligus testing/perbaikan bug.

    • Tetapi saya juga khawatir kalau terus bergantung hanya pada Claude Code, kemampuan development saya yang sebenarnya akan menurun.
  • Masalah besar pada aplikasi chat (ChatGPT, Claude.ai) adalah perilaku aneh terkait context window (terpotong tiba-tiba, diringkas, “ghost snippet” muncul lagi, dan sebagainya). Mungkin akan lebih nyaman kalau pengguna bisa langsung memilih apakah ingin mempertahankan konteks terus atau memulai chat baru, tetapi pada praktiknya ini sulit dihindari karena batasan paket dan komputasi. Kenyataannya, kita memang perlu memakai tool developer (Google AI Studio) atau aplikasi chat yang membungkus API agar bisa mengirim seluruh konteks secara utuh. Jika membuat aplikasi chat kustom, kita bahkan bisa menyisipkan timestamp di tiap pesan dan menginstruksikan LLM, “setiap 10 menit ringkas isi periode itu ke baris baru di tabel Markdown”.

    • Ada juga saran bahwa daripada berdasarkan rentang waktu, mungkin lebih baik “berdasarkan jumlah pesan”, misalnya “setiap pesan ke-10 rangkum ke blah-blah.md”.
  • Saya rasa paket harga kali ini adalah kasus pertama yang secara terbuka mengakui bahwa biaya melonjak seperti ‘kuadrat’ ketika jumlah token bertambah. Ini tampaknya pertama kalinya penyedia LLM merefleksikan struktur harga nonlinier. Pendekatan ini mirip dengan scaling law inferensi yang sudah kita kenal.

  • Juga mengarahkan ke diskusi topik terkait

  • Fitur ini keren, tetapi saya penasaran apa yang bisa dilakukan untuk meningkatkan kecepatan inferensi. Secara pribadi, 200K konteks sudah cukup bagi saya; saya hanya ingin respons yang lebih cepat. Saya rasa banyak orang juga akan puas kalau ukuran konteks lebih kecil asalkan agen bisa bekerja jauh lebih cepat (saat ini harus menunggu 2-3 menit per prompt).