Claude Code yavaşladığında neredeyse herkes aynı hatayı yapar: tek bir sorun varmış gibi davranır. Oysa burada iç içe geçmiş iki ayrı şey vardır ve bunları karıştırmak, yanlış tarafı saatlerce kurcalamak demektir.
Birinci neden tamamen oturumun içinde kalır. Konuşma uzadıkça model her seferinde daha çok belirteç üzerinden akıl yürütmek zorunda kalır, dolayısıyla yanıtlar doğal olarak uzar. İkinci neden ise bambaşka bir yerde: ağda. Claude Code bir dosyayı okumak, bir komutu çalıştırmak, sonucu görmek için arka arkaya onlarca gidiş-dönüş yapar. Bu yolculukların her biri fazladan birkaç yüz milisaniye taşıyorsa, çok adımlı bir iş resmen sürünmeye başlar.
Asıl mesele şu: en çok önerilen çözümler — bağlamı sıkıştır, daha hafif bir modele geç — yalnızca birinci nedene dokunur. Darboğazınız API'ye giden tıkalı bir yolsa, bağlamı sabaha kadar sıkıştırın, fark etmez. Gecikme her araç çağrısında yeniden, ayrı ayrı tahsil edilir.
Kimler bu yavaşlığı yaşıyor
Pratikte iki tür kullanıcı şikâyet ediyor. İlki, gün boyu tek oturumda çalışan geliştirici. Sabah her şey çevik başlar; öğleden sonraya doğru aynı isteklerin yanıtı gözle görülür biçimde uzar. Bu klasik bağlam birikmesidir. On beş bin belirteçle açılan bir sohbet, altmış bine ulaştığında bambaşka davranır.
İkincisi coğrafi olarak API'den uzaktaki geliştirici. Onlar için Claude Code daha ilk komuttan itibaren ağırdır, oturumun ne kadar uzadığıyla hiç ilgisi yoktur. Çünkü her istek hedefe varmadan önce dolambaçlı, tıkalı bir hat boyunca ilerler. Bir agent peş peşe dosya okuyup düzenlemeye başladığında bu gecikme katlanır.
Bir de gözden kaçan ara durum var. Dizüstü evde tıkır tıkır çalışır, ama ofise ya da ortak çalışma alanının ağına bağlanınca belirgin biçimde tavsar. Burada makine yaşlanmamıştır; çıkış hattınız daha dolambaçlı bir rotaya kaymıştır, gidiş-dönüş süresi de paket kaybı da birlikte tırmanır. "Yer değiştirince yavaşlıyor" diyorsanız, ilk refleksiniz Claude Code'u yeniden kurmak olmasın. Önce ağ çıkışınızdan şüphelenin.
Sorunu ikiye bölerek teşhis etmek
Önce: yavaşlık bağlamla birlikte mi büyüyor?
Bunu test etmek çok basit. Tertemiz yeni bir oturum açın ve az önce yavaş bulduğunuz aynı istemi gönderin. Yeni oturum hızlı, eskisi yavaşsa karşınızda ağ sorunu yok, bağlam şişmesi var.
Çözüm de buna göre değişir. Girdi yüz bin belirteç civarına yaklaşmadan erkenden sıkıştırın. Birbiriyle alakasız işler için temiz oturumlar açmaya alışın. Ve gereksiz yere koca koca paketleri ya da üretilmiş dosyaları bağlama çekmekten kaçının; yüklediğiniz her baytı model işe başlamadan önce baştan sona okumak zorunda.
Sonra: her çağrının ağ vergisini ölçün
Pırıl pırıl yeni bir oturum bile yavaşsa, gidiş-dönüşü ölçmenin zamanı gelmiştir. API ana makinesine ping atın ve değere bakın. Sürekli 200 milisaniyenin üzerindeyse, art arda gelen her araç çağrısı bu gecikmeyi olduğu gibi devralıyor demektir.
Şunu unutmayın: Claude Code araç tabanlı çalışır. Dosya oku, komut çalıştır, çıktıyı oku, düzenle. Tek bir görev rahatlıkla yirmiden fazla gidiş-dönüş içerebilir. 250 milisaniyelik bir hat, model daha düşünmeye başlamadan saniyelerce kayıp anlamına gelir. Bağlamı çoktan kısalttığı halde Claude Code'un hâlâ yavaş kalmasının en yaygın sebebi tam olarak budur.
Titreşim ve yeniden iletim: sinsi olan
Bazen ortalama gecikme makul görünür ama deneyim yine de berbattır. Suçlu genelde kararsız bir hattır: değer sert biçimde salınır, ara sıra paketleri düşürür ve bunların yeniden gönderilmesi gerekir. Kısa bir mtr oturumu çalıştırıp her atlamadaki kayıp yüzdesine bakın. Yeniden iletim sıradan bir pingde görünmez, ama etkileşimli kodlamayı yerle bir eder; takılan her paket imleci bir an donduruyor.
Pratik bir hile daha: aynı işi günün farklı saatlerinde çalıştırın. Akşamüstü ev ağları ve uluslararası hatlar genelde daha kalabalıktır, gecikme ve kayıp da tepe yapar. Sabah hızlı, akşam belirgin biçimde yavaşsa bu makinenizin değil, paylaşılan hattın doyması sorunudur. Yoğun ve sakin saatten birer ölçüm alıp yan yana koymak, tahmine hiç gerek bırakmadan sorunun yerini gösterir.
Modeli görevin boyuna göre seç
Her adım en güçlü modeli hak etmez. Kısa bir söz dizimi sorusu ya da birkaç satır açıklama için daha hafif, hızlı bir model neredeyse anında döner. Ağır akıl yürütme isteyen işleri ise daha yavaş ama daha yetenekli olana bırakın. Modeli işe uydurmak kendi elinizle yarattığınız gecikmeyi siler. Yalnız şunu da bilin: bu, zaten sağlam bir hattı tamamlar, bozuk bir hattı kurtarmaz.
Yanıt süresini gerçekte ne belirliyor
| Etken | Belirti | Nerede | Ne yapmalı |
|---|---|---|---|
| Bağlam birikmesi | Oturum uzadıkça yavaşlar | Yerel oturum | Erken sıkıştır, yeni oturum aç |
| Çağrı başına gecikme | İlk komuttan itibaren yavaş | Ağ rotası | API'ye giden yolu iyileştir |
| Titreşim ve paket kaybı | Görev ortasında rastgele donma | Ağ rotası | Düşük kayıplı kararlı hat kullan |
| Model seçimi | Önemsiz işte ağır model | Yapılandırma | Modeli görevin boyuna uydur |
Tablodaki ilk satır ve sonuncusu sizin alışkanlığınızla ilgili; ortadaki ikisi ise hattınızla. Hangisinin sizi vurduğunu yukarıdaki testlerle birkaç dakikada ayırt edebilirsiniz.
Sık sorulanlar
Bilgisayarım çok hızlı, Claude Code neden hâlâ ağır?
Çünkü beklemenin büyük kısmı ağ ve modelin düşünme süresinden geliyor, yerel hesaplamadan değil. Hızlı bir işlemci araçlarınızı çabuk çalıştırır ama ne API'ye gidiş-dönüşü ne de büyük bağlamda modelin akıl yürütme süresini kısaltır.
Bağlamı sıkıştırmak işe yarıyor mu, yaramıyor mu?
Oturum uzunluğundan kaynaklanan yavaşlıkta gerçekten yarıyor; daha az bağlam, her yanıtta daha az işlem demek. Ama yavaş bir ağ hattına hiçbir etkisi yok. Bazılarının sıkıştırıp da hiç fark görmemesinin nedeni bu.
Kablolu bağlantı Wi-Fi'den daha mı iyi?
Çoğu zaman evet. Kablolu hatlar kalabalık bir Wi-Fi'ye kıyasla daha az titreşir ve daha az paket düşürür. Etkileşimli kodlama da tam olarak bu ani sıçramalara karşı hassas.
Ağ yolunu iyileştirmek deneyimi ne kadar değiştirir?
Çağrı başına alınan gecikme vergisini keser ve titreşimi yumuşatır. Böylece bir agent çalışmasındaki onlarca gidiş-dönüşün her biri hem daha hızlı hem daha öngörülebilir döner. Çok adımlı işlerde bu küçük kazanımlar üst üste binince fark gerçekten büyük olur.
Özetle, Claude Code yavaşlığından kurtulmanın yolu tahmin etmeyi bırakıp sorunu ikiye bölmektir. Yavaşlık oturumla mı büyüyor yoksa ilk tuştan mı başlıyor, önce bunu doğrulayın. Bağlam tarafını oturum disiplininizle, ağ tarafını ise sürekli düşük gecikme için kurulmuş bir hatla halledin.
İkinci yarıda işiniz kolaylaşsın isterseniz, geliştirici trafiğine göre ayarlanmış düğümlerle gidiş-dönüşü kısa ve kararlı tutan NasaCode tam da bunun için var.
