ChatGPT Desktop’ı Verimli Kullanma Rehberim: Luna, Terra, Sol ve Astra Arasındaki Farklar

ChatGPT Desktop’ı gerçek geliştirme, araştırma ve proje işlerinde bir süre kullandıktan sonra model seçimine bakışım değişti.

Artık meseleye “En güçlü model hangisi?” diye bakmıyorum.

Benim için asıl soru şu:

Bu işi düzgün şekilde tamamlayabilecek en hızlı ve en ekonomik model hangisi?

Çünkü her işte en güçlü modeli kullanmak gereksiz kaynak tüketebiliyor. Ama diğer taraftan, sırf daha ekonomik diye yetersiz bir model kullanıp aynı işi beş kere düzeltmek de pek mantıklı değil.

Doğru modeli seçmek, projeyi iyi anlatmak, uzun sohbetleri gereksiz yere sürdürmemek ve karmaşık işlerde önce plan çıkarmak; ChatGPT Desktop’tan aldığım verimi ciddi şekilde artırdı.

Önce isimlendirmeyle ilgili önemli bir noktayı netleştirelim:

Luna, Terra ve Sol GPT-5.6 ailesine ait. Astra ise GPT-6 modeli.

Eylül 2026 itibarıyla OpenAI, Astra’yı özellikle daha zor ve kapsamlı işler için konumlandırıyor.

Aslında dört model, dört farklı kaynak bütçesi demek

Ben modelleri kabaca şöyle düşünüyorum:

OpenAI da Luna’yı yüksek hacimli ve maliyet hassasiyeti olan işler için, Terra’yı zekâ ile maliyet arasında denge kuran model olarak, Sol’u karmaşık profesyonel işler için ve Astra’yı en zor görevler için konumlandırıyor.

Buradaki fark pratikte gerçekten önemli.

Mesela 300 satırlık bir listedeki SKU kodlarını ayıklayacaksam Astra kullanmak bana göre biraz gereksiz.

Bu, birkaç CSV kolonunu yeniden adlandırmak için kıdemli sistem mimarı çağırmaya benziyor.

Ama production ortamında birkaç servisi, veritabanını, uygulama kodunu ve eksik stack trace’leri aynı anda anlamayı gerektiren garip bir problem varsa, işte orada daha fazla reasoning bütçesi kullanmak gayet mantıklı olabilir.

Benchmark farkı, fiyat farkından daha küçük

GPT-5.6 ailesinde dikkatimi çeken noktalardan biri şu oldu:

Luna ve Terra’yı, Sol’un basitçe “daha kötü versiyonları” gibi düşünmek doğru değil.

OpenAI tarafından yayınlanan bazı benchmark sonuçlarında modeller arasındaki fark aslında düşündüğümüz kadar büyük değil.

Tabii bunlar benchmark sonuçları. Senin projenin birebir aynı sonucu vereceği anlamına gelmiyor.

Ama günlük ve daha basit işlerde neden Luna veya Terra kullanmanın mantıklı olduğunu güzel gösteriyor.

Astra ise farklı bir nesil olduğu için onu eski benchmark sonuçları üzerinden kıyaslamak çok doğru değil.

Astra ve Sol’un aynı testlerde karşılaştırıldığı daha yeni sonuçlarda fark daha belirgin hale geliyor:

Özellikle görev; yazılımlarla etkileşim, uzun bir muhakeme zinciri, bilinmeyen ortamlar veya birkaç farklı yeteneğin aynı anda kullanılmasını gerektiriyorsa Astra’nın farkı daha çok ortaya çıkıyor.

Benim burada uyguladığım kural basit:

Kullanmayacağın zekâ için fazladan kaynak harcama.

Reasoning seviyesi bazen model kadar önemli

Model seçmek işin yalnızca yarısı.

Diğer yarısı ise modele ne kadar düşünme alanı verdiğin.

Sol, Terra, Luna ve Astra farklı reasoning seviyeleriyle çalışabiliyor. Genel mantık şu:

Daha yüksek reasoning seviyesi, modelin zor problemleri çözmek için daha fazla hesaplama yapmasına izin veriyor.

Ama bunun doğal sonucu olarak daha fazla kaynak ve kullanım hakkı tüketilebiliyor.

Ben bu yüzden her göreve otomatik olarak High veya Max reasoning vermiyorum.

Örneğin:

Luna / Low

Veri dönüştürme, alan isimlerini değiştirme, kayıtları kategorize etme veya basit metin düzenlemeleri için gayet yeterli olabilir.

Terra / Medium

Normal özellik geliştirme, dokümantasyon okuma, bir dosyanın analiz edilmesi veya nispeten standart bir kod değişikliği için güzel bir başlangıç noktası.

Sol / Medium veya High

Mimari kararlar, kolay görünmeyen bug’lar, güvenlik riskleri veya birbiriyle bağlantılı birkaç sistem söz konusuysa daha mantıklı.

Astra / Low veya Medium

Zaten oldukça güçlü olabilir.

High veya Max seviyesini ise ancak gerçekten karmaşık bir problem varsa kullanmayı tercih ederim.

Çünkü daha fazla düşünmek her zaman daha iyi sonuç anlamına gelmiyor.

Bazen problem zaten basittir.

Modele daha fazla düşünme bütçesi vermek yalnızca daha fazla kaynak harcatır.

Context window ile kullanım limiti aynı şey değil

Bu konu kolayca karıştırılabiliyor.

Güncel API modelleri çok büyük context window’lara sahip.

Ancak bu, ChatGPT aboneliğinin sana sohbet başına o kadar tokenı ücretsiz verdiği anlamına gelmiyor.

Context window, modelin teorik olarak aynı görev içerisinde ne kadar bilgiyi dikkate alabildiğini gösterir.

Kullanım limiti ise aboneliğin veya kullandığın çalışma modunun sana ne kadar kaynak ayırdığıyla ilgilidir.

Örneğin ChatGPT Work ve Codex tarafında kullanım; sabit bir mesaj sayısından çok yapılan işin ağırlığına göre değişebiliyor.

Plus planında OpenAI’nin verdiği yaklaşık beş saatlik kullanım aralıkları şu şekilde:

Buradaki sayıları kesin limit gibi düşünmemek gerekiyor.

Bir fonksiyonun adını değiştirmekle yüzlerce dosyadan oluşan bir repository’yi analiz etmek aynı kaynak tüketimine sahip değil.

Reasoning seviyesi, input büyüklüğü, üretilen çıktı, tool kullanımı ve görevin kaç adımdan oluştuğu tüketimi ciddi şekilde değiştirebiliyor.

Zaten sadece bu tablo bile neden her işte Astra kullanmanın mantıklı olmadığını güzel anlatıyor.

Modeller gerçekte ne kadar maliyetli?

ChatGPT aboneliğindeki kullanım ile API fiyatlandırması birebir aynı şey değil.

Ama API fiyatları modeller arasındaki hesaplama maliyetinin farkını anlamak açısından oldukça güzel bir referans.

Bir milyon token için standart metin fiyatlandırması kabaca şöyle:

Bunu biraz daha anlaşılır hale getirelim.

Diyelim ki aynı görev:

20.000 input token

ve

5.000 output token

kullandı.

Tool maliyetlerini ve caching avantajlarını hesaba katmazsak yaklaşık maliyet şöyle olur:

Tabii bu tablo bütün modellerin aynı miktarda token tüketeceği anlamına gelmiyor.

Daha güçlü bir model problemi ilk seferde çözebilir.

Daha ekonomik model ise aynı problem üzerinde birkaç kez düzeltme yapmak zorunda kalabilir.

Bu yüzden benim için iki farklı kavram var:

token başına maliyet

ve

tamamlanmış görev başına maliyet.

Bunlar aynı şey değil.

“Bu model ortalama kaç dakikada bitirir?” sorusunun dürüst bir cevabı yok

İlk başta ben de şöyle basit bir tablo oluşturmak istiyordum:

Luna = 30 saniye / 5K token
Terra = 1 dakika / 8K token
Sol = 3 dakika / 20K token

Ama aslında böyle bir tablo yanıltıcı olurdu.

Çünkü “bir görev” dediğimiz şeyin standardı yok.

Bir görev tek cümlelik olabilir.

Başka bir görev 500 dosyalık repository olabilir.

Birinde hiçbir tool kullanılmaz.

Diğerinde onlarca araç çağrısı gerekebilir.

Reasoning seviyesi değişebilir.

Sohbet geçmişi büyüyebilir.

Model önce yanlış bir yolu deneyip geri dönebilir.

Bütün bunlar süreyi ve tüketimi değiştiriyor.

Bu yüzden benim baktığım metrik şu:

Doğru sonuca ulaşmak için toplamda ne kadar süre ve model kaynağı harcandı?

Ucuz modelin altı kere denenmesi gerekiyorsa, Sol’un ilk seferde doğru çözmesi toplamda daha ekonomik olabilir.

Uzun sohbetler fark ettirmeden pahalı hale geliyor

ChatGPT kullanırken benim için en önemli keşiflerden biri de bu oldu.

Biz sohbet ekranına baktığımızda mesajları görüyoruz.

Model açısından baktığında ise bunların önemli bir bölümü context haline geliyor.

Konuşma büyüdükçe modelin önünde daha fazla:

• eski talimat,

• kod,

• cevap,

• log,

• başarısız deneme,

• açıklama,

• tool çıktısı

birikiyor.

Ve bunların önemli bir kısmının sonraki görevlerde tekrar değerlendirilmesi gerekebiliyor.

Bu yüzden artık bütün projeyi tek bir sonsuz sohbet penceresinde yürütmeye çalışmıyorum.

Mesela şu işleri yaptığımı düşünelim:

• ödeme entegrasyonu,

• Shopify OAuth,

• ürün aktarımı,

• stok senkronizasyonu,

• güvenlik incelemesi.

Bunları gerektiğinde ayrı görevler ve ayrı sohbetler halinde yürütmeyi tercih ederim.

Bunun iki avantajı var:

Model gereksiz bağlamla uğraşmıyor.

Ben de her görevin amacını çok daha temiz şekilde tarif edebiliyorum.

Ama burada da aşırıya kaçmamak lazım.

Eğer yeni görev gerçekten önceki çalışmaya bağlıysa sırf token azaltmak için sohbeti bölmenin anlamı yok.

Ayrı sohbet açıp eski konuşmanın tamamını tekrar yapıştırmak zaten hiçbir şeyi çözmez.

Buradaki amaç:

Context’i sıfırlamak değil, gereksiz context’i azaltmak.

İş vermeden önce projeyi README ile tanıt

Kodlama projelerinde en çok faydasını gördüğüm şeylerden biri, modele işe başlamadan önce düzgün bir proje açıklaması vermek oldu.

Burada README gerçekten önemli.

İyi hazırlanmış bir README en azından şu soruların cevabını hızlıca vermeli:

• Bu proje ne yapıyor?

• Hangi teknoloji stack’i kullanılıyor?

• Repository nasıl organize edilmiş?

• Proje nasıl çalıştırılıyor?

• Testler nasıl çalıştırılıyor?

• Bozulmaması gereken mevcut kurallar neler?

• Hangi servis veya API’lere bağlı?

• Hangi alanlar özellikle hassas?

Bunun ciddi zaman kazandırdığını düşünüyorum.

Model projeyi tanımıyorsa iki işi aynı anda yapmaya çalışıyor:

Önce mimariyi çözmeye çalışıyor.

Sonra senin verdiğin problemi çözmeye çalışıyor.

İyi bir README verdiğinde ise birkaç adım önden başlıyor.

Tabii bunun da önemli bir güvenlik tarafı var.

Modele yardımcı olmak için README içine şifre, API secret, private key veya production erişim bilgileri koymayın.

Hangi konuda uzman gibi davranması gerektiğini söyle

Önemli görevlerin başında modele nasıl bir bakış açısıyla yaklaşmasını istediğimi de belirtmeyi faydalı buluyorum.

Bu, başına:

“Sen çok iyi bir uzmansın.”

yazınca modelin bir anda daha zeki hale gelmesi anlamına gelmiyor.

Asıl faydası, göreve hangi perspektiften bakması gerektiğini netleştirmesi.

Örneğin şöyle bir talimat kullanabilirim:

Kıdemli bir Laravel/PHP geliştiricisi ve uygulama güvenliği uzmanı gibi çalış.

Değişiklik yapmadan önce projenin README dosyasını oku.

Amaç:
Mevcut public API davranışını bozmadan Shopify senkronizasyon problemini çöz.

Kod değiştirmeden önce:

1. İlgili kodları incele.
2. Sorunun muhtemel nedenini belirle.
3. Kısa bir uygulama planı hazırla.
4. Geriye dönük uyumluluk ve güvenlik risklerini düşün.

Söylediklerimi mekanik şekilde uygulamak zorunda değilsin.

Benim gözden kaçırdığım riskleri, eksik gereksinimleri, çelişkileri
veya daha iyi çözümleri de bulmaya çalış.

Daha doğru bir yol görüyorsan bunu belirt ve planı ona göre düzenle.

İşin tamamlanmış sayılması için:

Problem çözülmüş olmalı,
mevcut davranış bozulmamalı
ve ilgili testler başarıyla geçmeli.

Buradaki benim için en önemli bölüm şu:

Sadece benim söylediklerimi yapma. Benim görmediğim şeyleri de görmeye çalış.

Ben modele kötü bir varsayımı körü körüne uygulatmak istemiyorum.

Amacım söylediğimi harfiyen yapan bir yapay zekâ değil.

Amacım ne yapmak istediğimi anlayıp, gerekiyorsa:

“Burada daha güvenli bir yol var.”

veya

“Bu değişiklik başka bir yeri bozabilir.”

diyebilen bir çalışma arkadaşı elde etmek.

Bence profesyonel sonuç ile sadece talimatı yerine getiren sonuç arasındaki önemli farklardan biri burada ortaya çıkıyor.

Karmaşık işlerde önce plan, sonra uygulama

Küçük bir CSS margin değişikliği için plan hazırlatmanın pek anlamı yok.

Ama production veritabanını etkileyecek büyük bir migration için durum farklı.

Görev:

• büyükse,

• tanıdık değilse,

• riskliyse,

• birden fazla sisteme dokunuyorsa

önce modelden bir plan çıkarmasını tercih ediyorum.

Model önce şunları belirlesin:

1. Neleri incelemesi gerekiyor?

2. Sorunun asıl kaynağının ne olduğunu düşünüyor?

3. Hangi dosyalar veya sistemler etkilenecek?

4. Neleri değiştirmeyi planlıyor?

5. Ne bozulabilir?

6. Sonucun doğru olduğunu nasıl kontrol edecek?

Bundan sonra uygulamaya geçsin.

Özellikle Sol ve Astra gibi modellerde planlama çok daha anlamlı hale geliyor çünkü zaten bu modelleri genellikle daha karmaşık işler için kullanıyoruz.

Planlamanın bana sağladığı başka önemli bir avantaj daha var:

Model 20 dosyayı değiştirmeden önce yanlış yöne gittiğini fark etme şansım oluyor.

Benim pratik model seçme yöntemim

Bir süre böyle çalıştıktan sonra kendi model seçim sistemim oldukça basitleşti.

İş mekanikse Luna ile başla.

Normal düzeyde anlayış ve karar verme gerekiyorsa Terra kullan.

Muhakemenin doğru olması kaynak tasarrufundan daha önemliyse Sol’a geç.

Problem gerçekten zor, alışılmadık, uzun soluklu veya yanlış yapılması pahalıysa Astra kullan.

Ama modeli yükseltmeden önce kendime başka bir soru soruyorum:

Ben görevi gerçekten düzgün anlattım mı?

Çünkü daha güçlü model, vermediğin bir gereksinimi kendi kendine bilemez.

Erişimi olmayan bir dosyayı okuyamaz.

Eksik context’i daha fazla reasoning vererek sihirli şekilde tamamlayamazsın.

Bazen modeli Luna’dan Sol’a geçirmek yerine düzgün bir README hazırlamak çok daha fazla fark yaratıyor.

Bazen problem modelde değil, görev tanımında oluyor.

Bu yüzden bugün ChatGPT Desktop kullanırken benim çalışma düzenim kabaca şu:

Doğru context’i ver → görevi net tarif et → işi kaldırabilecek en ekonomik modeli seç → gerekiyorsa reasoning seviyesini artır → görevleri odaklı tut → problem gerçekten gerektiriyorsa daha güçlü modele geç.

Benim deneyimimde bu yaklaşım hem daha hızlı hem daha ekonomik.

Ama daha önemlisi, ortaya çıkan işi kontrol etmeyi ve güvenmeyi çok daha kolay hale getiriyor.