Claude Code'da model ve çaba: daha fazlasını bilmek mi, daha çok çabalamak mı?

Claude Code size iki ayar sunar ve her ikisi de "cevabı daha iyi hale getiriyor" gibi görünür: model ve çaba seviyesi. Peki bunlar aslında çıktıya ne yapar? Ve daha büyük bir modele mi yoksa sadece çaba seviyesini değiştirmeye mi yönelmeniz gerektiğini nasıl anlarsınız?

Fable gibi daha büyük bir model seçmenin size Sonnet'ten daha akıllı bir çıktı vereceğini ve daha yüksek bir çaba seviyesinin sadece Claude'un cevap vermeden önce daha uzun düşündüğü anlamına geldiğini varsaymak kolaydır.

İlk varsayım doğrudur. En büyük modellerimiz, sektör standardı kıyaslamalara göre daha yeteneklidir.

Ancak çaba, "düşünme süresinden" daha fazlası anlamına gelir. Çaba, Claude'un isteğiniz üzerinde genel olarak ne kadar iş yaptığını kontrol eder. Bu, ne kadar süre düşündüğünü de içerir, ancak aynı zamanda:

• kaç dosya okuduğunu;
• ne kadar doğrulama yaptığını; ve
• sizinle kontrol etmeden önce çok adımlı bir görevde ne kadar ilerlediğini de içerir.

Daha yüksek çabada Claude, size dönmeden önce bu eylemlerden daha fazlasını (dosyaları okuma, testleri çalıştırma, çift kontrol yapma) gerçekleştirir. Daha düşük çabada, bir şeyi kendi başına çözmek için token harcamaktansa sizden daha fazla bağlam istemeyi tercih eder.

Model seçimi nasıl çalışır

Model ayarının aslında neyi kontrol ettiğini anlamak için, enter tuşuna bastığınız andan itibaren en baştan başlamak yardımcı olur.

Claude Code, mesajınızı sistem promptu, araç tanımları, CLAUDE.md dosyanız, konuşma geçmişi ve bağlamdaki tüm dosyalarla bir araya getirir. Bunların tümü API'ye tek bir istek olarak gönderilir.

Claude Code'un sahip olduğu her şey tek bir API isteğine paketlenir. Sunucuda, metin modele ulaşmadan önce tokenize edilir.

Ancak model bunların hiçbirini düz metin olarak görmez. Sunucuda olan ilk şey tokenizasyondur: metin parçalara ayrılır ve her parça, modelin eğitildiği sabit bir kelime dağarcığından bir tamsayıya eşlenir. const 1978'e, await 4293'e eşlenebilir. Bu noktadan itibaren, sizin promptunuz bir tamsayı dizisidir.

Tokenleştirici, metninizi parçalara ayırır ve her parçayı sabit bir kelime dağarcığındaki bir tamsayıya eşler. Üst satırdaki her parça, token kimliği haline gelir (alt satır); gösterilen kimlikler açıklama amaçlıdır.

Modelin işi, bu diziyi almak ve bir sonraki tokenin ne olacağını tahmin etmektir. Bunu, kelime dağarcığındaki her token için bir olasılık hesaplayarak ve en yüksek olanlardan seçerek yapar. "const x = await" ifadesinden sonra, iyi eğitilmiş bir model "fetch"e yüksek olasılık (çok olası) ve "banana"ya sıfıra yakın olasılık (hiç olası değil) verir.

Modelin tahmini, kelime dağarcığındaki her token için bir olasılıktır. En iyi tahmin ile ilgisiz bir tahmin arasındaki fark çok büyüktür.

Girdi tokenlerinizi bu olasılıklara dönüştüren şey ağırlıklardır (parametreler olarak da adlandırılır): büyük matrisler halinde düzenlenmiş milyarlarca sayı. Bir token tahmin etmek için model, girdinizi bu matrislerden geçirir (uzun bir matris çarpımı zinciri) ve sonunda olasılıkları okur. Ağırlıklar, modelin "bildiği" her şeyin yaşadığı yerdir.

Her modelin ağırlıkları eğitim sırasında belirlenir ve siz istek gönderdiğinizde salt okunurdur. Promptunuzdaki, CLAUDE.md dosyanızdaki veya bağlamınızdaki hiçbir şey onları değiştirmez. Çıkarım kelimesine denk geldiyseniz, tüm anlamı budur: modeli eğitim tamamlandıktan sonra, ağırlıklar sabitken kullanmak.

Promptunuz girer, olasılıklar çıkar. Ortadaki ağırlıklar değişmez.

Claude'un TypeScript, popüler framework'ler veya diğer genel programlama bilgileri hakkında bildiği her şey, eğitim sırasında bu ağırlıklara kodlanmıştır.

Promptunuz ve bağlamınız yine de tahmini yönlendirebilir. Gerçek kodunuzu Claude'un önüne koymak yönlendirmedir ve çok iyi çalışır. Ancak bu, ağırlıkların kendisine hiçbir şey eklemez.

Eğer bir kütüphane model eğitildiğinde mevcut değilse, ağırlıklarda da yoktur. Dokümanları bağlama koyabilirsiniz ve Claude bunları kullanır, ancak bu yönlendirmedir, öğretme değildir. Claude'un yanıtı yalnızca o tek istek için etkilenir, ancak temel model hiçbir şeyi hatırlamamıştır.

Claude güvenle var olmayan bir API'yi çağırdığında (bir halüsinasyon), bu ağırlıkların eğitim modellerinden makul görünen bir token dizisi üretmesidir, başarısız bir arama değil.

Peki modeli değiştirmek aslında ne yapar? İsteğinizi hangi donmuş ağırlık kümesinin işleyeceğini değiştirir.

Model bir kerede tam bir cevap üretmez. Bir token tahmin eder, onu diziye ekler ve bir sonrakini almak için tüm hesaplamayı tekrar çalıştırır. 200 tokenlik bir yanıt, ağırlıklar üzerinden 200 ayrı geçiştir. Bekleme sürenizin (ve çıktı maliyetinizin) çoğu bu döngüden gelir.

Dizi, adım başına tam olarak bir token uzar. Model, sıradakinin ne olacağını tahmin etmek için her seferinde tüm diziyi yeniden okur.

Model ayarı, isteğinizi hangi ağırlıkların işleyeceğine ve ayrıca her çıktı tokeninin ne kadara mal olacağına karar verir.

Karar vermediği şey ise kaç token üretileceğidir. Bu sayı, Claude'un ne kadar iş yapmaya karar verdiğine bağlı olarak aynı prompt için büyük ölçüde değişebilir.

İşte çabanın kontrol ettiği şey tam olarak budur.

Çaba nasıl çalışır

Claude Code bir görev üzerinde çalışırken ürettiği tokenler birkaç kategoriye ayrılır:

• Düşünme: Eylemlerden önce ve arasında akan muhakemeyi görürsünüz.
• Araç çağrıları: Read veya Edit gibi bir aracı ve argümanlarını adlandıran, Claude Code'un daha sonra ayrıştırdığı ve yürüttüğü yapılandırılmış bloklar.
• Size metin: Plan, ilerleme güncellemeleri, sondaki özet.

Bunların tümü, aynı döngüden gelen, aynı oranda faturalandırılan sıradan çıktı tokenleridir. Örneğin, düşünme tokenleri, diğer çıktı tokenleriyle tamamen aynı şekilde üretilir ve o turun geri kalanı için bağlamda kalır.

Claude kod yazmaya geçtiğinde, önceki muhakemesi, tıpkı okuduğu bir dosya gibi girdinin bir parçasıdır.

Claude'un tüm çıktısı tokenlerdir. Düşünme, araç çağrıları ve size metin, aynı döngüden üretilir.

Peki çaba bunu nasıl değiştirir? Çaba seviyesi, isteğin bir parçası olarak modele, promptunuzun hemen yanında gönderilir. Model, her çaba seviyesinde nasıl davranacağını anlamak üzere eğitilmiştir ve bu öğrenilmiş davranış, donmuş ağırlıklara yerleştirilmiştir.

İsteğiniz geldiğinde, çaba, modelin prompt metninize yanıt vermesiyle aynı şekilde yanıt verdiği bir girdi daha olur. Claude'un görevi tamamlanmış saymadan önce ne kadar titiz ve ne kadar emin olması gerektiğini belirler. Bu, her turda değerlendirilir ve daha yüksek güvene ulaşmak daha fazla token gerektirir.

Aynı prompt, iki çaba seviyesi. Yüksek çaba yolu, daha yüksek güvenli bir cevaba ulaşmak için yaklaşık 7 kat daha fazla token üretir.

Daha yüksek çaba seviyelerinde Claude genellikle bir plan oluşturarak başlar ve çaba seviyesi bu planın derinliğini ve genişliğini etkiler. Ancak plan yerinde donmuş değildir. Claude, eylemlerinden sonuçlar aldıkça, ne kadar ilerleme kaydettiğine ve biriken sonuçtan ne kadar emin olduğuna dair resmini günceller.

Üç hipotezli bir hata ayıklama planının 1. adımı hatayı bulduğunda, "2. ve 3. hipotezleri araştır" artık gerekli olmayabilir. Claude bunu genellikle açıkça belirtir (ör. "ilk kontrol buldu, bu nedenle kalan kontrollere gerek yok") ve atlar. Görev listelerinin çalışma sırasında revize edildiğini Claude Code'da görürsünüz.

Daha yüksek çaba, Claude'un çift kontrol yapma olasılığını artırır, örneğin bulduğu cevabı doğrulamak veya atlayabileceği hipotezleri hala incelemek gibi. Ancak, çaba seviyesi yükseltildi diye genellikle basit bir görevde kullanımı yapay olarak şişirmez. "Fazla düşünme", ekibimizin model eğitimi sırasında özellikle dikkat ettiği bir durumdur çünkü etkinliği azaltır.

Bir çaba seviyesi seçmek

Çoğu görev için modelin varsayılan çaba seviyesini kullanın. Varsayılan, Claude'un token kullanımını çoğu insanın bir göreve harcamak isteyeceği seviyeye ölçeklediği seviyedir.

Çabayı, Claude'un ne kadar sıkı ve ne kadar uzun çalıştığına dair manuel bir müdahale olarak düşünün. Uzmanlık alanınıza veya yaptığınız işin türüne bağlı olarak titizlik veya hız konusunda güçlü bir tercihiniz olduğunda bilinçli olarak kullanın ve bunu görev göre değil, genel bir tercih olarak ele alın.

Opus 4.8'in lansmanını takiben pratik bir not: testlerimizde, Opus 4.8'deki varsayılan çaba ayarı, aynı görevde Opus 4.7'deki varsayılan çaba ayarıyla yaklaşık aynı miktarda token için daha iyi sonuçlar üretir.

Claude yanlış yaptığında neyi değiştirmeli

Claude bir şeyi yanlış yaptığında, ilk içgüdünüz bir ayarı değiştirmek olmamalıdır. Ona verdiğiniz bağlama bakmak olmalıdır. Promptunuz çok mu belirsiz? Claude doğru araçlara bağlı mı? Doğru becerilere sahip mi?

Gerekli olmaması gereken bir görevde çabayı artırıyorsanız, düzeltme genellikle yukarı akıştadır: bağlamınızda, CLAUDE.md dosyanızda veya görevin kapsamında.

Ancak diyelim ki net bir bağlam verdiniz ve Claude hala yanlış yapıyor. Kendinize sormanız gereken soru şudur: yeterince çabalamadı mı, yoksa yeterince bilmiyor muydu?

Model: sorun çok zordu

Sorun gerçekten zor olduğunda daha büyük bir model seçin; ince hatalar, bilinmeyen alanlar, mimari kararlar gibi. Daha küçük model, ona ne kadar bağlam verirseniz verin kendinden emin bir şekilde yanlış olduğunda, istediğiniz şey daha büyük bir modeldir.

Daha büyük modeller ayrıca belirsizliği ele almada daha iyidir. Daha küçük modellerde, yürütmeyi yönlendiren belirli talimatlar başarı için daha iyi bir reçetedir.

İş rutin olduğunda daha küçük bir model seçin: tam olarak tanımlayabileceğiniz düzenlemeler, mekanik değişiklikler, zaten bağlamda olan kodla ilgili sorular. Görevin ihtiyaç duymadığı bir yetenek için ödeme yapmanın bir anlamı yoktur.

Claude ilgili tüm bağlama sahipse, açıkça denediyse ve hala yanlış yaptıysa; bu daha büyük bir modele geçme sinyalidir. Ve daha büyük modeldeyseniz ve iş bir süredir rutinse, daha küçük modele geçmek hızı artıracak ve genellikle çıktı kalitesini etkilemeden maliyeti düşürecektir.

Çaba: Claude yeterince çabalamadı

Claude yeterince çabalamayarak yanlış yaptıysa daha yüksek bir çaba seviyesi seçin: bir dosyayı atlamak, testleri çalıştırmamak veya işini çift kontrol etmemek gibi. Bu, en çok modelin varsayılanının altında bir çaba seviyesi seçtiyseniz geçerlidir.

Uzman, uzman ve generalist

İki ayar hakkında düşünmenin bir yolu, Fable'ın neredeyse hiç kimsenin çözemediği sorunları çözebilen bir uzman, Opus'un uzman ve Sonnet'in gerçekten iyi bir generalist olmasıdır. Çaba seviyesi, herhangi birinin görevinizde ne kadar zaman harcayacağına karar verir.

Düşük çabada Opus, sizinkine benzer sorunlarla ilgili derin deneyime sahip bir uzmanla beş dakika geçirmek gibidir. Kod tabanınızda olmayan bilgileri getirirler; daha önce gördükleri desenler, kontrol etmeyi bildikleri tuzaklar, ancak birçok benzer sorunu çözmüş olmaktan elde edebileceğiniz türden bir deneyim. Ancak beş dakika, kodunuzu hızlıca okumak anlamına gelir, her dosyayı dikkatlice incelemek değil.

Yüksek çabada Sonnet, tüm öğleden sonrası olan generalisttir. Kodlamada harikadırlar ve her şeyi okuyacak, bir şeyleri çalıştıracak, işlerini çift kontrol edecek ve sonunda sizin özel kodunuzu iyice anlayacaklardır.

Fable, herkes takıldığında aradığınız uzmandır. Düşük çabada bile, kimsenin göremeyeceği şeyi fark edeceklerdir. Bu tanıma, en çok ödediğiniz şeydir, bu yüzden onu gerçekten ihtiyaç duyan görevler için saklamaya değer.

Bunların hiçbiri evrensel olarak "daha iyi" değildir. Model ayarı kabaca ne kadar yetenekli olduğudur; çaba ayarı ise kabaca ne kadar titiz olduğudur. Çoğu gerçek görev her ikisinden de biraz gerektirir.

Çaba, model ve token tüketimi

Peki model seçimi, çaba ve token tüketimi nasıl etkileşime girer? Göreve bağlıdır.

Aynı çaba seviyesindeki rutin işlerde, hem daha büyük hem de daha küçük modeller genellikle doğru yapar. Daha büyük model, daha yüksek bir token başına fiyattan, ekstra doğrulama adımlarıyla daha fazla token tüketir. Bu nedenle, rutin bölümler için daha küçük modele geçmek, hiçbir kalite maliyeti olmadan gerçek para tasarrufu sağlar.

Eğriler yalnızca açıklama amaçlıdır ve her iki model tarafından da hızlıca tamamlanabilecek kadar basit tek bir görev için gösterilmiştir. Gerçek kıyaslama verilerini temsil etmezler.

Daha zor, çok adımlı işlerde denklem tersine döner. Daha küçük model, yeteneğinin sınırına doğru ilerlemek zorunda kalır, yinelemeleri tüketirken, daha büyük model aynı kalite çubuğuna daha az adımda ulaşır.

Daha büyük model için token başına daha fazla ödersiniz, ancak daha küçük olanı gerçekten zorlayan görevlerde, görev başına toplam maliyet daha düşük çıkabilir. Ve daha da önemlisi: daha büyük model, en yüksek çaba ayarlarında bile daha küçük modelin tamamlayamadığı görevleri tamamlayabilir.

Bu en çok Fable'da belirgindir. Uzun, çok adımlı işlerde en ileriye gider. Testlerimizde, Opus ve Sonnet'in hiçbir çaba seviyesinde ulaşamadığı işleri tamamladı. Ayrıca token başına en pahalıya mal olur, bu da onu gerçekten ihtiyaç duyan işler için saklamanın diğer nedenidir.

Eğriler yalnızca açıklama amaçlıdır ve her iki modeli de zorlayacak kadar zor tek bir görev için gösterilmiştir. Gerçek kıyaslama verilerini temsil etmezler.

Yukarıdaki grafiklerdeki kilit nokta: çaba, Claude'un eğri boyunca ne kadar ilerlemeye istekli olduğunu seçer. Bu, Claude'un görevi tamamlamak için o kadar ileri gitmesi gerektiği anlamına gelmez.

Son olarak, çaba token tüketimini şekillendirir, ancak onu sınırlamaz. Sistemdeki tek sabit sınır, bir yanıtı akışın ortasında kesen max_tokens değeridir, ancak bu kaba bir araçtır ve çoğunlukla API geliştiricileriyle ilgilidir. Görev bütçeleri gibi daha yumuşak kontroller veya promptunuzda Claude'dan kısa tutmasını istemek daha faydalıdır. Bunlar, modelin takip etmek üzere eğitildiği rehberliktir (sınıra yaklaştıkça toparlanmaya bakacaktır), çarptığı bir duvar değil.

Çaba, Claude'un ne kadar iş yaptığını değiştirir. Model, Claude'un ne bildiğini değiştirir.

Bir sonuçtan memnun olmadığınızda, herhangi bir ayara dokunmadan önce bağlamı kontrol edin: Claude'a net bir prompt, doğru araçlar ve beceriler ve kendi işini doğrulaması için bir yol verin.

Claude hala yanlış yapıyorsa, kendinize sorun: yeterince bilmiyor muydu, yoksa yeterince çabalamadı mı? Yeterince bilmemek bir model sorunudur, yeterince çabalamamak bir çaba sorunudur.

Bu makale, Claude Code ekibinin teknik personel üyesi @lydiahallie tarafından yazılmıştır.