---
title: "Cara Memeriksa Prompt dan Harness Sebelum Beralih ke Claude Opus 5"
locale: id
category: how_to
category_name: "Panduan"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/claude-opus-5-verification-and-migration-guide
published_at: 2026-07-28T11:42:11+09:00
---

# Cara Memeriksa Prompt dan Harness Sebelum Beralih ke Claude Opus 5

> Menjelaskan cara membedakan karakteristik Claude Opus 5 yang diklaim dalam materi yang diberikan dari informasi yang dapat diverifikasi, serta cara merancang ulang prompt, harness, dan sistem evaluasi saat mengadopsi model generasi baru. Status peluncuran, harga, dan nama model harus selalu diperiksa melalui daftar model dan tabel harga resmi Anthropic.

## Key Points

- Tanggal peluncuran, harga, dan performa Claude Opus 5, Fable 5, serta Sonnet 5 yang tercantum dalam materi harus diverifikasi secara independen melalui sumber resmi sebelum digunakan.
- Alih-alih langsung menyalin prompt lama ke model baru, kualitas, biaya, dan latensi harus diukur kembali menggunakan data pekerjaan nyata.
- Instruksi verifikasi yang tumpang tindih dan pemanggilan subagent tanpa batas dapat meningkatkan biaya serta waktu eksekusi tanpa memperbaiki hasil.
- Pemisahan instruksi sistem, aturan proyek, Skill yang dimuat saat diperlukan, dan referensi teknis memudahkan pengelolaan konteks.
- Dibandingkan peringkat benchmark, evaluasi internal yang mencerminkan pekerjaan nyata dan biaya kegagalan organisasi memberikan dasar yang lebih langsung untuk memilih model.

Materi yang diberikan memperkenalkan Claude Opus 5 sebagai model yang disesuaikan untuk pekerjaan enterprise dan agen sehari-hari, serta menyatakan bahwa prompt dan harness yang ada perlu dirancang ulang untuk generasi baru Claude. Namun, **tanggal rilis, harga, performa, dan pernyataan mitra terkait Claude Opus 5, Fable 5, dan Sonnet 5 yang disebutkan dalam materi belum diverifikasi secara independen hanya berdasarkan informasi yang diberikan dalam tulisan ini.** Secara khusus, perlu diperiksa terlebih dahulu dalam daftar model resmi apakah `Fable` merupakan nama model resmi Anthropic.

Oleh karena itu, dokumen ini tidak mengulangi informasi rilis tersebut sebagai fakta yang telah dipastikan, tetapi mengelompokkan hal-hal yang perlu dikonfirmasi melalui dokumentasi resmi dan prosedur verifikasi yang dapat diterapkan dalam peralihan model aktual.

## Informasi rilis yang harus diperiksa terlebih dahulu

Sebelum menerapkan model baru pada API, aplikasi Claude, atau Claude Code, hal-hal berikut harus dicocokkan dengan dokumentasi resmi Anthropic dan layar pemilihan model pada layanan yang digunakan.

| Hal yang diperiksa | Klaim materi yang diberikan | Verifikasi yang diperlukan |
|---|---|---|
| Nama model | Claude Opus 5, Fable 5, Sonnet 5 | Nama produk dan ID model yang tepat dalam daftar model resmi |
| Tanggal rilis | Masing-masing 9 Juni, 30 Juni, 24 Juli | Tahun dan tanggal dalam pengumuman resmi serta riwayat perubahan |
| Harga Opus 5 | Input 5 dolar, output 25 dolar/1 juta token | Daftar harga API resmi, tarif terpisah untuk batch, cache, dan konteks panjang |
| Model default dalam produk | Model default baru Claude Max | Ketersediaan berdasarkan wilayah, paket harga, dan klien |
| Peran antarmodel | Dibagi menjadi pekerjaan otonom jangka panjang, pekerjaan sehari-hari, dan pekerjaan ringan | Deskripsi model resmi dan hasil evaluasi pekerjaan aktual |
| Peningkatan performa | Peningkatan dengan persentase tertentu dibandingkan model sebelumnya | Tugas evaluasi, jumlah sampel, kriteria pengukuran, dan sumber asli mitra |

Jika nama model atau harga tidak tercantum dalam dokumentasi resmi, informasi tersebut tidak boleh digunakan untuk konfigurasi API dan perhitungan anggaran. Jika menggunakan penyedia cloud atau layanan penjualan kembali, ID model, harga, dan waktu ketersediaannya mungkin berbeda dari API langsung Anthropic.

## Kriteria penilaian yang perlu berubah dalam peralihan model

### 1. Ukur efisiensi per tugas, bukan performa tertinggi

Memproses semua permintaan dengan model termahal dapat meningkatkan biaya dengan cepat ketika agen berulang kali memanggil berbagai alat dan subagent. Model harus dipilih bukan berdasarkan nama atau kelasnya, melainkan dengan mempertimbangkan indikator berikut secara bersamaan.

- **Tingkat keberhasilan:** Persentase pemenuhan persyaratan tanpa perlu koreksi manusia
- **Total biaya:** Biaya yang mencakup tidak hanya permintaan awal, tetapi juga percobaan ulang, pemanggilan alat, dan pemanggilan subagent
- **Waktu penyelesaian:** Waktu yang mencakup waktu tunggu serta waktu peninjauan dan koreksi oleh manusia
- **Biaya kegagalan:** Dampak yang ditimbulkan kegagalan, seperti celah keamanan, deployment yang salah, atau analisis yang terlewat
- **Konsistensi:** Tingkat perubahan hasil ketika jenis tugas yang sama diulang

Biaya per tugas tidak boleh dinilai hanya berdasarkan tarif token. Secara konseptual, biaya tersebut dapat dihitung sebagai berikut.

`Total biaya per tugas = biaya model utama + biaya subagent + biaya alat + biaya percobaan ulang + biaya peninjauan manusia`

### 2. Pisahkan benchmark publik dan evaluasi internal

Benchmark publik merupakan titik awal untuk membandingkan karakteristik umum model, tetapi tidak menjamin keberhasilan pada codebase, format dokumen, atau aturan pekerjaan tertentu. Organisasi harus membuat set evaluasi internal yang menganonimkan pekerjaan aktual.

Set evaluasi yang baik mencakup kasus-kasus berikut.

- Tugas representatif yang harus diselesaikan secara normal
- Kasus batas yang sering dijawab salah oleh model
- Tugas dengan permintaan ambigu yang memerlukan pertanyaan tambahan
- Tugas yang memerlukan pemanggilan alat atau pemeriksaan materi eksternal
- Tugas berisiko tinggi yang mengharuskan eksekusi dihentikan atau persetujuan manusia diperoleh
- Tugas yang mengharuskan status disimpan dan dipulihkan selama pelaksanaan jangka panjang

Agar dapat dibandingkan, input, alat, batas waktu, dan kriteria keberhasilan yang sama harus diterapkan pada setiap model. Lebih aman mencatat tingkat keberhasilan dan distribusi biaya dari beberapa kali pengulangan daripada mengandalkan satu atau dua hasil yang mengesankan.

### 3. Evaluasi model dan harness sebagai satu sistem

**Harness** berarti lingkungan eksekusi yang mengelilingi model. Ini mencakup system prompt, petunjuk proyek, pencarian, memori, alat, Skill, subagent, pengelolaan izin, serta logika verifikasi dan percobaan ulang.

Model yang sama dapat memberikan hasil berbeda bergantung pada harness. Misalnya, jika model itu sendiri menulis dan menjalankan pengujian sementara harness juga mewajibkan verifikasi yang sama, pekerjaan tersebut dapat terduplikasi. Sebaliknya, berisiko jika tahap yang memerlukan kontrol deterministik, seperti persetujuan deployment atau pemeriksaan keamanan, diserahkan pada penilaian otonom model.

Prinsip utamanya adalah **membedakan penalaran yang dikuasai model dari kontrol yang wajib dijamin oleh sistem**.

## 6 hal yang perlu diperiksa dalam prompt dan harness

### 1. Hapus instruksi verifikasi dan pemeriksaan ulang yang duplikatif melalui eksperimen

Menghapus tanpa syarat kalimat seperti `Setelah selesai, Anda wajib memeriksanya kembali` bukanlah jawaban yang selalu benar. Pertama-tama, lacak apakah verifikasi yang dilakukan secara sukarela oleh model baru bertumpang tindih dengan tahap verifikasi harness.

- Jika peninjauan mandiri model hanya berulang tanpa meningkatkan kualitas, kurangi prompt.
- Pertahankan pemeriksaan yang dapat diotomatisasi dalam harness, seperti pengujian, validasi skema, dan analisis statis.
- Jangan mengganti persetujuan untuk tugas berisiko tinggi seperti pembayaran, deployment, dan penghapusan data dengan verifikasi mandiri model.

### 2. Tetapkan syarat pemanggilan dan batas maksimum subagent

subagent berguna untuk riset paralel atau pemisahan bidang khusus, tetapi mendelegasikan tugas kecil sekalipun akan meningkatkan biaya dan latensi. Kebijakan berikut dapat ditetapkan secara eksplisit.

- Gunakan subagent hanya untuk tugas yang dapat dibagi secara independen.
- Batasi jumlah yang dapat dijalankan secara bersamaan dalam satu permintaan.
- Berikan hasil akhir dan syarat penghentian yang jelas kepada setiap subagent.
- Cegah beberapa agen menelusuri materi yang sama secara duplikatif.
- Dapatkan persetujuan manusia jika perkiraan biaya atau waktu melampaui ambang batas.

### 3. Ubah aturan larangan terperinci menjadi kriteria penilaian

Daftar larangan yang panjang dapat saling bertentangan atau gagal menangani situasi baru. Untuk area berisiko rendah seperti gaya, model dapat diberi kewenangan untuk membaca konteks sekitar dan membuat penilaian.

- Berbasis aturan: `Jangan pernah menulis docstring dalam beberapa paragraf.`
- Delegasi penilaian: `Ikuti kepadatan komentar, format docstring, penamaan, dan idiom pada kode yang ada.`

Namun, aturan dengan biaya pelanggaran yang besar, seperti penanganan data pribadi, keamanan, dan kewajiban hukum, harus dipertahankan dalam bentuk batasan eksplisit dan pemeriksaan terprogram.

### 4. Tentukan panjang respons dan format output secara langsung

Sumber daya yang digunakan untuk penalaran dan panjang jawaban yang terlihat oleh pengguna bukanlah konsep yang sama. Meskipun klien menyediakan opsi intensitas penalaran seperti `effort` atau opsi serupa, jika memerlukan jawaban singkat, tuliskan ketentuan output secara terpisah.

Berikut contohnya.

- `Tuliskan kesimpulan terlebih dahulu dan rangkum alasannya dalam paling banyak tiga poin.`
- `Tulis jawaban akhir dalam paling banyak 500 karakter.`
- `Kembalikan hanya objek JSON yang valid tanpa penjelasan.`
- `Laporkan hanya file yang diubah, alasan utama, dan risiko yang tersisa.`

### 5. Kalibrasikan kembali intensitas penalaran menggunakan pekerjaan aktual

Jangan langsung menerapkan intensitas penalaran atau nilai default effort yang digunakan pada model sebelumnya ke model baru. Ukur kurva biaya dengan memulai dari pengaturan rendah dan meningkatkannya hanya ketika kualitas tidak memadai.

| Jenis tugas | Arah pengaturan awal | Kondisi untuk meningkatkan |
|---|---|---|
| Klasifikasi dan konversi format | Mulai dari rendah | Ketika kesalahan skema atau kelalaian terjadi berulang kali |
| Modifikasi dokumen dan kode umum | Bandingkan rentang menengah | Ketika dependensi beberapa file terlewat |
| Debugging kompleks | Uji pada tingkat menengah atau lebih tinggi | Ketika tingkat keberhasilan analisis penyebab dan verifikasi tidak memadai |
| Pekerjaan agen jangka panjang | Ukur per tahap | Bagian sulit yang memerlukan perencanaan ulang dan pemulihan |

Nama opsi yang tepat dan cakupan dukungannya dapat berbeda menurut versi API dan produk, sehingga dokumentasi resmi harus diperiksa.

### 6. Pisahkan konteks berdasarkan peran dan ungkapkan secara bertahap

Jika semua petunjuk dimasukkan ke dalam satu system prompt atau `CLAUDE.md`, informasi yang tidak relevan pun dapat disertakan dalam setiap permintaan. Struktur hierarkis berikut bersifat praktis.

1. **Petunjuk sistem dan produk:** Aturan yang selalu diperlukan, seperti peran, batas keamanan, dan kontrak output
2. **Petunjuk proyek ringan:** Perintah build, struktur direktori, dan metode kerja umum
3. **Skill yang dimuat saat diperlukan:** Prosedur bersyarat seperti deployment, perubahan database, dan framework tertentu
4. **Referensi teknis:** Skema API, contoh kode, dokumen desain, dan spesifikasi yang dapat diuji

Hal ini dapat disebut **pengungkapan bertahap**. Model dapat mencari atau memuat materi yang diperlukan pada tahap saat ini, tetapi materi yang digunakan harus dicatat untuk memastikan reproduktibilitas dan kemampuan audit.

## Prosedur migrasi yang disarankan

### Tahap 1: Bekukan kondisi saat ini

Simpan prompt model lama, versi alat, tingkat keberhasilan, penggunaan token, latensi, dan kasus kegagalan. Tanpa baseline, sulit untuk menilai apakah model baru benar-benar memberikan peningkatan.

### Tahap 2: Verifikasi informasi dan izin model

Periksa ID model resmi, harga, batas konteks, dukungan alat, dan kebijakan retensi data. Di lingkungan pengujian, batasi izin untuk menulis, menghapus, dan melakukan deployment.

### Tahap 3: Uji harness lama apa adanya

Pada awalnya, jangan mengubah semuanya sekaligus. Dengan hanya mengganti model dan membandingkannya dengan baseline, dampak perubahan model dapat dipisahkan.

### Tahap 4: Hapus instruksi duplikatif satu per satu

Hapus satu per satu jenis instruksi verifikasi, aturan gaya yang bertele-tele, contoh yang tidak perlu, dan referensi yang selalu disuntikkan. Ukur kembali kualitas dan biaya setelah setiap perubahan.

### Tahap 5: Buat kebijakan routing

Pilih model berdasarkan tingkat kesulitan pekerjaan, risiko, perkiraan konteks, dan batas waktu. Peran setiap model yang diusulkan oleh materi yang diberikan harus diuji sebagai hipotesis setelah nama resmi dan performanya dikonfirmasi, dan tidak boleh langsung diadopsi sebagai kebijakan operasional.

### Tahap 6: Lakukan deployment mulai dari traffic terbatas

Terapkan terlebih dahulu pada sebagian pengguna atau tugas yang tidak berisiko. Perluas cakupan setelah mengamati tingkat kegagalan, percobaan ulang, jumlah subagent, kesalahan alat, dan waktu koreksi manusia.

## Checklist operasional

- [ ] Nama model resmi dan ID model API telah diperiksa.
- [ ] Tarif yang benar-benar diterapkan, termasuk input, output, cache, dan batch, telah diperiksa.
- [ ] Tersedia set evaluasi internal yang terdiri atas pekerjaan aktual.
- [ ] Tahap verifikasi model dan harness tidak tumpang tindih.
- [ ] Tersedia kriteria pemanggilan subagent, jumlah eksekusi bersamaan, dan batas maksimum anggaran.
- [ ] Panjang respons dan skema output telah ditentukan.
- [ ] Kualitas, biaya, dan latensi berdasarkan intensitas penalaran telah dibandingkan.
- [ ] Pemeriksaan deterministik dan persetujuan manusia tetap diberlakukan untuk tugas berisiko tinggi.
- [ ] Konteks telah dipisahkan menjadi petunjuk tetap, Skill, dan referensi.
- [ ] Model dan pengaturan lama untuk rollback telah disiapkan.

## Kesimpulan

Inti peralihan ke model baru bukanlah mempersingkat prompt tanpa syarat atau memperluas otonomi tanpa syarat. Intinya adalah **memeriksa informasi produk resmi terlebih dahulu, lalu membagi kembali peran model dan harness melalui evaluasi pekerjaan aktual**.

Angka dan nama terkait Claude Opus 5 dalam materi yang diberikan harus diperlakukan sebagai informasi sementara sampai dasar resminya dikonfirmasi. Namun, penghapusan verifikasi duplikatif, pembatasan subagent, kontrak output yang jelas, pengungkapan konteks secara bertahap, dan routing berbasis evaluasi internal merupakan prinsip peralihan yang dapat diterapkan terlepas dari generasi model.

## FAQ

### Apakah Claude Opus 5 merupakan model yang telah dirilis secara resmi?
Materi yang diberikan mencantumkan tanggal rilis dan harga, tetapi hal tersebut belum diverifikasi secara independen hanya berdasarkan informasi yang diberikan dalam tulisan ini. Sebelum nama model dan ID model yang tepat dikonfirmasi melalui daftar model resmi Anthropic, pengumuman, dan konsol API, sebaiknya informasi tersebut tidak dianggap sebagai informasi produk yang telah dipastikan.

### Apakah Fable 5 merupakan nama model resmi Anthropic?
Hal tersebut tidak dapat dikonfirmasi hanya berdasarkan materi yang diberikan. Meskipun nama produknya serupa, Anthropic dapat menggunakan ID model API atau penamaan yang berbeda untuk setiap layanan. Oleh karena itu, perlu diverifikasi dalam daftar model resmi apakah nama `Fable 5` benar-benar ada.

### Apakah semua prompt yang ada harus dihapus jika beralih ke model Claude yang baru?
Tidak. Pertama-tama, lakukan evaluasi dasar dengan konfigurasi yang ada, kemudian hapus satu per satu instruksi verifikasi yang tumpang tindih atau aturan gaya yang tidak diperlukan sambil membandingkan kualitas dan biaya. Kontrol yang harus dijamin oleh sistem, seperti pemeriksaan keamanan, validasi skema output, dan persetujuan deployment, harus tetap dipertahankan.

### Apa itu harness?
Harness adalah sistem yang mengelilingi model AI agar dapat dijalankan dalam pekerjaan nyata. Sistem ini mencakup prompt sistem, pedoman proyek, alat, pencarian, memori, Skill, subagent, percobaan ulang, pengelolaan izin, dan prosedur verifikasi otomatis.

### Bagaimana cara membatasi penggunaan subagent?
Gunakan hanya untuk tugas yang dapat dibagi secara independen dan tetapkan batas maksimum jumlah eksekusi simultan serta jumlah total pemanggilan. Hasil dan syarat penghentian setiap subagent harus ditentukan secara jelas. Sistem juga dapat dirancang agar meminta persetujuan manusia jika perkiraan biaya atau waktu melampaui ambang batas.

### Mengapa evaluasi internal lebih penting daripada benchmark publik?
Benchmark publik tidak sepenuhnya mencerminkan basis kode, format dokumen, lingkungan alat, dan biaya kegagalan suatu organisasi. Tingkat keberhasilan, total biaya, waktu penyelesaian, dan konsistensi hasil harus diukur menggunakan kasus pekerjaan nyata agar dapat menentukan model mana yang sesuai untuk lingkungan operasional.

### Jika model memiliki verifikasi mandiri, apakah pengujian dapat dihilangkan?
Tidak. Peninjauan mandiri oleh model merupakan sarana pendukung dan tidak menggantikan pengujian, pemeriksaan skema, analisis statis, maupun kebijakan keamanan. Terutama untuk tugas berisiko tinggi seperti deployment, pembayaran, dan penghapusan data, diperlukan pemeriksaan deterministik dan persetujuan manusia.

### Jika effort diturunkan, apakah jawaban juga otomatis menjadi lebih singkat?
Belum tentu. Intensitas penalaran dan panjang output akhir dapat menjadi sasaran kontrol yang terpisah. Jika memerlukan jawaban yang ringkas, format respons seperti jumlah karakter, jumlah butir, atau skema output harus ditentukan secara langsung dalam prompt.

## Sources

- [Dokumentasi Anthropic: Ikhtisar model](https://docs.anthropic.com/en/docs/about-claude/models/overview)
- [Harga Anthropic](https://www.anthropic.com/pricing)
- [Dokumentasi Anthropic: Ikhtisar rekayasa prompt](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview)
- [Dokumentasi Anthropic: Memori Claude Code](https://docs.anthropic.com/en/docs/claude-code/memory)

## Images

![Ilustrasi kubus AI yang diperiksa di dekat penghalang peringatan dan ikon daftar cek](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5MCwicHVyIjoiYmxvYl9pZCJ9fQ==--f44d725b558668593419631e29f28834deb66ecc/ai-95ae89bc.webp)
![Model AI terhubung ke keamanan, dokumen, pengguna, alat, kontrol agen, dan indikator evaluasi](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzY5NiwicHVyIjoiYmxvYl9pZCJ9fQ==--5ddddd2dfbbbcedb1849fbdfe606aca94f9a98af/ai-b298a672.webp)