DCP: Dynamic Context Pruning untuk AI Coding Assistant

Masalah: Context Window yang Membengkak

AI coding assistant seperti Claude Code atau OpenCode bekerja dengan membaca seluruh history percakapan Anda. Setiap pesan, setiap hasil command, setiap file yang pernah dibaca — semua masuk ke context window.

Masalahnya: percakapan coding bisa panjang. Anda memulai dengan eksplorasi codebase (50+ file dibaca), lalu debugging (ratusan baris error log), lalu implementasi (multiple file edits), lalu testing. Setelah 2 jam, context window Anda berisi 15,000+ token history.

Dari semua itu, berapa persen yang masih relevan? Mungkin hanya 10-15%. Sisanya adalah:

• Hasil explorasi yang sudah tidak relevan
• File-file yang pernah dibaca tapi bukan yang sedang dikerjakan
• Error log dari percobaan sebelumnya yang sudah fixed
• Pesan-pesan konfirmasi dan status update yang tidak perlu

Context window yang membengkak menyebabkan:

1. Response lebih lambat — AI memproses lebih banyak data
2. Kualitas menurun — AI "bingung" karena terlalu banyak noise
3. Biaya naik — Token usage membengkak untuk hal-hal yang tidak relevan
4. Lost focus — AI mungkin mengutip informasi yang sudah usang

Solusi: DCP (Dynamic Context Pruning)

Dynamic Context Pruning adalah teknik yang digunakan AI coding assistant untuk secara otomatis mengidentifikasi dan menghapus konteks yang sudah usang, sambil mempertahankan informasi yang masih relevan.

Bayangkan seperti garbage collector untuk conversation AI. Yang penting tetap ada, yang sudah tidak relevan — dihapus.

Cara Kerja DCP

DCP bekerja berdasarkan beberapa prinsip scoring:

1. Recency — Pesan terbaru lebih bernilai daripada pesan lama
2. Relevance — Konten yang terkait dengan instruction saat ini diprioritaskan
3. Semantic importance — Error messages, code changes, keputusan arsitektur — tetap dipertahankan
4. User intent — Pesan terakhir user dan konteks task yang aktif adalah yang paling bernilai

Proses pruning terjadi secara otomatis di background:

┌─────────────────────────────────────┐
│   Context Window (128K tokens)      │
├─────────────┬───────────────────────┤
│  KEEP       │  PRUNE                │
│             │                       │
│  ✓ Pesan user terkini              │
│  ✓ File yang sedang diedit          │  ✗ Explorasi hasil awal
│  ✓ Error log yang belum resolved    │  ✗ File yang sudah selesai
│  ✓ Keputusan arsitektur             │  ✗ Status messages lama
│  ✓ Build/test result terbaru        │  ✗ Conversation chitchat
└─────────────┴───────────────────────┘

Contoh Skenario: Tanpa vs Dengan DCP

Skenario Tanpa DCP (Context window penuh):

Session: 2 jam coding

Context accumulated:
- Message 1-5: Explorasi project structure (3,200 tokens)
- Message 6-12: Read 8 files (5,400 tokens)
- Message 13-18: First debugging attempt, error logs (4,100 tokens)
- Message 19-22: Failed approach discussions (2,800 tokens)
- Message 23-28: Second approach, working solution (3,500 tokens)
- Message 29-30: Testing and verification (1,200 tokens)

Total: ~20,200 tokens
Relevant for current work: ~4,700 tokens (23%)
Wasted: ~15,500 tokens (77%)

Skenario Dengan DCP (Context window optimal):

Session: 2 jam coding

After pruning:
- Recent user messages: preserved
- Current working files: 2 files active (1,800 tokens)
- Last error + resolution: preserved (900 tokens)
- Architecture decision made: summarized (600 tokens)
- Build/test result latest: preserved (1,400 tokens)

Total after pruning: ~5,800 tokens
Retained relevance: ~85%
Savings: ~14,400 tokens (71%)

Cara Kerja di OpenCode

OpenCode mengimplementasikan DCP melalui beberapa mekanisme:

1. Session Summarization Context yang sudah tidak aktif tetapi masih berpotensi relevan akan disummarize daripada dihapus sepenuhnya. Ini seperti "bookmark" — AI tahu ada informasi penting, tapi tidak menyimpan seluruh detailnya.

# Daripada menyimpan 50 baris error log lengkap:
# DCP menyimpan:
session_summary:
  - "Attempt 1: Type error in auth.ts line 45 (resolved - fixed import)"
  - "Attempt 2: LSP diagnostics clean after refactor"

2. Sliding Window + Anchoring Menggunakan sliding window yang otomatis menghapus pesan terlama, tapi "anchor" pesan-pesan penting (keputusan user, code architecture, critical errors).

3. Working Set Isolation AI assistant mengidentifikasi "working set" — file dan konteks yang sedang aktif dikerjakan. Konteks di luar working set mendapat prioritas rendah untuk pruning.

Kapan DCP Paling Efektif

Tips Memaksimalkan DCP

1. Fokus pada satu task per session — DCP bekerja optimal ketika working set jelas
2. Gunakan explicit instruction — "Focus on auth module only" membantu AI mengidentifikasi apa yang penting
3. Clear context saat pindah topic — Jika berganti dari frontend ke backend, mulai fresh atau explicit "done with frontend, now backend"
4. Summarize keputusan penting — Tulis keputusan arsitektur secara eksplisit sehingga AI tahu harus preserve
5. Jangan takut discard — Informasi yang sudah tidak relevan bisa di-re-explore kapan saja

Metrics Nyata

Dari pengujian pada project real-world:

Session: Full-stack feature (4 jam)
Total messages: 87
Raw context: 31,400 tokens

After DCP:
- Pruned messages: 52 (60%)
- Retained context: 8,200 tokens
- Response time improvement: 40% faster
- Output quality: maintained (no degradation)
- Token cost savings: ~74%

Kesimpulan

Dynamic Context Pruning bukan magic — ini tentang mengelola keterbatasan context window secara cerdas. Dengan DCP, AI coding assistant bisa menjaga fokus, response lebih cepat, dan biaya lebih rendah — tanpa kehilangan konteks yang benar-benar penting.

Untuk developer yang sering bekerja dengan AI assistant dalam session panjang, DCP adalah salah satu optimasi paling signifikan yang bisa diterapkan. Bukan soal "berapa besar context window", tapi "seberapa relevan isi context window".

Baca juga:

• RTK: Kompresi Output Terminal — Mengompresi output terminal hingga 90%
• Caveman Mode: Komunikasi Efisien — Kurangi token response AI hingga 75%