Forem: Tobias Hoffmann

Ghostty GitHub'dan Ayrılıyor: Geliştirici Araçları Üreticileri İçin Ne Anlama Geliyor?

Tobias Hoffmann — Thu, 30 Apr 2026 04:05:52 +0000

28 Nisan 2026'da Mitchell Hashimoto, açık kaynaklı terminal emülatörü Ghostty'nin GitHub'dan ayrılacağını duyurdu. Hashimoto GitHub kullanıcısı 1299; Şubat 2008'den beri platformu neredeyse her gün kullandı. Ancak karar gününde bu geçmiş artık belirleyici değildi: kişisel günlüğünde zaten “neredeyse her gün bir X var” şeklinde kesintileri takip ediyordu ve aynı gün yaşanan GitHub Actions hatası PR incelemelerini iki saat boyunca engelledi. Kararı netti: “Her gün sizi saatlerce bloke ediyorsa, burası artık ciddi işler yapmak için bir yer değil.”

Apidog'u bugün deneyin

Geliştirici araçları geliştiriyorsanız bu duyuru yalnızca “bir proje GitHub’dan ayrılıyor” haberi değildir. Hashimoto, HashiCorp’u GitHub üzerinde kurdu; Terraform, Vagrant, Vault, Consul ve Boundary gibi araçları bu ekosistem üzerinden yayınladı. Bu profildeki bir kullanıcının dünyanın en baskın geliştirici platformundan güvenilirlik nedeniyle ayrılması, araç geliştiricileri için doğrudan bir uyarıdır: kritik yolda yer alıyorsanız, güvenilirlik özelliklerden önce gelir.

Yapay zeka dönemi geliştirici araçlarının GitHub odaklı iş akışlarını nasıl değiştirdiğine dair arka plan için AGENTS.md dosyaları nasıl yazılır ve ekipler için GitHub Copilot kullanımı ve faturalandırma API'si yazılarına bakabilirsiniz. GitHub güvenilirlik boşlukları etrafında otomasyon geliştiren bir ekibin bakış açısı için Clawsweeper triage botu yazısı da iyi bir örnektir.

TL;DR

Mitchell Hashimoto, 28 Nisan 2026'da Ghostty'nin GitHub'dan ayrılacağını duyurdu.
Gerekçe özellik, fiyatlandırma veya politika değil; kronik GitHub Actions ve platform kesintileriydi.
Duyuru gününde GitHub Actions hatası PR incelemelerini yaklaşık iki saat engelledi.
Ghostty'nin GitHub deposu salt okunur yansıma olarak kalacak; aktif geliştirme aşamalı olarak başka bir platforma taşınacak.
Hashimoto henüz hedef platform açıklamadı; ticari ve FOSS seçenekleri değerlendiriyor.
Geliştirici araçları için ana ders: Kullanıcının kritik yolundaysanız, kesinti doğrudan güven kaybıdır.
API ekipleri için uygulanabilir model: sağlayıcıdan bağımsız istemciler, mock sunucular, çoklu sağlayıcı testleri ve önceden hazırlanmış taşıma yolları.

Hashimoto gönderide ne söyledi?

Duyuru gönderisi kısa ve doğrudan. Manifesto yok, Microsoft eleştirisi yok, yeni platform tanıtımı yok.

Hashimoto’nun anlattığı zaman çizelgesi şöyle:

GitHub kesintilerini kişisel günlüğüne kaydetmeye başladı.
Günlük beklediğinden hızlı doldu.
Yazıyı yazdığı sabah GitHub Actions hatası PR incelemelerini iki saat boyunca engelledi.
Ghostty için GitHub’ın artık yeterince güvenilir olmadığı sonucuna vardı.

Bu kararı tek bir kötü güne tepki olarak okumamak gerekiyor. 27 Nisan 2026’da Actions, paketler ve API yüzeyini etkileyen büyük bir GitHub kesintisi yaşandı; ancak Hashimoto’nun günlüğü bundan önce başlamıştı. Yani kararın nedeni tek olay değil, birikmiş paterndi.

Geçişin sınırları da net:

Ghostty ayrılıyor.
Hashimoto’nun diğer projeleri şimdilik GitHub’da kalıyor.
Ghostty deposu mevcut URL’de salt okunur yansıma olarak kalacak.
Sorunlar, PR’ler ve CI dahil aktif geliştirme yeni platforma taşınacak.
Hedef platform henüz açıklanmadı.
Geçiş tek seferlik “bayrak günü” şeklinde değil, aşamalı yapılacak.

Bu noktada önemli olan şey, şikayetin ürün yönüyle ilgili olmaması. Sorun şu: temel geliştirme altyapısı saatlerce çalışmadığında, üstündeki proje de çalışamıyor.

Güvenilirlik neden platform seçiminden daha önemli?

Duyuruda çoğu kişinin sorduğu ilk soru şu oldu:

Ghostty nereye taşınıyor?

Daha önemli soru ise şu:

GitHub gibi olgun bir platform, Hashimoto gibi uzun süreli ve yüksek profilli bir kullanıcının güvenilirlik nedeniyle ayrılacağı noktaya nasıl geldi?

Bu duyuruyu klasik “X platformundan ayrılıyorum” yazılarından ayıran üç unsur var.

1. Kullanıcı profili

Hashimoto yeni bir kullanıcı değil. Fortune 500 şirketlerinde kullanılan altyapı araçlarının arkasındaki isimlerden biri. GitHub'ın güvenilir olmadığını söylediğinde, bu mesaj yalnızca bireysel geliştiricilere değil, kaynak kodu stratejisi belirleyen ekip liderlerine ve CTO’lara da ulaşır.

2. Ayrılma nedeni

Sebep Copilot, Microsoft, yapay zeka eğitimi, fiyatlandırma veya politika değil.

Sebep daha basit:

Araç ihtiyaç duyulduğunda çalışmıyor.

Geliştirici araçları için bu en kritik eksendir.

3. Ton

Gönderi öfkeli değil. Daha çok, kalmak için uzun süre çabalamış bir kullanıcının yazdığı kısa bir olay sonrası raporu gibi. Bu da onu daha etkili kılıyor.

Bir geliştirici aracı işletiyorsanız en kötü senaryo budur: kullanıcılarınız size kızmaz, sadece kesinti kayıtlarını sessizce biriktirir ve bir noktada ayrılır.

Kendi geliştirici aracınızı nasıl stres test edersiniz?

Ürününüz bir geliştiricinin kritik yolundaysa, Hashimoto duyurusunu bir kontrol listesine dönüştürebilirsiniz.

1. Kullanıcılarınız sizin için aynı günlüğü yazabilir mi?

Son 90 gündeki tüm olayları çıkarın:

durum sayfasına giren kesintiler,
iç ekiplerin bildiği ama dışarıya yansımayan bozulmalar,
yavaşlamalar,
kuyruk gecikmeleri,
bölgesel sorunlar,
CI/CD başarısızlıkları.

Sonra bunları en yoğun kullanıcılarınızın çalışma saatleriyle eşleştirin.

Sorulacak pratik soru:

En ağır kullanıcılarımız, bizi beklerken haftada kaç saat kaybediyor?

Cevap sıfırdan büyükse, kullanıcı güveni aşınıyor demektir.

2. Güvenilirliğinizin yönü ne?

Tekil kesinti önemlidir, ancak trend daha önemlidir.

Şu metrikleri bileşen bazında izleyin:

olay sayısı,
ortalama çözüm süresi,
tekrar eden olay oranı,
kullanıcı etkisi süresi,
iş saatlerinde gerçekleşen kesinti oranı.

Basit bir tablo bile yeterlidir:

Bileşen        Bu Ay Olay  Önceki Ay Olay  Trend
Actions        5           2               ↑
API            3           3               →
Paketler       2           1               ↑
Web UI         1           4               ↓

SLA hâlâ tutuyor olabilir; ancak olay sıklığı artıyorsa güvenilirlik sessizce kötüleşiyor demektir.

3. Durum sayfanız gerçeği hızlı gösteriyor mu?

Kullanıcılar kendi günlüklerini genelde resmi sinyale güvenmediklerinde tutar.

Durum sayfanızda yalnızca “büyük kesinti” değil, aşağıdakiler de görünür olmalı:

belirli özellik bozulmaları,
bölgesel yavaşlıklar,
arka plan kuyruğu gecikmeleri,
CI çalıştırıcı kapasite sorunları,
API hata oranı artışları.

İyi durum sayfası soğuk değil, sıcak çalışır: kullanıcı problemi yaşarken sinyal verir.

4. Uptime’ı kendi grafiğinize göre değil, müşterinin iş akışına göre ölçüyor musunuz?

%99,95 çalışma süresi iyi görünebilir. Ancak kesintiler hep müşterinin PR inceleme, deploy veya yayın saatlerine denk geliyorsa pratikte güvenilir değilsiniz.

Örneğin:

Toplam aylık kesinti: 2 saat
Kesinti zamanı: Pazartesi 10:00-12:00
Müşteri iş akışı: Haftalık release hazırlığı
Gerçek etki: Release gecikmesi

Kullanıcı açısından bu “ayda 2 saat” değil, “release sırasında sistem çalışmadı” demektir.

GitHub kilitlenmesi neden yalnızca git geçmişi değildir?

Hashimoto’nun en dikkat çekici cümlelerinden biri şu fikirdi:

Projelerimi nereye koyacağım benim için hiç sorun olmamıştı: her zaman GitHub.

Bu alışkanlık pahalıdır.

Bir projeyi GitHub’dan taşırken yalnızca git geçmişini taşımıyorsunuz. Şunları da düşünmeniz gerekir:

issues,
pull request geçmişi,
review yorumları,
Discussions,
Actions workflow dosyaları,
secret yönetimi,
CODEOWNERS kuralları,
release artifact’leri,
package registry,
OAuth entegrasyonları,
webhook’lar,
bot izinleri,
branch protection kuralları.

Git deposunu klonlamak kolaydır:

git clone https://github.com/org/project.git

Ama issue geçmişini, PR review bağlamını ve CI kimlik bilgilerini aynı sadelikte taşıyamazsınız.

Geliştirici aracı geliştiriyorsanız bu risk daha da büyür. Aracınız:

GitHub Action olarak çalışıyorsa,
Marketplace üzerinden dağıtılıyorsa,
GitHub OAuth ile giriş yapıyorsa,
GitHub Packages üzerinden paket yayınlıyorsa,

aracınızın güvenilirliği GitHub’ın güvenilirliğine bağlı hale gelir.

Kullanıcı kesintiyi yaşadığında çoğu zaman şunu ayırmaz:

GitHub mı çöktü?
Sizin aracınız mı çöktü?
Entegrasyon mu çöktü?

Kullanıcı açısından sonuç aynıdır: iş durmuştur.

Daha az kilitlenme için mimari yaklaşım

GitHub’ı “altyapının kendisi” olarak değil, “sağlayıcılardan biri” olarak modelleyin.

Örnek arayüz:

interface SourceProvider {
  listPullRequests(repo: string): Promise<PullRequest[]>;
  getIssue(repo: string, id: number): Promise<Issue>;
  createComment(targetId: string, body: string): Promise<void>;
}

GitHub adaptörü:

class GitHubProvider implements SourceProvider {
  async listPullRequests(repo: string) {
    // GitHub REST veya GraphQL API çağrısı
  }

  async getIssue(repo: string, id: number) {
    // GitHub issue çağrısı
  }

  async createComment(targetId: string, body: string) {
    // GitHub comment çağrısı
  }
}

Daha sonra GitLab, Forgejo veya başka bir sağlayıcı için aynı arayüzün arkasına adaptör ekleyebilirsiniz.

class GitLabProvider implements SourceProvider {
  async listPullRequests(repo: string) {
    // GitLab merge request çağrısı
  }

  async getIssue(repo: string, id: number) {
    // GitLab issue çağrısı
  }

  async createComment(targetId: string, body: string) {
    // GitLab note/comment çağrısı
  }
}

Bu yaklaşım tüm geçiş maliyetini ortadan kaldırmaz, ancak sağlayıcı bağımlılığını kod tabanının her yerine yaymanızı engeller.

Geliştirme platformu alternatifleri

Hashimoto hedef platform açıklamadı. Ancak Ghostty gibi açık kaynaklı bir proje için seçeneklerin şekli belli.

Forgejo

Forgejo, Gitea’nın tamamen açık kaynaklı bir hard fork’u. Codeberg e.V. tarafından sürdürülüyor. FOSS uyumlu projeler için güçlü bir adaydır. Federasyon ve ActivityPub tarafında da ilerleme vardır.

Codeberg

Codeberg, kar amacı gütmeyen bir kuruluş tarafından işletilen barındırılmış Forgejo örneğidir. Açık kaynak projeler için ücretsizdir. GitHub ölçeğinde bir Actions eşdeğeri henüz yoktur.

GitLab

GitLab güçlü CI/CD, olgun proje yönetimi ve ticari destek sunar. Birçok iş akışında GitHub’a doğrudan alternatif olabilir. Ancak lisanslama ve ürün yönü nedeniyle bazı FOSS toplulukları için tartışmalıdır.

Sourcehut

Sourcehut e-posta tabanlı iş akışını merkeze alır. Minimalist ve hızlıdır. Niştir, ancak kullanan geliştiriciler tarafından güçlü şekilde benimsenir.

Kendi barındırdığınız Forgejo veya Gitea

En yüksek kontrolü sağlar, ancak operasyonel sorumluluk da sizdedir. Yedekleme, güncelleme, güvenlik, izleme ve kapasite planlamasını siz yaparsınız.

Radicle

Radicle eşten eşe bir model sunar; merkezi ana bilgisayar yoktur. Federasyon argümanı burada güçlüdür, ancak büyük ve görünür projeler için hâlâ erken olabilir.

Bu seçeneklerin hiçbiri GitHub’ın tüm yüzeyini birebir karşılamaz. Zaten ana nokta da bu: tek bir platform tüm geliştirme yığınını emdiğinde, ondan temiz şekilde ayrılmak yapısal olarak zorlaşır.

API ekipleri için ders

Terminal emülatörü geliştirmiyor olabilirsiniz. Ancak API veya API aracı geliştiriyorsanız aynı model geçerlidir.

Şu eşlemeyi yapın:

GitHub Actions  -> bağımlı olduğunuz yukarı akış API
Issues / PR     -> müşterinin size hata bildirdiği kanal
GitHub kesintisi -> sağlayıcı kesintisi

Temel soru değişmez:

Müşterinizin işinin ne kadarı kontrol edemediğiniz bir hizmete bağlı?

Bu riski azaltmak için üç pratik model kullanabilirsiniz.

1. Bağımlı olduğunuz API’leri mock edin

Yukarı akış API kapalıyken geliştirme durmamalı.

Bu nedenle şu katmanlarda mock sunucu kullanın:

yerel geliştirme,
test paketi,
CI,
demo ortamı,
hata senaryosu testleri.

Basit bir örnek:

{
  "id": "evt_123",
  "status": "processed",
  "amount": 1999,
  "currency": "USD"
}

Bu yanıtı canlı API’den beklemek yerine mock sunucuda tanımlarsanız, upstream kapalı olsa bile geliştirme devam eder.

Apidog, aynı veri tanımlarından mock sunucu üretme modelini destekler. Canlı API’yi test etmek için kullandığınız şema, geliştirme sırasında mock yanıt üretmek için de kullanılabilir.

Çok sağlayıcılı bir senaryonun pratik görünümü için GPT-5.5 API'si nasıl kullanılır yazısındaki OpenAI benzeri ekosistem karşılaştırmasına bakabilirsiniz.

2. Birden fazla sağlayıcıya karşı test edin

LLM veya API sağlayıcılarıyla çalışıyorsanız, tek sağlayıcıya bağlı kalmak operasyonel risk yaratır.

Örneğin ürününüz şu sağlayıcılardan birini kullanıyor olabilir:

OpenAI,
Anthropic,
Mistral,
DeepSeek,
Google,
xAI.

Benzer endpoint şekillerine sahip olsalar bile hata davranışları, hız limitleri ve yanıt formatları farklı olabilir.

Test matrisinizi tek sağlayıcıyla sınırlamayın:

providers:
  - openai
  - anthropic
  - mistral
  - deepseek

CI’da aynı sözleşme testini her sağlayıcı için çalıştırın:

PROVIDER=openai npm test
PROVIDER=anthropic npm test
PROVIDER=deepseek npm test

Böylece “birincil sağlayıcı çöktü, biz de çöktük” yerine “yedek sağlayıcıya geçtik” diyebilirsiniz.

Apidog ortam değişkenleriyle bu geçişi tek konfigürasyon değişikliğine indirebilirsiniz:

BASE_URL=https://api.provider-a.example
API_KEY=...

veya:

BASE_URL=https://api.provider-b.example
API_KEY=...

3. Yayın hattınızı barındırma platformundan ayırın

CI tamamen GitHub Actions üzerindeyse ve GitHub Actions çalışmıyorsa, yayın yapamazsınız.

Minimum uygulanabilir önlem:

kritik release job’larını ikinci bir çalıştırıcıda aynalayın,
self-hosted runner seçeneğini test edin,
manuel release yolunu belgeleyin,
artifact üretimini tek platforma bağlamayın.

Örnek basit manuel fallback:

npm ci
npm run test
npm run build
npm publish

Bu komutlar belgelenmemişse, gerçek cevap şudur:

CI kapalıysa release yapamıyoruz.

Ücretli müşterisi olan bir araç için bu kabul edilebilir bir durum değildir.

Esnek API çalışmaları için Apidog tarzı iş akışı

Yukarı akış sağlayıcı kesintilerine karşı daha dayanıklı bir API iş akışı şu şekilde kurulabilir:

Apidog'u indirin.
Bağımlı olduğunuz her yukarı akış API için ayrı proje oluşturun.
İstek ve yanıt şemalarını bir kez tanımlayın.
Bu şemalardan mock sunucu üretin.
Kimlik bilgilerini ortam kapsamlı değişken veya sır olarak saklayın.
Aynı istekleri dev, staging ve prod ortamlarında çalıştırın.
Her release’te sözleşme testlerini çalıştırın.
Desteklediğiniz her sağlayıcı için aynı test setini koşturun.
Upstream bozulduğunda geliştirme ortamını mock sunucuya çevirin.
Canlı servis dönene kadar ürün geliştirme ve test akışını durdurmayın.

Örnek ortam modeli:

dev:
  BASE_URL=https://mock.example
  API_KEY=mock-key

staging:
  BASE_URL=https://sandbox.provider.example
  API_KEY=staging-key

prod:
  BASE_URL=https://api.provider.example
  API_KEY=prod-key

Bu model Ghostty’ye veya yapay zekaya özgü değildir. Dış bağımlılığı olan her API ekibi için geçerlidir.

Geliştiricilerin duyurudan çıkardığı sonuçlar

İlk tepkiler birkaç gruba ayrıldı.

“Aferin ona” grubu

Uzun süredir GitHub kesintilerinden rahatsız olan güç kullanıcıları, bu gönderiyi kendi deneyimlerini görünür kılmak için bir işaret olarak gördü. Birçoğu zaten ikinci bir platforma yansıtma yapıyordu; gönderi bu yansıtmayı daha ciddi ele almalarına neden oldu.

“Bu yalnızca tek kesinti” diyenler

Bu grup GitHub’ın genel uptime rakamlarının hâlâ rekabetçi olduğunu savunuyor. Makro düzeyde haklı olabilirler. Ancak Hashimoto’nun vurgusu tek olay değil, olayların yönü ve sıklığıydı.

“Geçiş zor” diyen pragmatikler

Bu grup da haklı. GitHub’dan çıkmak yalnızca repo taşımak değildir. Issue, PR, CI ve kimlik yüzeyi maliyeti büyüktür. Hashimoto’nun salt okunur yansıma ve aşamalı geçiş planı bu nedenle mantıklıdır.

“Benim depolarım ne olacak?” diye düşünen bakımcılar

Küçük projeler için hesap farklıdır. Hashimoto için saatlerce kesinti ciddi üretkenlik kaybıdır; hafta sonu projesi için yalnızca rahatsızlık olabilir. Ancak yansıtma gibi düşük maliyetli önlemler çoğu proje için yine de değerlidir.

Kendi yığınız için pratik kontrol listesi

Aşağıdaki listeyi doğrudan uygulayabilirsiniz.

1. Aktif depoları ikinci platforma yansıtın

Haftalık veya günlük mirror job kurun.

git remote add mirror git@example.com:org/project.git
git push mirror --mirror

Forgejo, Codeberg veya GitLab kullanılabilir. Amaç hemen taşınmak değil; gerektiğinde çıkış yolunu hazır tutmaktır.

2. Sağlayıcı istemcilerini adaptör arkasına alın

Kötü örnek:

import { GitHubClient } from "@vendor/github";

const prs = await github.listPullRequests(repo);

Daha iyi örnek:

const provider: SourceProvider = createProvider(process.env.SOURCE_PROVIDER);
const prs = await provider.listPullRequests(repo);

Bu sayede GitHub varsayılan kalabilir, ancak tek seçenek olmaz.

3. Manuel fallback yolunu belgeleyin

Şu soruya yazılı cevap verin:

CI çalışmıyorsa release nasıl yapılır?

Belge örneği:

## Manuel Release

1. `main` branch'ini çek.
2. `npm ci` çalıştır.
3. `npm test` çalıştır.
4. `npm run build` çalıştır.
5. Versiyonu doğrula.
6. `npm publish` çalıştır.
7. Release notunu manuel yayınla.

4. Kritik bağımlılıkları listeleyin

Bir tablo oluşturun:

Servis            Kritik mi?  4 saat kapalıysa ne olur?  Fallback
GitHub Actions    Evet        Release durur              Self-hosted runner
GitHub API        Evet        Bot çalışmaz               Cache + retry
Package registry  Evet        Yayın yapılamaz            Manuel publish
LLM provider      Evet        Özellik yavaşlar/durur     İkinci sağlayıcı

Boş kalan fallback alanları risk listesidir.

5. Olayların ikinci türevini izleyin

Sadece uptime değil, olay sıklığı trendini de izleyin.

Ay       Olay Sayısı
Ocak     2
Şubat    3
Mart     5
Nisan    8

Bu tablo SLA ihlali göstermeyebilir, ama geçiş planı hazırlamanız gerektiğini gösterebilir.

API aracı özelinde çalışan bir örnek için sağlayıcı kesintilerinden kurtulan dayanıklı iş akışları oluşturma yazısı, DeepSeek ve OpenAI’yi ikili sağlayıcı örneği olarak kullanarak aynı modeli adım adım ele alır.

Sıkça Sorulan Sorular

Ghostty nereye taşınıyor?

Hashimoto duyuru gönderisinde hedef platform açıklamadı. Ticari ve FOSS sağlayıcılarla görüşmelerin sürdüğünü, geçişin aşamalı yapılacağını söyledi. Mevcut GitHub deposu salt okunur yansıma olarak kalacak.

GitHub gerçekten bu kadar güvenilmez mi?

GitHub’ın genel uptime rakamları benzer platformlarla rekabetçi olabilir. Ancak Hashimoto’nun şikayeti genel yüzde değil, kritik yoldaki tekrar eden kısmi kesintilerdi. Actions, Paketler ve API yüzeyindeki kısa kesintiler bile PR inceleme, CI ve release akışlarını doğrudan durdurabilir.

Depolarımı hemen GitHub’dan taşımalı mıyım?

Çoğu ekip için hemen taşınmak gerekli olmayabilir. Ancak yansıtma neredeyse her zaman düşük maliyetli ve faydalıdır. Haftalık mirror job kurmak, tam geçiş kararı vermeden çıkış yolunu hazır tutar.

Bu GitHub Copilot veya GitHub Actions kullanımımı etkiler mi?

Hashimoto’nun gönderisi Copilot’u özel olarak hedef almıyor. Ancak duyuru günündeki GitHub Actions kesintisi doğrudan tetikleyiciydi. Copilot ayrı bir ürün yüzeyidir ve güvenilirliği ayrıca değerlendirilmelidir. Copilot tarafındaki kullanım ve faturalandırma detayları için ekipler için GitHub Copilot kullanımı ve faturalandırma API'si yazısına bakabilirsiniz.

GitHub API’lerine bağımlı yapay zeka dönemi geliştirici araçları için bu ne anlama geliyor?

GitHub API’sini saran inceleme botları, issue triage araçları veya MCP sunucuları GitHub’ın güvenilirlik profilini miras alır. Azaltma stratejisi aynıdır:

önbellekleme,
retry,
açık hata durumları,
mock upstream,
sağlayıcı adaptörü,
manuel fallback.

Apidog mock sunucu modeli bu tür test ve geliştirme akışlarını daha dayanıklı hale getirmek için kullanılabilir. Çalışan bir örnek için Clawsweeper triage bot yazısı incelenebilir.

Bu bir “GitHub’dan ayrılma” trendi mi?

Muhtemelen yavaş ilerleyen bir trendin işareti. Büyük projeleri GitHub’dan taşımak haftalar sürebilir; çoğu ekip bunu keyfi olarak yapmaz. Hashimoto gönderisinin önemi, uzun süreli ve yüksek profilli bir kullanıcının geçiş maliyetini ödemeye değer bulmasıdır.

“Geliştirici aracı geliştiricisi” kimdir?

Başka geliştiricilerin günlük iş akışında kullandığı yazılımı geliştiren herkes. Buna şunlar dahildir:

terminaller,
editörler,
CI araçları,
API istemcileri,
izleme araçları,
paket kayıt sistemleri,
review botları,
yapay zeka kodlama yardımcıları.

Müşteriniz geliştiriciyse ve aracınız onların kod yazma, test etme veya yayınlama yolunda duruyorsa, Hashimoto’nun güvenilirlik dersi doğrudan sizin için geçerlidir.

Mistral Medium 3.5 API Nasıl Kullanılır?

Tobias Hoffmann — Thu, 30 Apr 2026 03:57:03 +0000

Mistral, Medium 3.5'i 29 Nisan 2026'da yayınladı. API model kimliği mistral-medium-3.5, uç nokta https://api.mistral.ai/v1/chat/completions ve istek şeması OpenAI standardına yakındır; çoğu entegrasyonda sağlayıcı değiştirmek temel URL ve model ID güncellemesiyle yapılır. Model; 256K bağlam penceresi, yerel görsel girdi, işlev çağırma, 24 dil desteği ve SWE-Bench Verified'da %77,6 başarı oranıyla kod, ajan ve uzun bağlam iş yükleri için konumlanır.

Apidog'u bugün deneyin

Bu kılavuzda kimlik doğrulama, temel parametreler, Python ve Node örnekleri, görsel girdi, araç çağırma, JSON modu, akış, hata yönetimi ve istemleri denerken maliyeti görünür tutan bir Apidog iş akışı yer alır. Karşılaştırmalı model rehberleri için DeepSeek V4 API'sini nasıl kullanacağınızı ve GPT-5.5 API'sini nasıl kullanacağınızı inceleyebilirsiniz.

TL;DR

Uç nokta: POST https://api.mistral.ai/v1/chat/completions
Kimlik doğrulama: Authorization: Bearer <MISTRAL_API_KEY>
Model ID: mistral-medium-3.5
Bağlam penceresi: 256K token
Fiyatlandırma: milyon giriş tokenı başına 1,5$, milyon çıkış tokenı başına 7,5$
Yetenekler: akıl yürütme, görsel girdi, yerel işlev çağırma, yapılandırılmış JSON çıkışı ve 24 dil desteği
Açık ağırlıklar: Hugging Face üzerinde mistralai/Mistral-Medium-3.5-128B
SWE-Bench Verified: %77,6
τ³-Telekom: 91,4
Pratik test akışı: Apidog'u indirin, API anahtarını gizli değişkende saklayın, mevcut modelinizle A/B test edin ve çağrı başına token maliyetini izleyin.

Medium 3.5'te Neler Değişti?

Medium 3, daha önce 128K bağlam penceresine sahip metin odaklı bir model olarak konumlanıyordu. Medium 3.5 ise Mistral'ın amiral gemisi birleştirilmiş modeli olarak gelir: talimat takip etme, akıl yürütme ve kodlama tek ağırlık setinde birleşir. Bu nedenle sohbet modeli ile akıl yürütme modeli arasında seçim yapmak yerine aynı model üzerinden ilerleyebilirsiniz.

Öne çıkan üç sayı:

SWE-Bench Verified: %77,6 — kod yamalama ve yazılım mühendisliği görevleri için güçlü bir gösterge.
τ³-Telekom: 91,4 — çok turlu ajan diyaloglarında güçlü performans.
256K bağlam — orta büyüklükte bir kod tabanını, uzun belgeleri veya saatlerce transkripti tek çağrıda işlemek için yeterli alan.

Fiyat tarafında Medium 3.5 daha pahalıdır. Medium 3, milyon giriş tokenı başına 0,40$ ve milyon çıkış tokenı başına 2,00$ seviyesindeydi. Medium 3.5, giriş için 1,5$ ve çıkış için 7,5$ olarak fiyatlanır. Bu yüzden pratik yaklaşım şudur:

Ucuz ve toplu işler için Medium 3 kullanın.
Kod, görsel, uzun bağlam veya ajan mantığı gereken kritik çağrılarda Medium 3.5'e yükseltin.

Önkoşullar

İlk çağrıdan önce şunları hazırlayın:

console.mistral.ai üzerinde ödeme yöntemi tanımlı bir Mistral hesabı.
Üretim için proje kapsamlı bir API anahtarı.
Python veya JavaScript SDK.
İstekleri tekrar çalıştırmak, farklı prompt sürümlerini karşılaştırmak ve anahtarı gizli tutmak için Apidog gibi bir API istemcisi.

API anahtarını terminalde ortam değişkeni olarak tanımlayın:

export MISTRAL_API_KEY="..."

Uç Nokta ve Kimlik Doğrulama

Medium 3.5 için sohbet tamamlama uç noktası:

POST https://api.mistral.ai/v1/chat/completions

Minimum curl isteği:

curl https://api.mistral.ai/v1/chat/completions \
  -H "Authorization: Bearer $MISTRAL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mistral-medium-3.5",
    "messages": [
      {
        "role": "user",
        "content": "Explain dense merged checkpoints in two sentences."
      }
    ]
  }'

Başarılı yanıt şunları içerir:

choices
usage.prompt_tokens
usage.completion_tokens
usage.total_tokens
izleme için kullanılabilecek id

Hatalar ise genellikle error.code ve error.message alanlarını içeren OpenAI benzeri bir zarfla döner.

İstek Parametreleri

Parametre	Tip	Değerler	Not
`model`	string	`mistral-medium-3.5`	Zorunlu
`messages`	array	rol/içerik çiftleri	Zorunlu
`temperature`	float	`0` - `1.5`	Genel kullanım için `0.7`, kod için `0.3` önerilir
`top_p`	float	`0` - `1`	Varsayılan `1.0`
`max_tokens`	int	`1` - bağlam limiti	Çıkış uzunluğunu sınırlar
`stream`	bool	`true` / `false`	SSE akışını açar
`tools`	array	OpenAI araç şeması	Yerel işlev çağırma
`tool_choice`	string/object	`auto`, `any`, `none` veya belirli araç	Araç kullanımını kontrol eder
`response_format`	object	`{"type":"json_object"}` veya JSON şeması	Yapılandırılmış çıktı
`random_seed`	int	herhangi bir int	Tekrarlanabilirlik için
`safe_prompt`	bool	`true` / `false`	Mistral güvenlik istemini ekler
`presence_penalty`	float	`-2` - `2`	Tekrarlanan konuları cezalandırır
`frequency_penalty`	float	`-2` - `2`	Tekrarlanan tokenleri cezalandırır

OpenAI'dan geçerken iki fark önemlidir:

OpenAI:  tool_choice="required"
Mistral: tool_choice="any"

OpenAI:  seed
Mistral: random_seed

Python ile Medium 3.5 Kullanımı

Resmi Mistral SDK'sı:

import os
from mistralai import Mistral

client = Mistral(api_key=os.environ["MISTRAL_API_KEY"])

response = client.chat.complete(
    model="mistral-medium-3.5",
    messages=[
        {"role": "system", "content": "Reply in code only."},
        {"role": "user", "content": "Write a Rust function that debounces events."},
    ],
    temperature=0.3,
    max_tokens=2048,
)

print("Content:", response.choices[0].message.content)
print("Total tokens:", response.usage.total_tokens)

cost = (
    response.usage.prompt_tokens * 1.5 / 1_000_000 +
    response.usage.completion_tokens * 7.5 / 1_000_000
)

print("Cost estimate USD:", cost)

OpenAI SDK ile uyumlu kullanım:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MISTRAL_API_KEY"],
    base_url="https://api.mistral.ai/v1",
)

response = client.chat.completions.create(
    model="mistral-medium-3.5",
    messages=[
        {"role": "user", "content": "Hello, Mistral."}
    ],
)

print(response.choices[0].message.content)

Eğer sağlayıcıdan bağımsız bir kod tabanınız varsa OpenAI SDK yolu daha hızlıdır. Mistral'a özgü özellikleri daha net kullanmak istiyorsanız resmi mistralai SDK'sını tercih edin.

Node.js ile Medium 3.5 Kullanımı

Resmi Mistral SDK'sı:

import { Mistral } from "@mistralai/mistralai";

const client = new Mistral({
  apiKey: process.env.MISTRAL_API_KEY,
});

const response = await client.chat.complete({
  model: "mistral-medium-3.5",
  messages: [
    {
      role: "user",
      content: "Explain dense merged checkpoints in plain English.",
    },
  ],
  temperature: 0.7,
});

console.log(response.choices[0].message.content);
console.log("Usage:", response.usage);

OpenAI SDK ile:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.MISTRAL_API_KEY,
  baseURL: "https://api.mistral.ai/v1",
});

const response = await client.chat.completions.create({
  model: "mistral-medium-3.5",
  messages: [
    {
      role: "user",
      content: "Hello, Mistral.",
    },
  ],
});

console.log(response.choices[0].message.content);

Akış Yanıtları

Akış için stream: true kullanın. SSE parçaları OpenAI formatına yakındır.

stream = client.chat.stream(
    model="mistral-medium-3.5",
    messages=[
        {
            "role": "user",
            "content": "Stream a 300-word essay on merged checkpoints.",
        }
    ],
)

for chunk in stream:
    delta = chunk.data.choices[0].delta.content or ""
    print(delta, end="", flush=True)

Terminal yerine karşılaştırmalı test yapıyorsanız Apidog yanıt görüntüleyicisiyle aynı istemi farklı modellerde yan yana çalıştırabilirsiniz.

Araç Çağırma

Medium 3.5 yerel işlev çağırmayı destekler. Önce çağrılabilir araçları tools içinde tanımlayın:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Return the current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string"},
                    "unit": {"type": "string", "enum": ["c", "f"]},
                },
                "required": ["city"],
            },
        },
    }
]

response = client.chat.complete(
    model="mistral-medium-3.5",
    messages=[
        {
            "role": "user",
            "content": "Weather in Lagos in Celsius?",
        }
    ],
    tools=tools,
    tool_choice="auto",
)

tool_call = response.choices[0].message.tool_calls[0]

print(tool_call.function.name)
print(tool_call.function.arguments)

Tipik araç döngüsü:

Model araç çağrısı üretir.
Uygulama ilgili fonksiyonu yerel olarak çalıştırır.
Sonuç role: "tool" mesajı olarak tekrar modele gönderilir.
Model nihai cevabı üretir veya yeni bir araç çağrısı ister.

Bu akış OpenAI araç kullanım döngüsüyle aynıdır.

JSON Modu ve Yapılandırılmış Çıktı

Şema doğrulamalı çıktı için response_format içinde JSON şeması gönderin:

schema = {
    "type": "json_schema",
    "json_schema": {
        "name": "release_note",
        "schema": {
            "type": "object",
            "properties": {
                "title": {"type": "string"},
                "date": {"type": "string"},
                "bullets": {
                    "type": "array",
                    "items": {"type": "string"},
                },
            },
            "required": ["title", "date", "bullets"],
            "additionalProperties": False,
        },
        "strict": True,
    },
}

response = client.chat.complete(
    model="mistral-medium-3.5",
    messages=[
        {
            "role": "system",
            "content": "Reply with a single JSON object matching the schema.",
        },
        {
            "role": "user",
            "content": "Summarize today's Mistral Medium 3.5 release.",
        },
    ],
    response_format=schema,
)

print(response.choices[0].message.content)

Daha gevşek JSON çıktısı için:

response_format = {"type": "json_object"}

Bu durumda istemci tarafında Pydantic, Zod veya benzer bir doğrulama katmanı eklemek iyi olur.

Görsel Girdi

Medium 3.5, metinle birlikte görsel içerik alabilir. Görseli messages[].content içinde image_url olarak geçin:

response = client.chat.complete(
    model="mistral-medium-3.5",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "What is in this image and what is it doing wrong?",
                },
                {
                    "type": "image_url",
                    "image_url": "https://example.com/diagram.png",
                },
            ],
        }
    ],
)

print(response.choices[0].message.content)

Görseller giriş tokenı olarak ücretlendirilir. Tam token sayısı çözünürlüğe göre değişir ve usage.prompt_tokens alanında raporlanır. Yüksek hacimli görsel iş yüklerinde:

ilgili bölgeyi kırpın,
gereksiz çözünürlüğü azaltın,
her çağrıda usage değerini kaydedin.

Apidog'da Medium 3.5 Koleksiyonu Oluşturma

Terminalden aynı isteği tekrar çalıştırmak hem kredi tüketir hem de varyantlar arasındaki farkı takip etmeyi zorlaştırır. Daha sürdürülebilir akış:

Apidog'u indirin ve yeni bir proje oluşturun.
Bir ortam ekleyin.
MISTRAL_API_KEY değerini gizli değişken olarak kaydedin.
BASE_URL değerini şu şekilde tanımlayın:

https://api.mistral.ai/v1

Yeni bir POST isteği oluşturun:

{{BASE_URL}}/chat/completions

Header ekleyin:

Authorization: Bearer {{MISTRAL_API_KEY}}
Content-Type: application/json

Gövdeyi ekleyin:

{
  "model": "mistral-medium-3.5",
  "messages": [
    {
      "role": "user",
      "content": "Explain dense merged checkpoints in two sentences."
    }
  ],
  "temperature": 0.7,
  "max_tokens": 1024
}

Farklı model, sıcaklık ve araç ayarlarını test etmek için isteği çoğaltmak yerine değişkenleri kullanın.
Yanıt sonrası küçük bir maliyet betiği ekleyin:

const usage = response.json().usage;

const cost =
  usage.prompt_tokens * 1.5 / 1_000_000 +
  usage.completion_tokens * 7.5 / 1_000_000;

console.log(`Estimated cost: $${cost}`);

Zaten DeepSeek V4 API koleksiyonu kullanıyorsanız, koleksiyonu kopyalayıp temel URL'yi https://api.mistral.ai/v1, model kimliğini de mistral-medium-3.5 yapmanız yeterlidir. Aynı yaklaşım GPT-5.5 ile karşılaştırma için de geçerlidir.

Hata Yönetimi

İlk karşılaşacağınız durum kodları:

Kod	Anlamı	Düzeltme
`400`	Hatalı istek	`messages`, `tools` ve JSON şemasını doğrulayın
`401`	Geçersiz anahtar	console.mistral.ai üzerinden anahtarı yenileyin
`402`	Ödeme gerekli	Hesaba bakiye veya kart ekleyin
`403`	Model izni yok	Proje kapsamını ve model ID yazımını kontrol edin
`422`	Parametre aralık dışında	`max_tokens`, `tool_choice` veya şema alanlarını kontrol edin
`429`	Oran limiti	Üstel geri çekilme ile tekrar deneyin
`500`	Sunucu hatası	Kısa süre sonra tekrar deneyin
`503`	Aşırı yük	Bekleyin veya geçici olarak Medium 3'e dönün

Python için basit yeniden deneme deseni:

import time
import random

def with_retry(fn, retries=4):
    for attempt in range(retries):
        try:
            return fn()
        except Exception as exc:
            status = getattr(exc, "status_code", None)

            if status not in [429, 500, 502, 503, 504]:
                raise

            sleep = (2 ** attempt) + random.random()
            time.sleep(sleep)

    raise RuntimeError("Retry limit exceeded")

4xx hatalarını otomatik yeniden denemeyin. Bunlar genellikle geçici değil, istek veya yetki hatasıdır.

Maliyet Kontrolü Desenleri

Medium 3.5 güçlüdür, ancak çıktı tokenı pahalıdır. Üretimde şu desenleri uygulayın:

1. Varsayılanı ucuz model yapın

Önce Medium 3 veya daha ucuz bir modelle ilk geçiş yapın. Sadece doğrulama başarısız olursa veya düşük güven skoru dönerse Medium 3.5'e yükseltin.

2. `max_tokens` değerini sınırlandırın

{
  "max_tokens": 1200
}

256K bağlam girdi içindir. Uzun çıktı her çağrıda maliyeti hızlı artırır.

3. Sistem istemini kısaltın

Her sistem istemi tokenı her çağrıda tekrar faturalandırılır. 2.000 tokenlık sistem istemini 500 tokene indirmek, yüksek hacimde ciddi tasarruf sağlar.

4. Her çağrıda `usage` kaydedin

Kaydetmeniz gereken minimum alanlar:

{
  "prompt_tokens": 1234,
  "completion_tokens": 456,
  "total_tokens": 1690,
  "estimated_cost_usd": 0.005271
}

5. Görsel girdiyi seçici kullanın

Görseli modele göndermeden önce:

kırpın,
sıkıştırın,
gereksiz kareleri atın,
sadece yanıt için gerekli bölgeyi gönderin.

Medium 3.5'i Diğer Mistral Seviyeleriyle Karşılaştırma

Nisan 2026 sonu itibarıyla tablo:

Model	Bağlam	Giriş $/M	Çıkış $/M	Görsel	En iyi olduğu alan
`mistral-small`	32K	0,10$	0,30$	Hayır	Yüksek hacimli sınıflandırma, hafif sohbet
`mistral-medium-3`	128K	0,40$	2,00$	Hayır	Toplu iş, uzun sohbet
`mistral-medium-3.5`	256K	1,5$	7,5$	Evet	Akıl yürütme, kod, görsel, ajanlar
`mistral-large`	128K	2,00$	6,00$	Sınırlı	Sınır katmanı metin akıl yürütme

Medium 3.5; uzun bağlam, görsel girdi ve birleşik akıl yürütmeyi aynı seviyede toplar. Ancak seçim model adına göre değil, iş yüküne göre yapılmalıdır.

Başka Bir Sağlayıcıdan Geçiş

Çoğu durumda geçiş temel URL ve model ID değişikliğidir.

OpenAI'dan:

- base_url="https://api.openai.com/v1"
- model="gpt-5.5"
+ base_url="https://api.mistral.ai/v1"
+ model="mistral-medium-3.5"

DeepSeek'ten:

- base_url="https://api.deepseek.com/v1"
- model="deepseek-v4-pro"
+ base_url="https://api.mistral.ai/v1"
+ model="mistral-medium-3.5"

Dikkat edilecek iki fark:

- tool_choice="required"
+ tool_choice="any"

- seed=123
+ random_seed=123

Üretim trafiğini değiştirmeden önce:

Mevcut test suitinizi Mistral üzerinde çalıştırın.
Bir süre gölge trafik gönderin.
Yanıtları ve usage değerlerini kaydedin.
Apidog'da model farklarını yan yana karşılaştırın.

Gerçek Dünya Kullanım Senaryoları

Medium 3.5 için pratik kullanım alanları:

Kod inceleme asistanları: 256K bağlam sayesinde PR diff'i ve ilgili dosyaları aynı çağrıda değerlendirebilir.
Uzun belge Soru-Cevap: Sözleşme, RFP veya politika belgelerini parçalara bölmeden işleyebilir.
Çok modlu veri çıkarımı: Fiş, ekran görüntüsü veya diyagramlardan yapılandırılmış alan çıkarabilir.
Araç çağrılı ajan döngüleri: Yerel işlev çağırma sayesinde API, veri tabanı veya iç servislerle çok turlu iş akışları kurulabilir.

Sıkça Sorulan Sorular

API'deki Mistral Medium 3.5 model kimliği nedir?

Barındırılan API için:

mistral-medium-3.5

Hugging Face kontrol noktası:

mistralai/Mistral-Medium-3.5-128B

Medium 3.5 OpenAI ile uyumlu mu?

Büyük ölçüde evet. Uç nokta yapısı, header'lar ve çoğu parametre benzerdir. OpenAI Python ve Node SDK'ları base_url / baseURL değişikliğiyle kullanılabilir.

Farklılıklar:

tool_choice="required" yerine tool_choice="any"
seed yerine random_seed

Medium 3.5'i yerel olarak çalıştırabilir miyim?

Evet. Ağırlıklar, büyük gelir istisnası içeren Değiştirilmiş MIT Lisansı altında açıktır. 128B parametre sayısı ciddi GPU belleği gerektirir. Nicelenmiş GGUF derlemeleri için unsloth/Mistral-Medium-3.5-128B-GGUF kullanılabilir. Yerel çalıştırma desenleri için DeepSeek V4'ü yerel olarak nasıl çalıştıracağınız rehberindeki yaklaşım uygulanabilir.

Araç çağrılarıyla akışı destekliyor mu?

Evet. Akış sırasında araç çağrısı argüman parçaları delta.tool_calls üzerinden artımlı döner. Akış tamamlandığında parçalar tam JSON nesnesine birleştirilir.

Göndermeden önce giriş tokenlarını nasıl sayabilirim?

Tam sayım için mistral-common Python paketinin tokenlaştırıcısını kullanabilirsiniz. API'nin kullandığı tokenlaştırıcıyla eşleştiği için sonuçlar usage.prompt_tokens ile tutarlı olur.

Üretimde hangi bağlam uzunluğunu planlamalıyım?

256K üst sınırdır, varsayılan hedef değildir. 200K tokenlık bir çağrı, model çıktı üretmeden önce yalnızca giriş için yaklaşık 0,30$ maliyet oluşturur. Çoğu üretim iş yükü 32K altında tutulmalıdır; uzun bağlamı yalnızca gerçekten gerekiyorsa kullanın.

Ücretsiz katman var mı?

Mistral kalıcı bir ücretsiz katman duyurmaz; yeni hesaplar zaman zaman küçük deneme kredileriyle gelebilir. Benzer seviyedeki ücretsiz deneme seçenekleri için DeepSeek V4 API'sini ücretsiz olarak nasıl kullanacağınızı inceleyebilirsiniz.

Tasarım Odaklı API İş Akışı için API Platformu

Tobias Hoffmann — Thu, 30 Apr 2026 03:35:52 +0000

TL;DR

Tasarım öncelikli yaklaşımda API spesifikasyonu uygulama kodundan önce yazılır ve sonraki her şeyi yönlendirir: sahte API'ler (mocks), dokümantasyon, testler ve istemci taslakları. Bu iş akışını baştan sona destekleyen bir platform seçmek, kod ve dokümanları senkronize tutma yükünü azaltır. Bu makale, tasarım öncelikli yaklaşımı pratik bir iş akışı olarak açıklar ve Apidog'u eksiksiz bir tasarım öncelikli platform örneği olarak değerlendirir.

Apidog'u bugün deneyin

Apidog

Apidog'u ücretsiz deneyin

Giriş

Çoğu geliştirici API'leri önce kod yazarak geliştirmeyi öğrenir. Bir rota yazarsınız, bazı açıklamalar eklersiniz, bir jeneratör çalıştırırsınız ve dokümantasyon elde edersiniz. Bu yaklaşım bir noktaya kadar çalışır.

Sorun genellikle bakım aşamasında başlar:

Dokümantasyon gerçek davranıştan sapar.
Açıklamalar güncelliğini yitirir.
Yeni bir mühendis yanıt formatını değiştirir ancak dekoratörü güncellemeyi unutur.
Altı ay sonra dokümantasyon API'nin bir dizi string döndürdüğünü söylerken, gerçek yanıt value alanı olan nesnelerden oluşur.

Tasarım öncelikli yaklaşım bu akışı tersine çevirir. Spesifikasyon doğruluk kaynağıdır. Kod, dokümantasyon, mock sunucusu ve testler bu sözleşmeden türetilir.

Bu sadece süreç tercihi değildir. Tasarım öncelikli çalışan ekipler genellikle şu avantajları elde eder:

Daha az entegrasyon sürprizi
İlk günden kullanılabilir mock API ile daha hızlı ön uç geliştirme
İkincil bir çıktı olmadığı için daha doğru dokümantasyon
Daha net API sözleşmeleri

Ancak bu yaklaşımın çalışması için spesifikasyon yazmak pratik olmalıdır. Bir uç nokta tanımlamak 20 dakika, rota işleyicisini yazmak 5 dakika sürüyorsa ekip spesifikasyonu atlar. Araç, tasarım öncelikli yaklaşımı kod öncelikli yaklaşımdan daha yavaş değil, daha akıcı hale getirmelidir.

Uygulamada tasarım öncelikli yaklaşım ne anlama geliyor?

Tasarım öncelikli yaklaşım bir teknoloji değil, bir API geliştirme iş akışıdır.

1. Kod yazmadan önce sözleşmeyi tanımlayın

API tasarımı önce OpenAPI spesifikasyonu olarak tanımlanır. Minimum olarak şunları içermelidir:

Uç nokta yolları ve HTTP metotları
Path, query ve header parametreleri
POST, PUT, PATCH için request body şemaları
200, 400, 401, 422, 500 gibi yanıt şemaları
Kimlik doğrulama gereksinimleri
Alan açıklamaları ve örnekler

Örnek basit bir OpenAPI parçası:

paths:
  /users/{id}:
    get:
      summary: Kullanıcı profilini getir
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: "Başarılı yanıt"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/UserProfile"
        "404":
          description: "Kullanıcı bulunamadı"

Bu aşamada en önemli kararlar verilir:

İsimlendirme
Veri yapıları
Hata formatları
Sayfalama modeli
Kimlik doğrulama davranışı

2. Geliştirme sırasında mock API kullanın

Spesifikasyon mock sunucusuna yayınlanır. Böylece:

Ön uç mühendisleri gerçek backend hazır olmadan geliştirme yapabilir.
Backend mühendisleri spesifikasyonu gereksinim belgesi olarak kullanır.
Ekipler birbirini beklemeden paralel ilerler.

Ön uç tarafında örnek kullanım:

const response = await fetch("https://mock.example.com/users/123");
const user = await response.json();

console.log(user.email);

Backend henüz yazılmamış olsa bile UI geliştirme, validasyon ve entegrasyon hazırlığı başlayabilir.

3. Uygulamadan sonra sözleşme testi çalıştırın

Gerçek API tamamlandığında testler uygulamanın spesifikasyonla eşleştiğini doğrulamalıdır.

Örnek kontrol mantığı:

GET /users/{id}
Beklenen response schema: UserProfile
Gerçek response schema ile karşılaştır
Sapma varsa testi başarısız yap

Bu, dokümantasyon ve gerçek API arasındaki farkları erken yakalar.

4. Gereksinim değiştiğinde önce spesifikasyonu güncelleyin

Bir alan ekleniyorsa, kaldırılıyorsa veya yanıt formatı değişiyorsa önce OpenAPI sözleşmesi güncellenmelidir.

Doğru akış:

Spesifikasyonu güncelleyin.
Ön uç ve backend ekipleri değişikliği incelesin.
Mock API güncellensin.
Uygulama değiştirilsin.
Testler yeni sözleşmeye göre çalışsın.

Tasarım öncelikli bir platformda olması gerekenler

Her API aracı tasarım öncelikli iş akışını iyi desteklemez. Aşağıdaki özellikler kritik önemdedir.

Görsel API düzenleyici

Ham YAML ile çalışmak her zaman verimli değildir. Görsel bir düzenleyici:

Path, method, parametre ve response tanımlarını form üzerinden oluşturmalıdır.
Geçerli OpenAPI üretmelidir.
Şema bileşenlerini yeniden kullanmayı desteklemelidir.
Hataları düzenleme sırasında göstermelidir.

OpenAPI doğrulaması

Spesifikasyon mock, dokümantasyon veya kod üretimi için kullanılmadan önce geçerli OpenAPI olmalıdır.

İyi bir araç şu hataları erken yakalamalıdır:

Eksik response açıklaması
Geçersiz schema tipi
Yanlış $ref
Eksik required alanları
Hatalı security tanımı

Spesifikasyondan otomatik mock API oluşturma

İdeal akış şu kadar kısa olmalıdır:

OpenAPI endpoint tanımla
→ Kaydet
→ Mock URL hazır

Mock sunucusu şemadaki alan türlerini ve kısıtlamaları dikkate almalıdır:

format: email
minimum / maximum
enum
nested object
array
$ref bileşenleri

Dokümantasyon önizlemesi

Spesifikasyon sadece makine tarafından okunabilir olmamalıdır. Ekip içi inceleme için okunabilir dokümantasyona dönüşmelidir.

Dokümantasyon önizlemesi şunları göstermelidir:

Endpoint açıklaması
Request parametreleri
Request body
Response schema
Örnek response
Hata durumları

Ekip inceleme iş akışı

API sözleşmesi kod kadar önemlidir. Bu nedenle değişiklikler de kod değişiklikleri gibi incelenmelidir.

Gerekli özellikler:

Yorum ekleme
Değişiklik geçmişi
Kim, neyi, ne zaman değiştirdi bilgisinin tutulması
Endpoint veya alan bazında tartışma

Standart OpenAPI dışa aktarımı

Spesifikasyon taşınabilir olmalıdır. Platformdan standart OpenAPI olarak dışa aktarılıp şu araçlarla kullanılabilmelidir:

Kod jeneratörleri
API gateway'ler
Test framework'leri
Dokümantasyon araçları
CI doğrulama adımları

Tasarım öncelikli bir platform olarak Apidog

Apidog'un mimarisi spesifikasyonu birincil çıktı olarak ele alır. Tasarım sekmesi, mock sunucusu, test çalıştırıcısı ve dokümantasyon aynı API tanımına bağlıdır.

Görsel OpenAPI düzenleyici

Apidog'un tasarım arayüzü form tabanlıdır. Her endpoint yapılandırılmış bir şekilde tanımlanır:

Path
HTTP method
Parametreler
Request body
Response'lar
Schema alanları
Açıklamalar
Validasyon kuralları
Mock açıklamaları

YAML yazmak zorunda değilsiniz. Ancak isterseniz ham YAML veya JSON görünümünü açıp doğrudan düzenleyebilirsiniz. Görsel görünümdeki değişiklikler ham görünüme, ham görünümdeki değişiklikler de görsel görünüme senkronize olur.

Şema bileşenlerini tekrar kullanın

Ortak modelleri bileşen olarak tanımlayın.

Örnek:

components:
  schemas:
    UserProfile:
      type: object
      required:
        - id
        - email
      properties:
        id:
          type: string
          example: usr_123
        email:
          type: string
          format: email
          example: user@example.com
        displayName:
          type: string
          example: Ayşe Yılmaz

Daha sonra herhangi bir endpoint içinde bu şemaya referans verebilirsiniz:

schema:
  $ref: "#/components/schemas/UserProfile"

Bu yaklaşım tutarlılığı artırır. UserProfile değiştiğinde onu kullanan endpoint'ler aynı sözleşmeyi takip eder.

Gerçek zamanlı dokümantasyon önizlemesi

Bir endpoint tasarlarken dokümantasyon görünümü gerçek zamanlı olarak güncellenir. Böylece tasarım arayüzünden çıkmadan yayınlanacak dokümantasyonun nasıl görüneceğini kontrol edebilirsiniz.

Bu özellikle inceleme aşamasında faydalıdır:

Endpoint'i tanımlayın.
Dokümantasyon önizlemesini açın.
Alan açıklamalarını kontrol edin.
Ürün yöneticisi veya ön uç lideriyle bağlantıyı paylaşın.
Geri bildirimi spesifikasyon üzerinde uygulayın.

Eğer bir alan açıklaması dokümantasyonda belirsiz görünüyorsa, uygulama sırasında da belirsizlik yaratacaktır.

Akıllı Mock: spesifikasyondan çalışan mock API'ye

Apidog'da yeni bir endpoint kaydedildiğinde mock sunucusu hemen kullanılabilir hale gelir. Mock URL arayüzde görünür.

Mock yanıtları şemalara göre oluşturulur:

format: email olan string alanları geçerli e-posta adresleri döndürür.
minimum ve maximum değerleri olan integer alanları belirtilen aralıkta değerler döndürür.
Enum alanları tanımlı değerlerden birini döndürür.
İç içe nesneler ve diziler schema yapısını takip eder.
$ref bileşenleri çözülür ve mock response içinde kullanılır.

Belirli senaryolar için özel mock kuralları da tanımlayabilirsiniz:

Path parametresi 0 olduğunda 404 döndür.
Belirli bir query parametresi için özel payload döndür.
Hata yanıtlarını ön uç validasyonu için test et.

Örnek senaryo:

GET /users/0 → 404 Not Found
GET /users/123 → 200 UserProfile

Bu, UI tarafında başarı ve hata durumlarını backend beklemeden test etmeyi sağlar.

Ekip incelemesi ve değişiklik takibi

Apidog'daki API spesifikasyon değişiklikleri çalışma alanı üyeleri tarafından görülebilir. Belirli endpoint'lere veya alanlara yorum eklenebilir. Değişiklik geçmişi kimin neyi ne zaman değiştirdiğini takip eder.

Tasarım öncelikli iş akışında bu önemlidir çünkü API sözleşmesi artık ayrı bir dosya değil, ekip tarafından incelenen ve sürdürülen merkezi bir kaynaktır.

Tasarım öncelikli vs. kod öncelikli: gerçek ödünleşimler

Tasarım öncelikli yaklaşım her durumda otomatik olarak en iyi seçenek değildir. Karar verirken aşağıdaki farkları dikkate alın.

Tasarım öncelikli avantajları

Ön uç ve backend paralel çalışabilir.
Dokümantasyon türev değil, kaynak olduğu için daha doğru kalır.
Entegrasyon sorunları geç aşamada değil, tasarım incelemesinde ortaya çıkar.
API sözleşmeleri açık ve doğrulanabilir olur.
API değişiklikleri varsayılan olarak inceleme sürecinden geçer.

Tasarım öncelikli dezavantajları

Kod yazmadan önce spesifikasyon için zaman ayırmak gerekir.
Spesifikasyon araçlarının öğrenme eğrisi vardır.
Uygulama ve spesifikasyonu senkronize tutmak disiplin ister.
Alan tam anlaşılmadan aşırı detaylı spesifikasyon yazmak kararları erken kilitleyebilir.

Kod öncelikli avantajları

Küçük ve deneysel projelerde başlangıç daha hızlı olabilir.
Tek geliştiricili hızlı prototiplerde daha az süreç gerektirir.
Ek bir spesifikasyon aracı öğrenmek gerekmez.

Kod öncelikli dezavantajları

Dokümantasyon ikincil çıktıdır ve sapmaya açıktır.
Ön uç genellikle backend'in hazır olmasını bekler.
Sözleşme örtüktür; kırılma değişikliklerini yakalamak zordur.
API refactor işlemleri manuel dokümantasyon güncellemeleri gerektirir.

Bir API üzerinde birden fazla mühendis çalışıyorsa tasarım öncelikli yaklaşım genellikle daha iyi sonuç verir. En fazla fayda, ön uç ve backend koordinasyonu yüksek olan özelliklerde görülür.

Tasarım öncelikli iş akışlarını destekleyen araçlar

Apidog

Eksiksiz tasarım öncelikli platform: görsel düzenleyici, anında mock API oluşturma, dokümantasyon, test ve ekip incelemesi tek araçta bulunur. Ücretsiz katman tüm özellik setini kapsar. Güçlü mock oluşturma yeteneği pratik iş akışlarında belirgin fark yaratır.

Stoplight Studio

Spectral linting ile güçlü bir OpenAPI düzenleyicidir. Stil kuralları ve API yönetişimi için uygundur. Dahili mock sunucusu veya test çalıştırıcısı yoktur. Yönetişim araçlarına ihtiyaç duyan kuruluşlar için daha uygundur.

SwaggerHub

Olgun bir OpenAPI düzenleme ve işbirliği platformudur. Kurumsal alanda yaygın kullanılır. Mock yetenekleri sınırlıdır ve test odaklı değildir. Swagger ekosisteminde olan spesifikasyon ağırlıklı ekipler için uygundur.

Postman API Builder

Postman'ın OpenAPI spesifikasyonları oluşturabilen API tasarım özellikleri vardır. Ancak tasarım ve koleksiyon iş akışları ayrı hissedebilir. Mock sunucusu genellikle spesifikasyondan otomatik türetmek yerine koleksiyonlar üzerinden yapılandırılır. Kod öncelikli başlayıp dokümantasyon eklemek isteyen ekipler için çalışabilir.

Insomnia Belge Modu

Insomnia, OpenAPI spesifikasyon düzenlemeyi destekler ve temel mock özellikleri sunar. Özel tasarım öncelikli platformlara göre daha hafiftir. Tek geliştiriciler veya küçük projeler için uygun olabilir.

Apidog'da tasarım öncelikli bir iş akışı kurma

Adım 1: Koleksiyonla değil, spesifikasyonla başlayın

Yeni bir proje oluşturun ve tasarım sekmesini açın. İlk iş olarak istek göndericiye geçmeyin.

Önce en azından şunları tanımlayın:

Endpoint path
HTTP method
Başarılı response schema
Temel hata response'ları

Örnek başlangıç checklist'i:

[ ] GET /users/{id}
[ ] Path param: id
[ ] 200 response: UserProfile
[ ] 404 response: ErrorResponse
[ ] Auth gereksinimi

Adım 2: Önce paylaşılan bileşenleri oluşturun

Endpoint eklemeden önce ortak şemaları tanımlayın:

Hata yanıtı
Sayfalama sarmalayıcısı
Ortak entity alanları
Kimlik doğrulama hataları

Örnek hata formatı:

components:
  schemas:
    ErrorResponse:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: string
          example: USER_NOT_FOUND
        message:
          type: string
          example: Kullanıcı bulunamadı

Bu, her endpoint'in farklı hata formatı üretmesini önler.

Adım 3: Mock URL'yi erken paylaşın

Endpoint kaydedilir kaydedilmez mock URL'yi kopyalayın ve ön uç geliştiriciyle paylaşın.

Ön uç ekibi şu işleri hemen yapabilir:

UI entegrasyonu
Loading state
Empty state
Error state
Form validasyonu
Response mapping

Backend henüz tamamlanmamış olsa bile geliştirme başlayabilir.

Adım 4: Kod yazmadan önce dokümantasyonu inceleyin

Oluşturulan dokümantasyon önizlemesini kontrol edin.

Şu soruları sorun:

Alan adları açık mı?
Hata durumları yeterince tanımlı mı?
Response örneği gerçekçi mi?
Ön uç geliştirici bu dokümana bakarak entegrasyon yapabilir mi?
Auth gereksinimi net mi?

Belirsizlik varsa kodda değil, spesifikasyonda düzeltin.

Adım 5: Uygulamaya başlamadan önce sözleşmeyi kilitleyin

Tasarım incelemesi tamamlandığında ve yorumlar çözüldüğünde spesifikasyonu o sprint için kilitli kabul edin.

Uygulama sırasında sözleşme değişikliği gerekiyorsa sessizce kodu değiştirmeyin. Doğru akış:

Spec değişikliği öner
→ Ekip incelemesi
→ Mock güncellemesi
→ Uygulama değişikliği
→ Test doğrulaması

Adım 6: CI'da schema doğrulama testleri çalıştırın

Apidog test paketini her CI çalıştırmasında response schema doğrulaması yapacak şekilde ayarlayın.

Amaç:

Gerçek API, OpenAPI sözleşmesine uyuyor mu?
Beklenen alanlar var mı?
Alan tipleri doğru mu?
Hata response'ları dokümantasyonla eşleşiyor mu?

Bu adım uygulama ve spesifikasyonu senkronize tutan otomatik koruyucu katmandır.

Sıkça Sorulan Sorular

Tasarım öncelikli yaklaşım sadece REST API'ler için mi geçerli?

Hayır. Tasarım öncelikli prensip, sözleşme tanımlayabildiğiniz herhangi bir protokol için geçerlidir:

REST için OpenAPI
GraphQL için schema-first yaklaşım
gRPC için protobuf
Olay tabanlı sistemler için AsyncAPI

Apidog REST ve GraphQL tasarımını destekler. gRPC tarafında proto dosyaları benzer sözleşme öncelikli amacı taşır.

Geliştirmeye başlamadan önce her endpoint'i tanımlamak zorunda mıyız?

Hayır. Tasarım öncelikli yaklaşımı özellik bazında benimseyebilirsiniz.

Örneğin mevcut kod tabanı kod öncelikli olabilir, ancak yeni geliştireceğiniz ödeme özelliği için önce spesifikasyon yazabilirsiniz. Kademeli benimseme pratik ve uygulanabilir bir yaklaşımdır.

Tasarım öncelikli yaklaşım çevik sprintlerle nasıl çalışır?

Sprint başındaki tasarım oturumlarında o sprint'in API sözleşmeleri tanımlanır. Sprint sırasında ön uç ve backend paralel çalışır.

Tipik akış:

Sprint planlama
→ API sözleşmesi
→ Mock paylaşımı
→ Paralel frontend/backend geliştirme
→ Schema doğrulama
→ Entegrasyon

Spesifikasyon incelemesi sprint planlamanın doğal bir parçası olur.

Uygulama orijinal spesifikasyondan sapmak zorunda kalırsa ne olur?

Bu olabilir. Doğru süreç uygulamayı sessizce değiştirmek değildir.

Önce spesifikasyonu güncelleyin, paydaşlardan özellikle ön uç ekibinden onay alın, ardından uygulamayı değiştirin. Böylece spesifikasyon doğruluk kaynağı olarak kalır.

Apidog'un OpenAPI dışa aktarımından sunucu taslakları oluşturabilir miyiz?

Evet. Spesifikasyonu Apidog'dan OpenAPI 3.x olarak dışa aktarabilir ve standart kod üreteçleriyle kullanabilirsiniz. Örneğin openapi-generator, 50'den fazla sunucu dili ve framework'ü destekler.

Örnek komut:

openapi-generator-cli generate \
  -i openapi.yaml \
  -g nodejs-express-server \
  -o ./generated-server

Spesifikasyon sürümlemeyi nasıl ele alıyoruz?

Apidog proje içinde değişiklik geçmişini tutar. Paralel sürdürülen büyük sürüm değişiklikleri için ayrı projeler veya dallar kullanılabilir.

Örnek yaklaşım:

api-v1 → mevcut üretim sözleşmesi
api-v2 → yeni major değişiklikler

Sonuç

Tasarım öncelikli yaklaşım başlangıçta küçük bir disiplin yatırımı ister, ancak entegrasyon maliyetlerini azaltarak güçlü bir geri dönüş sağlar.

Başarılı olmak için kritik nokta aracın bu süreci kolaylaştırmasıdır. Spesifikasyon yazmak zorsa ekipler bunu atlar. Görsel düzenleyici, anında mock API, dokümantasyon önizlemesi, test ve ekip incelemesi aynı akışta olduğunda tasarım öncelikli yaklaşım teorik bir ideal olmaktan çıkar ve günlük geliştirme sürecinin doğal parçası haline gelir.

APIDOG Nisan Güncellemeleri: Yapay Zeka Agent Hata Ayıklayıcı, A2A Hata Ayıklayıcı ve Kolay Postman Geçişi

Tobias Hoffmann — Wed, 29 Apr 2026 09:01:18 +0000

Nisan sürümü, Yapay Zeka Aracısı (AI Agent) geliştirme sürecini daha kolay incelemek ve hata ayıklamak için yayınlandı.

Apidog'u bugün deneyin

Aracı geliştirirken zor olan kısım çoğu zaman nihai cevap değildir. Asıl sorun, cevaba gelene kadar ne olduğunu anlayabilmektir:

Aracı kullanıcının isteğini nasıl yorumladı?
Hangi aracı çağırdı?
Araçtan hangi çıktı döndü?
Sorun prompt tarafında mı, araç parametrelerinde mi, yoksa iş mantığında mı?

Bu sürümde Apidog, bu soruları daha hızlı yanıtlamak için birkaç pratik özellik ekliyor:

Yapay Zeka Aracısı Hata Ayıklayıcısı
A2A Hata Ayıklayıcısı
Postman API üzerinden içe aktarma
Yayınlanmış belgelerde yan panelde çalışan “Yapay Zekaya Sor”
Özel yapay zeka model sağlayıcıları

⭐ Yeni Güncellemeler

🔥 Yapay Zeka Aracısı Hata Ayıklayıcısı: Aracının Tüm Çalışmasını İnceleyin

Apidog bir süredir SSE uç noktaları için görsel hata ayıklamayı destekliyordu. Bu; akış model yanıtları, ilerleme güncellemeleri, gerçek zamanlı bildirimler ve olay odaklı API’ler için kullanışlıydı.

Ancak aracı hata ayıklaması yalnızca akışı izlemekten daha fazlasını gerektirir.

Bir model yanıtı genellikle sadece aracının nerede bittiğini gösterir. Geliştirme sırasında ise asıl ihtiyaç, aracının oraya nasıl geldiğini görebilmektir.

Yeni Yapay Zeka Aracısı Hata Ayıklayıcısı ile Apidog içinde şu adımları tek yerden inceleyebilirsiniz:

Konuşma turları
Model çağrıları
MCP araç çağrıları
Beceri (Skill) yürütmeleri
Araç sonuçları
Nihai çıktı

Bu özellikle aşağıdaki hata ayıklama senaryolarında işe yarar:

Kullanıcı isteği
  ↓
Model çağrısı
  ↓
Araç seçimi
  ↓
MCP aracı / Skill yürütmesi
  ↓
Araç sonucu
  ↓
Nihai cevap

Pratikte şu soruları daha hızlı yanıtlayabilirsiniz:

Prompt modele yeterli bağlam verdi mi?
Aracı doğru aracı seçti mi?
MCP aracı beklenen sonucu döndürdü mü?
Hata model yapılandırmasından mı kaynaklandı?
Araç parametreleri yanlış mıydı?
İş mantığı beklenen çıktıyı üretmedi mi?

Aracı sistemleri büyüdükçe, yalnızca nihai cevabı kontrol etmek yetersiz kalır. Bu hata ayıklayıcı, çalışmanın tamamını adım adım görmenizi sağlar.

🤝 A2A Hata Ayıklayıcısı: Aracılar Arası İletişimi Test Edin

Çoklu aracı sistemleri giderek daha yaygın hale geliyor. Birden fazla aracı birlikte çalıştığında, yalnızca tek bir aracının doğru çalışması yeterli değildir. Aracıların birbirine doğru görevleri aktarıp aktarmadığını, mesajları beklenen formatta gönderip göndermediğini ve sonuçları doğru döndürüp döndürmediğini de test etmeniz gerekir.

Apidog artık Google’ın A2A, yani Agent-to-Agent protokolü için hata ayıklamayı destekliyor.

A2A Hata Ayıklayıcısı ile şunları yapabilirsiniz:

A2A isteklerini doğrudan göndermek
İstek parametrelerini incelemek
Yanıtları kontrol etmek
Aracılar arası etkileşimin sonucunu doğrulamak

Bu, özellikle ham protokol detaylarını elle okumak veya farklı araçlar arasında geçiş yapmak istemeyen ekipler için daha pratik bir test akışı sağlar.

İki hata ayıklayıcının rolü kısaca şöyle ayrılır:

Araç	Ne için kullanılır?
Yapay Zeka Aracısı Hata Ayıklayıcısı	Tek bir aracının görev yürütme sürecini incelemek
A2A Hata Ayıklayıcısı	Bir aracının başka bir aracıyla iletişimini test etmek

Aracı tabanlı sistemler geliştiren ekipler genellikle her iki seviyede de hata ayıklamaya ihtiyaç duyar: önce tek aracının iç akışı, sonra aracılar arası iletişim.

📦 Postman API Aracılığıyla Postman Verilerini İçe Aktarın

Postman’dan geçiş yapan ekipler için içe aktarma süreci artık daha büyük çalışma alanlarına daha uygun hale geliyor.

Apidog zaten yerel Postman dosyalarını içe aktarmayı destekliyordu. Bu sürümle birlikte artık Postman API üzerinden şu verileri de içe aktarabilirsiniz:

Workspaces
Collections
Environments

Bu özellik özellikle yeni projeler oluştururken toplu geçiş yapmak için tasarlandı. Pratikte, tüm bir Postman Workspace’i Apidog’a taşımaya daha yakın bir deneyim sunar.

Postman hesabınızda birden fazla Workspace varsa, Apidog içe aktarımdan sonra bunlara karşılık gelen projeleri oluşturur.

Tipik kullanım akışı şöyle düşünülebilir:

Postman hesabı
  ↓
Postman API
  ↓
Workspace / Collection / Environment seçimi
  ↓
Apidog projeleri

Küçük geçişlerde yerel Postman dosyaları hâlâ kullanılabilir. Ancak daha büyük ekiplerde ve birden fazla Workspace içeren yapılarda API üzerinden içe aktarma daha az manuel işlem gerektirir.

📄 Yayınlanmış Belgelerdeki “Yapay Zekaya Sor” Artık Yan Panelde Açılıyor

Yayınlanmış belgelerdeki “Yapay Zekaya Sor” özelliği artık yan panelde çalışıyor.

Bu değişiklikle okuyucular mevcut belgeyi açık tutarken soru sorabilir. Belge sayfasından ayrılmadan:

API dokümanını okuyabilir
Belirli bir bölüm hakkında soru sorabilir
Cevabı inceleyebilir
Sayfadaki konumunu kaybetmeden okumaya devam edebilir

Bu özellikle uzun API belgelerinde kullanışlıdır. Cevap dokümanın içinde olabilir, ancak hızlıca bulmak zor olabilir. Yan panel, belge okuma ve soru sorma akışını aynı ekranda tutar.

🧠 Özel Yapay Zeka Model Sağlayıcıları

Ekipler artık özel bir Temel URL kullanarak özel yapay zeka model sağlayıcılarını bağlayabilir.

Bu, özellikle aşağıdaki yapılara sahip ekipler için faydalıdır:

Kendi barındırılan model servisi
Dahili model geçidi
Şirket içinde yönetilen özel yapay zeka altyapısı

Böyle bir kurulum kullanıyorsanız, yapay zeka ile ilgili iş akışlarını hata ayıklarken her seferinde farklı araçlara geçmek yerine bu sağlayıcıyı Apidog içinde kullanabilirsiniz.

🐞 Hata Düzeltmeleri ve Küçük İyileştirmeler

Bu sürümde ayrıca aşağıdaki düzeltmeler ve küçük iyileştirmeler yayınlandı:

OpenAPI akıllı birleştirmesinin uç nokta yanıt örneklerini korumadığı bir sorun düzeltildi.
Bir alt daldan korumalı bir ana dala birleştirmenin, seçili olmayan uç noktaları içerebileceği bir sorun düzeltildi.
Dallardan uç nokta sürümleri oluştururken yanlış açılır menü gösterimi düzeltildi.
CLI aracılığıyla testler çalıştırılırken TestData ve TestCase’lerin çalışmadığı bir sorun düzeltildi.
OpenAPI dışa aktarımının alakasız modüllerden yanıt bileşenlerini içerdiği bir sorun düzeltildi.
Yorumlu JSON için Markdown dışa aktarım biçimlendirmesi düzeltildi.
crypto is not defined hatasından kaynaklanan Word dışa aktarım hatası düzeltildi.
Basic Auth etkinleştirilmiş Knife4j’yi içe aktarırken kullanıcı adı ve parola alanlarının gösterilmediği bir sorun düzeltildi.
Etiketler sayı olduğunda oluşan uç nokta filtreleme hatası düzeltildi.
apidog endpoint list --branch komutunun belirtilen dal için veri döndürmediği bir sorun düzeltildi.
Birkaç MCP aracı parametresi, filtreleme ve hata mesajı sorunu düzeltildi.
Oluşturulan kodun typescriptThreePlus yapılandırma seçeneğini içermediği bir sorun düzeltildi.

🌟 Bunun Anlamı

Nisan sürümü, Yapay Zeka Aracısı ürünleri geliştiren ekipler için daha uygulama odaklı bir hata ayıklama ve geçiş akışı sunuyor.

Özetle:

Yapay Zeka Aracısı Hata Ayıklayıcısı, tek bir aracının çalışmasını adım adım incelemenize yardımcı olur.
A2A Hata Ayıklayıcısı, aracılar arasındaki iletişimi test etmeyi kolaylaştırır.
Postman API içe aktarma, daha büyük geçişlerde manuel dosya işlemlerini azaltır.
“Yapay Zekaya Sor” yan paneli, yayınlanmış belgelerde okuma ve soru sorma deneyimini iyileştirir.
Özel model sağlayıcıları, ekiplerin mevcut yapay zeka altyapılarını Apidog içinde kullanmasına olanak tanır.

Bu özellikler, aracı geliştirme süreci demo aşamasından gerçek projelere geçtiğinde ihtiyaç duyulan pratik araçlara odaklanır.

💬 Sohbetimize Katılın

Diğer API mühendisleri ve Apidog ekibiyle bağlantı kurun:

Gerçek zamanlı tartışmalar ve destek için Discord topluluğumuza katılın.
Teknik konuşmalar için Slack topluluğumuza katılın.
En son güncellemeler için X (Twitter)’da bizi takip edin.

Not: Tüm güncellemeler hakkında tam ayrıntılar için Apidog Değişiklik Günlüğü’nü kontrol edin!

Saygılarımızla,

Apidog Ekibi

GitHub Copilot Kullanım Ücretlendirmesi: API Ekipleri Ne Beklemeli?

Tobias Hoffmann — Wed, 29 Apr 2026 07:14:48 +0000

GitHub Copilot'ın faturalandırma modeli geçen yıl iki kez değişti ve bu ay tekrar değişti. Bu ay itibarıyla, pull request'lerdeki Copilot kod incelemesi, depoyu sahibi olan fatura hesabından GitHub Actions dakikalarını tüketmeye başlıyor. Geçen çeyrekte gelen premium istek kotasıyla birlikte API ekipleri artık aynı anda üç ölçüm birimini yönetmek zorunda: Copilot koltukları, premium istekler ve Actions dakikaları.

Apidog'u bugün deneyin

Bu yazıda her ölçüm biriminin neyi ölçtüğünü, yeni kod inceleme faturalandırmasının API depolarını nasıl etkilediğini ve maliyetleri faturaya yansımadan önce nasıl modelleyebileceğinizi adım adım ele alacağız.

Sonunda bunu Apidog içindeki bir iş akışıyla birleştiriyoruz. Böylece API spesifikasyonu, sözleşme testleri ve yapay zeka inceleme adımları üç ayrı faturalandırma paneline dağılmak yerine tek bir akışta yönetilebilir.

Ekibinizin doğrudan tükettiği model API'larının maliyetini de hesaplıyorsanız, GPT-5.5 fiyatlandırması ve DeepSeek V4 fiyatlandırması kılavuzları, aynı konunun belirteç başına maliyet tarafını açıklar.

Özet

Copilot maliyetini artık üç ayrı kalemle düşünün: koltuk lisansı, premium istekler ve Copilot kod incelemesi için Actions dakikaları.
Pull request üzerindeki Copilot kod incelemesi, arka planda GitHub Actions altyapısında çalışır.
API depoları daha fazla tüketir çünkü PR'lar genellikle spesifikasyon, oluşturulmuş istemci, handler ve test değişikliklerini birlikte içerir.
Premium istekler; Workspace, ajan modu, Copilot Spaces ve gelişmiş model seçimi gibi daha pahalı özellikleri sınırlar.
Bir sonraki fatura döneminden önce harcama limiti koyun, depo bazında Actions kullanımını ölçün ve API deposu başına aylık yaklaşık 400-800 Actions dakikası bütçeleyin.

Copilot maliyetini oluşturan üç ölçüm birimi

Copilot eskiden temelde tek bir lisans kalemiydi. Artık maliyeti üç parçada izlemek gerekiyor.

1. Koltuk başına lisans

Bu sabit maliyettir.

Copilot Business: kullanıcı başına aylık 10 dolar
Copilot Enterprise: kullanıcı başına aylık 19 dolar

Bu ücret; sohbet, satır içi tamamlamalar, çok satırlı öneriler, IDE entegrasyonları ve standart model havuzuna erişim için ödenir.

Uygulama adımı:

Aktif Copilot kullanıcılarını listeleyin.
Son 30-60 günde Copilot kullanmayan kullanıcıları işaretleyin.
Üç ayda bir koltuk denetimi yapın.
Pasif kullanıcılardan koltukları geri alın.

Basit hesap:

koltuk_maliyeti = aktif_kullanıcı_sayısı × koltuk_fiyatı

Örnek:

10 Enterprise kullanıcısı × 19 dolar = 190 dolar / ay

2. Premium istekler

Premium istekler, GitHub'ın daha pahalı Copilot özellikleri için kullandığı tüketim birimidir.

Aşağıdaki işlemler premium istek tüketebilir:

Ajan modu
Workspace kullanımı
Copilot Spaces sorguları
Varsayılan model dışında model seçimi
Çok adımlı yapay zeka görevleri

Mevcut oranlar revizyona tabi olmakla birlikte şu şekilde düşünülmelidir:

Özellik	Premium istek cinsinden maliyet
Varsayılan model sohbeti	Ücretli katmanlar için ücretsiz
Satır içi tamamlamalar	Ücretli katmanlar için ücretsiz
Ajan modu, varsayılan model	İstek başına 1
Workspace, varsayılan model	İstek başına 1
Claude Sonnet 4.5 seçimi	1,5x çarpan
GPT-5.5 seçimi	2x çarpan
GPT-5.5 Pro seçimi	6x çarpan
Copilot Spaces sorgusu	Sorgu başına 1

Dahil edilen kota:

Copilot Business: koltuk başına aylık 300 premium istek
Copilot Enterprise: koltuk başına aylık 1.000 premium istek
Aşım: istek başına 0,04 dolar
Aşım, kuruluşta belirlediğiniz harcama limitiyle sınırlanır

API ekiplerinde premium isteği artıran tipik görevler şunlardır:

"OpenAPI istemcisini yeniden oluştur."
"Bu endpoint için sözleşme testi yaz."
"Bu API değişikliğine göre handler ve testleri güncelle."
"Yeni response şemasına göre mock örneklerini düzenle."

Bu görevler tek bir kullanıcı istemi gibi görünse de arka planda birden fazla ajan adımı çalıştırabilir. Bu yüzden tek bir prompt, birkaç premium isteğe dönüşebilir.

3. Copilot kod incelemesi için Actions dakikaları

Bu ay ekipleri en çok şaşırtan değişiklik bu oldu.

Copilot bir pull request üzerinde otomatik kod incelemesi yaptığında, inceleme GitHub Actions altyapısında çalışır. Bu çalışma, kuruluşunuzun normal Actions dakika kotasından düşer.

Bilmeniz gerekenler:

Bu dakikalar ayrı bir Copilot kotası değildir.
GitHub planınızdaki mevcut Actions kotasından tüketilir.
Team planında ayda 3.000 dakika, Enterprise'da Linux runner'lar için 50.000 dakika kotası bulunur.
Özel depolardaki Actions dakikaları bütçeden düşer.
Genel depolardaki Actions kullanımı ücretsizdir.

Tipik bir API PR'ında Copilot kod incelemesi yaklaşık 2-6 Actions dakikası tüketebilir. Büyük fark içeren, çok dosyalı veya geniş bağlamlı incelemelerde bu süre 15 dakikaya kadar çıkabilir.

Basit hesap:

aylık_inceleme_dakikası = aylık_PR_sayısı × PR_başına_ortalama_dakika

Örnek:

50 PR × 4 dakika = 200 Actions dakikası / ay

Tek depo için bu makul görünebilir. Ancak üç aktif API deposunda:

3 depo × 200 dakika = 600 Actions dakikası / ay

Bu sayı, CI testleri çalışmadan önce tüketilen ek dakikadır.

API depoları neden daha fazla tüketir?

API depoları Copilot maliyetini ortalamadan daha hızlı artırır. Bunun üç ana nedeni var.

1. Pull request'ler daha büyüktür

Tipik bir API değişikliği sadece tek dosyayı etkilemez. Genellikle şunları içerir:

openapi.yaml veya benzeri API spesifikasyonu
Oluşturulmuş istemciler
Sunucu handler'ları
Sözleşme testleri
Mock veriler
Dokümantasyon örnekleri

Copilot incelemesi bu dosyaların tamamını okuyabilir. Daha büyük fark, daha uzun inceleme süresi ve daha fazla Actions dakikası anlamına gelir.

2. Oluşturulan kod inceleme maliyetini şişirir

Birçok ekip oluşturulmuş istemcileri commit eder. Bu dosyalar çoğu zaman mekanik çıktılardır, ancak PR farkına dahil olduklarında inceleme tarafından okunabilir.

Bu durumda iki sorun oluşur:

İnceleme süresi artar.
İnceleme değeri düşer çünkü üretilmiş kod genellikle manuel incelenmemelidir.

Pratik çözüm: oluşturulmuş istemcileri Copilot review path filtrelerinden hariç tutun.

3. PR başına birden fazla kontrol çalışır

API ekipleri genellikle aynı PR üzerinde şunları birlikte çalıştırır:

Copilot kod incelemesi
CodeQL
Snyk
Özel güvenlik tarayıcıları
Sözleşme testleri
Entegrasyon testleri

Copilot burada yeni maliyet kalemidir. Diğer kontroller zaten Actions dakikası tüketiyordu. Bu yüzden Copilot incelemesini her PR'da koşulsuz çalıştırmak yerine tetikleyicileri daraltmak gerekir.

Aylık Copilot faturanızı nasıl tahmin edersiniz?

Maliyeti üç adımda modelleyin.

Adım 1: Koltuk maliyetini hesaplayın

business_koltuk_maliyeti = aktif_kullanıcı_sayısı × 10
enterprise_koltuk_maliyeti = aktif_kullanıcı_sayısı × 19

Örnek:

aktif_kullanıcı_sayısı = 10
plan = Enterprise

koltuk_maliyeti = 10 × 19 = 190 dolar / ay

Adım 2: Premium istek aşımını hesaplayın

Geliştirici başına aylık tahmin yapın.

Yaklaşık kullanım profilleri:

Sadece sohbet ve temel kullanım: ayda yaklaşık 150 istek
Yoğun Workspace / ajan modu kullanımı: ayda yaklaşık 600-800 istek

Business için basit aşım hesabı:

premium_aşım = max(0, kullanılan_istekler - koltuk_başına_300) × 0,04

Enterprise için:

premium_aşım = max(0, kullanılan_istekler - koltuk_başına_1000) × 0,04

Kuruluş düzeyinde mutlaka harcama limiti koyun. Varsayılan davranışı sınırsız kabul etmek, aktif olarak izleme yapmayan ekipler için risklidir.

Adım 3: Kod incelemesi için Actions dakikalarını hesaplayın

Orta büyüklükteki API PR'ları için 4 dakikalık ortalama makul bir başlangıç noktasıdır.

inceleme_dakikaları = ay_başına_PR_sayısı × 4

Actions kotası aşılıyorsa:

inceleme_aşımı = max(0, inceleme_dakikaları - kalan_actions_kotası) × 0,008

Örnek senaryo:

10 geliştirici
Copilot Enterprise
Ayda 200 PR
PR başına ortalama 4 dakika Copilot incelemesi

koltuklar = 10 × 19 = 190 dolar
inceleme_dakikaları = 200 × 4 = 800 dakika
premium_aşım = yaklaşık 40 dolar

Yaklaşık sonuç:

Koltuklar: 190 dolar
Premium aşım: 40 dolar
İnceleme dakikaları: Enterprise kotası içinde ise 0 dolar
Toplam: yaklaşık 230 dolar / ay

Business katmanındaki küçük ekipler daha dar Actions kotası nedeniyle aşımı daha hızlı görebilir.

CI hattında hemen uygulayabileceğiniz optimizasyonlar

Aşağıdaki üç değişiklik genellikle en hızlı sonucu verir.

1. Bot PR'larında Copilot incelemesini atlayın

Dependabot veya Renovate PR'larında çoğu zaman yapay zeka kod incelemesine gerek yoktur.

Örnek GitHub Actions koşulu:

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  copilot-review:
    if: github.actor != 'dependabot[bot]' && github.actor != 'renovate[bot]'
    runs-on: ubuntu-latest
    steps:
      - uses: github/copilot-review@v1

Bu tek filtre, paket güncelleme trafiği yüksek depolarda ciddi dakika tasarrufu sağlar.

2. Oluşturulmuş istemcileri inceleme kapsamından çıkarın

Eğer depo her PR'da istemcileri yeniden oluşturuyorsa, Copilot farkı her seferinde okuyabilir.

Daha iyi yaklaşım:

Oluşturulmuş çıktılar için hash hesaplayın.
Hash temel branch ile aynıysa inceleme adımını atlayın.
Oluşturulmuş klasörleri path filtresi dışında bırakın.

Örnek hariç tutulacak klasörler:

generated/**
clients/**
sdk/**
dist/**

3. Copilot incelemesini sadece anlamlı API yollarında çalıştırın

İncelemeyi handler, spesifikasyon ve test dosyalarıyla sınırlayın.

on:
  pull_request:
    paths:
      - 'apis/**/*.yaml'
      - 'cmd/**'
      - 'internal/**'
      - 'tests/**'

Bu yaklaşımda Copilot incelemesi hâlâ kritik API mantığını görür, ancak oluşturulmuş veya alakasız dosyalar için dakika harcamaz.

API ekipleri için önerilen yönetim kontrolleri

Bu kontrolleri kurmak genellikle 20 dakika sürer ve sürpriz faturaları azaltır.

1. Kuruluş düzeyinde harcama limiti belirleyin

Harcama limitini depo bazında değil, kuruluş düzeyinde belirleyin.

Pratik yaklaşım:

beklenen_aylık_aşım × 1,2 = harcama_limiti

Eğer emin değilseniz daha düşük bir limit ile başlayın ve 30 gün sonra artırın.

2. Premium istek uyarılarını görünür hale getirin

GitHub dahil edilen kotanın yüzde 50, 75 ve 90 seviyelerinde uyarı gönderebilir. Bu uyarıları sadece e-postada bırakmayın.

Bağlayabileceğiniz yerler:

Slack
Microsoft Teams
PagerDuty
İç geliştirici portalı
FinOps dashboard'u

3. Copilot incelemesini etiketle tetikleyin

Her PR'da otomatik inceleme yerine etiket tabanlı model kullanın.

Örnek politika:

Sadece review-please etiketi olan PR'larda Copilot incelemesi çalışır.

Bunun avantajı:

Küçük veya mekanik PR'lar atlanır.
Kritik API değişiklikleri hâlâ incelenir.
Actions dakika tüketimi azalır.

4. Enterprise özelliklerini ekip bazında açın

Copilot Enterprise özelliklerini tüm kuruluşa tek seferde açmak yerine ekip bazında etkinleştirin.

Önerilen sıra:

API platform ekibi
Yoğun sözleşme testi yazan ekipler
SDK ve istemci üreten ekipler
Geniş organizasyon kullanımı

Bu yaklaşım yeni özelliklerin maliyetini kontrollü ölçmenizi sağlar.

Apidog bu akışta nerede duruyor?

Apidog, Copilot alternatifi değildir. API sözleşmesi, mock, test ve dokümantasyon katmanını tek yerde tutarak Copilot incelemesinin daha pahalı aşamalara gereksiz yere harcama yapmasını önlemeye yardımcı olur.

API depoları için pratik akış şu şekilde kurulabilir:

API spesifikasyonunu Apidog koleksiyonunda tutun.
Kaydedilmiş request/response örneklerini spesifikasyonla birlikte yönetin.
Sözleşme testlerini canlı API yerine Apidog mock sunucusuna karşı çalıştırın.
CI içinde önce sözleşme doğrulamasını çalıştırın.
Copilot incelemesini sadece doğrulama başarılıysa tetikleyin.

Örnek akış:

PR açılır
  ↓
OpenAPI / Apidog koleksiyonu doğrulanır
  ↓
Mock sunucuya karşı sözleşme testleri çalışır
  ↓
Başarısızsa pipeline durur
  ↓
Başarılıysa Copilot kod incelemesi çalışır

Bu sıralama önemlidir çünkü Copilot incelemesi hattaki daha pahalı adımlardan biridir. Ucuz sözleşme kontrollerinde başarısız olacak bir PR için inceleme dakikası harcamamak gerekir.

Daha temel mock iş akışı için Postman olmadan API testi kılavuzuna, model API senaryosu için DeepSeek V4 API kılavuzuna bakabilirsiniz.

Örnek CI akışı

Aşağıdaki yapı, önce ucuz kontrolleri çalıştırıp Copilot incelemesini sona bırakır.

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - 'apis/**/*.yaml'
      - 'cmd/**'
      - 'internal/**'
      - 'tests/**'

jobs:
  contract-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Örnek: sözleşme doğrulama adımı
      - name: Run contract validation
        run: |
          apidog-cli validate

  copilot-review:
    needs: contract-check
    if: github.actor != 'dependabot[bot]' && github.actor != 'renovate[bot]'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/copilot-review@v1

Buradaki amaç Copilot incelemesini kaldırmak değil, doğru yerde çalıştırmaktır.

Bir sonraki faturalandırma döngüsünde neyi izlemelisiniz?

Takviminize üç kontrol noktası ekleyin.

1-7. günler

Premium istek kullanımı genellikle normal görünür. Çoğu ekip ilk hafta dahil edilen kotanın altında kalır.

Kontrol edin:

Koltuk sayısı
Aktif kullanıcı sayısı
Premium istek eğilimi
Actions dakika taban çizgisi

14-21. günler

Yoğun Workspace veya ajan modu kullanıcıları dahil kotayı aşmaya başlayabilir.

Kontrol edin:

Hangi kullanıcılar kotaya yaklaşıyor?
Harcama limiti devrede mi?
Ajan modu kullanımı beklenen seviyede mi?

28-30. günler

Copilot incelemesinden kaynaklanan Actions dakika kullanımı belirginleşir.

Kontrol edin:

Bu ayki Actions kullanımı
Önceki ayla fark
En çok dakika tüketen depolar
En çok tetiklenen workflow'lar

Ay sonunda şu kararları verin:

Yoğun kullanıcıları Enterprise katmanına taşımak gerekiyor mu?
Pasif kullanıcıların koltukları kaldırılmalı mı?
Copilot review path filtresi daraltılmalı mı?
Etiket tabanlı tetikleme modeline geçilmeli mi?

Sık yapılan hatalar

API ekiplerinde en sık görülen sorunlar şunlar:

Harcama limiti olmaması

Tek bir ajan döngüsü uzun süre çalışabilir. Her zaman üst sınır belirleyin.
Copilot incelemesinin her depoda açık olması

İncelemenin gerçekten değer kattığı depoları seçin. Diğerlerinde kapatın.
Oluşturulmuş istemcilerin incelenmesi

Generated kodu path filtresiyle hariç tutun.
Bot PR'larının incelenmesi

Dependabot, Renovate ve şirket içi otomatik güncelleyicileri filtreleyin.
Öncesi/sonrası ölçüm yapılmaması

GitHub faturalandırma arayüzünden CSV dışa aktarımı alın ve her ay saklayın.

SSS

Koltuk fiyatı hâlâ kullanıcı başına 10 dolar mı?

Copilot Business kullanıcı başına aylık 10 dolar, Copilot Enterprise kullanıcı başına aylık 19 dolar ve bireyler için Copilot Pro aylık 10 dolardır. Koltuk katmanı, dahil edilen premium istek kotasını belirler.

Satır içi tamamlamalar artık ölçülüyor mu?

Hayır. Sohbet ve satır içi tamamlamalar için varsayılan model, ücretli katmanlarda ölçülmez. Premium istekler daha pahalı özellikleri ve model seçimini kapsar.

Premium kotam bittiğinde ne olur?

Varsayılan olarak istekler kota hatasıyla başarısız olmaya başlar. Aşım kullanımına izin vermek için kuruluş düzeyinde harcama limiti belirleyebilirsiniz. Aşım, belirlenen limite kadar istek başına 0,04 dolar olarak hesaplanır.

Kod incelemesi için Actions dakikaları ayrı mı faturalandırılır?

Hayır. Copilot kod incelemesi, CI işlerinizle aynı Actions dakika havuzunu tüketir. Bu yüzden toplam Actions kullanımını izlemeli ve workflow tetikleyicilerini buna göre ayarlamalısınız.

Copilot kod incelemesini tamamen devre dışı bırakabilir miyim?

Evet. Kuruluş yöneticisi politika düzeyinde depolar için Copilot kod incelemesini devre dışı bırakabilir. Aynı yaklaşım ekip bazında etkinleştirme için de kullanılabilir.

Copilot incelemesi özel API spesifikasyonlarında çalışır mı?

Evet. Özel depolarda çalışır ve Actions dakikası tüketir. İnceleyici, spesifikasyon ve handler dosyalarını diğer kaynak dosyalar gibi okuyabilir.

Copilot incelemesi premium istekleri de kullanıyor mu?

Şu anda Copilot kod incelemesi yalnızca Actions dakikalarını tüketir. İncelemede kullanılan model Copilot platformunun parçasıdır ve ayrı bir premium istek olarak faturalandırılmaz. Bu alan değişebileceği için GitHub değişiklik günlüğünü izlemek gerekir.

Son kontrol listesi

Bir sonraki fatura döneminden önce şunları yapın:

[ ] Aktif Copilot kullanıcılarını çıkarın.
[ ] Pasif koltukları kaldırın.
[ ] Kuruluş düzeyinde harcama limiti belirleyin.
[ ] Premium istek uyarılarını Slack veya benzeri bir kanala bağlayın.
[ ] Bot PR'larında Copilot incelemesini kapatın.
[ ] Oluşturulmuş istemcileri path filtresinden çıkarın.
[ ] API depoları için aylık Actions dakika bütçesi belirleyin.
[ ] GitHub faturalandırma CSV'sini her ay dışa aktarın.
[ ] Ucuz sözleşme kontrollerini Copilot incelemesinden önce çalıştırın.

Hem Copilot incelemesi hem de CI içinde doğrudan model API çağrıları çalıştıran ekipler için GPT-5.5 ücretsiz Codex kılavuzu belirteç başına maliyet tarafını açıklar. Apidog ise mock ve sözleşme katmanını yöneterek yapay zeka incelemesinin yalnızca ucuz kontrolleri geçen PR'larda çalışmasına yardımcı olur.

Zuplo API'si Nasıl Kullanılır?

Tobias Hoffmann — Mon, 27 Apr 2026 08:59:54 +0000

Zuplo hakkında bilgi edindiyseniz ve onunla gerçek bir şeyler göndermek istiyorsanız, bu yazı tam size göre. Platformu öğrenmek hızlıdır, ancak dökümantasyonu farklı kaynaklara yayılmıştır. Bu rehberde, bir projeyi nasıl oluşturacağınız, rota açacağınız, API anahtarı kimlik doğrulaması ve hız limiti ekleyeceğiniz, özel bir TypeScript ilkesi yazacağınız, dağıtıma göndereceğiniz ve Apidog ile test edeceğiniz adım adım gösterilecektir.

Bugün Apidog'u deneyin

Bu sürecin sonunda, kimlik doğrulama, hız limiti, otomatik geliştirici portalı ve CI ile uyumlu bir Git iş akışı ile kaynak API'nızın önünde çalışan bir API gateway’iniz olacak. Tüm işlem yaklaşık otuz dakika sürer.

Zuplo’nun sizin için uygun olup olmadığından emin değilseniz, şu makaleye göz atın: Zuplo API ağ geçidi nedir. Diğer detaylar için Zuplo belgelerine başvurabilirsiniz.

Özet

portal.zuplo.com üzerinden kayıt olun veya npm create zuplo ile yerel proje başlatın.
config/routes.oas.json dosyasında rotaları tanımlayın ve URL Forward Handler ile kaynak API’ya yönlendirin.
Gerekli inbound policy’leri (API anahtarı doğrulama, hız limiti, şema doğrulama) rota dosyası veya Route Designer üzerinden ekleyin.
Özel mantık için modules/ klasöründe TypeScript modülleri yazın; runtime üzerinden tip güvenli erişim elde edersiniz.
Değişiklikleri bağlı Git dalına gönderin ve bir önizleme ortamı dağıtın; üretime almak için birleştirin.
Yayına almadan önce her rotayı Apidog ile test edin.
Ücretsiz plan ayda 100K istek sunar, Builder planı aylık 25$’dır.

Ön Koşullar

Başlamadan önce ihtiyacınız olanlar:

Bir Zuplo hesabı
Gateway’in önünde çalışacak bir kaynak API (yoksa https://echo.zuplo.io kullanılabilir)
CLI kullanacaksanız Node.js 18+

Ayrıca yerel geliştirme için bir kod editörü gerekir. VS Code + TypeScript eklentisi önerilir. VS Code içerisinden istek göndermek için Apidog VS Code uzantısını kurabilirsiniz.

Adım 1: Zuplo Projesi Oluşturun

Proje oluşturmanın iki yolu var: Web portali veya CLI.

Seçenek A: Portal Kullanarak

portal.zuplo.com adresinde oturum açın.
"Yeni Proje"ye tıklayın, örneğin acme-gateway adını verin.
"Boş Proje"yi seçin.
Kod sekmesi başlangıç dosya ağacı ile açılır.

Portal, projeyi varsayılan olarak yönetilen bir Git deposuna bağlar. Sonradan kendi GitHub, GitLab, Bitbucket veya Azure DevOps deponuzu Ayarlar’dan bağlayabilirsiniz.

Seçenek B: CLI Kullanarak

Yerel projeyi CLI ile başlatmak için:

npm create zuplo@latest -- --name acme-gateway
cd acme-gateway
npm install
npm run dev

Geliştirme sunucusu 9000 portunda başlar ve Route Designer’a http://localhost:9100 üzerinden erişebilirsiniz. Yaptığınız değişiklikler otomatik olarak yansır.

Projeyi dağıtıma hazır hale getirmek ve Zuplo hesabınıza bağlamak için:

npx zuplo link

Hesap ve ortam seçin. Sonrasında güncel dalı dağıtmak için:

npx zuplo deploy

Adım 2: İlk Rotanızı Tanımlayın

config/routes.oas.json dosyasını açın. OpenAPI 3 dokümanı içinde aşağıdaki gibi bir rota ekleyin:

{
  "openapi": "3.1.0",
  "info": { "title": "Acme Ağ Geçidi", "version": "1.0.0" },
  "paths": {
    "/v1/products": {
      "get": {
        "summary": "Ürünleri listele",
        "operationId": "list-products",
        "x-zuplo-route": {
          "corsPolicy": "anything-goes",
          "handler": {
            "export": "urlForwardHandler",
            "module": "$import(@zuplo/runtime)",
            "options": {
              "baseUrl": "${env.ORIGIN_URL}"
            }
          },
          "policies": { "inbound": [] }
        },
        "responses": {
          "200": { "description": "Başarılı" }
        }
      }
    }
  }
}

x-zuplo-route altında handler ve policy’leri tanımlarsınız. ${env.ORIGIN_URL} ortam değişkeni ile farklı backend’lere yönlendirme yapabilirsiniz.

Ortam değişkenini portaldan veya yerelde config/.env dosyasına ekleyin. Kaydedin, değişiklikler anında yansır. Test için http://localhost:9000/v1/products adresine gidin.

Adım 3: API Anahtarı Kimlik Doğrulaması Ekleyin

Kamuya açık API’ler için kimlik doğrulama gerekir. Zuplo, yönetilen API anahtarı servisi sağlar.

Rota dosyanızda inbound policy’yi ekleyin:

"policies": {
  "inbound": ["api-key-auth"]
}

Policy tanımını config/policies.json içerisine ekleyin:

{
  "name": "api-key-auth",
  "policyType": "api-key-inbound",
  "handler": {
    "export": "ApiKeyInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "allowUnauthenticatedRequests": false
    }
  }
}

Portal üzerinden Hizmetler > API Anahtar Servisi'ne gidin, “Tüketici Oluştur” ile yeni bir API anahtarı üretin.

Başlık olmadan test edin:

curl -i https://PROJENIZ.zuplo.app/v1/products
# HTTP/2 401

Doğru başlıkla tekrar deneyin:

curl -i https://PROJENIZ.zuplo.app/v1/products \
  -H "Authorization: Bearer SIZIN_API_ANAHTARINIZ"
# HTTP/2 200

Dilerseniz OpenAPI dökümanı ile Apidog'da test ortamı kurabilir, API anahtarınızı ortam değişkeni olarak bağlayabilirsiniz.

Adım 4: Hız Sınırı Ekleyin

API’nizi hız limiti olmadan yayınlamayın. Aşağıdaki şekilde inbound policy’lere ekleyin:

"policies": {
  "inbound": ["api-key-auth", "rate-limit-by-key"]
}

Policy tanımı:

{
  "name": "rate-limit-by-key",
  "policyType": "rate-limit-inbound",
  "handler": {
    "export": "RateLimitInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "rateLimitBy": "sub",
      "requestsAllowed": 60,
      "timeWindowMinutes": 1
    }
  }
}

Her müşteri için 60 istek/dk sınırı. Aşağıdaki betikle test edin:

for i in {1..70}; do
  curl -s -o /dev/null -w "%{http_code}\n" \
    https://PROJENIZ.zuplo.app/v1/products \
    -H "Authorization: Bearer SIZIN_API_ANAHTARINIZ"
done | sort | uniq -c

60 satır 200, 10 satır 429 görmelisiniz.

Adım 5: İstek Yüklerini Doğrulayın

Bir POST rotanız varsa, gövde şemasını OpenAPI ile tanımlayın:

"/v1/products": {
  "post": {
    "summary": "Ürün oluştur",
    "operationId": "create-product",
    "requestBody": {
      "required": true,
      "content": {
        "application/json": {
          "schema": {
            "type": "object",
            "required": ["name", "priceCents"],
            "properties": {
              "name": { "type": "string", "minLength": 1 },
              "priceCents": { "type": "integer", "minimum": 1 },
              "category": { "type": "string", "enum": ["food", "drink"] }
            }
          }
        }
      }
    },
    "x-zuplo-route": {
      "handler": { /* yukarıdakiyle aynı */ },
      "policies": {
        "inbound": [
          "api-key-auth",
          "rate-limit-by-key",
          "validate-request"
        ]
      }
    }
  }
}

Policy tanımı:

{
  "name": "validate-request",
  "policyType": "open-api-request-validation-inbound",
  "handler": {
    "export": "OpenApiRequestValidationInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "validateBody": "reject"
    }
  }
}

Eksik veya hatalı gövdeler gateway’de 400 ile reddedilir. Apidog ile başarılı, eksik alanlı ve hatalı enum’lu fonksiyon testleri oluşturun.

Adım 6: Özel TypeScript Policy Yazın

Hazır policy’ler çoğu ihtiyacı karşılar. Ancak özel mantık gerekirse, örneğin ücretli müşterilere farklı cache davranışı eklemek için:

modules/tiered-cache.ts:

import { ZuploRequest, ZuploContext, HttpProblems } from "@zuplo/runtime";

interface PolicyOptions {
  paidPlanHeader: string;
  paidMaxAge: number;
}

export default async function (
  response: Response,
  request: ZuploRequest,
  context: ZuploContext,
  options: PolicyOptions,
): Promise<Response> {
  const plan = request.user?.data?.plan ?? "free";

  if (plan === "free") {
    response.headers.set("Cache-Control", "no-store");
  } else {
    response.headers.set(
      "Cache-Control",
      `public, max-age=${options.paidMaxAge}`,
    );
  }

  context.log.info(`Cache header set for plan=${plan}`);
  return response;
}

Policy olarak ekleyin:

{
  "name": "tiered-cache",
  "policyType": "custom-code-outbound",
  "handler": {
    "export": "default",
    "module": "$import(./modules/tiered-cache)",
    "options": {
      "paidPlanHeader": "x-plan",
      "paidMaxAge": 300
    }
  }
}

Rota dosyasında outbound policy olarak referans verin:

"policies": {
  "inbound": ["api-key-auth", "rate-limit-by-key"],
  "outbound": ["tiered-cache"]
}

Bu policy’yi Jest veya Vitest ile birim test edebilirsiniz.

Adım 7: Uca Dağıtım

Git ile dağıtım yapın:

git add .
git commit -m "Kimlik doğrulama, hız limiti ve cache policy eklendi"
git push origin feature/products-gateway

Her dal için önizleme ortamı oluşur ve URL’i log’da görebilirsiniz. Önizleme URL’sini Apidog ile test edin. Her şey tamamsa ana dala birleştirin:

git checkout main
git merge feature/products-gateway
git push origin main

Birleştirme otomatik olarak prod dağıtımını tetikler.

Adım 8: Geliştirici Portalı Oluşturun

Portalınız https://PROJENIZ.developers.zuplo.com adresinde barındırılır. İçerik:

Her rota için OpenAPI şeması, açıklama ve deneme konsolu
cURL, JS, Python, Go ve diğer dillerde kod örnekleri
Otomatik API anahtarı oluşturma
Markalama kontrolleri: Geliştirici Portalı > Ayarlar

OpenAPI şemanız yeterliyse, portal ekstra iş gerektirmez. Özelleştirmek için Zuplo Geliştirici Portalı kodunu çatallayabilirsiniz.

Adım 9: Tümünü Apidog ile Test Edin

Gateway’iniz yayında olduğunda, her rota ve policy’i Apidog ile test edin.

Önerilen süreç:

OpenAPI şemanızı https://PROJENIZ.zuplo.app/openapi üzerinden içe aktarın.
local, preview, production ortamları oluşturun ve uygun base_url/api_key girin.
Her rota için başarılı, kimlik doğrulama hatalı ve hız limiti tetikleyen örnekler oluşturun.
Apidog’un test senaryoları ile zincirli istekler kurun ve yanıtları doğrulayın.
Dilediğiniz dilde kod örneklerini alın ve dokümanlarınıza ekleyin.

Postman’dan geçiş için API test rehberini izleyebilirsiniz. Apidog’u indirin ve sürecinize entegre edin.

Zuplo Kullanımı Hakkında Sık Sorulan Sorular

Bir rotayı spesifikasyonu değiştirmeden ortamlar arasında nasıl değiştiririm?

Ortam değişkenleri kullanın. Her ortam için Ayarlar veya config/.env dosyasına ORIGIN_URL tanımlayın, handler’da ${env.ORIGIN_URL} kullanın.

Zuplo'yu çevrimdışı çalıştırabilir miyim?

Evet. npm run dev ile 9000 portunda local gateway ve 9100 portunda Route Designer açılır. API anahtarı servisi hariç tüm özellikler offline çalışır. API anahtarı için npx zuplo link ile bulut hizmetine bağlanabilirsiniz.

Kötü bir dağıtımı nasıl geri alırım?

git revert ile son merge commit’ini geri alın ve push edin. Zuplo otomatik olarak eski sürümü yayına alır.

Dağıtım sırasında devam eden isteklere ne olur?

Dağıtımlar uçta atomiktir. Devam eden istekler eski sürümü bitirir, yeni istekler yeni sürüme gider.

Zuplo'yu gRPC veya WebSockets ile kullanabilir miyim?

Evet. urlForwardHandler WebSocket yükseltmesini ve gRPC ise ilgili handler ile desteklenir.

Zuplo API’mi AI araçlarına nasıl açarım?

Rotalara MCP Server Handler ekleyin, OpenAPI şemanıza işaret edin ve işlemleri seçin. Policy’ler MCP istekleri için de geçerlidir. MCP Server dökümantasyonu detaylıdır.

Üretimde ağ geçidi ne kadar tutar?

Ücretsiz katman ayda 100K istek kapsar. Builder planı aylık 25$’a 1M istek içerir, fazlası için 100K başına 100$ ücretlendirilir. Kurumsal fiyatlar için fiyatlandırma sayfasını inceleyin.

Sonuç

Artık API anahtarı doğrulama, anahtar başına hız limiti, istek doğrulama, özel TypeScript outbound policy ve geliştirici portalı içeren, Git ile global edge’e dağıtılan bir Zuplo gateway’iniz var. Aynı proje ile preview, prod ve AI agent erişimi yönetebilirsiniz.

Bunu stabil tutmanın yolu, test döngüsüdür. Her önizleme merge etmeden Apidog ile kimlik doğrulama hatalarını, eksik şema alanlarını ve yanlış hız limitlerini önceden yakalayın. Apidog’u indirin ve API gateway’inize bağlayın.

Zuplo API Ağ Geçidi Nedir?

Tobias Hoffmann — Mon, 27 Apr 2026 06:36:31 +0000

Çoğu API ağ geçidi hâlâ 2014 operasyon ekibi için tasarlanmış gibi hissettiriyor. YAML dosyalarını yönetiyorsunuz, kontrol düzlemiyle uğraşıyorsunuz ve değişikliklerinizi uygulamak için küme erişimi olan birinden yardım bekliyorsunuz. Zuplo bu modeli tersine çeviriyor: Rotalarınızın bir Git deposunda yaşadığı, politikalarınızı TypeScript ile yazabildiğiniz ve her taahhüdün saniyeler içinde 300'den fazla küresel konuma dağıtıldığı, programlanabilir ve uç-yerel bir API ağ geçidi. Bu yazıda Zuplo API ağ geçidinin yeteneklerini, Kong ve AWS API Gateway'den nasıl ayrıştığını, fiyatlandırmasını ve otuz dakikadan kısa sürede ilk ağ geçidinizi nasıl kuracağınızı adım adım bulacaksınız. Ayrıca yönlendirme, kimlik doğrulama ve hız sınırlama için örnek kodları ve üretime geçmeden önce Apidog ile uç noktalarınızı nasıl test edebileceğinizi anlatan pratik başlıklar da mevcut.

Apidog'u bugün deneyin

Zuplo, bir zamanlar Kong, Apigee ve AWS API Gateway'in hâkim olduğu bir kategoride rekabet ediyor. Temel yaklaşım: Geliştiriciler gerçek bir programlama dili ve modern bir iş akışıyla çalışır, operasyonlar yönetilen bir hizmet alır, ürün ise yerleşik para kazanma araçlarına sahip olur. Bu yazı, bu farkları ve pratik iş akışını özetliyor.

ÖZET

Zuplo, 300'den fazla Cloudflare veri merkezinde 50ms'den kısa gecikme ve sıfır soğuk başlatma ile rotalarınızı çalıştıran, tamamen yönetilen uç-yerel bir API ağ geçididir.
Yapılandırma GitOps tabanlıdır; ağ geçidiniz bir Git deposunda yaşar, dağıtımlar CI/CD üzerinden yapılır.
Politikalar, YAML/Lua yerine TypeScript ile yazılır, tam IDE desteği vardır.
Ücretsiz katman, sınırsız ortam, API anahtarı ve geliştirici portalı ile ayda 100.000 isteği kapsar.
API anahtarı kimlik doğrulama, JWT, OAuth2, hız sınırlama, istek doğrulama, otomatik geliştirici portalı ve Stripe ile para kazanma dahili olarak gelir.
Zuplo artık MCP Sunucu İşleyicisi sunuyor; böylece herhangi bir rota Claude, Codex, Cursor gibi MCP istemcilerine açılabilir.
Her Zuplo rotasını üretime almadan önce uçtan uca Apidog ile test edin.

Zuplo Nedir?

Zuplo, üç temel ilkeye dayalı bir API yönetim platformudur: yapılandırma yerine kod, bölge yerine uç, GUI yerine Git. Cloudflare’in uç ağında tamamen yönetilen bir hizmet olarak çalışır; bir dağıtım yaptığınızda 300+ veri merkezine otomatik olarak ulaşır.

Çoğu ağ geçidi yapılandırmanızı bir YAML dosyasında ya da kontrol düzlemi veritabanında saklarken, Zuplo ağ geçidinizi bir TypeScript projesi olarak ele alır. Temel dosya yapısı:

routes.oas.json: Uç noktaları tanımlar
modules/: Özel TypeScript modülleri (politikalar)
zuplo.json: Politika ve yapılandırma dosyası

GitHub’a push yaptığınızda platform otomatik olarak oluşturur, doğrular ve dağıtır.

Platform REST, GraphQL, gRPC, WebSockets ve SOAP’u destekler. SOC 2 Tip II uyumlu, AWS, Azure ve GCP üzerinde çalışabiliyor; kendi kendine barındırılan Kubernetes seçeneği de var. Fiyatlandırma istek hacmine göre; detaylar için Zuplo fiyatlandırma sayfasına bakabilirsiniz.

Geliştiriciler Neden Kong, Apigee ve AWS API Gateway Yerine Zuplo'yu Seçiyor?

Her ağ geçidinin kendine özgü bir karakteri var. Kong maksimum kontrol isteyen, karşılığında Lua uzmanlığı gerektiren açık kaynaklı bir ağır sıklet. Apigee kurumsal segmentte, derin analizler ve yüksek öğrenme eğrisine sahip. AWS API Gateway ise AWS kullananlar için varsayılan, ancak geliştirici portalı zayıf ve Lambda entegrasyonu soğuk başlatma problemi taşıyor.

Zuplo, platform mühendisliği ekibi olmayan küçük ama kurumsal ihtiyaçlardaki ekipler için ideal. Fark yaratan noktalar:

YAML değil, kod: Bir hız sınırlama politikası Zuplo’da üç satır TypeScript ile yazılır. Kong’da aynı iş için 15+ satır YAML gerekir.
Geliştirici portalı dahili: Kong’da portal sadece kurumsal plana dahildir. Zuplo’da ücretsiz katman da dâhil, OpenAPI spesifikasyonundan otomatik portal oluşturulur.
Varsayılan GitOps: Tüm değişiklikler çekme isteğidir. Otomatik inceleme, denetim ve revert desteği var.
Uç-yerel, soğuk başlatma yok: Cloudflare Workers üzerinde çalışır. İstekler milisaniyeler içinde en yakın veri merkezinden ulaşır.

Eğer ekibinizde Kong/Apigee yatırımı varsa ve operasyonel yük sorun değilse geçiş şart değil. Ancak yeni başlıyorsanız, Zuplo iş akışında belirgin avantaj sunar.

Zuplo API Ağ Geçidinin Temel Özellikleri

TypeScript Öncelikli Programlanabilirlik

Ağ geçidi davranışı, rotalarınızın yanında TypeScript dosyalarında tanımlanır. İsteğe özel gelen/giden politikalar, fonksiyon olarak yazılır. Tam tip desteği, otomatik tamamlama ve test kolaylığı sağlar.

Örnek: Yanıttan dahili bir başlığı kaldıran politika:

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

export default async function (
  response: Response,
  request: ZuploRequest,
  context: ZuploContext,
) {
  response.headers.delete("x-internal-trace-id");
  return response;
}

Bu dosyayı modules/strip-internal-header.ts olarak ekleyin, rotada referans verin, Git’e itin—hepsi bu.

60+ Hazır Politika

API anahtarı kimlik doğrulama, JWT doğrulama, OAuth 2.0, hız sınırlama, istek/yanıt doğrulama, CORS, IP listeleme, istek dönüşümü ve upstream entegrasyonları için 60’tan fazla hazır politika. Sadece rota tanımında ekleyin, kod yazmak gerekmez.

Otomatik Oluşan Geliştirici Portalı

OpenAPI spesifikasyonunuza bağlayın; etkileşimli deneme, cURL/JS/Python/Go örnekleri, self-servis API anahtar yönetimiyle portal anında hazır.

Yerleşik API Para Kazanma

Stripe ile entegre olarak API erişimi satabilirsiniz. Plan tanımlayın, Stripe bağlayın, ödemeler ve abonelik yönetimi otomatik çalışır.

Yapay Zeka Araçları için MCP Sunucu İşleyicisi

OpenAPI spesifikasyonunuzu yönlendirin, hangi işlemleri açacağınızı seçin. Böylece Claude Code, OpenAI Codex, Cursor ve diğer MCP istemcileri API’nizi otomatik kullanabilir. Standart politikalara ek olarak AI agent’lar için de kimlik doğrulama ve hız sınırlama çalışır. Detaylı rehber: API’leri MCP ile açma.

Uç Dağıtım, 50ms Altı Gecikme

Her dağıtım Cloudflare’in 300+ bölgesine otomatik gider. Hiçbir ek yapılandırma gerekmez; her istek kullanıcıya en yakın uç noktadan yönlendirilir.

Zuplo Perde Arkasında Nasıl Çalışır?

Bir istek uç konumda şu sırayla işlenir:

Rota Eşleşmesi: URL ve metot, routes.oas.json ile eşleşir.
Gelen Politikalar: API anahtarı, JWT, hız sınırlama, şema doğrulama gibi politikalar sırayla uygulanır.
İşleyici: Proxy, statik yanıt, özel TypeScript kodu veya MCP’ye çağrı yapılır.
Giden Politikalar: Yanıt dönüşümleri ve başlık manipülasyonu.
Yanıt: Müşteriye döner; loglar ve metrikler gözlemlenebilirlik katmanına gider.

Tüm pipeline Cloudflare Worker’da çalışır. Gecikme düşük, kapasite kullanımı optimize.

İlk Zuplo Ağ Geçidinizi Kurma

30 dakikadan kısa sürede ilk çalışan ağ geçidinizi kurmak için adımlar:

Kayıt ve Proje Oluşturma: zuplo.com’dan kaydolun, yeni proje başlatın. GitHub entegrasyonu ile kendi deponuza bağlayın.
OpenAPI Spesifikasyonunu İçe Aktarın: Mevcut bir OpenAPI spesiniz varsa, içe aktarın. Yoksa UI üzerinden rotaları oluşturun.
API Anahtarı Kimlik Doğrulama Politikası Ekleyin: Rota düzenleyicide api-key-inbound politikasını ekleyin. Zuplo otomatik olarak tüketici veritabanı ve anahtar UI’si oluşturur.
Hız Sınırı Ekleyin: rate-limit-inbound politikasını, örneğin anahtar başına dakikada 100 istek ile ekleyin. Sadece rota dosyasına JSON bloğu eklemeniz yeterli.
Dağıtın: Dalınıza push yapın. Zuplo önizleme ortamı oluşturur, merge sonrası prod’a çıkar.
Ağ Geçidini Test Edin: Yeni gateway URL’sine geçerli/geçersiz API anahtarı, aşılmış limit ve hatalı yüklerle istek göndermek için Apidog kullanın.

Kurulum dakikalar içinde tamamlanır. Asıl zorluk rotaları iyi adlandırmak ve mantık ayrımını doğru yapmaktır.

TypeScript'te Özel Politikalar Yazma

Hazır politikalar çoğu durumu kapsar. Özel gereksinimler için TypeScript ile yeni politika yazabilirsiniz. Örnek: İstekleri, upstream’e ulaşmadan önce dahili bir hizmetten gelen verilerle zenginleştirin.

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

interface UserContext {
  userId: string;
  plan: "free" | "pro" | "enterprise";
}

export default async function (
  request: ZuploRequest,
  context: ZuploContext,
): Promise<ZuploRequest | Response> {
  const apiKey = request.user?.sub;
  if (!apiKey) {
    return new Response("Unauthorized", { status: 401 });
  }

  const lookupUrl = `https://internal.example.com/users/${apiKey}`;
  const userResponse = await fetch(lookupUrl, {
    headers: { authorization: `Bearer ${context.environment.INTERNAL_TOKEN}` },
  });

  if (!userResponse.ok) {
    return new Response("User lookup failed", { status: 502 });
  }

  const user = (await userResponse.json()) as UserContext;
  request.headers.set("x-user-id", user.userId);
  request.headers.set("x-user-plan", user.plan);
  return request;
}

Burada:

Politika normal bir async fonksiyon, kolayca birim test edilebilir.
Ortam değişkenlerine context.environment ile erişilir, tip güvenli.
Response döndürmek işlem hattını kısa devre yapar (ör: kimlik doğrulama hatası).

2026'da Zuplo Fiyatlandırması

Üç ana plan:

Ücretsiz, ayda 0$: Ayda 100K istek, sınırsız ortam, sınırsız API anahtarı ve geliştirici portalı, 1 GB çıkış, 2 geliştirici.
Builder, ayda 25$: 1M istek, 2 özel alan adı, 100K istek başına 1 GB çıkış, ek istek başı 100$.
Enterprise, 1.000$+ / ay: Sınırsız istek ve alan adı, %99,5–%99,999 SLA, GitHub Enterprise/GitLab/Azure DevOps entegrasyonu, SSO, RBAC ve 7/24 destek.

AI Ağ Geçidi ve Geliştirici Portalı ürünleri ayrı katmanlarda; güncel rakamlar için Zuplo fiyatlandırma sayfasına bakın.

AWS API Gateway milyon REST isteği başına 3.50$, veri transferi ve Lambda maliyetleri eklenir. Kong’un kurumsal katmanı genelde Zuplo Enterprise’dan daha pahalı. Sadece ücretsiz katman bile erken aşama projeler için fazlasıyla yeterli.

Zuplo Ne Zaman Doğru Tercih, Ne Zaman Değil?

Zuplo’yu seçin:

Yönetilen ağ geçidi istiyor, Kubernetes üstünde Kong kurmak istemiyorsanız
Ekibiniz TypeScript/JavaScript’e hâkimse
Ayrı bir satıcı kullanmadan geliştirici portalı istiyorsanız
API’den gelir elde edip Stripe faturalandırmasını entegre etmek istiyorsanız
API’nizi AI agent’lara açmak ve MCP desteği almak istiyorsanız
Trafiğiniz küresel ve uç gecikmesi kritikse

Zuplo uygun değil:

Tam açık kaynak kod kontrolü gerekiyorsa (Kong)
Tamamen şirket içi, internete çıkışı olmayan bir mimariniz varsa (Kong/Tyk self-hosted)
NGINX’in dahili özelliklerine erişmeniz gerekiyorsa
Zaten Apigee veya MuleSoft’a derin yatırımınız varsa

Zuplo Ağ Geçidinizi Apidog ile Test Etme

Gateway’iniz önizleme ortamında yayına alındıktan sonra, üretime geçmeden önce tüm rotaları ve politikaları kapsamlıca test edin. Bu noktada bir API istemcisi şart.

Apidog, OpenAPI spesifikasyonunuzu direkt içe aktarır ve Zuplo rotalarınızı test paketiyle eşleştirir. Şunları kolayca yapabilirsiniz:

Her rotayı geçerli/geçersiz API anahtarı ile çağırıp kimlik doğrulama politikalarını doğrulayın
Hatalı yüklerle istek doğrulamasını test edin
Hız sınırlama eşiklerinde rate limit politikalarını zorlayın
Ortam değişkenleri ile önizleme/üretim URL ve anahtarlarını yönetin
cURL, JS, Python ve Go kod örnekleri oluşturun

Ayrıca Apidog’un otomatik test senaryoları ile, manuel script yazmaya gerek kalmadan hızlıca kapsamlı testler yapabilirsiniz. VS Code uzantısı için buraya, Postman alternatifi için buraya bakabilirsiniz. Başlamak için Apidog'u indirin.

Zuplo API Ağ Geçidi Hakkında Sıkça Sorulan Sorular

Zuplo Açık Kaynak mı?

Çekirdek çalışma zamanı kapalı kaynaklı, ancak geliştirici portalı ve bazı yardımcı kütüphaneler açık kaynak. Kendi kendine barındırılan Kubernetes seçeneği mevcut; çoğu ekip yönetilen hizmeti tercih ediyor.

Zuplo Kendi Altyapımda Çalışabilir mi?

Evet. Enterprise planında self-hosted Kubernetes seçeneği var; karşılığında küresel uç dağıtımdan vazgeçersiniz ve operasyon sizde olur.

Zuplo, Cloudflare API Shield ile Karşılaştırıldığında?

API Shield temel güvenlik (schema validation, abuse detection, mTLS) sunar. Zuplo ise tam yönetim platformu: yönlendirme, politika, portal, para kazanma, MCP. İhtiyaçlarınıza göre ikisini birlikte de kullanabilirsiniz.

Zuplo Mevcut OpenAPI Spesifikasyonumla Çalışıyor mu?

Evet. Spesifikasyonu içe aktarın, rotalar ve portal otomatik oluşur; istek doğrulama aynı şemayı kullanır.

Zuplo Ağ Geçidimi Claude veya Codex Gibi AI Agent’lara Açabilir miyim?

Evet, MCP Sunucu İşleyicisi ile. OpenAPI spesini yönlendirip hangi işlemleri açacağınızı seçersiniz, AI agent’lar aynı kimlik doğrulama ve hız sınırlama kurallarıyla erişir.

Bir Zuplo Dağıtımı Ne Kadar Sürer?

Push-to-deploy döngüsü önizleme ortamı için genellikle 60 saniyeden kısa sürer. Üretim yükseltmeleri daha da hızlıdır; bakım penceresi yoktur.

Cloudflare Çökerse Ne Olur?

Zuplo, Cloudflare uç ağında çalışır. Bölgesel bir kesinti o bölgeyi etkiler. Enterprise planı için çoklu bulut seçenekleri var. Standart ekipler Cloudflare’in genel güvenilirliğine güvenir.

Sonuç

Zuplo, operasyonel karmaşa olmadan kurumsal API özellikleri isteyen ekipler için güçlü bir seçenektir. TypeScript tabanlı politikalar, GitOps dağıtım, otomatik geliştirici portalı, entegre para kazanma ve AI agent’lar için MCP desteği ile yalnızca bir yönlendirme katmanı değil, tam bir platform sunar. Ücretsiz katman gerçek üretim için yeterlidir; daha büyük ihtiyaçlar için Enterprise mevcut.

Denemek için, gerçek API’nizle 30 dakikalık kurulumu tamamlayın, tüm politikaları Apidog ile test edin ve kararınızı gerçek kullanım üzerinden verin. Yönetilen uç gateway ve güçlü bir test istemcisi, "API’miz var"dan "ürünümüz var"a geçişin en hızlı yoludur. Apidog'u indirin ve test sürecine başlayın.

DeepSeek V4'ü Yerel Olarak Nasıl Çalıştırılır?

Tobias Hoffmann — Fri, 24 Apr 2026 05:19:23 +0000

DeepSeek V4, 23 Nisan 2026'da Hugging Face üzerinde MIT lisanslı ağırlıklarıyla yayınlandı. Bu lisans, kendi donanımında ileri seviye yapay zeka çalıştırmak isteyen ekipler için büyük bir avantaj. V4-Flash (284B toplam, 13B aktif parametre) FP8'de iki adet H100'e sığarken, V4-Pro (1.6T toplam, 49B aktif parametre) bir küme gerektiriyor ve kod/muhakeme konularında GPT-5.5 ve Claude Opus 4.6 ile rekabetçi şekilde çalışıyor.

Apidog'u bugün deneyin

Bu rehberde, DeepSeek V4'ü yerelde kurmak için donanım gereksinimlerinden başlayıp, niceleme (quantization) işlemlerine, vLLM ve SGLang kurulumlarına, araç entegrasyonu ve Apidog ile üretim öncesi doğrulamaya kadar tüm adımlar pratik bir şekilde ele alınmıştır.

Ürüne genel bakış için DeepSeek V4 nedir makalesine göz atın. Barındırılan API entegrasyonu için DeepSeek V4 API nasıl kullanılır. Maliyet analizi için DeepSeek V4 API fiyatlandırması.

TL;DR

V4-Flash, FP8'de 2 × H100 80GB veya INT4'te 1 × H100 üzerinde çalışır. FP8 ağırlıklar ~500GB.
V4-Pro, FP8 modunda üretim için 16+ H100 gerektirir.
vLLM, OpenAI uyumlu sunucu kurmanın en hızlı yoludur. vllm>=0.9.0 V4 desteğiyle gelir.
SGLang, araç kullanımı ve yapılandırılmış çıktı isteyen ekipler için alternatiftir.
AWQ INT4 veya GPTQ INT4 quantization, V4-Flash'i tek bir 80GB karta yaklaşık %5 kalite kaybıyla sığdırır.
http://localhost:8000/v1 adresine yönlendirme ve barındırılan API koleksiyonunu tekrar kullanmak için Apidog kullanabilirsiniz.

Kimler kendi kendine barındırmalı?

Aşağıdaki ekipler için self-hosting doğru tercihtir:

Uyumluluk gerektirenler: Sağlık, finans, hukuk, savunma gibi verinin dışarı çıkamayacağı alanlarda; MIT lisansı sayesinde veri kullanımı ve dağıtımında kısıtlama yoktur.
Büyük ve stabil iş yükleri: V4-Pro API fiyatları giriş başına 1.74 $/M, çıkış başına 3.48 $/M. Ayda 200 milyar jetonu aşan işlerde donanım ekonomisi avantajlıdır.
İnce ayar ve araştırma: Temel checkpointler sürekli ön eğitim ve alan adaptasyonu için uygundur; MIT lisansı ile türetilmiş modelleri ticari olarak kullanabilirsiniz.

Küçük prototipler, GPU yönetimi deneyimi olmayan ekipler ve aylık 200 dolar altında API kullananlar için self-hosting önerilmez.

Donanım Gereksinimleri

DeepSeek V4, FP4 + FP8 mixed precision ile daha verimli VRAM kullanır.

Varyant	Toplam parametre	Aktif parametre	FP8 VRAM	INT4 VRAM	Minimum kart
V4-Flash	284B	13B	~500GB	~140GB	2 × H100 80GB (FP8) veya 1 × H100 (INT4)
V4-Pro	1.6T	49B	~2.4TB	~700GB	16 × H100 80GB (FP8) veya 8 × H100 (INT4)

Notlar:

MoE belleği toplamdır, aktif olan değildir. Bellek hesabında tüm uzmanlar için VRAM gerekir, yalnızca aktif parametreler işlem maliyetini etkiler.
H200 ve MI300X alternatif olarak kullanılabilir.
Tüketici GPU'ları uygun değil; V4-Flash bile 24GB RTX 5090'da çalışmaz.
Apple Silicon (M3/M4 Max) sadece test/development için uygundur, prodüksiyon için değil.

Adım 1: Ağırlıkları İndirin

Resmi HuggingFace depoları:

deepseek-ai/DeepSeek-V4-Flash
deepseek-ai/DeepSeek-V4-Pro
İnce ayar için: deepseek-ai/DeepSeek-V4-Flash-Base ve DeepSeek-V4-Pro-Base

Kurulum ve indirme:

pip install -U "huggingface_hub[cli]"
huggingface-cli login

huggingface-cli download deepseek-ai/DeepSeek-V4-Flash \
  --local-dir ./models/deepseek-v4-flash \
  --local-dir-use-symlinks False

V4-Flash için ~500GB, V4-Pro için birkaç TB disk alanı ayırın. Çin içi için modelscope.cn hızlı bir alternatif.

Adım 2: Sunum Motoru Seçimi

İki ana seçenek:

vLLM: En geniş topluluk ve en iyi OpenAI uyumluluğu. Varsayılan öneri.
SGLang: Daha iyi araç kullanımı ve yapılandırılmış çıktı isteyenler için.

Her ikisi de V4'ü kutudan çıkar çıkmaz destekliyor.

Adım 3: V4-Flash'i vLLM ile Sunmak

Kurulum ve başlatma:

pip install "vllm>=0.9.0"

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 2 \
  --max-model-len 1048576 \
  --dtype auto \
  --enable-prefix-caching \
  --port 8000

Kritik parametreler:

--tensor-parallel-size 2: 2 H100 kullanır; daha fazla kart için artırılabilir.
--max-model-len 1048576: 1M tokenlık pencere; VRAM için düşürebilirsiniz.
--enable-prefix-caching: Tekrarlayan öneklerde hızlandırma sağlar.
--dtype auto: FP8 karma hassasiyeti için.

Açılan sunucu OpenAI uyumlu istemcilerle http://localhost:8000/v1 üzerinden kullanılabilir.

Adım 4: V4-Pro'yu vLLM ile Sunmak

V4-Pro için daha fazla paralellik gerekir:

vllm serve deepseek-ai/DeepSeek-V4-Pro \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2 \
  --max-model-len 524288 \
  --enable-prefix-caching \
  --port 8000

Bağlam uzunluğunu VRAM'e göre ayarlayın. Paralellik parametreleri küme/çoklu GPU için optimize edilmiştir.

Adım 5: SGLang ile Sunmak (Araç Kullanımı için Alternatif)

Kurulum ve sunucu başlatma:

pip install "sglang[all]>=0.4.0"

python -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V4-Flash \
  --tp 2 \
  --context-length 1048576 \
  --port 30000

SGLang, http://localhost:30000/v1 adresinde OpenAI uyumlu API sunar. Daha iyi fonksiyon çağrısı ve JSON çıktısı için lang DSL'si kullanılabilir.

Adım 6: Tek GPU’da Çalıştırmak için Niceleme

INT4 quantization ile V4-Flash, tek 80GB kartta küçük bir kalite kaybıyla çalışır.

AWQ (Önerilir)

pip install autoawq

python -c "
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer

model_path = './models/deepseek-v4-flash'
out_path = './models/deepseek-v4-flash-awq'
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
model.quantize(tokenizer, quant_config={'w_bit': 4, 'q_group_size': 128})
model.save_quantized(out_path)
tokenizer.save_pretrained(out_path)
"

GPTQ

pip install auto-gptq
# GPTQ quantization için AWQ ile benzer talimatları takip edebilirsiniz.

Niceleme sonrası vLLM ile başlatırken --quantization awq veya --quantization gptq parametresini ekleyin.

Adım 7: Apidog ile Test Etme

Üretim trafiği göndermeden önce yerel sunucunuzu Apidog ile test edin.

Apidog'u indirin.
http://localhost:8000/v1/chat/completions adresine yönlendirilmiş bir koleksiyon oluşturun.
Barındırılan API'ye gönderdiğiniz aynı test isteklerini kullanın, yanıtları karşılaştırın.
KV önbelleğini test etmek için 500K tokenlık uzun bir bağlam gönderin.
Araç çağırma akışını baştan sona test edin.

Barındırılan DeepSeek V4 API koleksiyonu temel URL değişikliğiyle lokal sunucuda aynen çalışır.

Gözlemlenebilirlik ve İzleme

Başlangıçtan itibaren şu metrikleri izleyin:

Saniye başına token (input/output): vLLM /metrics endpointinde Prometheus formatında sunar.
GPU kullanımı: nvidia-smi veya DCGM ile kontrol edin. <70% ise batch size'ı artırın.
KV cache isabet oranı: --enable-prefix-caching ile ölçülür, düşüş varsa promptlarda değişiklik olabilir.
İstek gecikmeleri (p50/p95/p99): Yüksek p99, darboğaz işareti olabilir.

Tüm metrikleri Grafana veya mevcut izleme altyapınıza entegre edin.

V4 Temel Checkpointlerde İnce Ayar

Checkpointler üzerinden SFT ve LoRA ile ince ayar yapmak için standart pipeline:

pip install "torch>=2.6" transformers accelerate peft trl

# V4-Flash-Base üzerinde LoRA ile SFT
python -m trl sft \
  --model_name_or_path deepseek-ai/DeepSeek-V4-Flash-Base \
  --dataset_name your-org/your-sft-set \
  --output_dir ./models/v4-flash-custom \
  --per_device_train_batch_size 1 \
  --gradient_accumulation_steps 16 \
  --learning_rate 2e-5 \
  --bf16 true \
  --use_peft true \
  --lora_r 64 \
  --lora_alpha 128

V4-Pro üzerinde tam parametre ince ayarı büyük donanım gerektirir. Çoğu ekip için LoRA adaptörleri pratik bir çözümdür.

Yaygın Tuzaklar

Başlangıçta OOM: --max-model-len VRAM'i aşıyorsa veya --tensor-parallel-size düşükse; bağlamı azaltın veya paralelliği artırın.
Yavaş ilk istek: vLLM ilk istekte derleme yapar; test isteğiyle ısıtın.
Araç kullanımı hataları: DeepSeek kodlama şeması OpenAI'den farklı olabilir; uygun SDK sürümünü kullandığınızdan emin olun.
FP8 hataları (eski kartlar): A100 FP8 desteklemez; BF16 kullanın ve 2x VRAM bekleyin.

Kendi Kendine Barındırma Ne Zaman Kârlı?

Barındırılan DeepSeek V4 fiyatlandırması baz alınarak:

V4-Flash (ayda 200B giriş + 20B çıkış token): API'de ~33.6K$; 8 × H100 sunucu kirası ~20K$, self-hosted %40 avantajlı.
V4-Pro (ayda 500B giriş + 50B çıkış): API'de ~1.04M$; 16 × H100 cluster kirası ~35K$, self-hosted %95 avantajlı.

V4-Flash için başabaş noktası aylık ~100B token; bunun altında barındırılan API daha uygun.

SSS

V4-Flash'i tek bir A100'de çalıştırabilir miyim?

Yoğun quantization ve kısa bağlamda evet, ama yavaş olacaktır (INT4 ile A100 80GB'da 5-15 token/sn).

V4, LoRA ince ayarını destekliyor mu?

Evet, temel checkpointleri ile TRL veya Axolotl pipeline'larını kullanabilirsiniz.

Yerel sunucu OpenAI uyumlu mu?

Evet, vLLM ve SGLang /v1/chat/completions ve /v1/completions endpointleriyle uyumlu. Barındırılan API kılavuzu localhost'a doğrudan uygulanabilir.

Yerel olarak thinking mode nasıl etkinleştirilir?

İstek gövdesine thinking_mode: "thinking" veya "thinking_max" ekleyin.

Yerel V4 sunucusundan stream yapılabilir mi?

Evet, stream: true ile OpenAI API'sinde olduğu gibi kullanabilirsiniz.

Donanım satın almadan önce deneme yapmak için en ucuz yol nedir?

RunPod veya Lambda'dan saatlik H100 kiralayıp V4-Flash'i INT4 modunda deneyin; 10-30$'lık bir test ile hızlıca karar verebilirsiniz.

DeepSeek V4 API Fiyatları

Tobias Hoffmann — Fri, 24 Apr 2026 04:30:26 +0000

DeepSeek, modellerin piyasaya sürüldüğü gün olan 23 Nisan 2026'da V4 fiyatlandırmasını duyurdu ve bu fiyatlar, ileri seviye yapay zeka için maliyet tabanını yeniden tanımladı. V4-Flash modeli, milyon giriş token başına 0,14 ABD doları ve milyon çıkış token başına 0,28 ABD doları ücretlendirilirken; V4-Pro modeli ise milyon giriş için 1,74 ABD doları ve çıkış için 3,48 ABD doları olarak ücretlendirilir. Her iki model de 1M token bağlam penceresi ve 384K'ya kadar çıkış tokenı sunar. Ayrıca, tekrarlanan istemlerde giriş maliyetini %80-%90 oranında azaltan otomatik önbellek isabet indirimi bulunur.

Apidog'u hemen deneyin

Bu rehberde; tam fiyat tablosunu, bağlam önbelleklemenin gerçek çağrı başına maliyeti nasıl düşürdüğünü, GPT-5.5 ve Claude Opus ile doğrudan kıyaslamayı ve Apidog ile harcamayı öngörülebilir tutmanın dört yolunu bulacaksınız.

Ürüne genel bakış için, DeepSeek V4 nedir yazısına göz atın. Geliştirici kılavuzu için, DeepSeek V4 API nasıl kullanılır makalesini inceleyin. Sıfır maliyetli yollar için, DeepSeek V4 ücretsiz nasıl kullanılır başlıklı yazıyı okuyun.

ÖZET

V4-Flash: $0,14 / M giriş (önbellek ıskası), $0,028 / M giriş (önbellek isabeti), $0,28 / M çıkış.
V4-Pro: $1,74 / M giriş (önbellek ıskası), $0,145 / M giriş (önbellek isabeti), $3,48 / M çıkış.
Bağlam penceresi: Her iki varyantta da 1M token giriş, 384K token çıkış.
Önbellek isabeti indirimi: Flash için yaklaşık %80, Pro için yaklaşık %92 indirim.
deepseek-chat ve deepseek-reasoner modelleri 24 Temmuz 2026'da kullanımdan kaldırılacak; faturalandırma V4-Flash üzerinden yapılacak.
V4-Pro, girişte GPT-5.5'ten yaklaşık 2,9 kat, çıkışta ise 8,6 kat daha ucuz.

Tam fiyat listesi

Model	Giriş (önbellek ıskası)	Giriş (önbellek isabeti)	Çıkış	Bağlam
`deepseek-v4-flash`	$0.14 / M	$0.028 / M	$0.28 / M	1M / 384K
`deepseek-v4-pro`	$1.74 / M	$0.145 / M	$3.48 / M	1M / 384K
`deepseek-chat` (Kaldırılıyor)	V4-Flash Düşünme Dışı	—	—	—
`deepseek-reasoner` (Kaldırılıyor)	V4-Flash Düşünme	—	—	—

Önemli detaylar:

Düşünme ve düşünme dışı modda fiyatlar aynıdır; model kimliği oranı belirler.
Önbellek isabet fiyatlandırması otomatik ve kullanıcı müdahalesi gerektirmez. Önekler en az 1.024 token olmalı ve tam eşleşmeli.
Eski deepseek-chat ve deepseek-reasoner kimlikleri artık V4-Flash olarak faturalandırılır, 24 Temmuz 2026 sonrası tamamen kaldırılacak.

Basit Bağlam Önbellekleme

Önbellekleme, DeepSeek V4'te önemli bir maliyet avantajı sağlar. Özellikle tekrarlayan uzun sistem istemleri, ajan araç şemaları ve RAG bağlamı ile çalışıyorsanız, tekrar eden önekler sayesinde sonraki çağrılarda giriş token maliyeti ciddi oranda düşer.

Pratik Örnek:

20.000 tokenlık sabit sistem istemi olan bir ajanınız var, ardından her biri 200 token olan 100 kullanıcı sorusu soruyorsunuz.

Önbellekleme Olmadan:

Giriş: 100 çağrı × 20.200 token × $1,74 / M = $3,52
Çıkış: 100 çağrı × 500 token × $3,48 / M = $0,17
Toplam: $3,69

Önbellekleme ile (ilk çağrı ıskası, sonraki 99 isabet):

İlk çağrı girişi: 20.200 × $1,74 / M = $0,035
99 önbellek isabetli önek: 99 × 20.000 × $0,145 / M = $0,287
99 kullanıcı dönüşü (ıskası): 99 × 200 × $1,74 / M = $0,034
Çıkış: 100 × 500 × $3,48 / M = $0,174
Toplam: $0,53

Yani, aynı iş yükünde yaklaşık 7 kat daha ucuz. V4-Flash'ta bu etki daha da büyüktür.

GPT-5.5 ve Claude ile Karşılaştırma

Aşağıdaki tablo, giriş/çıkış başına maliyetleri ve bağlam limitlerini pratik olarak karşılaştırır:

Model	Giriş (standart)	Giriş (önbellekli)	Çıkış	Bağlam
DeepSeek V4-Flash	$0.14 / M	$0.028 / M	$0.28 / M	1M
DeepSeek V4-Pro	$1.74 / M	$0.145 / M	$3.48 / M	1M
GPT-5.5	$5 / M	$1.25 / M	$30 / M	1M
GPT-5.5 Pro	$30 / M	—	$180 / M	1M
Claude Opus 4.6	$15 / M	$1.50 / M	$75 / M	200K

Yorumlar:

V4-Pro, çıkış tokenında GPT-5.5'ten 8,6 kat, Claude Opus 4.6'dan 21 kat daha ucuzdur.
Önbellekli girişte, V4-Pro hem GPT-5.5 hem de Claude karşısında yaklaşık 10 kat daha ucuzdur.
Performans olarak V4-Pro, LiveCodeBench ve Codeforces'ta GPT-5.5 seviyesinde veya üzerinde; maliyeti ise çok daha düşük. Detaylı kıyas için DeepSeek V4 nedir yazısına bakın.

Not: Bazı senaryolarda Claude veya Gemini modelleri uzun bağlamda veya belirli testlerde daha iyi olabilir, fakat maliyet/performans oranı çoğu iş yükünde DeepSeek lehine.

Yaygın İş Yükleri için Maliyet Modellemesi

Aşağıda üretimde sık karşılaşılan 4 iş yükü ve V4-Pro için maliyetleri yer alıyor (önbellek ıskası tabanlı):

1. Ajanlı Kodlama Döngüsü (50K bağlam, 2K çıkış, görev başına 20 çağrı)

Giriş: 50.000 × 20 × $1,74 / M = $1,74
Çıkış: 2.000 × 20 × $3,48 / M = $0,14
Görev başına toplam: ~$1,88

GPT-5.5 ile aynı iş yükü ~$6,20

2. Uzun Belge Soru-Cevap (500K bağlam, 1K çıkış)

Giriş: 500.000 × $1,74 / M = $0,87
Çıkış: 1.000 × $3,48 / M = $0,003
Çağrı başına toplam: ~$0,87

GPT-5.5 ile aynı iş yükü ~$2,53

3. Yüksek Hacimli Sınıflandırma (2K bağlam, 200 çıkış, 10.000 çağrı)

Bu senaryoda V4-Flash daha uygun.

Giriş: 2.000 × 10.000 × $0,14 / M = $2,80
Çıkış: 200 × 10.000 × $0,28 / M = $0,56
Toplam: ~$3,36

GPT-5.5 ile aynı iş yükü ~$110

4. Tekrarlanan İstemli Sohbet Robotu (10K sistem istemi, 500 kullanıcı tokenı, 1K çıkış, 1.000 oturum)

İlk çağrı girişi: 10.500 × $1,74 / M = $0,018
Önbellek isabetli giriş: 999 × 10.000 × $0,145 / M = $1,45
Kullanıcı dönüşleri: 999 × 500 × $1,74 / M = $0,87
Çıkış: 1.000 × 1.000 × $3,48 / M = $3,48
Toplam: ~$5,82

GPT-5.5 ile aynı iş yükünde ~$26,35

Dikkat Edilmesi Gereken Gizli Maliyetler

Fiyat tablosu tek başına yeterli değildir; aşağıdaki noktalar ilk aylarda faturada sürpriz yaratabilir:

Düşünme modu token enflasyonu: thinking_max, aynı istemde non-thinkinge göre 3-10 kat fazla çıkış tokenı üretir. Token kullanımı ciddi artar. thinking_max modunu isteğe bağlı olarak kullanın ve izleyin.
Sessiz bağlam büyümesi: Ajan döngülerinde tüm konuşmayı tekrar tekrar bağlama eklemeyin. Çok hızlı büyür. Kısaltma ve özetlemeyle sınırlandırın.
Yeniden deneme fırtınaları: Yanlış yapılandırılmış döngülerde, tekrar tekrar başarısız istekler faturayı hızla artırır. Üstel geri çekilme ve istek başına sabit retry limiti ekleyin.
Geliştirme döngüsü: curl ile elle deneme yapmak her seferinde tüm bağlamı yeniden çalıştırır. Apidog ile değişken ikamesi ve ücretsiz denemelerle bu maliyetleri minimize edin.

Apidog'da Maliyeti Takip Etme

Maliyetleri sürekli kontrol etmek için pratik bir iş akışı:

Apidog'u indirin ve DEEPSEEK_API_KEY'i ortam değişkeni olarak tanımlayın.
https://api.deepseek.com/v1/chat/completions adresine tek bir POST isteği kaydedin.
Yanıt panelinde usage.prompt_tokens, usage.completion_tokens ve usage.reasoning_tokens değerlerini sabitleyin. Her çağrıda, çıktıyla birlikte maliyet analizi anında görünür.
model ve thinking_mode parametrelerini değiştirerek V4-Flash/V4-Pro ve Düşünme-Dışı/Düşünme-Max A/B testi yapın.
GPT-5.5 için aynı koleksiyonu oluşturun (detaylar için GPT-5.5 API rehberi). Böylece iki sağlayıcıda da maliyetleri tek pencerede karşılaştırabilirsiniz.

Bu süreç, ay sonunda ortaya çıkabilecek maliyet sürprizlerinin %80'ini önden görmenizi sağlar.

Harcamayı Öngörülebilir Tutan Dört Kural

Varsayılan olarak V4-Flash kullanın. Yalnızca kalite farkı gelir etkisi yaratıyorsa V4-Pro'ya geçin.
Varsayılan olarak Düşünme-Dışı modunu seçin. Zor görevlerde Düşünme-Yüksek; kritik işlerde Düşünme-Maks modunu kullanın.
max_tokens değerini sınırlayın. 384K sınırı bir güvenlik önlemidir, çoğu üretim çıktısı 2K'yı geçmez.
Kullanım telemetrisi gönderin. Her çağrıda prompt_tokens, completion_tokens, reasoning_tokens değerlerini kaydedin ve özellikle reasoning token artışlarında otomatik uyarı verin.

Sıkça Sorulan Sorular

Ücretsiz bir katman var mı?

API'da ücretsiz katman yok; bazı yeni hesaplara sınırlı deneme kredisi gelebilir. API dışındaki ücretsiz yollar için DeepSeek V4'ü ücretsiz nasıl kullanacağınızı inceleyin.

Önbellek isabeti fiyatlandırması nasıl işler?

Aynı hesapta tekrarlanan 1.024+ token önekler otomatik olarak önbellekli fiyatla faturalandırılır. İlk çağrı tam oranı, takip edenler indirimli oranı öder.

Düşünme modları daha mı pahalı?

Token başına oran sabit; ancak düşünme modlarında daha fazla token kullanılır. Gerçek maliyeti ölçmek için usage.reasoning_tokens'ı izleyin.

Fiyatlar sabit mi?

DeepSeek fiyatları zaman zaman günceller. Güncel oranlar için canlı fiyatlandırma sayfasına bakın.

V4-Pro ve V4-Flash aynı çıkış oranına mı sahip?

Hayır; V4-Pro çıkışı $3,48 / M, V4-Flash çıkışı $0,28 / M. Bu yüzden çoğu iş için V4-Flash tercih edilir.

Anthropic formatındaki uç nokta fiyatı değiştiriyor mu?

Hayır; https://api.deepseek.com/anthropic OpenAI formatındaki uç nokta ile aynı fiyatı kullanır.

Uygulamada yukarıdaki adımları izleyerek maliyetleri önceden tahmin edebilir, beklenmedik faturaların önüne geçebilirsiniz. Geliştirici iş akışınızda Apidog ile entegrasyon ve otomatik telemetriyi ihmal etmeyin.

DeepSeek V4 API Nasıl Kullanılır?

Tobias Hoffmann — Fri, 24 Apr 2026 04:29:58 +0000

DeepSeek V4, ilk günden itibaren canlı API ile kullanılabilir durumda. Model kimlikleri deepseek-v4-pro ve deepseek-v4-flash ile OpenAI uyumlu uç noktada (temel URL: https://api.deepseek.com) çalışır. Yani, halihazırda OpenAI gibi bir istemci kullanıyorsanız, sadece temel URL'yi değiştirerek DeepSeek V4'e geçebilirsiniz.

Apidog'u bugün deneyin

Bu teknik rehberde; kimlik doğrulama, önemli parametreler, Python ve Node istemci örnekleri, düşünme modu kullanımı, araç çağrısı, akışlı yanıtlar ve maliyet kontrolünü Apidog tabanlı bir iş akışı ile adım adım öğreneceksiniz.

Ürün genel bakışı için DeepSeek V4 nedir ve ücretsiz kullanım için DeepSeek V4'ü ücretsiz nasıl kullanırsınız bağlantılarına göz atabilirsiniz.

TL;DR

DeepSeek V4, https://api.deepseek.com/v1/chat/completions (OpenAI uyumlu) ve https://api.deepseek.com/anthropic (Anthropic uyumlu) uç noktalar ile sunulur.
Model Kimlikleri: deepseek-v4-pro (1.6T toplam, 49B aktif) ve deepseek-v4-flash (284B toplam, 13B aktif).
Her iki model de 1M token bağlamı ve üç düşünme modunu destekler: non-thinking, thinking, thinking_max.
DeepSeek önerisi: temperature=1.0, top_p=1.0 — GPT-5.5/Claude varsayılanlarını kullanmayın.
Eski deepseek-chat ve deepseek-reasoner kimlikleri 24 Temmuz 2026'da kaldırılacak; geçişinizi bu tarihten önce yapın.
İstekleri kolayca tekrarlamak, düşünme modlarını karşılaştırmak ve API anahtarınızı terminal geçmişinizden uzak tutmak için Apidog'u indirin.

Önkoşullar

İlk isteğiniz için aşağıdaki adımları tamamlayın:

En az 2$ bakiye yüklü, platform.deepseek.com üzerinden oluşturulmuş bir DeepSeek geliştirici hesabı.
Her proje için ayrı API anahtarı (proje kapsamlı anahtarlar önerilir).
OpenAI uyumlu temel URL'yi destekleyen bir SDK. Python için openai>=1.30.0, Node için openai@4.x doğrudan çalışır.
Tekrarlanabilir API çağrıları için bir istemci. Curl ilk test için yeterli; seri ve karşılaştırmalı çağrılar için Apidog'u tercih edin.

API anahtarını ortam değişkeni olarak kaydedin:

export DEEPSEEK_API_KEY="sk-..."

Uç Nokta ve Kimlik Doğrulama

İki temel uç nokta:

POST https://api.deepseek.com/v1/chat/completions    # OpenAI formatı
POST https://api.deepseek.com/anthropic/v1/messages  # Anthropic formatı

Çoğu senaryo için OpenAI uyumlu formatı seçin. Kimlik doğrulama için Authorization başlığına Bearer token ekleyin.

Örnek cURL isteği:

curl https://api.deepseek.com/v1/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "messages": [
      {"role": "user", "content": "MoE yönlendirmesini iki cümlede açıklayın."}
    ]
  }'

Başarılı yanıt; choices dizisi, token kullanımı (usage bloğu) ve izleme için bir id içerir. Hatalar, OpenAI standardında döner (error.code, error.message).

İstek Parametreleri

Aşağıdaki tablo, DeepSeek V4'te kullanabileceğiniz başlıca parametreleri özetler:

Parametre	Tür	Değerler	Notlar
`model`	string	`deepseek-v4-pro`, `deepseek-v4-flash`	Zorunlu.
`messages`	array	rol/içerik çiftleri	Zorunlu. OpenAI ile aynı şema.
`thinking_mode`	string	`non-thinking`, `thinking`, `thinking_max`	Varsayılan `non-thinking`.
`temperature`	float	0 ila 2	DeepSeek 1.0 öneriyor.
`top_p`	float	0 ila 1	DeepSeek 1.0 öneriyor.
`max_tokens`	int	1 ila 131,072	Çıkış uzunluğunu sınırlar.
`stream`	bool	doğru veya yanlış	SSE akışını etkinleştirir.
`tools`	array	OpenAI araç belirtimi	Fonksiyon çağrısı için.
`tool_choice`	string veya object	`auto`, `required`, `none`, veya belirli araç	Araç kullanımını kontrol eder.
`response_format`	object	`{"type": "json_object"}`	JSON modlu çıktı.
`seed`	int	herhangi bir int	Tekrarlanabilirlik için.
`presence_penalty`	float	-2 ila 2	Tekrarlanan konuları cezalandırır.
`frequency_penalty`	float	-2 ila 2	Tekrarlanan token'ları cezalandırır.

thinking_mode: Maliyet üzerinde en büyük etkiye sahip parametredir.
- non-thinking: Hızlı, en düşük maliyetli mod.
- thinking: Doğruluk için ek token harcar.
- thinking_max: Maksimum doğruluk, en yüksek maliyet.
temperature ve top_p: DeepSeek'in önerdiği şekilde 1.0 kullanın.

Python İstemcisi

openai SDK ile temel URL'yi değiştirerek doğrudan kullanabilirsiniz:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/v1",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "Sadece kodla yanıt ver."},
        {"role": "user", "content": "Olayları debounc eden bir Rust fonksiyonu yaz."},
    ],
    extra_body={"thinking_mode": "thinking"},
    temperature=1.0,
    top_p=1.0,
    max_tokens=2048,
)

choice = response.choices[0]
print("İçerik:", choice.message.content)
print("Akıl yürütme tokenları:", response.usage.reasoning_tokens)
print("Toplam tokenlar:", response.usage.total_tokens)

extra_body, DeepSeek'e özgü parametreleri OpenAI SDK üzerinden iletmek için kullanılır.

Node İstemcisi

Node ekosisteminde de benzer yapı ile ilerleyebilirsiniz:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek-v4-flash",
  messages: [
    { role: "user", content: "Muon optimizatörünü basit İngilizce ile açıkla." },
  ],
  thinking_mode: "thinking",
  temperature: 1.0,
  top_p: 1.0,
});

console.log(response.choices[0].message.content);
console.log("Kullanım:", response.usage);

Node SDK, bilinmeyen alanları üst düzeyden kabul eder; thinking_mode doğrudan geçilebilir.

Yanıtların Akışı

Akışlı yanıt almak için stream: true ayarını kullanın ve gelen SSE parçalarını işleyin:

stream = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "MoE hakkında 300 kelimelik bir deneme akışla gönder."}],
    stream=True,
    extra_body={"thinking_mode": "non-thinking"},
)

for chunk in stream:
    delta = chunk.choices[0].delta.content or ""
    print(delta, end="", flush=True)

Düşünme modu açıkken, akıl yürütme izleri delta.reasoning_content ile ayrı olarak akışa alınır. Bunları arayüzde gösterebilir veya yoksayabilirsiniz.

Araç Çağrısı

V4, OpenAI araç (function calling) şemasını destekler. tools dizisinde fonksiyon tanımlayıp otomatik çağrıya açabilirsiniz.

tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Bir şehir için mevcut hava durumunu döndürür.",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string"},
                "unit": {"type": "string", "enum": ["c", "f"]},
            },
            "required": ["city"],
        },
    },
}]

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "Lagos'ta hava durumu Celsius cinsinden nedir?"}],
    tools=tools,
    tool_choice="auto",
    extra_body={"thinking_mode": "thinking"},
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name, tool_call.function.arguments)

Fonksiyonu çağırıp sonucu API'ye tekrar gönderebilir, OpenAI pattern'ı ile aynı döngüyü kurabilirsiniz.

JSON Modu

Yapılandırılmış JSON çıktı almak için aşağıdaki gibi kullanın:

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "Tek bir JSON nesnesiyle yanıt ver."},
        {"role": "user", "content": "Bu sürüm notunu {başlık, tarih, madde işaretleri} olarak özetle: ..."},
    ],
    response_format={"type": "json_object"},
    extra_body={"thinking_mode": "non-thinking"},
)

JSON modunda çıktı her zaman geçerli JSON olur. Şema doğrulama gerekiyorsa, istemci tarafında Pydantic veya Zod vb. ile eşleştirin.

Apidog'da Koleksiyon Oluşturun

Terminalden istek göndermek yerine, iş akışınızı görselleştirmek ve karşılaştırmak için şu adımları izleyin:

Apidog'u indirin ve yeni bir proje açın.
{{DEEPSEEK_API_KEY}} için gizli bir ortam değişkeni ekleyin.
Authorization: Bearer {{DEEPSEEK_API_KEY}} başlığı ile {{BASE_URL}}/chat/completions'a POST isteği oluşturun.
model ve thinking_mode parametrelerini değiştirerek varyantlar arasında A/B testi yapın.
Her çağrıda usage.reasoning_tokens değerini kontrol ederek fazladan düşünme moduna ödeme yapmadığınızdan emin olun.

Ayrıca, GPT-5.5 API koleksiyonu'nu kopyalayıp temel URL ve model kimliklerini değiştirerek iki platformu yan yana test edebilirsiniz.

Hata Yönetimi

DeepSeek, OpenAI hata zarfını takip eder. Sık karşılaşılan hata kodları ve çözümleri:

Kod	Anlamı	Çözüm
400	Hatalı istek	JSON şemasını, özellikle `messages` ve `tools`'u kontrol edin.
401	Geçersiz anahtar	platform.deepseek.com adresinde yeniden oluşturun.
402	Yetersiz bakiye	Hesaba para yükleyin.
403	Modele izin verilmiyor	Anahtarın kapsamını ve model kimliğinin yazımını kontrol edin.
422	Parametre aralık dışında	`max_tokens` veya `thinking_mode` muhtemelen uyuşmuyor.
429	Oran sınırlaması	Geri çekilin, ardından üstel gecikme ile tekrar deneyin.
500	Sunucu hatası	Bir kez tekrar deneyin; tekrar ederse, durum sayfasını kontrol edin.
503	Aşırı yüklenmiş	V4-Flash'e geri dönün veya 30 saniye içinde tekrar deneyin.

429 ve 5xx kodları için çağrılarınızı üstel geri çekilme ile sarmalayın. 4xx kodlarını otomatik yeniden denemeyin.

Maliyet Kontrol Desenleri

Maliyetleri yönetmek için şu pratik desenleri uygulayın:

Varsayılan olarak V4-Flash kullanın. Yüksek kalite gerektiren istemler için sadece V4-Pro'ya geçin.
thinking_max'i bayrak arkasına alın. En pahalı moddur; sadece gerekliyse açın.
max_tokens'ı sınırlandırın. Çoğu çıktı için 2.000 token yeterli.
Her çağrıda usage'ı loglayın. Token tüketimini gözlemleyerek beklenmeyen maliyet artışlarını yakalayın.

Eski DeepSeek Modellerinden Geçiş

deepseek-chat ve deepseek-reasoner kimlikleri 24 Temmuz 2026'da kaldırılacak. Geçiş yapmak için sadece model adını değiştirin:

-  model="deepseek-chat"
+  model="deepseek-v4-pro"

Üretim geçişinden önce Apidog ile yan yana A/B testi yaparak kalite farkını gözlemleyin.

SSS

DeepSeek V4 API üretime hazır mı?

Evet. API 23 Nisan 2026'da ağırlıklarla birlikte açıldı; altyapı olgun.

V4, Anthropic formatını destekliyor mu?

Evet, https://api.deepseek.com/anthropic/v1/messages ile kullanılabilir.

Bağlam penceresi nedir?

Her iki modelde de 1 milyon token. Think Max için minimum öneri 384K token.

Girdi tokenlarını nasıl sayarım?

Yaklaşık değer için OpenAI tokenlaştırıcı; tam sayı için yanıtın usage bloğu.

API ile ince ayar yapılabiliyor mu?

Lansmanda hayır; sadece kendi barındırılan checkpoint'ler üzerinden (Hugging Face).

API ücretsiz mi?

Ücretsiz katman yok, ancak yeni hesaplar bazen deneme kredisi alabilir.

DeepSeek V4 API Ücretsiz Nasıl Kullanılır?

Tobias Hoffmann — Fri, 24 Apr 2026 04:29:19 +0000

DeepSeek V4, 23 Nisan 2026'da lansman yaptı ve API fiyatları çoğu ekibin ücretsiz katman arayışını gereksiz kılacak kadar düştü. Ancak, kart bilgisi vermeden V4'ü programatik olarak çağırmak isteyen geliştiriciler için tamamen ücretsiz yollar mevcut. Agregatör gateway’ler :free varyantlarını sunar, Hugging Face paylaşılan çıkarım uç noktası sağlar ve resmi API yeni hesaplara deneme kredisi tanımlar. Bu üç yöntemi birleştirip Apidog üzerinde bir geri dönüş zinciri kurarak hiç harcama yapmadan V4 tabanlı bir ürün prototipi çıkarabilirsiniz.

Apidog'u bugün deneyin

Bu kılavuz, DeepSeek V4 API’ye özel ücretsiz yolları kapsar. Web sohbeti ve kendi kendine barındırma dahil daha geniş kapsam için DeepSeek V4'ü ücretsiz olarak nasıl kullanabilirsiniz başlığına bakın. Ücretli adım adım kurulum için DeepSeek V4 API'sini nasıl kullanabilirsiniz rehberini inceleyin. Ürünün genel görünümü için DeepSeek V4 nedir yazısına göz atın.

Özet (TL;DR)

OpenRouter ücretsiz katmanı — deepseek/deepseek-v4-flash:free ve bazen deepseek-v4-pro:free. OpenAI uyumlu, anahtar başına günde birkaç yüz istek.
Hugging Face Çıkarım Sağlayıcıları — https://router.huggingface.co/hf-inference adresinde ücretsiz, oran sınırlamalı, prototipleme için ideal.
Chutes ücretsiz katmanı — Lansmandan sonraki ilk hafta sık sık ücretsiz DeepSeek uç noktaları sunan topluluk GPU ağı.
DeepSeek deneme kredisi — platform.deepseek.com adresindeki yeni hesaplara bazen başlangıç bakiyesi tanımlanıyor.
Kendi GPU’nuzda kendi kendine barındırılan V4-Flash da lisans düzeyinde ücretsizdir; detaylar için DeepSeek V4'ü yerel olarak nasıl çalıştırabilirsiniz başlığını inceleyin.
Apidog ile geri dönüş zinciri kurun, istek yapısı tüm sağlayıcılar için sabit kalsın.

Neden ücretsiz API yolu mevcut?

DeepSeek’in ücretli tarifeleri zaten ucuz, peki neden ücretsizini arayalım? Üç sebep:

Kart öncesi prototipleme: Ödeme eklemeden, tedarik veya hızlı PoC için V4’ü koddan çağırmak isteyebilirsiniz.
Öğrenci, araştırma ve açık kaynak: Bütçesiz küçük projeler yine de kaliteli modele ihtiyaç duyar.
Sağlayıcı karşılaştırması: Üç ücretsiz endpoint’te aynı prompt’u çalıştırmak, pratikteki gecikme/kalite/fark farklarını görmenizi sağlar.

Bunlar ilginizi çekiyorsa, bu rehber tam size göre. Üretime göndereceğiniz bir ürün kuruyorsanız, ücretli API rehberine geçin; resmi DeepSeek API’deki 2$ minimum yükleme, oran sınırlamalarıyla uğraşmaktan daha avantajlıdır.

Yol 1: OpenRouter ücretsiz katmanı

OpenRouter, OpenAI uyumlu API arkasında öncü modelleri toplayan bir ağ geçididir. DeepSeek’in V3, V3.1, V3.2 ve şimdi V4 sürümlerinde güvenilir şekilde ücretsiz varyantlar açıyor.

Kurulum

openrouter.ai adresine kaydolun.
Ayarlar → Anahtarlar altında API anahtarı oluşturun.
Model kataloğunda :free soneki olan girişleri (ör. deepseek/deepseek-v4-flash:free) bulun.
Herhangi bir OpenAI uyumlu SDK ile uç noktayı çağırın.

from openai import OpenAI

client = OpenAI(
    api_key=OPENROUTER_API_KEY,
    base_url="https://openrouter.ai/api/v1",
)

response = client.chat.completions.create(
    model="deepseek/deepseek-v4-flash:free",
    messages=[{"role": "user", "content": "Refactor this Go function to use channels."}],
)

print(response.choices[0].message.content)

Sınırlar

OpenRouter’daki ücretsiz istekler, yoğunlukta ücretli trafiğin arkasında sıraya girer. Genelde anahtar başına günde 50-200 istek limiti, sıkı eşzamanlılık ve haber verilmeksizin varyant değişimi olabilir. Yalnızca prototipleme amaçlıdır.

Node.js Sürümü

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENROUTER_API_KEY,
  baseURL: "https://openrouter.ai/api/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek/deepseek-v4-flash:free",
  messages: [{ role: "user", content: "Explain MoE routing like I'm 12." }],
});

console.log(response.choices[0].message.content);

Yol 2: Hugging Face Çıkarım Sağlayıcıları

Hugging Face, V4 kontrol noktalarını piyasaya sürüldükten kısa süre sonra paylaşılan bir çıkarım endpoint’i olarak sunuyor. Bir HF token’ı ile çağırmak ücretsiz, ancak en sıkı oran sınırlarına sahip.

import os
from huggingface_hub import InferenceClient

client = InferenceClient(
    model="deepseek-ai/DeepSeek-V4-Flash",
    token=os.environ["HF_TOKEN"],
)

response = client.chat_completion(
    messages=[
        {"role": "user", "content": "Write a Python decorator that retries with jitter."}
    ],
    max_tokens=512,
)

print(response.choices[0].message.content)

HF token’ı huggingface.co/settings/tokens üzerinden ücretsiz alınabilir. Gecikme ve hız, yük ve token sayısına göre değişir. Daha fazla limite ihtiyacınız varsa, HF Pro veya ücretli DeepSeek API’ye geçin.

Yol 3: Chutes ve topluluk ağ geçitleri

Chutes, genellikle ücretsiz veya çok düşük maliyetli DeepSeek modellerini barındıran merkeziyetsiz bir GPU ağıdır. https://llm.chutes.ai/v1 adresinden OpenAI uyumlu endpoint sunar.

client = OpenAI(
    api_key=CHUTES_API_KEY,
    base_url="https://llm.chutes.ai/v1",
)

response = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V4-Flash",
    messages=[{"role": "user", "content": "Compare CSA and HCA attention in two sentences."}],
)

Kullanılabilirlik ve model kimlikleri değişkenlik gösterir. Bağımlılık kurmadan önce Chutes panelinden mevcut modelleri ve maliyeti kontrol edin.

Yol 4: DeepSeek deneme kredisi

DeepSeek, yeni hesaplara zaman zaman deneme kredisi tanımlar. Miktar ve geçerlilik süresi değişir; genellikle e-posta doğrulamasından sonra hesaba 1$ yüklenir. Kayıt sonrası platform.deepseek.com’daki faturalandırma panelini kontrol edin.

1$ deneme kredisi ile V4-Flash’ta yaklaşık 7 milyon giriş token’ı, V4-Pro’da 570 bin giriş token’ı alırsınız. Yüzlerce prototip çağrısı için yeterlidir.

Apidog'da sağlayıcıdan bağımsız ücretsiz bir zincir oluşturun

Birden fazla ücretsiz yol desteklemek, sağlayıcılar kısıtlandığında sorunsuz çalışan esnek bir prototip sağlar. Adımlar:

Apidog'u indirin ve yeni proje oluşturun.
Dört ortam açın: openrouter, huggingface, chutes, deepseek-trial.
Her ortamda ilgili API anahtarını gizli değişken olarak kaydedin ve BASE_URL’yi ayarlayın.
Parametreli bir model alanı ile {{BASE_URL}}/chat/completions’a POST isteği kaydedin.
Aynı prompt’u tüm sağlayıcılarda tek tıkla çalıştırmak için ortam değiştirin.

Aynı yaklaşımı GPT-5.5 API ücretsiz yolları için de kopyalayıp sağlayıcıları değiştirerek uygulayabilirsiniz.

Koda bir geri dönüş zinciri bağlayın

Bir sağlayıcı kısıtlandığında, otomatik geri dönüş zinciriyle diğerine geçiş yapabilirsiniz. OpenAI SDK’sı ile:

import os
from openai import OpenAI, RateLimitError, APIError

PROVIDERS = [
    {
        "base_url": "https://openrouter.ai/api/v1",
        "api_key": os.environ["OPENROUTER_API_KEY"],
        "model": "deepseek/deepseek-v4-flash:free",
    },
    {
        "base_url": "https://llm.chutes.ai/v1",
        "api_key": os.environ["CHUTES_API_KEY"],
        "model": "deepseek-ai/DeepSeek-V4-Flash",
    },
    {
        "base_url": "https://api.deepseek.com/v1",
        "api_key": os.environ["DEEPSEEK_API_KEY"],
        "model": "deepseek-v4-flash",
    },
]

def call_v4(messages):
    for provider in PROVIDERS:
        try:
            client = OpenAI(
                api_key=provider["api_key"],
                base_url=provider["base_url"],
            )
            return client.chat.completions.create(
                model=provider["model"],
                messages=messages,
            )
        except (RateLimitError, APIError) as e:
            print(f"{provider['base_url']} failed: {e}")
            continue
    raise RuntimeError("all providers exhausted")

Her ücretsiz yolun aslında ne için iyi olduğu

Yol	En iyi olduğu alan	En kötü olduğu alan
OpenRouter ücretsiz	Prototipleme, günlük geliştirme	Sıkı SLA'lar gerektiren işler
HF Çıkarım	Keşif, defterler	Düşük gecikmeli işler
Chutes	Deneysel topluluk çalışması	Uzun vadeli bağımlılıklar
DeepSeek deneme	Tam doğruluk testi	Sürekli üretim
Kendi kendine barındırılan V4-Flash	Uyumluluk gerektiren işler	GPU kapasitesi olmayan ekipler

Önemli kota hesaplaması

Herhangi bir ücretsiz yolu kullanmadan önce, günlük işleme kapasitenizi hesaplayın:

OpenRouter ücretsiz: Anahtar başına günlük ~100 istek, her biri ~50K token. Günde 30-50 geliştirme çağrısı için yeterlidir.
HF Çıkarım ücretsiz: Paylaşılan oran limitleri, toplamda yaklaşık 1K istek/gün. Yük altında yavaşlayabilir.
Chutes: Değişken; en iyi çaba olarak değerlendirin.
DeepSeek deneme (1$): V4-Flash’ta 10K giriş token’ı ile yaklaşık 700 çağrı. Sınırlı ama cömert.
Kendi kendine barındırma: Donanımınıza bağlı. 4 × H100 ile saniyede 50-150 token işleyebilirsiniz.

Daha fazlasına ihtiyacınız varsa, ücretli API’ya geçmek daha mantıklı. V4-Flash’ta 0,14 $/M fiyatla, 2K bağlam ve 500 çıkış token’ı ile 10.000 çağrı yaklaşık 2,80 $’a mal olur. Prototip sonrası ücretli API genellikle daha basit çözüm sunar.

Ücretli API'ye ne zaman geçmeli?

Ücretsiz katmanı aştığınızın 3 pratik göstergesi:

Oran limitleri günde birden fazla kez sizi durduruyor.
Bir iş yükü için birden fazla ücretsiz sağlayıcıyı bir araya getiriyorsunuz.
Testleriniz öngörülebilir gecikme veya SLA gerektiriyor.

platform.deepseek.com adresinde minimum yükleme 2$. Yoğun prototipleme için ücretsiz katmanlarda harcayacağınız zaman, ücretli API’dan daha pahalıya gelebilir. Tam oranlar için DeepSeek V4 fiyatlandırma kılavuzu'na bakın.

SSS

Bu yollar kalıcı olarak ücretsiz mi?

Hayır. Ücretsiz katmanlar değişkendir, prototipleme için uygundur, üretim için değildir.

OpenRouter :free gerçek V4 mü çalıştırıyor?

Evet, ancak sıkı oran limitli paylaşılan altyapı üzerinde. Kalite eşleşir, hız eşleşmez.

Ücretsiz yol çıktısını ürünümde kullanabilir miyim?

Her sağlayıcının koşullarını okuyun. OpenRouter oran sınırı dahilinde ticari kullanıma izin verir. HF Çıkarım ticariye izin verir, sıkı sınır koyar. DeepSeek deneme kredisi ana hükümlere tabidir.

Hangi ücretsiz yolun gecikmesi en iyi?

DeepSeek deneme kredisi; doğrudan üretim altyapısıdır. OpenRouter ikinci sırada. HF Çıkarım ve Chutes değişkendir.

V4’ü ücretsiz olarak kendim barındırabilir miyim?

Lisans MIT, evet. Maliyet donanımdır. Kurulum için DeepSeek V4'ü yerel olarak nasıl çalıştırabilirsiniz başlığına bakın.

Bugün hangi ücretsiz yolu kullandığımı nasıl takip edebilirim?

Apidog ile yanıt görüntüleyicide usage alanını sabitleyin. Çoğu toplayıcıda kullanım panosu mevcuttur.

DeepSeek V4 Kullanımı: Web Sohbet, API ve Self-Hosted Yöntemleri

Tobias Hoffmann — Fri, 24 Apr 2026 04:20:02 +0000

DeepSeek V4, 23 Nisan 2026'da dört kontrol noktası, canlı bir API ve Hugging Face'de MIT lisanslı ağırlıklarla yayınlandı. Bu kombinasyon, onu kullanmanın tek bir "doğru yolu" olmadığı anlamına geliyor; en iyi yol, anında erişim, üretim API çağrıları veya şirket içi dağıtım isteyip istemediğinize bağlıdır. Bu kılavuz, her üçünü de ödünleşimleri, püf noktaları ve yeniden kullanabileceğiniz üretime hazır bir prompt iş akışıyla birlikte anlatmaktadır.

Apidog'u hemen deneyin

Sadece ürün seviyesi genel bir bakış istiyorsanız, önce DeepSeek V4 nedir yazısını okuyun. Sadece API kullanımına ilişkin ayrıntılı bilgi için DeepSeek V4 API kılavuzuna bakın. Sıfır maliyetli yol için DeepSeek V4'ü ücretsiz olarak nasıl kullanacağınıza bakın. Gerçek istekleri test etmeye hazır olduğunuzda Apidog'u edinin ve koleksiyonu önceden oluşturun.

TL;DR

En hızlı yol: chat.deepseek.com. Ücretsiz web sohbeti, varsayılan olarak V4-Pro, üç düşünme modu.
Üretim yolu: https://api.deepseek.com/v1/chat/completions, model ID'leri deepseek-v4-pro veya deepseek-v4-flash ile.
Kendi kendine barındırılan yol: Hugging Face'den ağırlıkları çekin, repodaki /inference komut dosyalarını çalıştırın.
Yönlendirme ve sınıflandırma için Non-Think'i, kod ve analiz için Think High'ı, maliyetten ziyade doğruluk önemli olduğunda ise sadece Think Max'i seçin.
DeepSeek'ten örnekleme önerisi: temperature=1.0, top_p=1.0. Buna tekrar şüpheyle yaklaşmayın.
API istemcisi olarak Apidog'u kullanın; OpenAI uyumlu format, kaydedilen bir isteğin DeepSeek, OpenAI ve Anthropic'te tekrar oynatılması anlamına gelir.

İş Yükünüz İçin Doğru Yolu Seçin

Dört pratik yol var. Her birinin öne çıktığı farklı kullanım alanları mevcut:

Yol	Maliyet	Kurulum süresi	En iyisi
chat.deepseek.com	Ücretsiz	30 saniye	Hızlı testler, geçici işler
DeepSeek API	Token başına ücretlendirme	5 dakika	Üretim, ajanlar, toplu işler
Kendi kendine barındırılan V4-Flash	Yalnızca donanım maliyeti	Birkaç saat	Şirket içi uyumluluk, çevrimdışı çıkarım
Kendi kendine barındırılan V4-Pro	Yalnızca küme maliyeti	Bir gün	Araştırma, özel ince ayarlar
OpenRouter / toplayıcı	Token başına ücretlendirme	2 dakika	Çoklu sağlayıcı yedeklemesi

Yol 1: V4'ü Web Sohbetinde Kullanın

En hızlı başlama yolu resmi sohbet arayüzüdür:

chat.deepseek.com adresine gidin.
E-posta, Google veya WeChat ile oturum açın.
V4-Pro varsayılan modeldir. Üstteki anahtardan Non-Think, Think High ve Think Max modunu seçebilirsiniz.
Prompt'unuzu yazmaya başlayın.

Web sohbeti üzerinden dosya yükleyebilir, web araması yapabilir ve 1M token bağlam desteğinden yararlanabilirsiniz. Hesap bazlı hız limiti uygulanır; yoğun kullanımda yanıtlar yavaşlayabilir fakat genelde bloklanmaz.

Web arayüzü için tipik işler: hata izi teşhisi, uzun PDF özetleme, farklı modellerle prompt karşılaştırması. Kötü kullanım: otomatikleştirilmiş veya tekrar oynatılması gereken işler.

Yol 2: DeepSeek API'sini Kullanın

Üretim ve otomasyon için en pratik yöntem budur. API, OpenAI formatı ile tamamen uyumlu.

API Anahtarı Alın

platform.deepseek.com adresinden kaydolun.
Bir ödeme yöntemi ekleyin (minimum 2 dolar yükleme).
API Anahtarları altında yeni bir anahtar oluşturun ve gizli anahtarı saklayın.

Anahtarı terminal ortamına ekleyin:

export DEEPSEEK_API_KEY="sk-..."

Minimum Uygulanabilir API Çağrısı

curl https://api.deepseek.com/v1/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "messages": [
      {"role": "user", "content": "Bu Python fonksiyonunu eşzamansız olarak yeniden düzenleyin. Sadece kodla yanıtlayın."}
    ],
    "thinking_mode": "thinking"
  }'

Daha uygun maliyetli bir cevap için deepseek-v4-pro yerine deepseek-v4-flash kullanın. Düşünme modunu hız için non-thinking olarak ayarlayın.

Python İstemcisi ile Kullanım

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/v1",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "Sen özlü bir kıdemli mühendissin."},
        {"role": "user", "content": "CSA+HCA hibrit dikkat yığınını açıklayın."},
    ],
    extra_body={"thinking_mode": "thinking_max"},
    temperature=1.0,
    top_p=1.0,
)

print(response.choices[0].message.content)

Node.js İstemcisi ile Kullanım

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.DEEPSEEK_API_KEY,
  baseURL: "https://api.deepseek.com/v1",
});

const response = await client.chat.completions.create({
  model: "deepseek-v4-flash",
  messages: [{ role: "user", content: "Rust'ta bir fizzbuzz yaz." }],
  temperature: 1.0,
  top_p: 1.0,
});

console.log(response.choices[0].message.content);

Tüm endpoint ve parametre detayları ile hata yönetimi için DeepSeek V4 API kılavuzunu inceleyin.

Yol 3: Apidog ile Otomatikleştirin ve Tekrar Oynatın

Curl ile bir-iki deneme kolaydır; ancak tekrar eden denemeler için Apidog ile çok daha verimli çalışırsınız.

Mac, Windows veya Linux için Apidog'u indirin.
Yeni bir API projesi oluşturun, https://api.deepseek.com/v1/chat/completions adresine POST isteği ekleyin.
Authorization: Bearer {{DEEPSEEK_API_KEY}} başlığı ekleyin, anahtarı ortam değişkeni olarak saklayın.
İlk JSON gövdesini yapıştırıp kaydedin. Her değişiklikten sonra tek tıkla tekrar oynatabilirsiniz.
Yanıtları karşılaştırmak için yerleşik viewer'ı kullanın, özellikle Non-Think ve Think Max varyantlarının çıktısını gözlemleyin.

Aynı koleksiyonla OpenAI GPT-5.5, Claude ve DeepSeek V4 isteklerini yan yana test edebilirsiniz. Bu, sağlayıcılar arası A/B testini kolaylaştırır ve faturalama görünürlüğü sağlar. Var olan GPT-5.5 koleksiyonunu temel URL değiştirerek V4 koleksiyonu haline getirmek mümkündür.

Yol 4: V4-Flash'i Kendi Kendine Barındır

Şirket içi uyumluluk, hava boşluğu veya maliyet gerekçeleriyle kendi sunucunuzda çalıştırmak için MIT lisanslı ağırlıkları kullanabilirsiniz.

Donanım Gereksinimleri

V4-Flash (13B aktif, toplam 284B): FP8 için 2-4 H100/H200/MI300X kart, INT4 nicemlemede tek bir 80GB kartta sıkı batch ile çalışır.
V4-Pro (49B aktif, toplam 1.6T): 16-32 H100 gerektirir.

Model Ağırlıklarını İndirin

pip install -U "huggingface_hub[cli]"

huggingface-cli login  # Gerekirse

huggingface-cli download deepseek-ai/DeepSeek-V4-Flash \
  --local-dir ./models/deepseek-v4-flash \
  --local-dir-use-symlinks False

V4-Flash FP8 ~500GB; V4-Pro ise birkaç TB büyüklüğünde olabilir.

Çıkarım Sunucusunu Başlatın

pip install "vllm>=0.9.0"

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 4 \
  --max-model-len 1048576 \
  --dtype auto

vLLM çalıştıktan sonra, OpenAI uyumlu herhangi bir istemciyi http://localhost:8000/v1 adresine yönlendirin. Apidog koleksiyonunu da bu şekilde kullanabilirsiniz.

V4’ü Etkili Yönlendirme (Prompting)

Pratik prompt yazımı için:

Düşünme modunu her zaman açıkça belirtin. thinking_mode parametresini göreve göre ayarlayın.
Sistem mesajlarını sadece kişilik ve ton için kullanın. Görev tanımını kullanıcı mesajında belirtin.
Kod görevlerinde test vaka(ları) ekleyin. Başarısız bir testi ekleyin, modelin daha doğru kod üretme ihtimali artar.

Uzun bağlamlarda, önemli bilgileri prompt'un başı ve sonuna yakın tutmaya çalışın.

Maliyet Kontrolü

Varsayılan olarak V4-Flash kullanın. V4-Pro'ya yalnızca kalite farkı ölçüldüğünde geçin.
Varsayılan olarak Non-Think kullanın. Sadece gerektiğinde Think High veya Think Max’a yükseltin.
max_tokens sınırı belirleyin. Çoğu yanıt için 2.000 token yeterlidir.

Apidog ortam değişkenlerini kullanarak test ve prod anahtarlarını ayırabilirsiniz. Apidog yanıt token sayılarını da gösterir; bu sayede uzun prompt'ları hızlıca tespit edebilirsiniz.

DeepSeek V3 veya Diğer Modellerden Geçiş

deepseek-chat / deepseek-reasoner’dan geçiş: Model ID’sini deepseek-v4-pro veya deepseek-v4-flash ile değiştirin.
OpenAI GPT-5.x'ten geçiş: Temel URL’yi https://api.deepseek.com/v1 olarak değiştirin, model ID’sini güncelleyin.
Anthropic Claude’dan geçiş: https://api.deepseek.com/anthropic endpoint’i veya OpenAI formatını kullanın.

SSS

V4'ü kullanmak için ücretli hesap gerekir mi? Web sohbeti ücretsizdir. API için minimum 2 dolar yükleme gerekir. Ücretsiz kullanım yolları için DeepSeek V4'ü ücretsiz olarak nasıl kullanacağınıza bakın.

Varsayılan olarak hangi varyantı kullanmalıyım? V4-Flash ve Non-Think mod ile başlayın. Kaliteyi ölçüp gerekiyorsa yükseltin.

V4'ü MacBook'ta çalıştırabilir miyim? V4-Flash, 128GB RAM'li M3 Max/M4 Max ile ağır nicemleme altında yavaşça çalışabilir. V4-Pro dizüstünde çalışmaz. Dizüstü için API veya web sohbetini kullanın.

V4 araç kullanımı/fonksiyon çağırmayı destekliyor mu? Evet. OpenAI uyumlu endpoint tools dizisini kabul eder, yanıtlar tool_calls ile gelir. Anthropic endpoint'i de destekler.

Yanıtları nasıl akış yapabilirim? İstek gövdesinde stream: true ayarlayın. Yanıt, OpenAI uyumlu SSE akışıdır.

API hız limiti var mı? Barındırılan API limitleri api-docs.deepseek.com'da yayınlanır. Kendi barındırılan modelde donanımınız dışında ek limit yoktur.

Forem: Tobias Hoffmann

Ghostty GitHub'dan Ayrılıyor: Geliştirici Araçları Üreticileri İçin Ne Anlama Geliyor?

TL;DR

Hashimoto gönderide ne söyledi?

Güvenilirlik neden platform seçiminden daha önemli?

1. Kullanıcı profili

2. Ayrılma nedeni

3. Ton

Kendi geliştirici aracınızı nasıl stres test edersiniz?

1. Kullanıcılarınız sizin için aynı günlüğü yazabilir mi?

2. Güvenilirliğinizin yönü ne?

3. Durum sayfanız gerçeği hızlı gösteriyor mu?

4. Uptime’ı kendi grafiğinize göre değil, müşterinin iş akışına göre ölçüyor musunuz?

GitHub kilitlenmesi neden yalnızca git geçmişi değildir?

Daha az kilitlenme için mimari yaklaşım

Geliştirme platformu alternatifleri

Forgejo

Codeberg

GitLab

Sourcehut

Kendi barındırdığınız Forgejo veya Gitea

Radicle

API ekipleri için ders

1. Bağımlı olduğunuz API’leri mock edin

2. Birden fazla sağlayıcıya karşı test edin

3. Yayın hattınızı barındırma platformundan ayırın

Esnek API çalışmaları için Apidog tarzı iş akışı

Geliştiricilerin duyurudan çıkardığı sonuçlar

“Aferin ona” grubu

“Bu yalnızca tek kesinti” diyenler

“Geçiş zor” diyen pragmatikler

“Benim depolarım ne olacak?” diye düşünen bakımcılar

Kendi yığınız için pratik kontrol listesi

1. Aktif depoları ikinci platforma yansıtın

2. Sağlayıcı istemcilerini adaptör arkasına alın

3. Manuel fallback yolunu belgeleyin

4. Kritik bağımlılıkları listeleyin

5. Olayların ikinci türevini izleyin

Sıkça Sorulan Sorular

Ghostty nereye taşınıyor?

GitHub gerçekten bu kadar güvenilmez mi?

Depolarımı hemen GitHub’dan taşımalı mıyım?

Bu GitHub Copilot veya GitHub Actions kullanımımı etkiler mi?

GitHub API’lerine bağımlı yapay zeka dönemi geliştirici araçları için bu ne anlama geliyor?

Bu bir “GitHub’dan ayrılma” trendi mi?

“Geliştirici aracı geliştiricisi” kimdir?

Mistral Medium 3.5 API Nasıl Kullanılır?

TL;DR

Medium 3.5'te Neler Değişti?

Önkoşullar

Uç Nokta ve Kimlik Doğrulama

İstek Parametreleri

Python ile Medium 3.5 Kullanımı

Node.js ile Medium 3.5 Kullanımı

Akış Yanıtları

Araç Çağırma

JSON Modu ve Yapılandırılmış Çıktı

Görsel Girdi

Apidog'da Medium 3.5 Koleksiyonu Oluşturma

Hata Yönetimi

Maliyet Kontrolü Desenleri

1. Varsayılanı ucuz model yapın

2. max_tokens değerini sınırlandırın

3. Sistem istemini kısaltın

4. Her çağrıda usage kaydedin

5. Görsel girdiyi seçici kullanın

Medium 3.5'i Diğer Mistral Seviyeleriyle Karşılaştırma

Başka Bir Sağlayıcıdan Geçiş

Gerçek Dünya Kullanım Senaryoları

Sıkça Sorulan Sorular

API'deki Mistral Medium 3.5 model kimliği nedir?

Medium 3.5 OpenAI ile uyumlu mu?

Medium 3.5'i yerel olarak çalıştırabilir miyim?

Araç çağrılarıyla akışı destekliyor mu?

Göndermeden önce giriş tokenlarını nasıl sayabilirim?

Üretimde hangi bağlam uzunluğunu planlamalıyım?

Ücretsiz katman var mı?

Tasarım Odaklı API İş Akışı için API Platformu

TL;DR

Giriş

2. `max_tokens` değerini sınırlandırın

4. Her çağrıda `usage` kaydedin