Mengarahkan pemikiran

Pemikiran Claude bersifat adaptif: model mengevaluasi setiap permintaan dan memutuskan sendiri apakah akan berpikir dan seberapa banyak. Anda menetapkan sebuah intent, secara opsional menentukan effort, dan model mengalokasikan penalaran di tempat yang menurutnya penalaran akan membantu.

Ini membuat pemikiran sangat cocok untuk beban kerja yang mencampur permintaan sepele dan kompleks, serta untuk alur kerja agentik jangka panjang di mana jumlah penalaran yang tepat bervariasi dari langkah ke langkah.

Untuk cara mengaktifkan pemikiran, cara membaca output pemikiran, dan output pemikiran pada Claude Fable 5 dan Claude Mythos 5, lihat ikhtisar Pemikiran. Halaman ini membahas bagaimana Claude memutuskan kapan harus berpikir, cara mengarahkan keputusan tersebut, serta mekanisme caching, biaya, dan harga yang mengikutinya.



Bagaimana Claude memutuskan kapan harus berpikir

Pemikiran bersifat opsional bagi model. Pada setiap permintaan, Claude menimbang kompleksitas input dan memutuskan apakah penalaran yang lebih dalam akan meningkatkan jawaban. Pertanyaan faktual sederhana mungkin mendapat respons langsung tanpa blok pemikiran sama sekali; soal matematika multilangkah atau tugas debugging yang rumit memicu penalaran yang lebih dalam.

Keputusan terjadi per permintaan. Percakapan yang sama dapat berisi giliran dengan dan tanpa pemikiran, dan giliran di mana Claude memilih untuk tidak berpikir tidak berisi blok pemikiran. Jangan membangun logika aplikasi yang mengasumsikan setiap giliran asisten dimulai dengan blok pemikiran.

Kontrol utama atas keputusan ini adalah parameter effort, yang bertindak sebagai panduan lunak untuk seberapa bersedia Claude berpikir dan seberapa dalam; lihat Tingkat effort di halaman ini untuk apa yang dilakukan setiap tingkat.

Jika Anda ingin Claude lebih jarang berpikir, turunkan tingkat effort sebelum beralih ke pengarahan berbasis prompt.

Pemikiran juga menyisip dengan penggunaan alat secara otomatis: Claude dapat berpikir di antara panggilan alat, merefleksikan setiap hasil alat sebelum memutuskan apa yang harus dilakukan selanjutnya (interleaved thinking). Anda tidak memerlukan header beta atau konfigurasi tambahan apa pun untuk ini.

Untuk gambaran lengkap tentang bagaimana konfigurasi pemikiran dan parameter effort berinteraksi, lihat Pemikiran dan effort.



Mengarahkan seberapa sering Claude berpikir

Apakah Claude berpikir pada giliran tertentu dapat diarahkan melalui prompt. Effort menetapkan postur keseluruhan, tetapi Anda juga dapat membentuk keputusan secara langsung dengan panduan bahasa alami, baik secara global di prompt sistem maupun per pesan dari giliran pengguna.

Gunakan kedua tuas tersebut bersama-sama dalam urutan ini:

1. Tetapkan tingkat effort yang sesuai dengan keseimbangan default kualitas dan latensi beban kerja Anda.
2. Tambahkan panduan prompt hanya jika pemicuan Claude masih tidak sesuai dengan kebutuhan Anda pada tingkat tersebut.

Untuk panduan prompting yang lebih luas dengan pemikiran, lihat memanfaatkan kemampuan thinking dan interleaved thinking.



Tingkat effort

Effort adalah tuas pengarahan utama untuk pemikiran. Setiap tingkat menetapkan default yang berbeda untuk seberapa sering Claude berpikir dan seberapa dalam:

Tabel ini menjelaskan bagaimana setiap tingkat mengubah perilaku pemikiran. Untuk panduan tentang tingkat mana yang harus dipilih untuk beban kerja tertentu, termasuk rekomendasi per model, lihat Kapan menyesuaikan parameter effort di halaman effort.

Effort ditetapkan di output_config.effort, bukan di dalam objek thinking; untuk contoh lengkap per bahasa, lihat Effort.

{
  "model": "claude-opus-4-8",
  "max_tokens": 4096,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

Ketersediaan tingkat bervariasi menurut model; tabel ketersediaan effort di halaman effort adalah otoritas untuk tingkat mana yang didukung setiap model.



Panduan prompt sistem

Panduan prompt sistem menggeser ambang pemikiran Claude untuk setiap permintaan dalam percakapan. Jika Claude berpikir lebih sering daripada yang dibutuhkan beban kerja Anda, tambahkan panduan seperti ini ke prompt sistem Anda:

Extended thinking adds latency and should only be used when it
will meaningfully improve answer quality, typically for problems
that require multistep reasoning. When in doubt, respond directly.

Untuk mendorong pemikiran sebagai gantinya, gunakan frasa seperti:

This task involves multistep reasoning. Think carefully before responding.

Efektivitas pengarahan dapat sensitif terhadap pilihan kata yang tepat. Jika satu frasa tidak menghasilkan perilaku yang Anda inginkan, coba varian yang lebih langsung.



Pengarahan per pesan

Anda juga dapat mengarahkan pemikiran berdasarkan per pesan dari giliran pengguna, secara independen dari prompt sistem. Menambahkan "Please think hard before responding." ke pesan pengguna mendorong Claude untuk berpikir pada giliran tersebut; "Answer directly without deliberating." menekannya.

Pengarahan per pesan berguna ketika hanya beberapa permintaan dalam percakapan yang memerlukan penalaran diperpanjang. Sebuah agent harness, misalnya, dapat menambahkan frasa pendorong pada langkah perencanaan dan frasa penekan pada konfirmasi rutin, tanpa menyentuh prompt sistem atau mengubah parameter permintaan apa pun di antara giliran.



Verifikasi pengarahan pada beban kerja Anda

Pengarahan berbasis prompt mengubah perilaku model, jadi perlakukan seperti perubahan prompt lainnya: ukur sebelum Anda merilis. Jalankan sampel representatif dari lalu lintas Anda dengan dan tanpa panduan, dan bandingkan seberapa sering pemikiran terpicu (keberadaan blok pemikiran dalam respons), penggunaan token output, latensi, dan kualitas jawaban pada kasus-kasus yang penting bagi Anda.



Mekanisme

Tiga mekanisme mengikuti dari Claude yang mengelola pemikirannya sendiri: validasi giliran, caching prompt, dan cara Anda membatasi biaya.



Validasi giliran

Giliran asisten tidak perlu dimulai dengan blok pemikiran. (Model yang menggunakan budget pemikiran manual lama mewajibkan giliran asisten terakhir dari permintaan dengan pemikiran aktif dimulai dengan blok pemikiran; lihat Struktur giliran dalam mode manual.)

Untuk aplikasi multi-giliran, ini berarti Anda dapat mengirimkan kembali riwayat percakapan dalam bentuk apa pun yang Anda miliki:

• Giliran asisten di mana Claude memilih untuk tidak berpikir adalah riwayat yang valid apa adanya.
• Anda dapat melanjutkan percakapan yang dimulai tanpa pemikiran, atau yang menggunakan konfigurasi pemikiran yang berbeda, tanpa menulis ulang riwayatnya.
• Riwayat yang dirakit dari sumber campuran tidak perlu blok pemikiran disisipkan kembali di awal setiap giliran asisten untuk lolos validasi.

Pelonggaran ini tentang validasi, bukan tentang apa yang harus Anda kirim. Ketika Anda memiliki blok pemikiran, kirimkan kembali tanpa modifikasi, terutama selama penggunaan alat, di mana blok tersebut membawa penalaran di balik panggilan alat Claude. Lihat ikhtisar Pemikiran untuk aturan lengkapnya.



Caching prompt

Permintaan berurutan yang mempertahankan konfigurasi pemikiran dan tingkat effort yang sama mempertahankan caching prompt; lihat Pemikiran dan caching prompt untuk aturan lengkapnya. Nilai effort yang diselesaikan dirender ke dalam prompt, jadi mengubahnya di antara permintaan membatalkan breakpoint cache, sama seperti mengubah parameter lama budget_tokens pada model yang menggunakannya. Menetapkan effort secara eksplisit ke default model setara dengan menghilangkannya dan tidak merusak cache.

Konsekuensi praktisnya: pilih konfigurasi pemikiran dan tingkat effort per percakapan dan pertahankan. Jika beberapa giliran membutuhkan lebih banyak atau lebih sedikit pemikiran, arahkan dengan prompting per pesan: panduan yang ditambahkan ke pesan pengguna terbaru membiarkan breakpoint cache sebelumnya tetap utuh, sedangkan perubahan konfigurasi atau effort tidak.

Contoh berikut mendemonstrasikan pembatalan dengan skrip multi-giliran yang dapat Anda jalankan sendiri:



Kontrol biaya

Anda tidak menetapkan budget token pemikiran. Dua kontrol membatasi biaya:

• max_tokens adalah batas keras pada total output untuk permintaan, gabungan pemikiran dan teks respons. Claude tidak pernah menghasilkan melewatinya. Dalam loop penggunaan alat, setiap permintaan dalam giliran memiliki max_tokens sendiri, jadi ini tidak membatasi pengeluaran seluruh giliran.
• effort adalah panduan lunak tentang seberapa banyak dari output tersebut yang dialokasikan Claude untuk pemikiran. Ini membentuk perilaku tetapi tidak menjamin jumlah token.

Karena pemikiran dihitung terhadap max_tokens, tetapkan cukup tinggi untuk menyisakan ruang bagi penalaran dan jawaban. max_tokens yang diukur untuk respons tanpa pemikiran sering kali terlalu kecil begitu Claude mulai berpikir pada permintaan yang sulit.

Pada effort high dan di atasnya, Claude mungkin berpikir secara ekstensif dan lebih mungkin menghabiskan budget. Jika Anda melihat stop_reason: "max_tokens" dalam respons, Anda memiliki dua solusi:

• Naikkan max_tokens untuk memberi model lebih banyak ruang untuk pemikiran plus jawaban.
• Turunkan tingkat effort sehingga Claude berpikir lebih sedikit dan menyisakan lebih banyak budget untuk teks respons.

Mana yang tepat tergantung pada apakah respons yang terpotong membutuhkan penalaran tersebut. Jika kualitas pada permintaan tersebut penting, naikkan batasnya; jika terlalu banyak dipikirkan, turunkan effort-nya.



Harga

Pemikiran dikenakan biaya untuk:

• Token yang digunakan Claude saat berpikir (ditagih sebagai token output)
• Blok pemikiran dari giliran asisten sebelumnya yang tetap berada dalam konteks, sesuai default preservasi: semua giliran secara default pada model keep-all, hanya giliran terakhir di tempat lain (ditagih sebagai token input)
• Token output teks standar

Apa yang ditagihkan kepada Anda sama terlepas dari pengaturan display; hanya apa yang Anda lihat yang berubah:

Untuk melihat berapa banyak token output yang ditagih yang dihabiskan untuk penalaran internal, baca usage.output_tokens_details.thinking_tokens dalam respons. Nilai ini mencerminkan penalaran mentah yang dihasilkan model (bukan teks ringkasan yang dikembalikan dalam body) dan selalu kurang dari atau sama dengan output_tokens. Kurangkan dari output_tokens untuk memperkirakan bagian output yang bukan penalaran. Saat streaming, rincian ini hanya muncul pada event message_delta terakhir.

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

output_tokens tetap menjadi total inklusif dan otoritatif yang digunakan untuk penagihan. output_tokens_details adalah rincian hanya-baca untuk observabilitas. Untuk informasi harga lengkap termasuk tarif dasar, penulisan cache, cache hit, dan token output, lihat Harga.



Langkah selanjutnya