Claude 5.5: Başarısız Görevler İçin Ödeme Yapmayı Bırakın

Önemli olan Sonnet ve Opus kurulumu: effort, önbellek, doğrulama ve tamamlanan görev başına maliyet

En ucuz model, token fiyatı en düşük olan model değildir

İşi bitiren, kontrolü geçen ve aynı bağlam için sizi beş kez daha ödeme yapmaya zorlamayan modeldir

Sonnet 5.5 ve Opus 5.5 bu ayrımı alışılmadık derecede önemli kılıyor. Biri hacim için fiyatlandırılmış. Diğeri ise daha zorlu işler için. Her ikisinin de yeni bir effort davranışı var ve her ikisi de iyi önbelleklenmiş bir ajan döngüsünde şaşırtıcı derecede ucuza gelebilir

Eski konfigürasyonunuzu bu modellerden herhangi birine kopyalarsanız sonuç daha yavaş, daha pahalı veya bir 400 hatası olabilir

Ben olsam bunun yerine şu kurulumu inşa ederdim

1GÖREV → SONNET 5.5 → KONTROL → GEREKİRSE OPUS 5.5 → DOĞRULANMIŞ SONUÇ
2             ↘ effort ↗         ↘ önbellek + kullanım defteri ↗

Substack'te AI ajanları, iş akışları ve üretim sistemleri hakkında pratik analizler yayımlıyorum

Bültene buradan katılın

Yığınınızı (stack) belirlemesi gereken tek metrik

Model karşılaştırmalarının çoğu milyon token başına dolar ile başlar

Ajanınız token teslim etmez. Tamamlanmış görevler teslim eder

https://x.com/claudeai/status/2102435511222890900

Tekrar edelim: bunlar onların testleri. Sizin mimarinizin kendi rakamlarına ihtiyacı var

Bu da kontrolün, etkileyici bir cevabı okuduktan sonra verilen muğlak bir "olmuş" onayı olamayacağı anlamına gelir. Kodlama için merge'i engelleyecek testi kullanın. Veri çıkarımı için gerekli alanları etiketli bir veri setiyle karşılaştırın. Araştırma için atıfta bulunulan kaynağın gerçekten her iddiayı destekleyip desteklemediğini kaydedin. Sadece demonuzdaki güzel örnekleri değil, asla geçemeyen görevlerin maliyetini de hesaba katın

Ve zorlu kuyruğu ayrıca inceleyin. En ucuz ayar isteklerinizin %90'ını hallediyor ama kalan %10'da bütçenin yarısını yakıyorsa, ortalaması farklı bir modele ihtiyaç duyan iş akışı kısmını gizleyebilir

5.5 fiyat listesi aslında ne diyor

3 Ekim 2026 itibarıyla, standart Claude API fiyatlarıyla, milyon token başına:

1SONNET 5.5
2Yeni girdi   $2       Çıktı   $10
3Önbellek okuma $0.20    Önbellek yazma  $2.50 / 5dk, $4 / 1s
4
5OPUS 5.5
6Yeni girdi   $4       Çıktı   $20
7Önbellek okuma $0.20    Önbellek yazma  $5 / 5dk, $8 / 1s

Her iki model de 1M token bağlam penceresine ve 128K token maksimum çıktıya sahip. Bunlar üst sınırlardır, ikisini de sonuna kadar doldurmak için birer neden değil.

Model özellikleri ve fiyatlandırma

Garip olan satır önbellek okuma

Opus'un yeni girdi ve çıktısı iki kat daha pahalı, ancak önbelleğe alınmış bir ön ek her iki modelde de milyon başına aynı $0.20'ye mal oluyor. Bu, bir Opus çalıştırmasını eşit derecede ucuz yapmaz: yeni girdi, çıktı ve önbellek yazmaları için yine daha fazla öder. Ancak bu, çok okumalı bir oturumda model fiyat farkının daralabileceği anlamına gelir

İnsanların gözden kaçırdığı ikinci bir ayrım daha var. Anthropic'in "Opus 5'ten %40 daha ucuz" ifadesi tipik \çalıştırma maliyetinin\ bir tahminidir. Opus 5.5'in yeni token fiyatları %20 düştü; önbellek okuma fiyatı ise %60 düştü. Bu rakamlar birbiriyle ilişkili ama birbirinin yerine kullanılamaz

Effort bir kalite ayarı değil, yönlendirme kararıdır

Sonnet 5.5 low, medium, high, xhigh ve max seviyelerini destekler. API'de varsayılan olarak high gelir; Anthropic, Claude uygulamalarında varsayılanın medium olduğunu belirtir. Opus 5.5 ise API'de varsayılan olarak medium gelir. Bu seviyeler, önceki modellerdeki aynı kelimelerin ifade ettiği şeylerle birebir aynı anlama gelecek şekilde kalibre edilmemiştir.

Benim başlangıç haritam:

• Sonnet low Dar kapsamlı, gecikmeye duyarlı ve ucuz bir kontrol mekanizması olan istekler için
• Sonnet medium Net tanımlanmış kodlama ve rutin çok adımlı işler için
• Sonnet high Medium çalıştırma gerçek bir kontrolü geçemediğinde veya görev kanıtlanmış bir karmaşıklık örüntüsü taşıdığında
• Opus medium Belirsiz, dosyalar arası, uzun vadeli ve Sonnet'in sorun etrafında dönüp durduğu işler için
• Xhigh/max Sadece değerlendirmeleriniz (eval) ekstra zaman ve tokenlara değecek bir kazanç gösterdiğinde

Bu evrensel bir hiyerarşi değil, başlangıç hipotezidir. Anthropic'in Sonnet 5.5 için bildirdiği FrontierCode sonuçlarında xhigh, max'ın üzerinde puan aldı. Daha fazla effort, daha iyi bir sonucun kanıtı değildir

Anthropic'in dipnotu bu mantığa aykırı sonucu açıklıyor: max seviyesinde model daha sık ek kod inceleme işlerine girişti. İncelenen iki vakada bu durum bir zaman aşımına veya görevin kapsamını aşan düzenlemelere yol açtı.

Hata modu "model yeterince düşünmedi" değildi. Effort'u yanlış yere harcamaktı. Ajanınız zaten kontrolleri geçiyorsa, ekstra inceleme turları bir maliyete ve yeni hataların kaynağına dönüşebilir

https://x.com/edwinarbus/status/2104675431853248816

Ayrıca max_tokens değerini düşük tutup buna optimizasyon demeyin. Bu sınır hem düşünmeyi hem de görünür çıktıyı kapsar. Görevin ortasında keserseniz, tasarruf etmek yerine kırpılmış bir cevap ve ikinci bir çalıştırma satın almış olursunuz

https://x.com/claudeai/status/2104633115620823187

Bu oldukça dikkat çekici bir lansman iddiası. Yine de bir üretim konfigürasyonunun sizin kendi temel çizginizi (baseline) geçmesi gerekir

Model yönlendiricisi icat etmeden önce küçük bir tarama yapın

Gerçekten önemsediğiniz 10-30 görev seçin. Kolay işleri, belirsiz işleri ve loglarınızdaki sinir bozucu hataları dahil edin. Her göreve bir doğrulayıcı atayın: testler, yapılandırılmış bir karşılaştırma, bilinen bir cevap veya çalıştırmadan önce kaydedilmiş insan odaklı bir değerlendirme rubriği

İşte en küçük ama işe yarar API araştırması. İhtiyacınız olan kullanım alanlarını loglar. Bunu her model ve effort seviyesinde aynı görev üzerinde çalıştırın, ardından kendi geçti/kaldı kontrolünüzü ekleyin. Bu tam teşekküllü bir ajan benchmark'ı değildir

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # claude-opus-5-5 ile tekrarlayın
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # high ile tekrarlayın
8    messages=[{"role": "user", "content": "Bunu gerçek bir görevle değiştirin."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("yeni", usage.input_tokens, "çıktı", usage.output_tokens)
15print("önbellek okuma", usage.cache_read_input_tokens)
16print("önbellek yazma", usage.cache_creation_input_tokens)

Bu kod resmi Anthropic Python paketini ve bir ANTHROPIC_API_KEY ortam değişkenini varsayar. Önbellekleme etkinleştirilmeden yapılan tek bir izole çağrıdır, dolayısıyla sıfır önbellek okuma ve yazması beklenir. Bir sonraki bölüm bunu neyin değiştirdiğini gösteriyor

Gerçek bir ajan için, yeniden denemeler ve araç çağrıları dahil olmak üzere tek bir görev kimliği altındaki tüm API çağrılarının kullanımını toplayın. Geçiş sayımını yalnızca doğrulayıcı işin bittiğini söylediğinde yapın

Varsayılanınızı seçmeden önce geçiş başına toplam doları karşılaştırın

Testi dürüst tutun:

• Konfigürasyonları karşılaştırmadan önce görev setini ve doğrulayıcıyı dondurun
• Her adayda aynı araçları, izinleri, bağlamı ve çıktı gereksinimlerini çalıştırın
• Geçiş oranını, toplam harcamayı, geçiş başına maliyeti, gecikmeyi ve en uzun veya en pahalı hataları kaydedin
• stop_reason: "max_tokens" durumunu ucuz bir başarı olarak değil, eksik bir deneme olarak sayın

Yukarıdaki kısa kod örneği, tek turlu bir araştırma için 8K çıktı sınırı kullanır. Bu sınırı uzun soluklu bir kodlama ajanına kopyalamayın.

Anthropic, ajan tabanlı işler için çok daha fazla alan önerir çünkü gizli düşünme de aynı limite dahildir.

Sınırı işe göre belirleyin, ardından cevabı işin ortasında durmaya zorlamak yerine harcamayı effort, önbellekleme ve bir görev bütçesiyle kontrol edin

İşin sabit kısmını önbelleğe alın

Ajanlar aynı sistem talimatlarını, araç tanımlarını, repo haritasını ve önceki konuşmayı defalarca gönderir. Bu ön ek sabitse, prompt caching (istem önbellekleme) ekonomiyi küçük bir prompt yeniden yazımından çok daha fazla değiştirir

Örneğin, 50 kez okunan 200K önbelleklenmiş token, 10M önbellek okuma tokenı demektir. Milyon başına $0.20 ile bu okumalar her iki 5.5 modelinde de $2'ye mal olur.

Opus 5.5'te aynı 10M tokenı yeni girdi olarak göndermek $40'a mal olurdu. 200K tokenlık ilk beş dakikalık önbellek yazımı da cabası, $1 daha.

Bu yalnızca ön ek ücretlerinin bir örneğidir: yeni girdi, çıktı, diğer yazmalar, TTL süresinin dolması ve gerçek önbellek ıskalamaları faturaya eklenir

Pratik kurallar:

• Claude API'sinde, üst düzey cache_control={"type": "ephemeral"} veya açık önbellek kesme noktalarıyla prompt caching'e dahil olun. Yukarıdaki araştırma ikisini de yapmaz, bu yüzden önbellek sayaçları normalde sıfırda kalır
• Sabit talimatları ve araçları, değişen kullanıcı isteğinden önceye koyun
• Paylaşılan ön eki turlar arasında aynı tutun; gerçek cache_read_input_tokens değerlerini doğrulayın
• Model değişikliğini ücretsiz bir devam değil, yeni bir konuşma bütçesi olarak ele alın. Önbellek modele özeldir: bir Opus isteği, Sonnet'in az önce önbelleğe aldığı ön eki okuyamaz
• Her turda üst düzey effort'u değiştirmekten kaçının; bu oluşturulan prompt'u değiştirir ve önbelleğe alınmış ön ekleri geçersiz kılar

Desteklenen modellerde mesaj başına effort değişikliği önceki önbelleği koruyabilir, ancak bu Anthropic'in beta başlığını gerektirir ve üst düzey output_config'i değiştirmekle aynı şey değildir.

Sonnet 5.5'in ayrıca bir between_tools uyarısı vardır: bu modda effort konuşmanın ortasında değiştirilemez.

Prompt caching dokümantasyonu

Hızlı bir yanıttan önbellek isabeti çıkarmayın. Usage nesnesini okuyun. Yeni girdiyi, önbellek oluşturmayı ve önbellek okumalarını birbirinden ayırır

Her iki 5.5 modeli de önbelleklenebilir bir ön ekte en az 512 token gerektirir. Ufacık bir system prompt yukarıdaki örnekteki tasarrufu sağlamaz. Varsayılan önbellek ömrü beş dakikadır ve bu hızlı bir araç döngüsüne uygundur.

Bir saatlik yazma daha pahalıdır ve yalnızca gerçek oturumlar beş dakikalık pencereyi kaçıracak kadar sık durakladığında mantıklıdır. Daha uzun TTL için ödeme yapmadan önce bu boşlukları ölçün

Endişeye göre değil, kanıta göre yükseltin

Çoğu ekip yönlendiriciyi tersten kurar: bir görevi "zor" olarak sınıflandırır, pahalı modele gönderir ve daha ucuz yolun işe yarayıp yaramayacağını asla öğrenemez

Doğrulayıcıyı yönlendirme sinyali olarak kullanın

11  Sonnet 5.5 · seçilen effort  → görevi çalıştır
22  Doğrulayıcı                   → geçerse kabul et
33  Opus 5.5 · medium            → yalnızca başarısızlık kanıtıyla yeniden dene
44  Doğrulayıcı                   → kabul et veya kanıtla devret

Kontrol bir test paketi, şema doğrulaması, bilinen bir cevap veya bir inceleyici olabilir. Neyin başarısız olduğunu açıklamalıdır.

"Cevap zayıf hissettiriyor" kötü bir yükseltme sinyalidir, "değiştirilen endpoint iki entegrasyon testinden kaldı" ise faydalıdır

Aynı prompt'u körü körüne tekrarlamayın. Bir sonraki denemeye başarısız olan kontrolü, ilgili artefaktları ve açığı kapatmak için net bir talimat verin. Merdiveni sınırlayın ki ajan, insan kararı gerektiren bir görevi düzeltmeye çalışırken bütçesini yakmasın

Çevrimdışı taramanızda bir Sonnet high yeniden denemesini test edebilirsiniz. Bunu canlı rotada yalnızca doğrulanmış görev başına maliyeti düşürüyorsa tutun. Opus'a geçmeden önce her başarısızlığın iki Sonnet çalıştırmasına ödeme yapması için hiçbir neden yok

Model geçişinin kendisi önbelleğe alınmış bir ön eki bozabilir. Kurtarma yolunu Opus-öncelikli bir rotayla karşılaştırırken bunu hesaba katın

Kesişim noktasını gözden kaçırmak kolaydır. Diyelim ki bir Sonnet denemesi $0.06'ya mal oluyor ve görevlerinizin %80'ini geçiyor.

Başarısız olan her görev daha sonra Opus'ta bitirmek için $0.20'ye mal oluyorsa, örnek ortalamanız tamamlanan görev başına $0.10 olur: $0.06 artı beşte bir görevde $0.20'lik bir kurtarma. Bu, her görevde Opus için $0.20 ödemekten iyidir. Ancak Sonnet $0.14'e mal oluyor ve sadece yarısını geçiyorsa, aynı merdiven model geçişini fiyatlamadan bile $0.24'e mal olur. Bu iş yükünde Opus-öncelikli yaklaşım daha ucuz ve hızlıdır

Bu rakamlar ölçülmüş Claude sonuçları değil, örneklerdir. Amaçları yönlendirme kuralını yanlışlanabilir kılmaktır. Merdiven ancak tasarruf edilen Opus çağrıları; başarısız Sonnet denemelerini, önbellek ıskalamalarını ve ek gecikmeyi telafi ettiğinde yerini hak eder

Bir orta yol da var: Anthropic'in beta advisor tool aracı. Sonnet görevi çalıştırmaya devam edebilir ve tüm işi Opus'a devretmek yerine zor bir kararda Opus'tan yardım isteyebilir.

Bu otomatik olarak daha ucuz değildir. Sonnet'in danışmana gerçekte ne sıklıkla başvurduğunu, bu çağrıların ne kadara mal olduğunu ve nihai geçiş oranını iyileştirip iyileştirmediğini loglayın. Çalıştırıcı nadiren soruyorsa, advisor sadece kullanılmayan bir özelliktir.

Bu 5.5 modellerinde tavsiyenin kendisi istemciye şifrelenmiş olarak döner, bu yüzden özel tavsiye metnini denetleyebileceğinizi varsaymak yerine ortaya çıkan işi değerlendirin

Model seçimi önem kazanmadan önce faturayı şişiren dört sızıntı

Her maliyet sorunu yeni bir yönlendirici gerektirmez

Önce bunları kontrol edin:

• Sürekli büyüyen çıktı Her iki 5.5 modelinde de çıktı tokenları, yeni girdi tokenlarının beş katıdır. Bir konuşmada uzun bir cevap, sonraki turlarda bağlam olarak geri dönebilir. Her adımın anlatıldığı bir transkript değil, artefaktı ve kısa bir tamamlama notu isteyin. Gizli düşünme de çıktı olarak faturalandırılır, bu yüzden sadece kısa bir nihai cevap bir effort sorununu çözmez. Sonucu doğrulamak için ihtiyacınız olan kanıtları bastırmayın
• Görevin gerektirdiğinden büyük görsellerSonnet 5.5, eski Sonnet sürümlerinden daha yüksek çözünürlüklü görselleri işleyebilir ve bu da görsel token sayılarını artırabilir. Ajanın sadece bir buton etiketine veya bir paragrafa ihtiyacı varsa, önce kırpın veya yeniden boyutlandırın. Yoğun bir grafiğe veya küçücük UI detaylarına ihtiyacı varsa, çözünürlüğü koruyun ve körü körüne küçültmek yerine maliyeti ölçün
• Kimsenin kullanmadığı bağlamAraç tanımları, güncelliğini yitirmiş loglar, eski arama sonuçları ve alabildiğine uzayan bir CLAUDE.md her isteğin peşinden gelebilir. Kalıcı kuralları kısa ve sabit bir ön eke koyun; geçici kanıtları onlara ihtiyaç duyan görevin yakınında tutun. Bağlamı budamak, modelin doğru bitirmek için hala ihtiyaç duyduğu gerçekleri silmemelidir
• Kimsenin beklemediği işler için etkileşimli fiyatlandırmaMessage Batches API, her iki modelde de girdi ve çıktıyı %50 indirimli sunar. Çevrimdışı değerlendirmeler, belge geriye dönük doldurmaları ve diğer asenkron işler için kullanışlıdır. Bir insanın bir sonraki adıma hemen ihtiyaç duyduğu canlı bir araç döngüsünün yerini tutmaz

Dördünde de örüntü aynıdır: daha fazla zeka satın almadan veya kalite bozulana kadar effort'u düşürmeden önce, görevin ihtiyaç duymadığı işleri ortadan kaldırın

Tasarrufu 400 hatasına çeviren migrasyon tuzakları

Eski istek gövdeleri 5.5 ailesi için kötü bir başlangıç noktasıdır.

Özellikle:

• Opus 5.5 thinking her zaman açıktır thinking: {"type": "disabled"} ve eski sabit budget_tokens ayarlarını kaldırın; derinliği output_config.effort ile kontrol edin
• Zorunlu araç seçimi her iki 5.5 modelinde de başarısız olur

tool_choice değerleri any ve tool 400 hatası döndürür. auto kullanın, aracın ne zaman kullanılması gerektiğini belirtin ve araç sonucunu kendi kodunuzda doğrulayın

• Thinking blokları metin blokları değildir İçeriği content [0] ile değil, type ile okuyun. Araç döngülerinde thinking bloklarını asistan turuyla birlikte değiştirmeden iade edin
• Arayüzünüz sessiz görünebilir Opus 5.5'te araçlar arası ilerleme, varsayılan görüntüleme ayarında boş olan thinking bloklarında gelebilir. Daha önce bu notları kullanıcılara gösteriyorsanız, desteklenen bir thinking görüntüleme modu isteyin ve blokları türe göre render edin. Aksi takdirde arayüz donmuş görünürken ajan çalışıyor olabilir
• Eski computer-use araç sürümleri başarısız olabilir Bir tarayıcı/bilgisayar ajanını taşımadan önce mevcut araç sürümünü kontrol edin
• Daha küçük bir max_tokens sınırı işi yarıda kesebilir

Metin gizli olsa bile thinking buna dahildir

Bunlar prompt yazma hileleri değil, API davranış değişiklikleridir.

Opus migrasyon rehberi ve Sonnet migrasyon rehberi

Sözleşmeyi kafanızda değil, Claude Code'da tutun

API, her kullanım alanını ölçebileceğiniz yerdir. Claude Code ise birçok insanın model değişikliğini ilk hissedeceği yerdir. Aynı ilke geçerlidir: ajana sınırları belli bir "tamamlandı" tanımı verin, ardından kanıtı göstermesini sağlayın

Claude Code'da /model modeli, /effort ise desteklenen effort seviyesini seçer. Oturumları karşılaştırmadan önce aktif ayarları kontrol edin. Sonnet API varsayılanı, Claude uygulamanızın veya Claude Code oturumunuzun o an ne kullandığını güvenilir şekilde tarif etmez

Bu, eksiksiz ve yeniden kullanılabilir bir CLAUDE.md başlangıç bloğudur. Komutları projenize uyacak şekilde değiştirin

1# Çalışma sözleşmesi
2
3Yalnızca istenen değişikliği yap. İlgisiz işleri koru.
4Düzenlemeden sonra ilgili testleri çalıştır. Çalıştıramadığın her kontrolü bildir.
5İstenen iş geçtiğinde dur. Ekstra özellik veya inceleme döngüsü ekleme.
6Şununla bitir: Değiştirildi / Doğrulandı / Kalan risk.
7Yıkıcı eylemlerden, yayımlamadan veya bu repo dışındaki değişikliklerden önce sor.

Bu blok sihirli bir şekilde her çalıştırmayı ucuzlatmaz. Başarıyı ve başarısızlığı görünür kılar. Buradan hareketle, aynı görevlerde Sonnet-öncelikli bir iş akışını Opus-öncelikli bir iş akışıyla karşılaştırabilirsiniz

Görev mesajının yine de spesifik olması gerekir. İşte "ödeme kodunu düzelt" ile bir ajanın gerçekten bitirebileceği bir iş arasındaki fark

1Değişiklik: ödeme endpoint'ini yeni istemciye taşı
2Bitti: eski istemci kaldırıldı, endpoint testleri geçti, diff bu yolla sınırlı
3Dur: veri silmeden veya repo dışında bir şey değiştirmeden önce sor
4Bildir: değiştirilen dosyalar, çalıştırılan kesin kontroller, kalan risk

Bu küçük sözleşme, doğrulayıcıya somut olarak inceleyeceği bir şey verir. Ayrıca modele durması için bir neden sunar. "Mükemmel olana kadar incele" gibi ucu açık bir talimat, başarılı bir değişikliği ücretli başka bir döngüye dönüştürebilir

Uzun projeler için kontrol listesini sıkıştırmadan (compaction) sağ çıkacak bir dosyada tutun. Alt ajanlar için, ana ajandan raporlarını kabul etmeden önce kanıtlarını incelemesini isteyin. Ve eğer sadece fikir istediyseniz, Claude'a inşa etmeye başlamamasını söyleyin. Bunlar "daha zeki ol" promptları değil, iş akışı sınırlarıdır

İlk olarak hayata geçireceğim kurulum

• 10-30 gerçek görev seçin ve her biri için bir kontrol tanımlayın
• Sonnet 5.5'i medium ve high, ardından Opus 5.5'i medium seviyesinde tarayın
• Her görev için yeni girdiyi, çıktıyı, önbellek yazmalarını, önbellek okumalarını, gecikmeyi, yeniden denemeleri ve geçti/kaldı durumunu loglayın
• Sabit ön eki önbelleklenebilir tutun ve usage içindeki isabetleri doğrulayın
• Yalnızca başarısızlıkları, kanıtlarıyla birlikte yukarı yönlendirin
• İş yükü değiştiğinde merdiveni yeniden gözden geçirin. Kaydedilmiş bir benchmark kalıcı bir gerçek değildir

Zorlu %10 sürekli olarak Sonnet başarısızlığından doğrudan Opus başarısına geçiyorsa, bu tanınabilir görev sınıfını baştan Opus'a yönlendirmeyi düşünün. Eğer Sonnet high aynı durumları daha ucuza geçiyorsa, orada tutun. Yönlendirici ölçülmüş bir politikadır, hangi modelin daha zeki olduğuna dair kalıcı bir görüş değil

5.5 yükseltmesi sadece "ucuz işler için Sonnet, zor işler için Opus kullan" demek değil

Modeli fiyatlandırmayı bırakıp biten işi fiyatlandırmaya başlamak için bir fırsat

Buraya kadar okuduysan

-> Substack'ime abone ol

-> Telegram grubuma katıl

-> Bu makaleyi yer imlerine ekle

-> @0xwhrrari hesabını takip et