Naik ke Claude Opus 4.7 tidak otomatis berarti semua prompt lama harus dibuang. Bagi tim yang sudah memakai Claude untuk produk internal, bot layanan pelanggan, pipeline dokumen, RAG, atau coding agent, risiko yang lebih sering muncul justru tersembunyi: kontrol masih menempel di parameter API lama, estimasi token sudah tidak akurat, atau instruksi tool terlalu samar.

Dokumentasi Anthropic untuk migrasi Opus 4.6 ke Opus 4.7 menyebut Opus 4.7 mempertahankan kemampuan platform utama Opus 4.6, tetapi migrasi tetap perlu memperhatikan thinking configuration, sampling-parameter removal, task budgets, dan tokenization. ^[15][26]

Panduan ini berangkat dari skenario Opus 4.6 ke Opus 4.7. Jika Anda datang dari model Claude yang lebih lama, gunakan daftar ini sebagai titik awal regression test, lalu tetap bandingkan perbedaan dari versi asal Anda. ^[15]

Mulai dari memetakan jenis workflow

Beban migrasi sangat bergantung pada cara Anda memakai Claude. Chat manual dan draf dokumen biasanya cukup diuji dengan prompt yang sering dipakai. Namun workflow API, RAG, agent, coding, vision, atau computer-use perlu audit parameter, kebijakan tool, dan model biaya yang lebih teliti. ^{[1][4][15][26][27]}

Jenis penggunaan	Yang paling perlu dicek sebelum migrasi
Chat manual, draf dokumen, kerja pengetahuan	Prompt rutin, gaya bahasa, format output, aturan kutipan, dan aturan penggunaan tool
Messages API / SDK	Model ID, konfigurasi thinking, parameter sampling, token counting, dan error handling
Tool use / RAG / web search	Kapan wajib memakai tool, kapan tidak boleh menebak, dan fallback saat tool gagal
Agent tugas panjang / coding agent	Effort, task budget, token budget, latensi, dan regression eval
Gambar, screenshot, PDF, computer-use	Resolusi gambar, aturan downsample, biaya token, dan kualitas pengenalan visual

1. Bereskan breaking change thinking terlebih dulu

Langkah pertama bukan mengutak-atik prompt, melainkan memeriksa konfigurasi API. Anthropic menyatakan developer dapat memakai claude-opus-4-7 melalui Claude API; bila aplikasi Anda menuliskan model ID secara eksplisit, masukkan perubahan ini ke uji shadow atau rollout kecil sebelum dibuka ke semua traffic. ^[10]

Bagian yang lebih kritis adalah konfigurasi thinking. Migration guide Anthropic menyebut konfigurasi extended thinking lama berbasis budget_tokens tidak lagi didukung pada Claude Opus 4.7 atau model setelahnya, dan akan mengembalikan error 400. Arah migrasinya adalah adaptive thinking. ^[15]

Yang perlu dilakukan:

• Cari budget_tokens di kode, SDK wrapper, prompt runner, konfigurasi platform internal, dan template request.
• Hapus konfigurasi extended thinking lama, lalu gunakan adaptive thinking sesuai API atau provider yang Anda pakai. ^[15]
• Jangan lagi menjadikan fixed thinking token budget sebagai tuas utama. Kalibrasikan kedalaman tugas lewat effort, task budget, batasan prompt, dan eval yang terdokumentasi. ^[26][27]

Anthropic juga menempatkan effort levels, task budgets, thinking configuration, sampling-parameter removal, dan tokenization sebagai perubahan API yang perlu diperiksa saat migrasi dari Opus 4.6 ke Opus 4.7. ^[26]

2. Pindahkan kontrol sampling ke prompt dan eval

Jika workflow lama mengandalkan temperature, top_p, atau top_k untuk mengatur kreativitas, stabilitas, atau variasi output, jangan anggap perilakunya akan sama setelah migrasi. Dokumentasi prompting Anthropic mencantumkan sampling-parameter removal sebagai hal yang perlu diperhatikan pada migrasi Opus 4.7; panduan migrasi OpenRouter untuk Claude 4.7 juga menandai sampling parameters removed, adaptive-only thinking, dan perilaku effort yang spesifik per provider. ^[26][14]

Dampaknya paling terasa pada tiga jenis tugas:

• Penulisan kreatif dan copy marketing, yang sebelumnya mungkin mengandalkan sampling lebih tinggi untuk variasi.
• Customer support, compliance, klasifikasi, atau ekstraksi data, yang sebelumnya mungkin mengandalkan sampling rendah untuk konsistensi.
• Batch generation, yang sebelumnya mungkin memakai parameter sampling untuk mengatur ragam jawaban.

Setelah migrasi, kontrol yang lebih sehat adalah prompt dan eval. Tuliskan gaya, format, larangan, dan kriteria sukses secara eksplisit. Gunakan few-shot example untuk mengunci pola output. Untuk ekstraksi, klasifikasi, dan laporan, gunakan format terstruktur. Lalu ubah golden examples dari Claude versi lama menjadi regression eval untuk membandingkan akurasi, kepatuhan format, biaya, dan latensi Opus 4.7. ^[26]

3. Tool use dan RAG: tulis policy seperti SOP

Untuk workflow RAG, web search, atau tool use, masalah biasanya bukan apakah model bisa memanggil tool, melainkan apakah aturan pemakaiannya cukup tegas. Dalam praktiknya, RAG adalah pola mengambil dokumen dari knowledge base atau sumber eksternal, lalu memasukkannya ke konteks model sebelum model menjawab.

Anthropic menyatakan model Claude terbaru dilatih untuk mengikuti instruksi secara presisi dan mendapat manfaat dari arahan eksplisit untuk memakai tool tertentu. Dokumen yang sama juga menyarankan adaptive thinking untuk beban kerja agentic seperti multi-step tool use, coding task kompleks, dan long-horizon agent loops. ^[1]

Aturan seperti ini sebaiknya ditulis langsung di system prompt atau policy workflow:

• Untuk informasi real-time, harga, kebijakan, versi produk, atau dokumen eksternal, wajib gunakan tool pencarian yang ditentukan.
• Jika knowledge base internal tidak memuat jawaban, model harus menyatakan bahwa informasi tidak dapat dikonfirmasi, bukan menebak.
• Jika hasil tool saling bertentangan, tampilkan konflik terlebih dahulu, lalu berikan kesimpulan konservatif.
• Jawaban akhir harus membedakan mana informasi dari tool dan mana penalaran model.

Ini sering lebih penting daripada sekadar mengganti model ID. Tool policy menentukan apakah agent akan melewatkan data penting, menebak saat bukti kurang, atau terlalu percaya diri saat hasil tool bertentangan. ^[1]

4. Agent tugas panjang: hitung biaya sebagai satu tugas, bukan satu jawaban

Opus 4.7 membawa perhatian khusus pada kontrol anggaran untuk long-running task dan agentic workflow. Dokumen What’s new Anthropic menyebut Opus 4.7 memperkenalkan task budgets. Dokumentasi lain menjelaskan bahwa parameter effort membantu menukar kemampuan dengan kecepatan dan token spend, sementara task budget memberi Claude perkiraan kasar tentang token yang tersedia untuk keseluruhan tugas. ^[4][27]

Jika workflow Anda berupa coding agent, research agent, browser agent, pemrosesan data panjang, atau loop multi-tool, pecah anggaran menjadi tiga lapis:

• Budget respons tunggal: berapa banyak token yang boleh dipakai output akhir.
• Budget reasoning dan tool: berapa banyak reasoning, tool call, serta tool result yang boleh dipakai dalam tugas bertahap.
• Budget tingkat tugas: batas biaya dan latensi untuk seluruh agent loop.

Jangan hanya memakai batas output akhir untuk memperkirakan biaya agent loop. Pada tugas panjang, biaya dapat datang dari banyak pemanggilan tool, hasil tool yang dimasukkan kembali ke konteks, parsing gambar atau PDF, retry, dan output akhir. Task budgets dan tokenizer baru di Opus 4.7 membuat benchmark ulang menjadi wajib untuk workflow seperti ini. ^[4][27]

5. Token, RAG, cache, dan batch: benchmark ulang

Ini bagian yang sering diremehkan. Anthropic menyatakan tokenizer baru Opus 4.7 dapat memakai sekitar 1x hingga 1,35x jumlah token saat memproses teks dibanding model sebelumnya, tergantung konten. Endpoint /v1/messages/count_tokens juga akan mengembalikan jumlah token berbeda untuk Opus 4.7 dibanding Opus 4.6, sehingga Anthropic menyarankan menghitung ulang dengan endpoint tersebut. ^[4]

Sebelum menaikkan traffic, uji ulang:

• Ukuran chunk dan overlap pada RAG.
• Batas pemotongan dokumen panjang.
• Panjang conversation memory.
• Estimasi biaya dan hit rate prompt caching.
• Batas biaya batch job.
• Ukuran hasil tool yang boleh dimasukkan kembali pada setiap putaran agent.
• Strategi preprocessing gambar dan PDF.

Jika workflow lama sudah dekat dengan batas biaya atau context limit, jangan memakai angka token lama apa adanya. Jalankan benchmark pada prompt inti, contoh dokumen panjang, dan tugas bertraffic tinggi, lalu putuskan apakah chunking, truncation, atau desain cache key perlu diubah. ^[4]

6. Gambar, screenshot, dan PDF: jangan selalu kirim resolusi maksimal

Dokumen Opus 4.7 menyebut dukungan high-resolution image. Namun dokumentasi Anthropic juga mengingatkan: jika fidelity gambar tambahan tidak dibutuhkan, turunkan resolusi gambar sebelum mengirimnya ke Claude agar penggunaan token tidak meningkat. ^[4][27]

Perubahan ini penting untuk tiga kategori workflow:

• Pemahaman screenshot, misalnya UI QA, screenshot tabel, atau analisis dashboard.
• Pemrosesan dokumen visual, misalnya PDF hasil scan, screenshot kontrak, atau halaman presentasi.
• Computer-use dan browser automation, saat model perlu memahami posisi tombol, form, pesan error, atau elemen layar.

Jika Anda naik dari Opus 4.6, kemampuan PDF dan vision masih termasuk dalam kumpulan kemampuan platform utama yang sama. Yang perlu diuji ulang adalah ukuran gambar yang dikirim, apakah high resolution benar-benar dibutuhkan, dan apakah setelah downsample teks kecil serta elemen UI penting masih terbaca. ^[15][27]

7. Provider atau gateway internal: jangan berasumsi mapping parameter sama

Jika Anda tidak langsung memanggil Anthropic API, melainkan lewat OpenRouter, platform cloud, multi-model router, atau gateway internal, jangan berasumsi nama field, parameter yang diabaikan, dan perilaku effort sama persis dengan Anthropic API. Panduan migrasi OpenRouter untuk Claude 4.7 secara terpisah mencantumkan sampling parameters removed, adaptive-only thinking, dan provider-specific effort behavior. ^[14]

Karena itu, selain membaca dokumentasi Anthropic, baca juga migration note provider yang benar-benar Anda pakai. Ini penting untuk gateway yang membungkus parameter upstream menjadi field internal. Saat migrasi, pastikan field mana yang masih aktif, mana yang diabaikan, dan mana yang bisa memicu error. ^[14]

Yang biasanya tidak perlu dibongkar total

Jika migrasi Anda dari Opus 4.6 ke Opus 4.7, platform dasarnya tidak berubah total. Migration guide Anthropic menyatakan Opus 4.7 mendukung fitur utama yang sama dengan Opus 4.6, termasuk context window 1 juta token, output maksimal 128k token, adaptive thinking, prompt caching, batch processing, Files API, PDF support, vision, serta kumpulan lengkap server-side dan client-side tools. ^[15]

Artinya, prioritas pertama biasanya bukan membangun ulang hal-hal ini:

• Alur upload dokumen dan Files API.
• Ketersediaan kemampuan PDF atau vision.
• Ketersediaan prompt caching atau batch processing.
• Kemampuan tool calling itu sendiri.
• Kemampuan long context itu sendiri.

Yang perlu dikalibrasi ulang adalah cara Anda mengontrol kemampuan tersebut: kapan tool wajib dipakai, berapa banyak token yang boleh dibakar, effort setinggi apa yang masuk akal, sebesar apa gambar dikirim, dan apa fallback saat proses gagal. ^{[1][4][15][27]}

Checklist migrasi praktis

Gunakan daftar ini untuk tim engineering, AI platform owner, atau siapa pun yang memegang Claude workflow di produksi.

API dan parameter

• Ganti model ke claude-opus-4-7, lalu lakukan small-traffic test atau shadow eval; Anthropic menyatakan developer dapat memakai model ID ini melalui Claude API. ^[10]
• Cari thinking, budget_tokens, dan wrapper extended thinking lama; migrasikan ke adaptive thinking karena Opus 4.7 atau model setelahnya tidak mendukung konfigurasi lama dan akan mengembalikan error 400. ^[15]
• Cari pemakaian temperature, top_p, top_k, atau kontrol sampling serupa; pindahkan kontrol stabilitas ke prompt, few-shot, schema, dan eval. ^[26]
• Jika memakai OpenRouter atau proxy layer lain, periksa migration guide provider dan mapping parameternya. ^[14]

Prompt dan tool use

• Tuliskan kapan model wajib memakai tool di system prompt; dokumentasi Anthropic menyebut model Claude terbaru mendapat manfaat dari instruksi tool-use yang eksplisit. ^[1]
• Tuliskan kapan model tidak boleh menebak dan bagaimana menjawab saat informasi tidak cukup.
• Definisikan fallback saat tool gagal, hasil tool bertentangan, atau data eksternal tidak tersedia.
• Untuk ekstraksi, klasifikasi, dan pembuatan laporan, tetapkan format output terstruktur.

Agent dan coding workflow

• Kalibrasi ulang effort dan task budget untuk coding agent, research agent, dan browser agent; dokumentasi Anthropic mengaitkan adaptive thinking dengan multi-step tool use, complex coding tasks, dan long-horizon agent loops. ^[1]
• Evaluasi penggunaan task budgets; dokumen Opus 4.7 mencantumkan task budgets dan mengingatkan bahwa token counting berbeda dari model sebelumnya. ^[4]
• Jangan menghitung biaya agent loop hanya dari output akhir; masukkan tool call, tool result, retry, reasoning, dan output akhir ke model biaya. ^[4][27]
• Bangun regression eval dari kasus sukses Claude versi lama, lalu bandingkan success rate, kepatuhan format, latensi, dan biaya Opus 4.7.

Token, dokumen, dan gambar

• Gunakan /v1/messages/count_tokens untuk menghitung ulang prompt inti, RAG chunks, dokumen panjang, dan batch job. ^[4]
• Uji ulang chunk size, truncation threshold, conversation memory, dan strategi prompt caching. ^[4]
• Buat policy downsample untuk gambar, screenshot, dan halaman PDF; jika fidelity tinggi tidak dibutuhkan, turunkan resolusi sebelum dikirim untuk mengendalikan penggunaan token. ^[27]

Urutan rollout yang paling aman

Cara paling aman bukan mengganti semuanya sekaligus. Jalankan bertahap:

1. Static scan: cari model ID, thinking, sampling, token counting, preprocessing gambar, dan parameter spesifik provider.
2. Small eval: pakai golden set lama untuk membandingkan kualitas output, format, tool use, biaya, dan latensi.
3. Perbaiki prompt berisiko tinggi: mulai dari tool use, RAG, coding agent, ekstraksi data, dan tugas compliance.
4. Rollout bertahap: pantau penggunaan token, jumlah tool call, error rate, latensi, dan laporan manusia.

Intinya: migrasi ke Claude Opus 4.7 bukan soal menulis ulang semua prompt, melainkan membuat kontrol yang dulu tersirat menjadi eksplisit. Thinking pindah ke adaptive thinking, sampling dikendalikan lewat prompt dan eval, agent panjang diberi budget yang jelas, serta biaya token dan gambar dibenchmark ulang. Dengan begitu, workflow lama tetap terkendali saat model baru mulai dipakai di produksi.