Beş sağlayıcı paneli. Üç API anahtarı seti. İki döndürme takvimi. Çok sağlayıcılı AI çalışmasının sürtünmesi hiçbir bütçe kaleminde görünmez — bir şeyi yayına almanızın ne kadar sürdüğünde ve kurulum maliyeti buna değmediği için denemeyi bıraktıklarınızda görünür.
09:00 ritüeli
Laptopu aç. Kahve. E-postayı kontrol et. OpenAI panelini aç, dünkü harcamaya bak, varsa uyarıları tıkla. Anthropic konsolunu aç, kredi bakiyesini kontrol et, geçen haftaki kuruluş yöneticisi davetinin işleme alınıp alınmadığını kontrol et. Google AI Studio’yu aç, gece boyunca çalıştırdığın ajan testinden gelen oran sınırı kullanımına bak. Orada çalışan bir yan projen varsa belki Replicate veya Fireworks’ü aç. Şimdi 1Password’ü kontrol et, kimlik bilgilerinin Cuma’dan bu yana döndürülmediğini doğrula.
Bu, AI üzerine inşa eden çoğu geliştiricinin pek bahsetmediği sabahın kısmı. İşe başlamadan önceki iş. Kimse tasarlamadığı için günün içine sızan 8–15 dakikalık paneller arası kontrol — bir sağlayıcı kaydından diğerine, rutine dönüşene kadar kendiliğinden ortaya çıktı. Planladığın işe başlamadan önce, hesabını tutmadığın ve geri alamadığın bir üretkenlik vergisini zaten ödemişsindir.
Kimsenin tam olarak itiraf etmediği şey: Çok sağlayıcılı AI iş yükleri yürüten çoğu geliştirici bu rutini fark etmeden gününe yerleştirdi. “Sadece işleri kontrol etmek” gibi gelir. Aslında her çalışma gününde bileşikleşen bir bağlam değiştirme maliyetidir; üretkenlik literatürü onlarca yıldır bu tür parçalanmış dikkatin yayına çıkma hızını öldüren şey olduğunu net biçimde ortaya koyuyor.
Yavaşlama soyut değil. Üç somut biçimde kendini gösterir: basit değişikliklerin ne kadar sürdüğünde, taahhüt etmeden önce aslında kaç modeli değerlendirdiğinde ve kurulum maliyeti buna değmediği için denemeyi bıraktıklarında. Bunların hiçbiri bütçe satırında görünmez. Hepsi gerçektir ve çok sağlayıcılı yığınlar işleten çoğu ekip bunları en az bir mertebe eksik tahmin eder.
Üretkenlik vergisinin aslında saklandığı yer
Bir geliştiriciye “API anahtarlarını yönetmek seni yavaşlatıyor mu?” diye sorarsan, dürüst cevap genelde “pek değil” olur. Her bir sürtünme küçük — burada 30 saniyelik bir giriş, orada 90 saniyelik bir bağlam değişimi, haftada bir beş dakikalık kimlik bilgisi araması. Hiçbiri haftanı yiyen şey gibi hissettirmez. Işıkları açık tutmak gibi gelir.
İşte bu yüzden maliyeti görmek zordur. Yeterince küçük taksitlerle ödenir, hiçbir temas noktası göze batmayacak kadar geniş dağıtılır ve o kadar sık tekrar eder ki sürtünmeyi tamamen fark etmeyi bırakırsın. Üretkenlik araştırması buna “dikkat kalıntısı” der — bir bağlamdan sonraki bağlama geçtiğinde odaklarının önceki bağlama bağlı kalan parçası. Paneller maliyet değil. Biriken dikkat kalıntısı maliyettir.
Günlük dört sürtünme noktası
Dört spesifik temas noktasında maliyet birikir. Her biri küçük. Dördü birlikte çalışma gününün anlamlı bir dilimidir.
- Yeni bir projeye başlarken kimlik bilgisi araması. Yeni bir müşteri projesi veya yeni bir özellik dalı açarsın. İlk ihtiyacın, bu işin çağıracağı sağlayıcıya uygun doğru API anahtarıdır. Bu, gizli bilgileri yöneten aracını açmak, doğru girdiyi bulmak, doğru anahtarı doğru yapılandırma dosyasına kopyalamak ve doğru ortamda (dev / staging / prod) olduğundan emin olmak demektir. Çok sağlayıcılı bir yığında, bu her projede — sağlayıcı başına bir kez — tekrar eder. Her seferde sürtünme küçüktür ve yıl boyunca projeler içinde toplanır.
- Hata ayıklarken panel gezintisi. Bir istek başarısız olur. Oran sınırı mıydı? Model kullanımdan mı kalktı? Yetkilendirme sorunu mu? İçerik politikası reddi mi? Bunu bulmak, ilgili sağlayıcının paneline gitmeyi, istek kaydını bulmayı ve hatayı sağlayıcının özel formatında okumayı gerektirir. Her sağlayıcı bunu farklı düzenler. OpenAI’nin günlükleri Anthropic’inkilerden, Google’unkilerden farklı şekilde yüzeye çıkar. Bugün üçüncü panele geçtiğinde bağlam değişiminin maliyetini fark edersin.
- Sağlayıcılar arasında oran sınırını yorumlamak. Her sağlayıcı oran sınırlarını farklı birimlerle ifade eder. OpenAI dakika başına token ve dakika başına istek kullanır. Anthropic, ayrı tavanlar olarak dakika başına giriş token’ları ve dakika başına çıkış token’ları kullanır. Google dakika başına istek ve gün başına token kullanır. Bir sınıra çarptığında, hata ayıklama yolun baktığın sağlayıcıya bağlıdır — uygulaman gereken zihinsel model sağlayıcıya özeldir. Bu, olay müdahalesinde en fazla dişini gösteren sürtünme noktasıdır; yavaş olmaya tahammül edemezsin.
- API referanslarını okurken dokümantasyon değiştirmek. İki sağlayıcıda araç kullanımını uyguluyorsun. OpenAI dokümanları araç kullanımını belirli bir şemayla işlevler olarak yapılandırır. Anthropic dokümanları bunu kendi şemasıyla tool_use blokları olarak yapılandırır. İkisini okumak, sekmeler arasında geçmek, kavramları iki format arasında zihinsel olarak çevirmek — odaklanmayı bozan bilişsel yük tam olarak budur. Yarım saatlik doküman-sekmelemesi on dakika gibi gelir; gerçek zaman kaybı 45 dakikaya daha yakındır.
Bunların hiçbiri tek başına yıkıcı değildir. Yıkım, planladığın işin üzerine her gün, günde birkaç kez olmalarıdır. Yayına çıkma hızı maliyeti, o küçük kesintilerin toplamıdır ve bunu yıl boyunca yaptığın çalışma günlerinin sayısıyla çarparsın.
Her kurulumda bir saatlik iş gerçekte nasıl görünür
Bunu görmenin en açık yolu, aynı bir saatlik işi iki farklı kurulumda karşılaştırmaktır: üç sağlayıcı entegrasyonu ayrı ayrı yönetilen bir kurulum, tek kimlik bilgisi arkasındaki tek bir OpenAI-uyumlu uç nokta ile bir kurulum. Aynı görev, aynı geliştirici, aynı çıktı — oraya varmak için farklı miktarda iş.
Görev: birincil üretim için Claude Sonnet 4.6 kullanan, Claude oran sınırına takılırsa GPT-5.5’e yedekleyen ve yanıtta yapılandırılmış çıkarma için Gemini 3.1 Pro kullanan yeni bir özellik uygulamak. Sağlayıcılar arası iş akışı — 2026’da rutin hâline gelen türden.
| Adım | Çok sağlayıcılı kurulum | Tek uç nokta kurulumu |
|---|---|---|
| Doğru kimlik bilgilerini projeye alın | Üç sağlayıcı panelini, üç gizli bilgi yöneticisi kaydını açın. ~6 dk. | Tek bir API anahtarı kopyalayın. ~30 sn. |
| SDK’ları kurun ve yapılandırın | Anthropic SDK (diğer işler için zaten kurulu). Google AI SDK (kurulum + yetkilendirme dokümanlarını okuyun). OpenAI SDK (zaten kurulu). ~15 dk. | OpenAI SDK zaten kurulu. base_url değerini değiştirin. ~30 sn. |
| Üç çağrıyı uygulayın | Üç farklı istek şekli, üç farklı yanıt ayrıştırıcı, üç farklı hata deseni. ~25 dk. | Üç modelin tümünde aynı istek şekli. ~10 dk. |
| Yedeğin uçtan uca çalıştığını test edin | Oran sınırına takılana kadar Claude’u vurun (veya hatayı simüle edin). Yedeği doğrulayın. ~12 dk. | Aynı mantık, ancak tutarlı hata semantiğine sahip tek bir uç noktaya karşı test edildi. ~5 dk. |
| Toplam | ~58 dk | ~16 dk |
40 dakikalık fark başlık bulgusu değil. Başlık bulgusu, çok sağlayıcılı kurulumun seni bir saat içinde üç kez bağlam değiştirmeye zorlamasıdır — ve bu bağlam değiştirme maliyeti hiçbir zaman çizelgede görünmez ama Cuma’ya kadar ne kadar ship ettiğinde gerçektir. Tek uç nokta kurulum, seni tek bir zihinsel modelde tutar: bir SDK, bir hata yüzeyi, bir kural seti. Kazandığın 40 dakikanın bir kısmı literal zamandır. Kalanı, aynı anda üç sağlayıcının tuhaflıklarını kafanda tutmak zorunda olmadığında birikmeyen dikkat kalıntısıdır.
Ortaya çıkan desen: Çok sağlayıcılı bir yığında, basit çapraz-model özellikleri tek bir birleşik uç nokta kurulumuna kıyasla ~3–4x daha uzun sürer. Oran, basit ve karmaşık görevlerde de geçerlidir. Sebep ham zorluk değil — işin her adımında üç sağlayıcının konvansiyonları arasında geçiş yapmanın bilişsel yüküdür.
Günlük ritüel kısaldığında neler değişir
Maliyet artımlarda birikir. Maliyeti kaldırdığında fayda da artımlardadır — ancak artımlar ters yönde bileşikleşir. Günlük bağlam değiştirme parçalanmasından 30 dakikayı geri alan bir geliştirici haftada yaklaşık iki buçuk çalışma saatini geri kazanır. Bir yılda bu kabaca üç tam çalışma haftası üretkenlik geri kazanımıdır. Geri kazanılan zaman tek fayda değildir ve muhtemelen en önemlisi de değildir. Uygulamada üç ikincil etki daha çok önem taşır.
Daha fazla denersiniz, çünkü deneme ucuzdur
Çok sağlayıcılı bir kurulumda yeni bir modeli denemek, entegrasyon seremonisinden geçmek demektir: hesabınız yoksa sağlayıcıya kaydolun, kimlik bilgisini ekleyin, SDK yeniyse kurun, sarmalayıcıyı yazın, dağıtın. Çoğu geliştirici için “bu yeni modeli denemeye değer mi?” eşiği yaklaşık yarım günlük emek civarında durur. Bu eşiği aşmayan hiçbir şey denenmez.
Tek uç nokta kurulumunda yeni bir modeli denemek bir yapılandırma değişikliğidir. Kodda model parametresini değiştirin, dağıtın, değerlendirme setinizi çalıştırın, karşılaştırın. Eşik yarım günden on dakikaya düşer. Toplayıcı uç noktalarda çalışan ekipler, aynı iş yükü için doğrudan çok sağlayıcılı entegrasyonlar kullanan ekiplere kıyasla 3–5x daha fazla model seçeneğini test eder — ve sonunda ulaştıkları daha iyi uyumlu seçimler, o daha geniş keşfi yansıtır. Denemeyi ucuzlattığınız için daha fazla denersiniz.
Yeni bir model çıktığında daha hızlı hareket edersiniz
2026’da bu, bir yıl öncesine göre daha da önemli. Yeni sınır modelleri her birkaç haftada bir çıkıyor. Bazen, önceki en iyi seçenek üzerinde zaten yayımladığınız bir iş yükü için fiyat-kalite sınırını anlamlı biçimde değiştiriyorlar. Doğrudan çok sağlayıcılı kurulumda yeni modeli değerlendirmek, yeni sağlayıcıyı kurmayı (ya da mevcut sağlayıcı entegrasyonuna yeni modeli eklemeyi, ya da yeni modeli SDK değişiklikleri boyunca geçirmeyi) gerektirir. Adil bir karşılaştırma elde edene kadar iki hafta geçer ve erken benimseyen avantajı kaybolur.
Tek uç nokta kurulumunda, yeni model genellikle toplayıcının kataloğunda kamuya açıklanmasından saatler sonra görünür. Test etmek bir model parametresi değişikliğidir. Karşılaştırma gün sonunda vardır. Bu yıl boyunca bileşikleşir — toplayıcı uç noktalardaki ekipler, iş yükleri için doğru modeli daha sık kullanır; çünkü daha iyi bir uyum göründüğünde geçiş maliyeti artık belirleyici faktör değildir.
Zamanınız üzerinde yeniden kontrol kurarsınız
Çok sağlayıcılı rutinin anlatması en zor maliyeti, ortadan kalktığında geliştiricilerin en güçlü hissettiği şeydir. Günlük 8–15 dakikalık panel kontrolü, kimlik bilgisi araması ve sağlayıcılar arası bağlam değiştirme sadece zaman değildir — aslında yapmak istediğiniz şeyle hiç ilgisi olmayan bakım işidir. Bu zaman ortadan kalktığında sabah farklı başlar. Laptopu açarsınız ve yaptığınız ilk şey inşa etmektir. Güne nasıl başladığınız üzerindeki yeniden kazanılan kontrol literal dakikalardan daha önemlidir ve geçişi yapan geliştiricilerin tutarlı biçimde en çok önemsedikleri değişim budur.
İlk gün alışkanlık değişimi
Şu anda çok sağlayıcılı bir kurulumda çalışıyorsanız ve yukarıdaki maliyetler tanıdık geliyorsa, geçiş çoğunlukla önce hangi iş yüklerini taşıyacağınızdır. Değişimin fiilen nasıl geliştiğine dair pratik bir çerçeve:
- İlk taşınacak iş yükü yeni bir özellik olmalı, mevcut olan değil. Henüz inşa etmeye başlamadığınız bir özellik seçin, tek uç nokta kurulumuna yönlendirin ve o iş akışından geçerek yayınlayın. Yeni deseni, bir geçiş maliyeti olmayan bir şey üzerinde öğreneceksiniz — yeniden inşa etmeniz gereken mevcut entegrasyon yok, riske atacağınız üretim trafiği yok. Özellik yayına çıktığında, iş akışı değişiminin size uyup uymadığını bilirsiniz.
- İkinci hamle prototipleme ortamınızdır. İş yükünüze karşı yeni modelleri test etmek için kullandığınız şey — değerlendirme iskeletiniz, istem yineleme not defteriniz, A/B karşılaştırma betiğiniz — bunu sonraki adımda tek uç nokta kurulumuna taşıyın. Deneyim faydası önce burada görünür ve eşik düşüşü “entegrasyon için yarım günden” “yapılandırma değişikliğine” en görünür hâliyle burada olur. İlk hafta içinde daha fazla model denemeye başlayacaksınız.
- Mevcut üretim iş yükleri son taşınacaklardır ve hepsinin taşınması gerekmez. Doğrudan sağlayıcı erişimiyle çalışan mevcut tek-model üretim iş yükünüz varsa — stabil, yüksek hacimli ve müzakere edilmiş kurumsal fiyatlandırmadan yararlanıyorsa — bu iş yükü olduğu yerde daha iyi olabilir. Toplayıcı deseni, uyduğu iş yükleri için bir araçtır; diğerleri oldukları yerde kalabilir. Karma kurulumlar işleten çoğu ekip, toplayıcının çok modelli ve deneysellik işlerini üstlendiğini, doğrudan sağlayıcı erişiminin ise tek-model üretim yollarında kullanıldığını görür.
- Panel alışkanlığını kırmak yaklaşık iki hafta sürer. Yeni kurulumun ilk bir-iki haftasında OpenAI’nin panelini açmaya devam edeceksiniz — alışkanlık, zorunluluk değil. Üçüncü haftaya gelindiğinde kas hafızası değişir ve sabah rutini, paneller arası kontrolden ziyade işle başlar. Geri kazanılan zaman ilk günden tam olarak gelmez; yeni alışkanlık yerleştikçe birikir.
Bu sizi nereye götürür
Çok sağlayıcılı AI, her sağlayıcının kötü olmasından dolayı bir problem değildir. Her sağlayıcı gayet iyi. Problem, üçünü veya dördünü aynı anda çalıştırdığınızda ortaya çıkan şeydir — bağlam değiştirme maliyeti, kimlik bilgisi yüzeyi, dokümantasyonu çapraz referanslama, panel parçalanması. Bunların hiçbiri tek başına yıkıcı değildir. Yıkım, planladığınız işin üzerine her gün, günde birkaç kez olmalarıdır.
Pratik bir sonraki adım: Kendinizi bir hafta boyunca zamanlayın. Her sağlayıcı panelini açtığınızda, sağlayıcı dokümanları arasında geçiş yaptığınızda veya bir kimlik bilgisi aradığınızda not alın. Haftanın sonunda dakikaları toplayın. Çok sağlayıcılı yığınlar işleten çoğu geliştirici toplamın onları şaşırttığını — ve tek uç nokta kurulumla karşılaştırmanın kendiliğinden ikna edici olduğunu — görür. Eşlik eden yazı, 500 Model, Tek Uç Nokta: Bunun Yığınız İçin Gerçekte Ne Anlama Geldiği, aynı kararın mimari tarafını kapsar; bu yazı onunla yaşamanın nasıl hissettirdiğiyle ilgili.
Çok sağlayıcılı AI’ın maliyeti API harcamasında değil, parçalanmış dikkatte ödenir. İyileşme, geldiğinde üç yerde görünür: sabahınızda geri kazanılan zaman, kurulum eşiği nedeniyle atlayacağınız halde denediğiniz modeller ve güne nasıl başladığınız üzerinde kontrol. Bunların hiçbiri bütçe satırında görünmez. Üçü de gerçektir ve geçişi yapan geliştiriciler bunları tutarlı biçimde fiilen tasarruf edilen saatlerin üstünde sıralar.