DEV Community: Tobias Hoffmann

Bitwarden Yapay Zeka Kodlama Aracısı Güvenli Kasa Erişim Paylaşımı

Tobias Hoffmann — Fri, 15 May 2026 08:17:06 +0000

Claude Code, Codex veya Cursor ile gerçek API’lere dokunan işler yapıyorsanız, kimlik bilgisi yönetimi hızla riskli hale gelir: API anahtarını sohbete yapıştırmak modeli kalıcı bağlama maruz bırakır; .env dosyasına koymak ise aracının bash ile okuyup dışarı taşıyabileceği bir sır üretir. Daha güvenli desen: sırrı modele vermeyin, yalnızca ihtiyaç duyan alt sürece çalışma anında enjekte edin.

Apidog'u bugün deneyin

Bitwarden’ın açık kaynak projesi Agent Access, bu problemi çözmek için bir kimlik bilgisi paylaşım protokolü, CLI (aac) ve Rust + Python SDK sunar. Parola yöneticiniz ile uzaktaki bir süreç — AI aracı, CI runner veya betik — arasında şifreli bir tünel kurar. Tüketici süreç, kasanın tamamını görmeden yalnızca kapsamlandırılmış alan adı veya kasa öğesi için gerekli sırrı alır.

Bu yazıda Agent Access’i kuracak, aac connect ve aac run komutlarını kullanacak, Claude Code, Codex ve Cursor iş akışlarına nasıl yerleştirileceğini görecek ve Yapay Zeka Aracısı API Kimlik Bilgilerini Nasıl Güvenli Hale Getirilir yazısındaki kimlik bilgisi hijyeni prensiplerini pratik hale getireceğiz.

Agent Access nedir?

Agent Access, Bitwarden tarafından geliştirilen ancak farklı parola yöneticilerinin de benimseyebilmesi için açık tasarlanan bir protokol ve referans uygulamadır.

Çalışma modeli:

Bir sağlayıcı bağlantı isteklerini dinler.
Bir tüketici — aracı, betik veya CI job — sağlayıcıya bağlanır.
Tüketici, alan adı veya kasa öğesi kimliğiyle kimlik bilgisi ister.
Sağlayıcı ne döneceğine karar verir.
Tüketici kasanın tamamını hiçbir zaman göremez.

CLI aracı aac, Noise protokolünü kullanarak uçtan uca şifreli bir tünel kurar. Sağlayıcı, tüketicinin kimlik bilgisiyle ne yaptığını görmez; tüketici de kasanın geri kalanını göremez. Denetim izleri iki tarafta da tutulur.

Not: Agent Access şu anda erken önizleme aşamasındadır. Proje README’si API’lerin ve protokollerin değişebileceğini belirtir. Ayrıca hassas kimlik bilgilerinin doğrudan LLM’lere veya AI aracılarına girilmesi önerilmez.

Bu yüzden en güvenli pratik desen şudur: aac run ile sırrı yalnızca alt sürece ortam değişkeni olarak verin; modelin bağlam penceresine hiçbir zaman koymayın.

2026’da neden önemli?

AI kodlama aracıları artık yalnızca öneri üretmiyor. Claude Code, Codex, Cursor ve benzerleri:

depoyu okuyor,
testleri çalıştırıyor,
API’lere istek atıyor,
CI/CD süreçlerine dokunuyor,
dağıtım betiklerini tetikliyor.

Bunların çoğu API anahtarı, token veya parola gerektiriyor. Postman’ın açığa çıkmış API anahtarları olayı, yalnızca insan hatasıyla bile kimlik bilgisi hijyeninin ne kadar zor ölçeklendiğini gösterdi. İnsan + AI aracı kombinasyonu daha fazla risk üretir.

Doğru yaklaşım “aracıya daha çok güvenmek” değil, “aracıya daha az sır vermek”tir.

Agent Access bu modeli protokol düzeyinde uygular:

kimlik bilgisi kapsamlandırılır,
aktarım sırasında şifrelenir,
çalışma anında alınır,
süreç bittiğinde ortamdan kaybolur.

API Anahtarı Yönetim Araçları daha geniş araç ekosistemini kapsar; Agent Access ise özellikle AI aracıları ve geliştirici iş akışları için tasarlanmış bir katman sunar.

Kurulum

Platformunuza göre aac ikilisini indirin.

macOS Apple Silicon

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-aarch64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

macOS Intel

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-macos-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Linux x86_64

curl -L https://github.com/bitwarden/agent-access/releases/latest/download/aac-linux-x86_64.tar.gz | tar xz
sudo mv aac /usr/local/bin/

Windows x86_64

En son yayın sayfasından aac-windows-x86_64.zip dosyasını indirin ve PATH içindeki bir dizine çıkarın.

Kurulumu doğrulayın:

aac --help

Bitwarden CLI (bw) PATH içinde varsa, aac varsayılan kimlik bilgisi sağlayıcısı olarak bunu kullanır. Deneme yapmak için demo sağlayıcıyı kullanabilirsiniz:

aac connect --provider example --domain test.com --output json

Hızlı başlangıç: kimlik bilgisi eşleştirme ve alma

İlk terminalde, kasaya erişimi olan makinede dinleyiciyi başlatın:

aac listen

Bu komut bir eşleştirme jetonu üretir.

İkinci terminalde veya uzak tüketici makinede bağlanıp belirli bir alan adı için kimlik bilgisi isteyin:

aac connect --token <eşleştirme-jetonu> --domain github.com --output json

Örnek çıktı:

{
  "credential": {
    "notes": null,
    "password": "alligator5",
    "totp": null,
    "uri": "https://github.com",
    "username": "example"
  },
  "domain": "github.com",
  "success": true
}

Betiğiniz bu JSON’u ayrıştırabilir:

aac connect --token "$AAC_TOKEN" --domain github.com --output json | jq -r '.credential.password'

Alan adı yerine kasa öğesi kimliğiyle almak için:

aac connect --id <kasa-öğesi-kimliği> --output json

--id ve --domain birlikte kullanılmaz; yalnızca birini seçin. Kasa öğesinde TOTP yapılandırılmışsa aynı yanıt içinde döner.

En önemli desen: `aac run` ile ortam enjeksiyonu

aac connect, JSON çıktısını kendiniz işleyeceğiniz betikler için uygundur. AI aracılarıyla daha güvenli desen ise aac run kullanmaktır.

aac run:

kimlik bilgisini alır,
seçilen alanları ortam değişkenlerine dönüştürür,
alt süreci bu ortamla çalıştırır,
sırrı stdout’a veya diske yazmaz.

Belirli alanları enjekte edin:

aac run --domain example.com \
  --env DB_PASSWORD=password \
  --env DB_USER=username \
  -- psql

Tüm alanları AAC_ önekiyle enjekte edin:

aac run --domain example.com --env-all -- ./deploy.sh

Varsayılan tüm alanlara ek olarak özel bir değişken adı verin:

aac run --domain example.com \
  --env-all \
  --env CUSTOM_PW=password \
  -- ./deploy.sh

Kullanılabilir alanlar:

username
password
totp
uri
notes
domain
credential_id

AI aracılarıyla önerilen kullanım budur. Model sırrı görmez; yalnızca şu komutu çalıştıran betiği görür:

aac run --domain api.stripe.com --env-all -- ./deploy.sh

Eğer aracı daha sonra $STRIPE_API_KEY değerini okumaya çalışırsa, değer yalnızca alt süreç kapsamındadır. Bu izolasyon prensibi, Yapay Zeka Aracısı API Kimlik Bilgilerini Nasıl Güvenli Hale Getirilir yazısındaki modelin pratik karşılığıdır.

Python ve Rust SDK’ları

CLI yeterli değilse Agent Access’i uygulamanıza gömmek için SDK kullanabilirsiniz.

Python

from agent_access import RemoteClient

client = RemoteClient("python-remote")
client.connect(token="ABC-DEF-GHI")

cred = client.request_credential("example.com")
print(cred.username, cred.password)

client.close()

Python modülü PyO3 tabanlıdır; ağır iş Rust tarafında kalır ve altta aynı Noise protokolü kullanılır.

Rust

Rust SDK, aynı RemoteClient arayüzünü kütüphane olarak sunar. Referans örnekler depoda examples/rust-remote/ altında bulunur.

Rust SDK şu durumlarda daha uygundur:

kendi tüketici sürecinizi Rust ile yazıyorsanız,
CLI aracı geliştiriyorsanız,
CI runner veya derlenmiş ikili dağıtmak istiyorsanız.

API araçları sunan ekipler için bu model, HashiCorp Vault veya Azure Key Vault entegrasyonlarının yanında konumlanır. Agent Access, kurumsal sır kasalarının yerine geçmez; geliştirici dizüstü bilgisayarı ve CI runner gibi daha dar iş akışlarını hedefler.

AI kodlama aracılarıyla entegrasyon

Claude Code

Dağıtım betiğinizi aac run ile sarın:

# deploy.sh
#!/usr/bin/env bash

aac run --domain prod.example.com --env-all -- ./run-deploy.sh

Çalıştırılabilir yapın:

chmod +x deploy.sh

Claude Code iş akışınızı doğrudan ./deploy.sh çağıracak şekilde ayarlayın. Model yalnızca betiği çalıştırır; kimlik bilgisi isteme veya görme ihtiyacı olmaz.

Claude Code GitHub Actions entegrasyonunda da aynı desen uygulanır:

runner’a aac kurun,
runner’ı sağlayıcıyla eşleştirin,
job içinde aac run ile kapsamlı kimlik bilgisi enjekte edin.

OpenAI Codex

Codex CLI için de aynı yaklaşımı kullanın. Modelin çağırdığı komut, gerçek sırrı değil yalnızca sarmalayıcı betiği görür:

# test-api.sh
#!/usr/bin/env bash

aac run --domain staging.example.com \
  --env API_TOKEN=password \
  -- npm run test:api

Codex bu betiği çağırır; token model bağlamına girmez. Codex’in daha geniş kullanım yüzeyi için telefonunuzdan Codex yazısına bakabilirsiniz.

Cursor

Cursor terminal komutları ve Composer iş akışlarında da aynı sarmalama çalışır:

aac run --domain dev.example.com --env-all -- npm run e2e

Cursor genellikle yerel geliştirme makinesinde çalıştığı için sağlayıcı dinleyicisi de aynı makinede olabilir.

OpenClaw

Agent Access, depoda SKILL.md içeren resmi bir OpenClaw becerisi sunar. OpenClaw tarzı beceriler kullanan ekiplerde en hazır entegrasyon budur: beceri protokol yapısını bilir, kimlik bilgilerini alır ve ilgili alt araca iletir.

Bu ekosistemdeki daha geniş kimlik bilgisi yönetimi için OpenClaw API anahtarları kılavuzu kullanılabilir.

Güvenlik modeli

Agent Access’in güvenlik modelini üç noktada düşünün.

1. Uçtan uca şifreleme

Tüketici ve sağlayıcı arasındaki trafik Noise protokol çerçevesi ile şifrelenir. Bu, WireGuard ve Signal’in kullandığı el sıkışma ailesidir.

2. Kapsamlandırılmış kimlik bilgisi

Tüketici yalnızca istediği alan adı veya kasa öğesi kimliği için kimlik bilgisi alır. Kasayı listeleyemez veya tüm sırları göremez.

3. Varsayılan olarak diske sır yazılmaz

aac run, sırrı ortam değişkeni olarak yalnızca alt sürece verir:

aac run --domain example.com --env API_KEY=password -- npm test

Bu modelde:

.env dosyası oluşmaz,
stdout’a sır yazılmaz,
shell geçmişine değer düşmez,
süreç bittiğinde ortam da kaybolur.

Agent Access’in korumadığı durumlar

Agent Access her şeyi çözmez.

Dikkat edilmesi gerekenler:

Güvenliği ihlal edilmiş tüketici süreç: Aracı veya alt süreç kötü niyetliyse kapsamlı kimlik bilgisi yine de sızabilir.
Güvenliği ihlal edilmiş sağlayıcı: Bitwarden kasanız ele geçirilmişse bu katman yardımcı olmaz.
LLM bağlamına yapıştırılan sırlar: Bir API anahtarını sohbet penceresine kopyalarsanız protokol sizi koruyamaz.

Kural basit: sırları modele değil, yalnızca ihtiyaç duyan alt sürece verin.

Pratik CI deseni: aracı kod yazar, Apidog test eder

Çoğu ekip için uygulanabilir döngü şöyle görünür:

AI aracı kod değişikliği yapar. Claude Code, Codex veya Cursor API’ye dokunan bir PR üretir.
CI testleri çalıştırır. Runner, API anahtarını aac run ile alır ve staging ortamına karşı testleri çalıştırır.
Apidog sözleşmeyi doğrular. Apidog, OpenAPI sözleşme testlerini ayrı bir CI adımı olarak çalıştırır.

Örnek CI adımı:

aac run --domain staging.example.com \
  --env API_TOKEN=password \
  -- npm run test:contract

Sonuç:

aracı kodu üretir,
Apidog sözleşmeyi doğrular,
API anahtarı modele veya düz metin dosyaya girmez.

AI aracıları API çağırırken test stratejisi için API’lerinizi Çağıran Yapay Zeka Aracılarını Test Etme yazısına bakabilirsiniz.

Sınırlamalar ve uyarılar

Erken önizleme: API’ler ve protokoller değişebilir. Üretim iş akışını v0 protokolüne bağlamadan önce değişiklik maliyetini hesaba katın.
Varsayılan sağlayıcı Bitwarden CLI: bw gerekir. Önce Bitwarden CLI kurun veya testte --provider example kullanın.
Yapılandırma dosyası yok: Tekrarlanan çağrılar için küçük sarmalayıcı betikler yazmanız gerekir.
LLM istemlerine sır yapıştırmayın: Agent Access kurulu olsa bile bu hata sizi savunmasız bırakır.

Sıkça sorulan sorular

Agent Access ücretsiz mi?

Evet. CLI, SDK’lar ve protokol Bitwarden GitHub organizasyonu altında açık kaynaktır. Bitwarden’ı kasa olarak kullanıyorsanız Bitwarden planınız ayrı bir konudur.

Bitwarden dışındaki parola yöneticileriyle çalışır mı?

Protokol satıcıdan bağımsız tasarlanmıştır. Referans uygulama Bitwarden desteği ve örnek sağlayıcıyla gelir. Diğer sağlayıcıların zamanla kendi entegrasyonlarını sunması beklenir.

Parola yöneticisi olmadan kullanabilir miyim?

Test için evet:

aac connect --provider example --domain test.com --output json

Üretim için gerçek bir sağlayıcı gerekir.

Tüketici sürecin ağ erişimine ihtiyacı var mı?

Evet. Tüketici, sağlayıcının dinleyicisine ulaşabilmelidir. Dinleyici ve tüketici aynı makinedeyse yerel bağlantı yeterlidir.

`.env` dosyasından farkı ne?

.env dosyası diskte kalır, yanlışlıkla repoya eklenebilir ve aracının çalıştırdığı komutlar tarafından okunabilir.

aac run ise sırrı yalnızca alt sürecin ortamına verir:

aac run --domain example.com --env API_KEY=password -- node script.js

Alt süreç bittiğinde sır da kapsam dışına çıkar.

HashiCorp Vault veya AWS Secrets Manager’ın yerini alır mı?

Hayır. Kurumsal sır kasaları, ölçekli servisler arası sır yönetimi için hâlâ doğru araçlardır. Agent Access daha çok geliştirici makinesi, AI aracı iş akışı ve CI runner boşluğunu hedefler.

Anthropic, OpenAI veya diğer aracı satıcıları bunu doğrudan entegre edecek mi?

Duyurulmuş bir entegrasyon yok. Şu anki pratik model, betikleri aac run ile sarmaktır.

Hata bildirmek veya katkı yapmak için nereye gitmeliyim?

GitHub deposu üzerinden issue açabilir, PR gönderebilir veya protokol tartışmalarına katılabilirsiniz.

Hemen deneyin

En küçük uçtan uca testi şu şekilde çalıştırın.

İlk terminal:

aac listen

İkinci terminal:

aac connect --provider example --domain test.com --output json

JSON yanıtını gördükten sonra bir sonraki adım:

demo sağlayıcıyı bw ile değiştirin,
gerçek bir betiği aac run içine alın,
API anahtarlarını AI aracı sohbetlerine yapıştırmayı bırakın.

API test tarafında Agent Access’i Apidog ile eşleştirebilirsiniz: kasa sırrı tutar, Apidog sözleşmeyi test eder, aracı kodu gönderir ve kimlik bilgileri düz metin olarak iş akışınızdan geçmez.

2026'da En İyi 7 API Yönetim Aracı (G2 Sıralaması)

Tobias Hoffmann — Fri, 15 May 2026 07:44:39 +0000

G2 İlkbahar 2026 API Yönetimi Çizelgesi yayınlandı. Çizelgede iki Lider (Apidog, viaSocket), üç Yüksek Performanslı (Traefik Labs, Rasayel, Backendless) ve iki Niş oyuncu (Moesif/WSO2, Thunder Client) yer alıyor. Yedi ürüne, üç çeyreğe ve her aracın hangi problem için tasarlandığına baktığınızda, “API yönetimi” etiketi altında ciddi kapsam farkları görüyorsunuz.

Apidog'u bugün deneyin

Özet

Apidog ve viaSocket, G2'nin İlkbahar 2026 API Yönetimi Çizelgesinde lider konumda. Apidog; API tasarımı, test, mock ve dokümantasyonu tek çalışma alanında yönetmek isteyen ekipler için öne çıkıyor. viaSocket ise API kancalarıyla kodsuz iş akışı otomasyonu için güçlü bir seçenek.

Diğer beş araç daha dar problemleri çözüyor:

Traefik Labs: API ağ geçidi ve GitOps tabanlı yönetim
Rasayel: WhatsApp Business API akışları
Backendless: otomatik REST/GraphQL API üreten BaaS
Moesif (WSO2): API analitiği ve para kazanma
Thunder Client: VS Code içinde REST istemcisi

Doğru seçim, ekibinizin “API yönetimi” ile neyi kastettiğine bağlı.

G2 İlkbahar 2026 Çizelgesi Ne Anlatıyor?

G2'nin İlkbahar 2026 raporları, 17 Mart 2026'da 27.019 rapor yayınladı. Bu, çeyreklik bazda %1.72 artış anlamına geliyor. G2 Pazarlama Başkan Yardımcısı Palmer Houchins'e göre, G2'deki ürünlerin yalnızca %3'ü tüm kategorilerde Lider rozeti alıyor.

Bu yüzden Lider konumu, özellikle birçok satıcının kanıt göstermeden “sektör lideri” dediği API yönetimi alanında önemli bir üçüncü taraf sinyali.

G2 çizelgesi iki eksen kullanır:

Müşteri memnuniyeti: kullanıcı yorumlarına dayanır.
Pazar varlığı: şirket boyutu, erişim ve yorum hacmi gibi metriklere bakar.

İlkbahar 2026'nın API Yönetimi kategorisinde:

Liderler: Apidog, viaSocket
Yüksek Performanslılar: Traefik Labs, Rasayel, Backendless
Niş oyuncular: Moesif (WSO2), Thunder Client

Kadran tek başına yeterli değildir. Niş bir araç, kapsamı tam olarak ihtiyacınıza uyuyorsa doğru seçim olabilir. Lider bir araç da çözmediğiniz bir problem için fazlalık olabilir.

Takip etmek isterseniz Apidog'u indirin.

Yedi Araca Hızlı Bakış

Araç	G2 kadranı	En uygun kullanım	Açık kaynak mı?	Fiyatlandırma modeli
Apidog	Lider	Hepsi bir arada API tasarımı, testi, mock, dokümantasyon	Ücretsiz katman + ücretli	Kullanıcı başına SaaS
viaSocket	Lider	API kancalarıyla kodsuz iş akışı otomasyonu	Hayır	Aylık 50$ başlangıç planı
Traefik Labs	Yüksek Performanslı	Bulut tabanlı API ağ geçidi + GitOps yönetimi	Evet, Proxy OSS	Ücretsiz OSS, ücretli Hub
Rasayel	Yüksek Performanslı	WhatsApp Business mesajlaşma + REST API	Hayır	Kullanıcı başına SaaS
Backendless	Yüksek Performanslı	Otomatik REST ve GraphQL API üreten BaaS	Hayır	Ücretsiz katman + ücretli
Moesif (WSO2)	Niş	API analitiği, gözlemlenebilirlik, para kazanma	Hayır	Kullanıma dayalı
Thunder Client	Niş	VS Code REST istemcisi	Hayır	Ücretsiz + Pro ücretli sürüm

G2'nin kategorisi; yaşam döngüsü platformlarını, iPaaS otomasyon araçlarını, ağ geçitlerini, analitik platformlarını ve IDE uzantılarını aynı çizelgede topluyor. Bu yüzden araçları doğrudan puanlarına göre değil, kullanım senaryosuna göre değerlendirmek gerekir.

Apidog: Uçtan Uca API İş Akışları İçin Lider

Apidog, API yaşam döngüsünün dört ana adımını tek çalışma alanında toplar:

API tasarımı
API testi
Mock servisleri
API dokümantasyonu

Çoğu API yönetimi ürünü yalnızca bu aşamalardan birini çözer. Geri kalan kısım için ekipler farklı araçları birbirine bağlamak zorunda kalır. Apidog'un G2 yorumlarında öne çıkmasının ana nedeni bu araç değişimini azaltmasıdır.

Apidog ile pratik iş akışı

Tipik bir ekip şu akışı kurabilir:

OpenAPI 3.0/3.1 şemasını Apidog içinde tasarlayın.
Endpoint’ler için örnek request/response tanımlayın.
Frontend ekibi için mock endpoint’i yayınlayın.
QA ekibi aynı şemadan test senaryoları oluştursun.
Dokümantasyonu public veya private URL olarak yayınlayın.
CI/CD içinde API testlerini çalıştırın.

Örnek bir OpenAPI endpoint tanımı:

paths:
  /users/{id}:
    get:
      summary: Kullanıcı detayını getir
      parameters:
        - name: id
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Başarılı yanıt
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: string
                  email:
                    type: string

Bu şema üzerinden:

Mock response oluşturabilirsiniz.
Test case üretebilirsiniz.
Dokümantasyonu otomatik yayınlayabilirsiniz.
Ekip içi review akışı başlatabilirsiniz.

Apidog’un güçlü olduğu yerler

Görsel API tasarımı: OpenAPI 3.0/3.1 ve dallanma destekli düzenleyici
Otomatik test: görsel test oluşturucu ve CI/CD entegrasyonu
Akıllı mock: şemadan dinamik yanıt üretimi
Otomatik dokümantasyon: public veya private URL, özel alan adı desteği
Ekip işbirliği: gerçek zamanlı senkronizasyon, sürüm kontrolü, rol tabanlı erişim

Apidog özellikle API spesifikasyonu için tek doğruluk kaynağı isteyen, 100 veya daha az mühendisten oluşan ekiplerde anlamlıdır. Backend geliştiricileri endpoint tasarlarken, QA aynı çalışma alanında test senaryoları yazabilir. Frontend ekibi ise backend tamamlanmadan mock API kullanabilir.

Ekipler, spesifikasyondan ilk entegrasyon testine kadar geçen sürede %50-60 azalma bildirmektedir. İlkbahar 2026 G2 yorumlarında ayrıca dallanma tabanlı tasarım incelemesi ve OpenAPI 3.1 düzenleyicisi, Stoplight ve SwaggerHub karşısında farklılaştırıcı olarak belirtilmektedir.

Apidog'u indirin ve Postman koleksiyonunuzu içe aktarın. Kredi kartı gerekmez; ücretsiz katman çoğu küçük ekip için yeterlidir.

viaSocket: Kodsuz Entegrasyon Ekipleri İçin Lider

viaSocket diğer Lider araçtır. Konumlandırması, kullanıcı profilini gördüğünüzde daha net anlaşılır. Geleneksel bir API ağ geçidinden çok Zapier veya Make'e yakın bir yapay zeka iş akışı otomasyon platformudur.

Temel kullanım amacı:

SaaS uygulamalarını bağlamak
Webhook tabanlı iş akışları kurmak
Koşullu mantık eklemek
Gerekirse özel JavaScript çalıştırmak
Mühendislik ekibine ihtiyaç duymadan otomasyon oluşturmak

Ne zaman kullanılır?

viaSocket şu senaryolarda uygundur:

Operasyon ekibi SaaS araçları arasında veri taşımak istiyor.
Pazarlama ekibi webhook ile kampanya otomasyonu kurmak istiyor.
Gelir ekipleri CRM, form, e-posta ve ödeme araçlarını bağlamak istiyor.
Hazır entegrasyon kataloğu yeterli, eksik kalan yerlerde özel API çağrısı gerekiyor.

Ne zaman kullanılmaz?

viaSocket bir API ağ geçidi değildir. Şunları beklememelisiniz:

Rate limiting
OAuth akış yönetimi
Contract testing
Internal microservice gateway
API yaşam döngüsü yönetimi

Fiyatlandırma, Eylül 2025 sonrası oluşturulan hesaplar için aylık 50 dolardan başlar. Bu da küçük tek kişilik denemeler için maliyetli olabilir.

Eğer ekibinizin problemi SaaS uygulamalarını bağlamaksa viaSocket mantıklı. Eğer genel API yayınlıyor veya mikroservis API’lerini yönetiyorsanız başka bir katmana ihtiyacınız var.

Traefik Labs: API Yönetimi Üzerine Açık Kaynak Ağ Geçidi

Traefik Proxy, bulut tabanlı uygulama proxy’si olarak yaygın kullanılan açık kaynaklı bir araçtır. Traefik Hub, bunun üzerine API yönetimi katmanı ekler:

Geliştirici portalları
Yaşam döngüsü kontrolleri
GitOps tabanlı yönetim
API rotaları ve politikaları

Bu kombinasyon, Traefik Labs’e Yüksek Performanslı konum kazandırdı. Pazar varlığı puanının daha düşük kalması, G2 yorumlarına yansımayan geniş OSS kullanıcı tabanıyla ilgili olabilir.

Traefik’i uygulamada nasıl konumlandırabilirsiniz?

Eğer Kubernetes kullanıyorsanız tipik akış şu olabilir:

API servislerinizi Kubernetes içinde yayınlayın.
Traefik Proxy ile ingress veya gateway routing kurun.
Route ve policy tanımlarını Git deposunda yönetin.
Traefik Hub ile API yönetimi, portal ve yaşam döngüsü kontrollerini ekleyin.
Tasarım ve test tarafında upstream araç olarak Apidog kullanın.

Basit bir Kubernetes Ingress örneği:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: users-api
spec:
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /users
            pathType: Prefix
            backend:
              service:
                name: users-service
                port:
                  number: 80

Güçlü olduğu yerler

Kubernetes Ingress
Service discovery
Dinamik yapılandırma
Otomatik Let's Encrypt
GitOps tabanlı API yönetimi
2026’da eklenen Yapay Zeka Ağ Geçidi özellikleri
OpenAI Responses API desteği gibi yönetilen endpoint senaryoları

Zorlayıcı olduğu yerler

Kubernetes kullanmayan ekipler için öğrenme eğrisi yüksektir.
Tasarım ve test kapsam dışıdır.
LDAP, gelişmiş portallar ve RBAC gibi kurumsal özellikler Hub tarafındadır; OSS Proxy içinde değildir.

Daha fazlası için açık kaynak API yönetimi araçları ve kurumsal ekipler için en iyi API yönetimi platformları özetlerine bakabilirsiniz.

Rasayel: WhatsApp Business API Platformu

Rasayel’in API yönetimi çizelgesindeki konumu ilk bakışta şaşırtıcı olabilir. Çünkü Rasayel özünde:

WhatsApp Business platformu
Ekip gelen kutusu
Chatbot aracı
Toplu mesajlaşma çözümü

olarak konumlanır.

G2’deki API yönetimi yerleşimi, REST ve GraphQL API'lerine, REST tarafında dakikada 200 istek limitine ve okuma/yazma yetkilendirmesine sahip API anahtar yönetimi arayüzüne dayanır.

Ne zaman seçilir?

Rasayel şu durumlarda uygundur:

Müşteri desteğiniz WhatsApp üzerinden ilerliyor.
Satış ekibi WhatsApp konuşmalarını HubSpot veya Pipedrive ile bağlamak istiyor.
WhatsApp mesajlaşmasını webhook üzerinden entegre etmek istiyorsunuz.
Twilio yerine daha ürünleşmiş bir WhatsApp ekip gelen kutusu istiyorsunuz.

Ne zaman seçilmez?

Rasayel şu senaryolarda doğru başlangıç noktası değildir:

Dahili mikroservis API’lerini yönetmek
Edge gateway kurmak
Genel API yaşam döngüsü yönetmek
WhatsApp içermeyen bir API platformu seçmek

Dar bir kullanım senaryosu için güçlü bir araçtır. Ancak çoğu API platformu kararında ilk aday değildir.

Backendless: Otomatik Oluşturulan API’ler ile BaaS

Backendless, veri modelinizden otomatik olarak REST ve GraphQL endpoint’leri oluşturan bir Backend-as-a-Service platformudur.

Temel mantık basittir:

Bir tablo tanımlayın.
Backendless sizin için API endpoint’i oluştursun.
Servis tanımlayın.
Method, client type, başarı/hata grupları ve çağrı izleme otomatik oluşsun.

Örnek kullanım senaryosu

Bir Tasks tablosu oluşturduğunuzu düşünün:

Alan	Tip
id	string
title	string
completed	boolean
ownerId	string

Backendless bu veri modelinden REST veya GraphQL endpoint’leri üretir. Böylece küçük ekipler backend servis yazmadan mobil veya web uygulaması geliştirmeye başlayabilir.

Güçlü olduğu yerler

Android, iOS, JavaScript ve .NET SDK’ları
Düşük kodlu backend geliştirme
İşlem başına güvenlik rolleri
Method bazlı erişim kontrolü
Servis seviyesinde API çağrı takibi

Zayıf olduğu yerler

Backendless şu durumlarda doğru araç olmayabilir:

Zaten çalışan bir backend yığınınız varsa
Mevcut servislerin önüne API yönetim katmanı arıyorsanız
Contract-first API tasarımı istiyorsanız
Tedarikçi bağımsız veya şirket içi dağıtım istiyorsanız

Backendless, hiç backend kurmak istemeyen girişimler ve küçük ekipler için uygundur. Probleminiz “servislerim var, bunları gateway ile yönetmek istiyorum” ise Backendless yanlış katmandır.

Moesif Bir WSO2 Şirketi: API Analitiği ve Para Kazanma

Moesif, zayıf olduğu için değil, kapsamı gereği Niş kategorisindedir. Bir API gateway veya tasarım aracı değildir. Zaten çalışan API’lerinizin üzerine analitik, gözlemlenebilirlik ve para kazanma katmanı ekler.

WSO2, Moesif'i Mayıs 2025'te satın aldı ve WSO2’nin Choreo platformu için analitik katmanı olarak entegre ediyor. Moesif kendi yol haritasıyla bağımsız bir yan kuruluş olarak faaliyet göstermeye devam ediyor.

Moesif ne sağlar?

Kullanıcı bazlı API kullanım analitiği
Endpoint bazlı trafik dökümü
Bölge bazlı kullanım görünümü
Trafik modelleri üzerinde anomali tespiti
Kullanım tabanlı faturalandırma
Plan yönetimi
Müşteri panelleri
API tüketicileri için funnel ve retention analitiği

Ne zaman kullanılır?

Moesif şu senaryolarda anlamlıdır:

Public API yayınladınız.
Hangi müşterinin hangi endpoint’i kullandığını görmek istiyorsunuz.
Kullanım tabanlı fiyatlandırmaya geçiyorsunuz.
Ölçümlü faturalandırma altyapısına ihtiyacınız var.
API tüketimi üzerinden ürün analitiği yapmak istiyorsunuz.

Ne zaman kullanılmaz?

Moesif şu durumlarda ilk araç olmamalıdır:

Henüz public API yayınlamadıysanız
API gateway arıyorsanız
API tasarım aracı istiyorsanız
Tek geliştirici olarak basit REST testi yapmak istiyorsanız

Moesif gateway’in yerine geçmez; gateway’in yanında çalışır.

Thunder Client: VS Code’un REST İstemci Uzantısı

Thunder Client, listedeki en dar kapsamlı araçtır. Postman veya Insomnia’ya benzer şekilde HTTP istekleri göndermenizi sağlar, ancak ayrı bir uygulama yerine VS Code içinde çalışır.

G2’deki Niş konumu, tek geliştirici memnuniyetinin yüksek olmasını fakat ekip ve kurumsal kapsamın sınırlı kalmasını yansıtır.

Ne için iyi?

VS Code’dan çıkmadan REST endpoint test etmek
Koleksiyonları JSON olarak depoda tutmak
Git dostu API request dosyaları kullanmak
Ortam değişkenleriyle çalışmak
Basit test assertion’ları yazmak

Örnek istek akışı:

GET https://api.example.com/users/123
Authorization: Bearer {{token}}
Accept: application/json

Beklenen yanıt:

{
  "id": "123",
  "email": "user@example.com"
}

Ne değildir?

Thunder Client şunların yerine geçmez:

Ekip işbirliği platformu
API tasarım aracı
API gateway
Mock server
Dokümantasyon oluşturucu

İşbirliği özelliklerindeki Pro ücretli sürüm bir sürtünme noktası olmuştur. Detay için Ekipler için Thunder Client: işbirliği sınırlamaları yazısına bakabilirsiniz.

API yönetiminiz “kod yazarken endpoint test etmek” ise Thunder Client uygundur. Tek geliştirici için doğru olabilir; ekip seviyesinde tasarım, mock, test ve dokümantasyon gerekiyorsa Apidog daha geniş kapsam sunar.

Ekibiniz İçin Doğru Aracı Nasıl Seçersiniz?

Kararı ürün adına göre değil, probleminize göre verin.

1. “API yönetimi” sizin yığınınızda ne demek?

İhtiyaç	Uygun araç
Tasarım, test, mock, dokümantasyon	Apidog
Gateway, rate limiting, JWT	Traefik veya bu çizelgede olmayan Kong
Yayınlanan API üzerinde analitik	Moesif
SaaS uygulamalarını webhook ile bağlama	viaSocket
Sıfırdan backend oluşturma	Backendless
WhatsApp Business API akışları	Rasayel
VS Code içinde bireysel REST testi	Thunder Client

2. Kaç kişi kullanacak?

Tek geliştirici: Thunder Client veya Apidog ücretsiz katmanı
5-50 kişilik ekip: uçtan uca kapsam için Apidog veya Backendless; gateway odaklı ekipler için Traefik Hub
100+ geliştirici: edge tarafında Traefik veya Kong, analitik için Moesif, tasarım için upstream katmanda Apidog

3. Başlangıç kısıtınız ne?

Kısıt	Daha uygun seçenekler
Para	Apidog ücretsiz katman, Traefik Proxy OSS, Backendless ücretsiz katman
Zaman	Apidog, viaSocket
Yönetim	Traefik Hub, Apidog, Moesif

4. Pratik karar akışı

Şu sorularla başlayın:

Public API yayınlıyor musunuz?
├─ Evet → Analitik gerekiyor mu?
│  ├─ Evet → Moesif
│  └─ Hayır → Gateway + tasarım/test katmanını değerlendirin
└─ Hayır → Internal API mi?
   ├─ Evet → Apidog + Traefik
   └─ Hayır → SaaS otomasyonu veya BaaS ihtiyacına bakın

Daha fazlası için 50 mühendisten oluşan bir ekip için API test aracı ve Apidog'u Stoplight ve SwaggerHub ile karşılaştıran tasarım odaklı API platformu karşılaştırmasına bakabilirsiniz.

İlkbahar 2026 Çizelgesinden Çıkarılacak Dersler

G2'nin İlkbahar 2026 API Yönetimi Çizelgesindeki yedi araç doğrudan aynı problem için yarışmıyor. Her biri “API yönetimi” başlığının farklı bir parçasını çözüyor.

Seçim yapmadan önce şu çıkarımları kullanın:

İki Lider iki farklı problemi çözüyor: Apidog tam yaşam döngüsü iş akışını, viaSocket kodsuz entegrasyonu hedefliyor.
Yüksek Performanslı araçlar dar problemleri iyi çözüyor: Traefik gateway, Rasayel WhatsApp, Backendless BaaS.
Niş olmak zayıflık değil, kapsam göstergesi olabilir: Moesif ve Thunder Client kendi alanlarında güçlü.
Uçtan uca düşük maliyetli bir yığın kurulabilir: Apidog ücretsiz katman + Traefik Proxy OSS + Moesif ücretsiz katman.

Ekibiniz API tasarımı, test, mock ve dokümantasyonu birlikte yönetiyorsa Apidog ile başlayın. Çoğu ekibin zaman kaybettiği iş akışını tek yerde topladığı için Lider konumdadır.

Apidog'u indirin ve Postman’dan içe aktarılmış çalışan bir API tasarımına kısa sürede başlayın. Yığının gateway tarafı için 2026'da geliştiriciler için en iyi 10 API ağ geçidi listesini inceleyin.

Apidog A2A Debugger ile Agent-to-Agent (A2A) Protokolü Nasıl Debug Edilir

Tobias Hoffmann — Fri, 15 May 2026 04:29:09 +0000

Diğer yapay zeka ajanlarıyla konuşan yapay zeka ajanları geliştiriyorsanız, en zor kısım genellikle “ajan diğer ajana tam olarak ne gönderdi?” sorusunu yanıtlamaktır. Konsol logları eksik kalır, ağ sekmeleri A2A alanlarını okumayı zorlaştırır, özel test script’leri ise hızla kırılır. Apidog’un A2A Hata Ayıklayıcısı, Agent2Agent (A2A) protokolü için bu akışı görsel ve tekrarlanabilir hale getirir: Ajan Kartı URL’sini yapıştırın, bağlanın, mesaj gönderin ve yanıtı Önizleme, İçerik ve Ham Veri olarak inceleyin.

Apidog'u bugün deneyin

Bu kılavuzda A2A Hata Ayıklayıcının ne işe yaradığını, ilk ajan bağlantısını nasıl kuracağınızı, test mesajı gönderirken nelere bakmanız gerektiğini ve Apidog’un mevcut MCP sunucu test araçlarının yanında nerede konumlandığını adım adım göreceksiniz. Protokol farklarını önce netleştirmek isterseniz, Apidog’da MCP ile A2A karşılaştırması iyi bir başlangıçtır.

A2A Nedir?

A2A, yani Agent2Agent, ajanlar arası iletişim için açık bir protokoldür. Bir ajanın yeteneklerini nasıl duyurduğunu, başka bir ajanın ona nasıl bağlandığını, mesajların ve dosya eklerinin nasıl değiş tokuş edildiğini ve görev durumunun nasıl raporlandığını tanımlar.

A2A’yı, ajanlar arası trafik için HTTP benzeri ince bir sözleşme olarak düşünebilirsiniz. Örneğin bir LangGraph ajanı, başka bir ekibin CrewAI ajanına, iki tarafın da birbirinin iç yapısını bilmesine gerek kalmadan mesaj gönderebilir.

A2A, MCP’den farklıdır:

MCP, tek bir ajanın araçlara ve kaynaklara erişmesiyle ilgilidir.
A2A, bir ajanın başka bir ajanla konuşmasıyla ilgilidir.

Detaylı farklar için MCP ile A2A karşılaştırması yazısına bakabilirsiniz.

A2A Hata Ayıklayıcı Ne Sağlar?

A2A Hata Ayıklayıcı, Apidog içinde yer alan görsel bir test çalışma alanıdır. A2A uç noktalarını üretim iş akışına bağlamadan önce doğrulamak için kullanılır.

Temel kullanım alanları:

Ajan Kartı bağlantısını doğrulama

Ajan Kartı URL’sini yapıştırın, Bağlan’a tıklayın ve ajanın adını, açıklamasını, yeteneklerini, beyan edilen becerilerini ve protokol sürümünü görün.
Mesaj gönderme

Düz metin istemleri gönderin, destekleniyorsa dosya ekleyin ve özel meta veri alanları ekleyin.
Yanıtı üç görünümde inceleme
- Önizleme: Yapılandırılmış çıktıyı ağaç görünümünde gösterir.
- İçerik: İnsan tarafından okunabilir çıktıyı gösterir.
- Ham Veri: JSON-RPC yükünü olduğu gibi gösterir.
Kimlik doğrulama ekleme

Taşıyıcı Token, Temel Kimlik Doğrulama ve özel başlık üzerinden API anahtarı desteklenir.
Özel başlıklar gönderme

Ağ geçidi kimlik doğrulaması, X-Request-Id, kiracı bilgisi veya ara katman başlıkları eklenebilir.
Oturum geçmişini izleme

Gönderilen mesajları oturum geçmişinde görebilir, yeni test için geçmişi temizleyebilirsiniz.

Curl komutu yazmanız gerekmez. Apidog, JSON-RPC zarfını, ajan destekliyorsa SSE akışını ve yanıt ayrıştırmayı kullanıcı arayüzünde yönetir.

Adım 1: İlk A2A Ajanına Bağlanın

Başlamadan önce üç şeye ihtiyacınız var:

Güncel Apidog istemcisi

Eski sürümler A2A Hata Ayıklayıcıyı içermeyebilir. Henüz kurmadıysanız Apidog’u indirin.
Ajan Kartı URL’si

Bu, A2A uyumlu ajanın keşif uç noktasıdır. Yerel geliştirme ortamında genellikle şöyle görünür:

   http://localhost:3000/.well-known/agent.json

Kimlik bilgileri Ajan kimlik doğrulama istiyorsa Bearer token, API anahtarı veya Basic Auth bilgilerini hazır bulundurun.

Apidog’da A2A Hata Ayıklayıcıyı açın, Ajan Kartı URL’sini üstteki alana yapıştırın ve Bağlan’a tıklayın.

Bağlantı başarılıysa durum Bağlandı olarak değişir ve panel şu bilgileri gösterir:

Ajan adı
Açıklama
Yetenekler
Beyan edilen beceriler
Protokol sürümü

Bağlantı başarısızsa şu kontrolleri yapın:

URL doğru mu?
Ajan çalışıyor mu?
URL tarayıcıda açıldığında JSON dönüyor mu?
Ajan Kartında gerekli alanlar var mı?
Keşif uç noktası kimlik doğrulama istiyor mu?

Ajan Kartı biçimini doğrulamak için GitHub’daki A2A protokol spesifikasyonu ile karşılaştırabilirsiniz.

Adım 2: Test Mesajı Gönderin

Bağlantı kurulduktan sonra Mesajlar sekmesini açın ve test isteminizi yazın.

Örnek:

Summarize the last three customer feedback notes in our shared knowledge base, then draft a one-paragraph reply for the support team.

Göndermeden önce isteğe bağlı olarak şunları ekleyebilirsiniz:

Dosya eki

Ataç simgesine tıklayıp dosya seçin. Hata ayıklayıcı, ajanın beyan ettiği giriş türlerini kontrol eder. Desteklenmeyen dosya türleri peşinen reddedilir; böylece 415 benzeri hatalar için gereksiz istek göndermezsiniz.

Meta veri

Mesaj zarfına anahtar-değer çiftleri ekleyebilirsiniz:

priority: high
tenant: acme-corp
locale: tr-TR

Bu alanlar A2A mesaj yüküne girer. Ajanın görev işleyicisi bu meta verileri okuyorsa davranışı etkileyebilir.

Hazır olduğunuzda Gönder’e tıklayın. Apidog isteminizi A2A mesaj yapısına sarar, ajana gönderir ve yanıtı bekler.

Adım 3: Yanıtı Üç Görünümle İnceleyin

A2A yanıtları farklı biçimlerde gelebilir:

Düz metin
Yapılandırılmış JSON
Dosya referansları
Görev durumu
Birden fazla yapıtın kombinasyonu

Apidog aynı yanıtı üç görünümde sunar.

Önizleme

Yapılandırılmış alanları okunabilir bir ağaç olarak gösterir. Özellikle şu alanları incelerken kullanışlıdır:

Görev kimliği
Durum
Yapıtlar
Geçmiş
İç içe geçmiş nesneler

İçerik

İnsan tarafından okunabilir çıktıdır. Ajan metin döndürdüyse, kullanıcıya göstereceğiniz ana içerik genellikle buradadır.

Ham Veri

Tüm JSON-RPC yükünü gösterir. Uyumluluk kontrolü, hata raporu veya alan adı doğrulaması yaparken en güvenilir görünümdür.

Önerilen hata ayıklama sırası:

Önce Ham Veri görünümünü açın.
Ajanın gerçekten ne döndürdüğünü doğrulayın.
Sonra Önizleme ile yapıyı kontrol edin.
En son İçerik görünümünde kullanıcıya gösterilecek çıktıyı kontrol edin.

Eğer Önizleme dolu ama İçerik boşsa, ajan Apidog’un okuyabildiği ancak düz metne çevirmediği bir yapıt tipi döndürüyor olabilir. Ham Veri’de error.message varsa, başlangıç noktanız burasıdır.

Oturum geçmişi sol panelde tutulur. Yeni bir test senaryosuna geçerken eski bağlamın sonucu etkilemesini istemiyorsanız Temizle’ye tıklayın.

Kimlik Doğrulama: Üç Yaygın Desen

Çoğu üretim A2A uç noktası kimlik doğrulama arkasındadır. Apidog’da üç yaygın yaklaşımı kullanabilirsiniz.

Taşıyıcı Token

Barındırılan ajanlarda en yaygın desendir. Kimlik doğrulama panelinde Taşıyıcı Token seçin ve token’ı yapıştırın.

Apidog her isteğe şu başlığı ekler:

Authorization: Bearer sk-agent-7f3e9a...

Temel Kimlik Doğrulama

Kullanıcı adı ve parola ile korunan ajanlar için kullanılır. Dahili veya eski sistemlerde yaygındır.

Temel Kimlik Doğrulama seçeneğini seçin, kullanıcı adı ve parolayı girin. Apidog Authorization: Basic ... başlığını sizin için oluşturur.

Özel Başlık Üzerinden API Anahtarı

Ajan standart olmayan bir başlık bekliyorsa Başlıklar bölümüne manuel ekleyin.

Örnek:

X-Agent-Key: agent-key-123

Aynı yöntem şu başlıklar için de geçerlidir:

CSRF token’ları
Kiracı kimlikleri
İstek imzaları
Ağ geçidine özel kimlik doğrulama başlıkları

Ajan kimlik bilgisi yönetimi için daha geniş bir rehbere ihtiyacınız varsa, Apidog Yapay Zeka Ajanı Kimlik Bilgileri kılavuzu kapsamlandırma, döndürme ve commit edilmemesi gereken sırlar gibi konuları ele alır.

Özel Başlıklar ve Meta Veriler: Hangisini Ne Zaman Kullanmalı?

A2A isteğinde ek veri göndermek için iki farklı yer vardır. Benzer görünürler, ancak farklı katmanlara giderler.

Kanal	Nerede bulunur	Ne için kullanılır
Özel Başlıklar	HTTP istek başlıkları	Ağ geçidi kimlik doğrulaması, gözlemlenebilirlik, `X-Request-Id`, özellik bayrakları
Meta Veriler	A2A mesaj yükü	Ajanın okuyacağı mesaj başına bağlam: öncelik, kiracı, yerel ayar

Kural basit:

Ters proxy, API gateway veya ara katman görmeliyse başlık kullanın.
Ajanın görev işleyicisi okumalıysa meta veri kullanın.

Bu ayrımı karıştırmak, “ajan gönderdiğim bağlamı neden görmedi?” hatalarının en yaygın nedenlerinden biridir.

Apidog’da A2A Hata Ayıklayıcı ve MCP Sunucu Testi

Apidog hem A2A Hata Ayıklayıcı hem de MCP test akışı sunar. Ancak bunlar farklı protokoller için farklı araçlardır.

Araç	Protokol	Test ettiği şey	Ne zaman kullanılır
A2A Hata Ayıklayıcı	Agent2Agent	Bağlantı, mesaj alışverişi, görev durumu	Ajanların diğer ajanları çağırdığı çoklu ajan sistemlerinde
MCP sunucu testi	Model Bağlam Protokolü	Araç çağrıları, kaynak erişimi, istem şablonları	Bir ajana araçlar veya kaynaklar sunan MCP sunucusu geliştirirken

Kısa karar ağacı:

Ajanınız başka bir ajanla konuşuyorsa: A2A
Ajanınız bir araç, API veya kaynağa erişiyorsa: MCP

Detaylı açıklama için MCP ile A2A karşılaştırması kılavuzuna bakabilirsiniz.

MCP tarafında test yapmak istiyorsanız, MCP sunucu test kılavuzu Apidog’daki manuel ve otomatik yolları kapsar. Gerçek dünya ajan sistemlerinde genellikle A2A koordinasyonu ve MCP araç erişimi birlikte kullanılır.

Yaygın Hata Ayıklama Döngüsü

“Ajan beklediğim gibi yanıt vermiyor” durumunda şu kısa döngüyü uygulayın:

A2A Hata Ayıklayıcıyı açın.
Ajan Kartı URL’si ile bağlanın.
Ajan Kartında beklediğiniz becerinin listelendiğini doğrulayın.
Beceriyi tetikleyecek en küçük düz metin mesajını gönderin.
İlk olarak Ham Veri görünümünü okuyun.
Yanıt eksik alan döndürüyorsa ajan kodunu kontrol edin.
Yanıt biçimsel olarak doğru ama içerik yanlışsa istem veya model mantığını inceleyin.
Düz metin akışı çalıştıktan sonra dosya eki ve meta veri ekleyin.

Bu yaklaşım, API’lerinizi çağıran yapay zeka ajanlarını nasıl test edersiniz yazısındaki izolasyon prensibiyle aynıdır: önce taşıma katmanını doğrulayın, sonra ajan mantığını ayıklayın.

Yapay Zeka İş Akışınızda Nereye Denk Geliyor?

Çoklu ajan sistemleri, modern yapay zeka iş akışlarında giderek daha sık kullanılıyor. Yapay zeka ajanları yeni API tüketicileridir yazısı, ajan trafiğini birinci sınıf API trafiği olarak ele almanın nedenlerini açıklar.

Bunun devamı olarak yapay zeka ajanları için API’ler tasarlama yazısı, tüketici insan geliştirici değil de LLM destekli ajan olduğunda API sözleşmesinde nelerin değiştiğini ele alır.

A2A Hata Ayıklayıcı, Apidog’un MCP İstemci görsel hata ayıklayıcısı ile aynı problem alanına odaklanır: ajan SDK’larının içinde gizli kalan trafiği görünür hale getirmek.

Akış şu hale gelir:

Ajanı bağlayın.
Ne gönderdiğini görün.
Ne aldığını inceleyin.
Yanlış alanları üretime çıkmadan düzeltin.

Apidog ücretsiz olarak indirilebilir ve A2A Hata Ayıklayıcı standart istemciyle birlikte gelir.

Sıkça Sorulan Sorular

A2A Hata Ayıklayıcı ücretsiz mi?

Evet. Standart Apidog istemcisiyle birlikte gelir. Apidog’u indirin ve güncel bir sürüm kullanıyorsanız A2A Hata Ayıklayıcı yan panelde görünür.

Herhangi bir çerçevede yazılmış ajanlarla çalışır mı?

Geçerli bir A2A Ajan Kartı sunan herhangi bir ajanla çalışır. Protokol çerçeveden bağımsızdır. LangGraph, CrewAI, AutoGen veya özel Python/Go ajanları, A2A spesifikasyonuna uydukları sürece kullanılabilir.

Oturumları daha sonra oynatmak üzere kaydedebilir miyim?

Oturumlar hata ayıklayıcı açıkken devam eder. Uzun süreli saklama için Ham Veri çıktısını kopyalayıp test yapıtlarınıza ekleyebilirsiniz. Tam oturum dışa aktarımı yol haritasındadır.

Akış yanıtlarını nasıl ele alıyor?

Ajan SSE akışını destekliyorsa, hata ayıklayıcı gelen parçaları okur ve Önizleme ile İçerik görünümlerini gerçek zamanlı günceller. Ham Veri, akış kapandığında birleştirilmiş yanıtı gösterir.

Meta veri alanı ile başlıklar bölümü arasındaki fark nedir?

Başlıklar HTTP katmanındadır; meta veriler A2A mesaj katmanındadır. Başlıklar ağ geçidine ve ters proxy’ye ulaşır. Meta veriler ajanın görev işleyicisine ulaşır.

Apidog, ajanın yanıtlarını kendi sunucularına kaydediyor mu?

Hayır. Apidog yerel bir istemci olarak çalışır. Makineniz ile ajan arasındaki trafik Apidog altyapısından geçmez.

A2A Hata Ayıklayıcıyı farklı bir ağdaki barındırılan ajanı test etmek için kullanabilir miyim?

Evet, ağ yolu açıksa. Hata ayıklayıcı, herhangi bir HTTP istemcisi gibi giden HTTPS istekleri yapar. Ajan VPN arkasındaysa, VPN bağlantısının aktif olması gerekir.

Hataları veya özellik isteklerini nereye bildirebilirim?

Apidog geri bildirim kanalı birincil yoldur. Spesifikasyon seviyesindeki konular için A2A protokol GitHub deposu kullanılmalıdır.

Şimdi Deneyin

Erişebileceğiniz en basit A2A ajanını seçin. Henüz bir ajanınız yoksa, A2A referans uygulamaları yerel olarak çalıştırabileceğiniz örnek bir sunucu içerir.

Minimum test döngüsü:

Ajanı yerelde veya erişilebilir bir ortamda çalıştırın.
Ajan Kartı URL’sini alın.
URL’yi Apidog A2A Hata Ayıklayıcıya yapıştırın.
Bağlan’a tıklayın.
Basit bir merhaba mesajı gönderin.
Önizleme, İçerik ve Ham Veri görünümlerini kontrol edin.

Bu küçük uçtan uca döngü çalıştıktan sonra gerçek istemlere, dosya eklerine, meta verilere ve çoklu ajan iş akışlarına geçebilirsiniz.

Hata ayıklayıcıyı API ve MCP çalışmalarınız için Apidog ile birlikte kullandığınızda, ajan sistemlerinin çalıştığı üç ana yüzey için tek bir arayüz elde edersiniz: HTTP, MCP ve A2A.

Telefondan OpenAI Codex Nasıl Kullanılır: 2026 iOS ve Android Rehberi

Tobias Hoffmann — Fri, 15 May 2026 03:13:04 +0000

OpenAI, Codex'i mobil cihazlara taşıdı. 14 Mayıs 2026 itibarıyla iOS ve Android ChatGPT uygulaması, Ücretsiz ve Go dahil tüm planlarda Codex deneyimini destekliyor. Artık telefonunuzdan çalışan görevleri izleyebilir, komutları onaylayabilir, modelleri değiştirebilir ve yeni işler başlatabilirsiniz.

Apidog'u bugün deneyin

Apidog okuyucuları uzun süredir ciddi yapay zeka kodlama akışlarının telefona ne zaman geleceğini soruyordu. Kısa cevap: şimdi. Bu yazıda mobil Codex'i nasıl kuracağınızı, hangi işleri telefondan güvenle yapabileceğinizi ve ekip akışlarına nasıl bağlayabileceğinizi adım adım ele alacağız.

Terminalinizdeki kodlama ajanları için arka plan okumak isterseniz Apidog'un Codex CLI kurulum kılavuzuna bakabilirsiniz. Anthropic ve Cursor tarafındaki mobil alternatifler için mobilde Claude Code incelemesi ve telefonunuzda Cursor çalıştırma yazısı da faydalı olacaktır. API tarafını da bu akışa dahil etmek istiyorsanız Apidog ile telefonunuzdaki Codex'in kullanacağı API sözleşmelerini hazırlayabilirsiniz.

"Her yerden Codex" ne anlama geliyor?

OpenAI'ın duyurusu yalnızca mobil uygulamadan ibaret değil. Codex artık dört ana yüzeyde kullanılabiliyor:

ChatGPT mobil uygulamasında Codex: iOS ve Android, önizleme, tüm planlar.
Slack'te Codex: Plus, Pro, Business, Enterprise ve Edu planlarında, ileti dizisinde @Codex kullanımı.
Codex Chrome uzantısı: 7 Mayıs 2026'da sunuldu; tarayıcıyı devralmadan sekmeler arasında çalışır.
Codex SDK: Codex'i kendi betiklerinizden ve CI süreçlerinizden programatik olarak kontrol etmenizi sağlar.

Mobil ana kullanım yüzeyi olsa da Slack ve SDK, ekiplerin Codex'i günlük geliştirme süreçlerine ne kadar entegre edebileceğini belirler. Örnek akış:

Slack'teki bir hata tartışmasında @Codex etiketlenir.
Codex ilgili depoda düzeltme dener.
Mühendis telefonundan diff'i inceler.
Uygunsa onaylar veya geri bildirim verir.

iOS ve Android'de Codex kurulumu

Mobil Codex ayrı bir uygulama değildir. Mevcut ChatGPT uygulamasının içinde gelir.

Adım 1: ChatGPT uygulamasını güncelleyin

iOS'te App Store'u, Android'de Play Store'u açın ve ChatGPT uygulamasını güncelleyin.

Mobil Codex, Codex değişiklik günlüğüne göre 13 Mayıs 2026 sürümünü veya daha yenisini gerektirir.

Adım 2: Masaüstünde kullandığınız hesapla oturum açın

Mobil Codex, web uygulamasıyla aynı ileti dizilerini, ortamları ve bağlı ana bilgisayarları görür. Bu yüzden masaüstünde ChatGPT veya Codex CLI için kullandığınız OpenAI hesabıyla oturum açın.

Adım 3: Bir bulut ortamı bağlayın

Codex'i yalnızca terminalinizden kullanıyorsanız, mobil uygulamanın çalışabilmesi için en az bir bulut ortamına ihtiyacınız vardır.

Web uygulamasında şu yolu izleyin:

Ayarlar → Codex → Ortamlar

Ardından:

GitHub hesabınızı bağlayın.
Bir depo seçin.
Ortam yapılandırmasını tamamlayın.
Mobil uygulamayı açın; bu yapılandırma otomatik devralınır.

Adım 4: Codex sekmesini açın

ChatGPT mobil uygulamasında alt gezinme çubuğundan Codex sekmesine dokunun. Etkin görevleriniz, ileti dizileriniz ve ortamlarınız listelenir.

Adım 5: Küçük bir test görevi çalıştırın

İlk denemede büyük bir refactor başlatmayın. Basit bir görev verin:

README dosyasındaki kurulum bölümünü daha açık hale getir.

veya:

src/utils/date.ts içindeki formatDate fonksiyonuna kısa bir docstring ekle.

Sonra telefondan şunları kontrol edin:

Codex görevi doğru depoda başlattı mı?
Diff telefonda okunabiliyor mu?
Değişiklik beklediğiniz dosyalarda mı?
Onay düğmesiyle akış tamamlanıyor mu?

Bu küçük uçtan uca döngü çalışıyorsa, uzun süren görevler ve çok dosyalı değişiklikler için de aynı modeli kullanabilirsiniz.

Telefonunuzdan neler yapabilirsiniz?

Mobil Codex, tam bir kod editörü değildir. Telefonu daha çok bir kontrol paneli gibi düşünün.

Telefondan şunları yapabilirsiniz:

Dizüstü bilgisayarlar, devbox'lar veya bağlı uzak ortamlardaki canlı çalıştırmaları izlemek
İleti dizilerine göz atmak ve paralel görevler arasında geçiş yapmak
Bir dala birleştirilmeden önce diff incelemek
Codex'in çalıştırmak istediği komutları onaylamak
Daha güçlü bir model gerektiğinde görev ortasında model değiştirmek
Yeni bir istemden veya GitHub issue'dan yeni görev başlatmak
Codex'in açtığı pull request üzerine yorum yapmak

OpenAI'ın ifadesiyle: "Telefonunuzdan, tüm ileti dizilerinizde çalışabilir, çıktıları inceleyebilir, komutları onaylayabilir, modelleri değiştirebilir veya yeni bir şey başlatabilirsiniz."

Pratik kullanım modeli şu şekilde olabilir:

1. Masaüstünde büyük görevi başlat.
2. Toplantıdayken veya dışarıdayken telefondan durumu izle.
3. Codex komut onayı isterse telefondan onayla.
4. Diff küçükse telefondan incele.
5. Diff büyükse masaüstüne dönüp detaylı review yap.

Slack: ekip ileti dizisinden Codex'e iş devretme

Slack entegrasyonu, Codex'i ekip içinde bir iş arkadaşı gibi kullanmanın en hızlı yollarından biridir.

Nasıl çalışır?

Çalışma alanı yöneticiniz Codex Slack uygulamasını Marketplace'ten yükledikten sonra, bir kanalda veya ileti dizisinde @Codex ile görev verebilirsiniz.

Örnek:

@Codex Bu issue'daki hata için api/users endpointindeki pagination davranışını kontrol edip düzeltme önerir misin?

Bot şunları yapar:

Yapılandırılmış ortamlar arasından uygun olanı seçer.
Ortam haritasındaki ilk depoyu varsayılan alır.
Gerekirse depo belirterek bunu geçersiz kılabilirsiniz.
Bir emoji ile tepki verir.
Görev bağlantısı paylaşır.
İş tamamlandığında ileti dizisinde sonuçla yanıt verir.

Gereksinimler

Slack entegrasyonu için şunlara ihtiyacınız vardır:

ChatGPT Plus, Pro, Business, Enterprise veya Edu planı
Bağlı GitHub hesabı
En az bir yapılandırılmış bulut ortamı
Slack uygulamasını yüklemek için çalışma alanı yöneticisi onayı

Ücretsiz plan Slack entegrasyonu için dahil değildir.

Kurumsal yöneticiler, Codex'in yanıt içeriğini kanala göndermesini devre dışı bırakabilir ve yalnızca görev bağlantısı paylaşmasını zorunlu kılabilir. Bu, üretilen kodun Slack dökümlerinde görünmesini engeller.

Pratik desen: issue triage + Codex

Bir GitHub issue Slack'e düştüğünde şu akışı kullanabilirsiniz:

1. Issue Slack kanalına düşer.
2. Bir ekip üyesi ileti dizisinde @Codex'i etiketler.
3. Codex ilk düzeltme denemesini yapar.
4. İnsan reviewer telefondan veya masaüstünden diff'i inceler.
5. Uygunsa PR sürecine devam edilir.

Benzer bir operasyonel model için OpenClaw GitHub triage botu yazısı da okunmaya değer.

Codex SDK: programatik kontrol

Codex SDK, betiklerden, zamanlayıcılardan ve CI çalıştırıcılarından Codex'i kontrol etmek isteyen ekipler içindir.

Örnek kullanım:

from openai import Codex

client = Codex()

task = client.tasks.create(
    repo="apidog/awesome-api",
    prompt="Add OpenAPI examples to every endpoint missing them.",
    environment="prod-mirror",
)

for event in client.tasks.stream(task.id):
    print(event.summary)

Bunu şu senaryolara bağlayabilirsiniz:

Eski issue'lar için gecelik düzeltme PR'ları açmak
Merge öncesinde eksik testleri Codex'e yazdırmak
OpenAPI örneği olmayan endpoint'leri tarayıp tamamlatmak
Belirli bir klasörde dokümantasyon güncellemesi başlatmak

Kurumsal çalışma alanları, etkileşimsiz akışlar için erişim belirteçleri oluşturabilir. Bu özellik 5 Mayıs 2026'da sunuldu.

Zaten GitHub Actions ile Claude Code çalıştırıyorsanız, Codex SDK OpenAI tarafında benzer boşluğu doldurur.

Planlar, fiyatlandırma ve kullanılabilirlik

Mobil önizleme, Ücretsiz ve Go dahil her plana açıktır. Diğer yüzeylerde plan kısıtlamaları vardır.

Yüzey	Ücretsiz	Go	Plus	Pro	Business	Enterprise / Eğitim
Mobil (iOS + Android)	Evet (önizleme)	Evet	Evet	Evet	Evet	Evet
Slack entegrasyonu	Hayır	Hayır	Evet	Evet	Evet	Evet
Chrome uzantısı	Evet (önizleme)	Evet	Evet	Evet	Evet	Evet
Codex SDK	Sınırlı	Sınırlı	Evet	Evet	Evet	Evet
Enterprise erişim belirteçleri	Hayır	Hayır	Hayır	Hayır	Hayır	Evet

Codex maliyetlerini daha ayrıntılı okumak için GPT-5.5 fiyatlandırma dökümüne bakabilirsiniz. Ödeme yapmadan denemek isteyenler için açık kaynak için ücretsiz Codex kılavuzu uygulama yolunu anlatır.

Telefon Codex'i alternatiflerle nasıl karşılaştırılır?

Mobil kodlama ajanları hızla büyüyen bir kategori. Bilmeniz gereken üç ana seçenek var:

OpenAI Codex: Bu yazının konusu. ChatGPT ile sıkı entegre, mobil kullanıcı deneyimi güçlü ve Ücretsiz planda mevcut.
Mobilde Claude Code: Claude Code mobil kurulumu, tmux oturumu ve SSH istemcisi üzerinden ilerler. Daha çok DIY yaklaşımıdır, ancak uzun süreli terminal çalışmaları için güçlüdür.
Telefonunuzda Cursor: Cursor mobil iş akışı, uzak geliştirme ve Cursor'ın web önizlemesine dayanır. Masaüstünde Cursor kullanan ekipler için mantıklıdır.

Masaüstü tarafındaki özellikleri yan yana görmek isterseniz Claude Code vs Codex 2026 karşılaştırması iyi bir başlangıçtır. Daha geniş bir görünüm için Copilot vs Claude vs Cursor vs Codex karşılaştırması da mevcut.

API'larınız ne olacak?

Telefonunuzdaki kodlama ajanı, ancak ürettiği kod üretimde doğru çalışıyorsa faydalıdır. API'lar da genellikle en kolay bozulan katmandır.

Apidog, API istemcisi, OpenAPI düzenleyici ve otomatik test çalıştırıcısını aynı akışta toplar. Codex ile birlikte kullanılabilecek pratik model:

Codex, mobil uygulama veya Slack üzerinden bir endpoint'e dokunan PR açar.
Apidog CI süreci, PR'ın preview dağıtımına karşı mevcut OpenAPI test paketini çalıştırır.
Testler yeşilse telefondan diff'i onaylarsınız.
Testler kırmızıysa Codex'e hata çıktısını verip düzeltme isteyebilirsiniz.

Örnek geri bildirim istemi:

Apidog testlerinde /v1/users endpointi için pagination beklentisi kırılıyor.
Test çıktısına göre limit ve offset davranışını düzelt, ancak response schema'yı değiştirme.

Bu modelde Codex kodu üretir; Apidog ise API sözleşmesinin bozulup bozulmadığını yakalar.

Başlamak için Apidog ChatGPT API test kılavuzu ve API'larınızı çağıran yapay zeka ajanlarını nasıl test edersiniz yazılarına bakabilirsiniz. Döngüyü bu akşam denemek isterseniz Apidog'u indirin.

Sıkça sorulan sorular

Mobil cihazda Codex çevrimdışı çalışır mı?

Hayır. Codex her zaman OpenAI'ın bulutuna veya bağlı ortamınıza karşı çalışır. Ağ bağlantısı olmadan uygulama bilinen son ileti dizisi durumunu gösterebilir, ancak yeni görev başlatamaz.

Mobil uygulamada doğrudan kod düzenleyebilir miyim?

Beklediğiniz anlamda hayır. İstem gönderebilir, çıktıları inceleyebilir ve değişiklikleri onaylayabilirsiniz. Mobil Codex bir editör değil, uzak bir ajan için kontrol yüzeyidir.

Mobil sürüm masaüstünden daha yavaş mı?

Ajan aynı arka uçta çalışır. Yavaş hissettiren taraf genellikle ekran alanıdır. Uzun diff'leri telefonda incelemek zordur. En iyi pratik, mobilde özeti okuyup büyük review'ları masaüstünde tamamlamaktır.

Mobil Codex sesli girişi destekliyor mu?

Evet. Mevcut ChatGPT ses modunu kullanarak Codex istemlerini diğer ChatGPT mesajları gibi dikte edebilirsiniz.

Onaylama sırasında sinyal kaybedersem ne olur?

Görev bulut tarafında çalışmaya devam eder. Yeniden bağlandığınızda durum güncellenir. Codex'in çalışmaya devam etmesi için açık bir mobil oturum gerekmez.

Kurumsal yöneticim mobil Codex'i devre dışı bırakabilir mi?

Evet. Çalışma alanı sahipleri yönetici panelinden Codex erişimini kısıtlayabilir. Masaüstü erişimini etkileyen aynı kontroller mobil için de geçerlidir.

Mobil cihazda Codex ek ücrete tabi mi olacak?

Mobil uygulama için ayrı bir ücret yoktur. Bulunduğunuz plana göre temel Codex işlem gücü için ödeme yaparsınız. Ayrıntılar için Codex fiyatlandırma yazısına bakabilirsiniz.

Bu eski "Codex" modelinden farklı mı?

Evet. Mevcut Codex, kullanımdan kaldırılan 2021 modeli değil, bir kodlama ajanı ürünüdür. Hâlâ eski API uç noktasını düşünüyorsanız Codex CLI tanıtımı, ürünün 2026'daki yapısını açıklar.

Bu gece deneyin

En küçük uçtan uca deneme için şu adımları izleyin:

ChatGPT uygulamasını güncelleyin.
Aynı OpenAI hesabıyla oturum açın.
Bir bulut ortamı bağlayın.
Küçük bir README değişikliği isteyin.
Diff'i telefondan inceleyin.
Onaylayın veya geri bildirim verin.

Bu akış çalıştığında Slack ve SDK katmanlarını eklemek anlamlı hale gelir.

Codex telefonunuzdan kod üretirken API sözleşmelerinizin doğru kalmasını istiyorsanız, onu Apidog ile eşleştirin. Ajan kodu yazar; test paketi regresyonu yakalar.

ERNIE 5.1 API Nasıl Kullanılır?

Tobias Hoffmann — Thu, 14 May 2026 08:44:29 +0000

ERNIE 5.1 9 Mayıs 2026'da yayınlandı ve bir hafta içinde Qianfan API'si kullanıma açıldı. Modeli kendi kodunuzdan çağırmak, araç çağrılarını ERNIE üzerinden yönlendirmek veya Apidog ile bir ajan döngüsüne bağlamak istiyorsanız, bu rehber hesap açmadan hata yönetimine kadar uygulanabilir adımları gösterir.

Apidog'u bugün deneyin

Sonunda çalışan curl, Python ve Node.js örneklerine, ayrıca Apidog’da yeniden kullanabileceğiniz bir istek yapısına sahip olacaksınız.

ERNIE 5.1 lansman analizini henüz okumadıysanız, önce ona göz atın. Yazı, DeepSeek V4 ve Kimi K2.6 ile karşılaştırmalı performansları ve ödünleşimleri ele alır.

Adım 1: Qianfan API anahtarı alın

ERNIE 5.1, Baidu Akıllı Bulut’un Qianfan platformu üzerinden sunulur. Ayrı bir “ERNIE API” yoktur; çağrılar Qianfan üzerinden yapılır.

cloud.baidu.com adresine gidin ve Baidu Akıllı Bulut hesabı oluşturun veya oturum açın.
Qianfan konsolunu açın: console.bce.baidu.com/qianfan
API Anahtar Yönetimi altında API Anahtarı Oluştur seçeneğine tıklayın.
Çalışma alanını seçin ve sohbet tamamlama hizmetine erişim izni verin.
Anahtarı kopyalayın. Formatı şuna benzer:

bce-v3/ALTAK-xxxx/xxxx

Anahtarı kaynak koduna yazmayın. Ortam değişkeni olarak saklayın:

export QIANFAN_API_KEY="bce-v3/ALTAK-xxxx/xxxx"

Dikkat etmeniz gereken iki nokta var:

Yeni v2 uç noktası tek bir Bearer token kullanır. Eski v1 OAuth access_token akışı kullanımdan kaldırılıyor; yeni entegrasyonları buna göre tasarlamayın.
ERNIE 5.1 ilk günden itibaren ücretli bir modeldir. İlk testten önce küçük bir bakiye yükleyin. ¥10 temel denemeler için yeterlidir.

Adım 2: OpenAI uyumlu uç noktaya curl ile istek gönderin

Qianfan, OpenAI uyumlu bir sohbet tamamlama uç noktası sunar. Bu nedenle OpenAI formatını destekleyen mevcut kodlarınız çoğunlukla yalnızca base_url ve model değişikliğiyle çalışır.

Temel URL:

https://qianfan.baidubce.com/v2

Model kimliği:

ernie-5.1

Erken erişim özellikleri için:

ernie-5.1-preview

Minimum çalışan istek:

curl https://qianfan.baidubce.com/v2/chat/completions \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "messages": [
      {"role": "system", "content": "You are a senior API designer."},
      {"role": "user", "content": "Sketch a REST schema for a GitHub-style PR review API. Be concise."}
    ],
    "temperature": 0.3
  }'

Yanıt OpenAI formatındadır:

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "created": 1746780000,
  "model": "ernie-5.1",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "..."
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 42,
    "completion_tokens": 318,
    "total_tokens": 360
  }
}

Hızlı hata kontrolü:

401 Unauthorized: Anahtar yanlış veya süresi dolmuş.
403: Anahtar geçerli, ancak model bu çalışma alanında etkin değil. Konsoldan ERNIE 5.1 erişimini etkinleştirin.

Adım 3: ERNIE 5.1’i Python’dan çağırın

Uç nokta OpenAI uyumlu olduğu için resmi openai Python SDK’sını kullanabilirsiniz. Tek yapmanız gereken istemciyi Qianfan’a yönlendirmek.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["QIANFAN_API_KEY"],
    base_url="https://qianfan.baidubce.com/v2",
)

response = client.chat.completions.create(
    model="ernie-5.1",
    messages=[
        {"role": "system", "content": "You explain APIs in plain English."},
        {"role": "user", "content": "Why would I use server-sent events over WebSockets for a chat UI?"},
    ],
    temperature=0.4,
)

print(response.choices[0].message.content)
print(f"\nTokens used: {response.usage.total_tokens}")

Kod tabanınızda OpenAI SDK’sı etrafında bir wrapper varsa, ERNIE 5.1’i A/B testine almak genellikle tek satırlık bir değişikliktir. Aynı yaklaşım DeepSeek API’si ve çoğu Çinli model sağlayıcısı için de geçerlidir.

Adım 4: Sohbet arayüzleri için streaming kullanın

Kullanıcıya dönük sohbet arayüzlerinde tam yanıtı beklemek yerine token akışı kullanın. Bunun için stream: true ayarlayın ve server-sent events çıktısını tüketin.

stream = client.chat.completions.create(
    model="ernie-5.1",
    messages=[
        {"role": "user", "content": "Write a haiku about API versioning."}
    ],
    stream=True,
)

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

Aynı isteği curl ile test etmek için:

curl https://qianfan.baidubce.com/v2/chat/completions \
  -H "Authorization: Bearer $QIANFAN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ernie-5.1",
    "stream": true,
    "messages": [
      {"role": "user", "content": "Stream a 3-sentence joke."}
    ]
  }' \
  --no-buffer

Akış formatı OpenAI ile aynıdır:

data: {...}
data: {...}
data: [DONE]

Adım 5: ERNIE 5.1’i araç çağrılarıyla kullanın

ERNIE 5.1’in öne çıktığı alanlardan biri araç kullanımıdır. Model, τ³-bench ve SpreadsheetBench-Verified’da DeepSeek-V4-Pro’nun üzerinde puan aldı. Bu, araç çağırmanın yalnızca demo senaryolarında değil, üretim akışlarında da kullanılabilir olduğunu gösterir.

Şema OpenAI function calling ile aynıdır:

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {
                        "type": "string",
                        "description": "City name, e.g. Singapore"
                    },
                    "unit": {
                        "type": "string",
                        "enum": ["celsius", "fahrenheit"]
                    },
                },
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="ernie-5.1",
    messages=[
        {"role": "user", "content": "What's the weather in Tokyo right now?"}
    ],
    tools=tools,
    tool_choice="auto",
)

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

if tool_calls:
    call = tool_calls[0]
    print(f"Model wants to call: {call.function.name}({call.function.arguments})")

Tipik araç döngüsü şöyledir:

Kullanıcı mesajını modele gönderin.
Model tool_calls döndürürse ilgili aracı çalıştırın.
Araç sonucunu tool rolünde yeni bir mesaj olarak konuşmaya ekleyin.
Modeli tekrar çağırın.
finish_reason == "stop" olduğunda ve tool_calls boş olduğunda döngüyü bitirin.

Uygulamada dikkat edilmesi gereken bir nokta var: ERNIE 5.1 bazen araç argümanlarını temiz JSON dizesi yerine kod bloğu içinde stringify edilmiş JSON olarak döndürebilir. Bu yüzden json.loads() işlemini try/except içine alın. Başarısız olursa <code>`json</code> bloklarını temizleyip yeniden ayrıştırın.

Adım 6: ERNIE 5.1’i Node.js’ten çağırın

openai v5+ kullanan Node.js projelerinde entegrasyon doğrudandır:

`javascript
import OpenAI from "openai";

const client = new OpenAI({
apiKey: process.env.QIANFAN_API_KEY,
baseURL: "https://qianfan.baidubce.com/v2",
});

const completion = await client.chat.completions.create({
model: "ernie-5.1",
messages: [
{
role: "user",
content: "Return a JSON object with 3 API design tips.",
},
],
response_format: { type: "json_object" },
});

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

response_format: { type: "json_object" } çalışır ve güvenilirdir. Kesin JSON şemaları için json_schema desteği Qianfan üzerinde hâlâ kullanıma sunulmaktadır. Üretimde yalnızca modele güvenmeyin; yanıt şeklini kendi kodunuzda doğrulayın.

Adım 7: Apidog ile sağlayıcıları test edin ve karşılaştırın

ERNIE 5.1, DeepSeek V4 ve Kimi K2.6 arasında karar veriyorsanız, bunu yalnızca terminalden yapmayın. Her sağlayıcı için ayrı klasör, aynı istek gövdeleri ve kaydedilmiş ortam değişkenleri içeren tek bir çalışma alanı oluşturmak için Apidog kullanın.

60 saniyelik kurulum:

Apidog’u açın.
LLM bake-off adında yeni bir proje oluşturun.

Ardından şu değişkenleri içeren bir ortam ekleyin:

`text QIANFAN_API_KEY DEEPSEEK_API_KEY MOONSHOT_API_KEY `

Sonra üç istek oluşturun:

Sağlayıcı	Base URL	Model
Qianfan	`https://qianfan.baidubce.com/v2`	`ernie-5.1`
DeepSeek	Sağlayıcının temel URL’si	`deepseek-chat`
Moonshot/Kimi	Sağlayıcının temel URL’si	`kimi-k2-6`

Her üç istekte aynı messages dizisini kullanın. Apidog’un Çalıştır özelliğiyle istekleri paralel çalıştırın ve çıktıları karşılaştırın.

Ücretsiz katman bu kullanım için yeterlidir. Apidog, her ortam için istek geçmişini saklar. Böylece ileride yeni bir model sürümü çıktığında aynı değerlendirmeyi tekrar çalıştırabilirsiniz.

Çoklu sağlayıcı testi hakkında daha fazla bilgi için Yerel LLM’leri API olarak test edin ve GLM 5.1 API rehberimize bakabilirsiniz.

Fiyatlandırma, oran sınırlamaları ve kotalar

ERNIE 5.1 için genel Qianfan fiyatlandırması yayın gönderisinde belirtilmemişti. Üretime almadan önce canlı konsol fiyat kartını kontrol edin.

Pratikte üç noktayı takip edin:

Oran sınırlamaları çalışma alanı kapsamındadır. Yeni hesaplar düşük QPS limitiyle başlar. Testlerden sonra konsoldan yükseltme yapın.
Token kullanımı yanıtta görünür. usage alanı her çağrı için prompt_tokens, completion_tokens ve total_tokens değerlerini verir. Bunları loglayın.
Önbellekleme otomatik değildir. Qianfan şu anda ERNIE 5.1 için istem önbellekleme ilkelini sunmamaktadır. 2.000 tokenlik sistem isteminiz varsa, her çağrıda bunun için ödeme yaparsınız.

Hata yönetimi

Pratikte en sık göreceğiniz hatalar:

Durum	Anlamı	Çözüm
`401`	Bearer token yanlış veya süresi dolmuş	Konsoldan yeniden oluşturun
`403`	Model bu çalışma alanında etkin değil	ERNIE 5.1’i konsoldan ekleyin
`429`	Oran limiti aşıldı	Backoff + jitter ile tekrar deneyin
`400` / `invalid messages`	Yanlış mesaj-rol sıralaması	Kullanıcı/asistan sırasını kontrol edin
`500` / `502`	Qianfan tarafında geçici sorun	Bir kez tekrar deneyin; sürerse durum sayfasını kontrol edin

Her çağrıyı sınırlı tekrar deneme döngüsüne alın. Üretimde yanıt başlıklarından request_id değerini loglayın; Baidu desteği hata ayıklama için buna ihtiyaç duyabilir.

Minimum üretim odaklı Python wrapper

ERNIE 5.1’i gerçek bir uygulamaya eklemek için başlangıç noktası olarak şu wrapper yeterlidir:

`python
import os
import time
import random
from openai import OpenAI, RateLimitError, APIError

client = OpenAI(
api_key=os.environ["QIANFAN_API_KEY"],
base_url="https://qianfan.baidubce.com/v2",
)

def chat(messages, , model="ernie-5.1", temperature=0.3, max_retries=3):
for attempt in range(max_retries):
try:
return client.chat.completions.create(
model=model,
messages=messages,
temperature=temperature,
)
except RateLimitError:
time.sleep((2 * attempt) + random.random())
except APIError as e:
if e.status_code and e.status_code >= 500 and attempt < max_retries - 1:
time.sleep(1 + attempt)
continue
raise

raise RuntimeError("ERNIE 5.1 retries exhausted")

Bu wrapper temel senaryoların çoğunu kapsar. Streaming ve araç döngülerini bunun üzerine inşa edebilirsiniz.

Sıkça sorulan sorular

ERNIE 5.1 API’si ücretsiz mi?

Hayır. Qianfan kullandıkça öde modeliyle çalışır. Kalıcı bir ücretsiz katman yoktur. Yeni hesaplar bazen deneme kredileri alabilir. Ücretsiz denemeler için ernie.baidu.com sohbet arayüzünü kullanabilir veya ücretsiz LLM seçeneklerine bakabilirsiniz.

ERNIE 5.1’i yerel olarak çalıştırabilir miyim?

Hayır. Açık ağırlıklar mevcut değildir. Şirket içi çalıştırma zorunluysa DeepSeek V4’ü yerel olarak çalıştırma rehberine veya 2026’nın en iyi yerel LLM’leri listesine bakın.

OpenAI SDK’sı değişiklik yapmadan çalışır mı?

Evet. base_url değerini https://qianfan.baidubce.com/v2, api_key değerini de Qianfan anahtarınız yapmanız yeterlidir. model alanında OpenAI model adları yerine Qianfan model kimlikleri kullanılır. Function calling, streaming ve response_format: json_object desteklenir. Kesin json_schema doğrulaması hâlâ kullanıma sunulmaktadır.

ERNIE 5.1 Çince ve İngilizce istemleri nasıl ele alır?

Her ikisi de güçlü şekilde desteklenir. 1.223’lük Arena Arama puanı karma dilli bir seçmen havuzundan gelmiştir. Teknik İngilizce görevlerinde, özellikle kod ve API tasarımı gibi alanlarda kapalı modellerle rekabetçidir. Çince yaratıcı yazımda Çin modelleri arasında üst seviyededir.

Maksimum çıktı uzunluğu nedir?

Resmi olarak yayınlanmadı. Pratikte tek dönüşlü yanıtlar model tamamlanmadan önce yaklaşık 8 bin token civarında sınırlanır. Uzun içerik üretimi için işi parçalara ayırın ve devam çağrıları kullanın.

ERNIE 5.1 üzerinde bir ajan geliştiriyorsanız Apidog’u indirin ve OpenAI uyumlu istek koleksiyonunu kullanarak Qianfan uç noktasını diğer servislerinizle birlikte test edin, mock’layın ve belgeleyin.

ERNIE 5.1 Nedir? Baidu'nun Yeni MoE Modeli

Tobias Hoffmann — Thu, 14 May 2026 07:19:20 +0000

Baidu, 9 Mayıs 2026'da ERNIE 5.1'i yayınladı. Öne çıkan nokta net: ERNIE 5.0'ın toplam parametrelerinin yaklaşık üçte birine sahip yalnızca metin tabanlı MoE model, Arena Search liderlik tablosunda 1.223 puanla dünya genelinde 4. sıraya, Çin modelleri arasında ise 1. sıraya yerleşti.

Apidog'u bugün deneyin

Bu sürüm, Baidu'nun yalnızca Çince görevlerde değil; araç kullanımı, uzun biçimli yaratıcı yazım ve muhakeme alanlarında da Gemini 3.1 Pro ve DeepSeek-V4-Pro ile rekabet etmeye çalıştığı ilk ERNIE sürümü olarak okunmalı. Eğer Apidog ile API tabanlı LLM iş akışları geliştiriyorsanız ve daha küçük ayak izine sahip, Çin bulutunda barındırılan bir öncü modeli değerlendirmek istiyorsanız, ERNIE 5.1 kısa listeye alınmalı.

Bu yazıda ERNIE 5.1'in ne sunduğunu, mimaride nelerin değiştiğini, Baidu'nun paylaştığı kıyaslama sonuçlarının DeepSeek-V4-Pro ve Gemini 3.1 Pro ile nasıl konumlandığını ve üretimde zaten DeepSeek V4 veya Kimi K2.6 kullanıyorsanız modeli nasıl değerlendirmeniz gerektiğini ele alıyoruz.

TL;DR: ERNIE 5.1 nedir?

ERNIE 5.1, benzer öncü modellerin ön eğitim maliyetinin yaklaşık %6'sında eğitildiği belirtilen, yalnızca metin tabanlı bir MoE modelidir. Toplam parametreleri ERNIE 5.0'ın yaklaşık üçte biri, ileri geçiş başına aktif parametreleri ise yaklaşık yarısı kadardır. Arena Search'te 1.223 puan alır, τ³-bench ve SpreadsheetBench-Verified araç kıyaslamalarında DeepSeek-V4-Pro'yu geçtiği açıklanmıştır ve araç kullanımıyla AIME26'da 99.6 skoruna ulaşır. Model; ERNIE sohbet arayüzü, Baidu AI Studio ERNIE 5.1 Oyun Alanı ve Qianfan API üzerinden denenebilir.

Bu sürüm geliştiriciler için neden önemli?

ERNIE 5.1'i yalnızca “Baidu yeni model çıkardı” diye okumamak gerekir. Geliştirici açısından üç başlık önemli.

1. Maliyet-kalite oranı

Baidu, ERNIE 5.1'in ön eğitim maliyetinin benzer modellerin yaklaşık %6'sı olduğunu belirtiyor. Bu doğrudan API fiyatı anlamına gelmez; ancak Qianfan üzerinde agresif fiyatlama yapılırsa, Çin merkezli LLM sağlayıcıları arasında fiyat baskısı yaratabilir.

Uygulamada takip etmeniz gerekenler:

Qianfan token fiyatları
giriş/çıkış token ayrımı
araç çağırma maliyetleri
yüksek hacimli isteklerde kota ve oran limitleri

2. Üç eksenli MoE yönlendirme

Baidu'ya göre ERNIE 5.1, MoE yönlendirmesini aynı anda şu eksenlerde yapıyor:

derinlik
genişlik
seyreklik

Çoğu MoE modelinde yönlendirme esas olarak hangi uzmanların etkinleşeceğiyle ilgilidir. ERNIE 5.1'deki iddia, modelin daha az aktif parametreyle araç kullanımı ve muhakeme performansını koruyabildiği yönünde. Bu yaklaşım, klasik GShard tarzı MoE'den çok DeepSeek-V3.x çizgisine daha yakın duruyor.

3. Araç kullanımı ana özellik haline geliyor

ERNIE 5.0 daha çok bilgi ve yaratıcı yazım modeli olarak konumlandırılmıştı. ERNIE 5.1 ise açık şekilde araç kullanımı, çok turlu görev yürütme ve kod yorumlayıcı destekli muhakeme tarafına odaklanıyor.

Bu nedenle ERNIE 5.1'i değerlendirirken yalnızca sohbet kalitesine bakmayın. Şu senaryoları da test edin:

JSON araç çağırma doğruluğu
yanlış araç seçme oranı
çok adımlı görevlerde durum takibi
başarısız API yanıtlarında toparlanma
uzun görevlerde tutarlılık

Kıyaslamalar: ERNIE 5.1 nerede duruyor?

Baidu'nun paylaştığı sonuçlar ve en yakın karşılaştırma noktaları şöyle:

Kıyaslama	ERNIE 5.1	Neyi test eder?	En yakın rakip
Arena Search liderlik tablosu	1,223 puan; küresel 4., Çin 1.	İnsan değerlendirmeli arama destekli soru-cevap	Gemini 3.1 Pro, GPT-5.x
τ³-bench	DeepSeek-V4-Pro'yu geçtiği açıklandı	Çok turlu araç kullanımı	DeepSeek-V4-Pro
SpreadsheetBench-Verified	DeepSeek-V4-Pro'yu geçtiği açıklandı	Gerçek dünya e-tablo görevleri	DeepSeek-V4-Pro
AIME26, araçlarla	99.6	Kod yorumlayıcı destekli rekabetçi matematik	GPT-5.x, Gemini 3.1 Pro
GPQA	“Önde gelen kapalı kaynak modellere yaklaşıyor”	Lisansüstü düzeyde bilimsel soru-cevap	Claude Sonnet 4.6
MMLU-Pro	“Önde gelen kapalı kaynak modellere yaklaşıyor”	Geniş alan bilgisi	Öncü modeller

Bu sonuçları yorumlarken dikkatli olun:

Arena puanları istem karışımına ve değerlendirici havuzuna bağlıdır.
Çince ağırlıklı istemler ERNIE 5.1'e avantaj sağlamış olabilir.
AIME26 sonucu araç desteklidir; saf muhakeme skoru açıklanmamıştır.
Yaratıcı yazım performansı “Gemini 3.1 Pro'ya yaklaşıyor” şeklinde konumlandırılmıştır, doğrudan geçtiği söylenmemiştir.

Buna rağmen τ³-bench ve SpreadsheetBench-Verified sonuçları önemlidir. İkisi de araç kullanımı merkezlidir, harici olarak sürdürülür ve pratik ajan iş akışlarına daha yakındır.

Mimari hakkında bilinenler

Baidu, DeepSeek'in V3 serisi için yaptığı kadar ayrıntılı teknik dokümantasyon paylaşmadı. Ancak yayın sonrası bilgiler şu noktaları doğruluyor:

Toplam parametreler: ERNIE 5.0'ın yaklaşık üçte biri
Token başına aktif parametreler: ERNIE 5.0'ın yaklaşık yarısı
Yönlendirme: derinlik, genişlik ve seyreklik üzerinde esnek MoE
Ön eğitim maliyeti: benzer modellerin yaklaşık %6'sı
Modalite: lansmanda yalnızca metin
Diller: Çince ve İngilizce sürümler mevcut

Açıklanmayan kritik alanlar:

kesin parametre sayısı
bağlam penceresi uzunluğu
eğitim token bütçesi
üretim oran limitleri
araç çağırma şeması ayrıntıları

Daha önce GLM 5.1 gibi Çinli MoE modelleriyle çalıştıysanız, benzer şekilde barındırılan API odaklı bir geliştirici deneyimi bekleyebilirsiniz.

ERNIE 5.1 ile henüz yapamayacaklarınız

Üretim mimarisi tasarlamadan önce sınırlamaları netleştirin.

Görsel giriş yok. ERNIE 5.1 yalnızca metin tabanlıdır. Görsel görevler için ERNIE-VL veya başka bir görsel modele ihtiyacınız olur.
Ses girişi veya çıkışı yok. Yerel konuşma, gerçek zamanlı ses veya TTS/STT özellikleri sunulmamıştır.
Yayınlanmış bağlam penceresi yok. Baidu kesin uzunluğu açıklayana kadar uzun belge iş akışlarını parçalara bölerek tasarlayın.
Hugging Face ağırlıkları yok. ERNIE 5.1 barındırılan bir modeldir. Şirket içi dağıtım gerekiyorsa DeepSeek V4'ü yerel çalıştırma veya yerel LLM seçenekleri daha uygun olabilir.

ERNIE 5.1'i hangi Çin modeliyle karşılaştırmalısınız?

DeepSeek, Kimi, GLM, Qwen ve ERNIE arasında seçim yaparken modeli iş yüküne göre değerlendirin.

ERNIE 5.1'i seçin

Şu durumlarda ERNIE 5.1 mantıklı adaydır:

Çince veya İngilizce arama destekli yanıtlar istiyorsanız
araç çağırma performansı öncelikliyse
Qianfan ekosisteminde çalışıyorsanız
Çin bulutunda barındırılan bir model sizin için uygunsa
maliyet-kalite oranını test etmek istiyorsanız

DeepSeek V4'ü seçin

Aşağıdaki ihtiyaçlar varsa DeepSeek V4 daha uygun olabilir:

açık ağırlık erişimi
şirket içi veya özel bulut dağıtımı
araçsız saf muhakeme performansı
daha fazla dağıtım kontrolü

Kimi K2.6'yı seçin

Belge ağırlıklı iş akışları, uzun bağlam ve büyük metin blokları öncelikliyse Kimi K2.6 değerlendirilmelidir.

GLM 5.1'i seçin

Daha dengeli bir genel amaçlı model arıyorsanız ve yığınınızda zaten Z.ai veya Zhipu bileşenleri varsa GLM 5.1 uygun aday olabilir.

Bu bir sıralama değil. En iyi yaklaşım, kendi görevlerinizden 20-50 örnek seçip modelleri aynı istemler, aynı araç şemaları ve aynı başarı kriterleriyle karşılaştırmaktır.

ERNIE 5.1'i bugün nerede deneyebilirsiniz?

Üç pratik yol var.

1. ERNIE sohbet arayüzü

ernie.baidu.com üzerinden tüketici sohbet arayüzünü kullanabilirsiniz.

Kullanım alanı:

hızlı deneme
yaratıcı yazım
genel muhakeme
model davranışını manuel gözlemleme

API anahtarı gerekmez, ancak bölgesel erişim ve hesap doğrulama koşulları değişebilir.

2. Baidu AI Studio ERNIE 5.1 Oyun Alanı

Baidu AI Studio üzerindeki ERNIE 5.1 Oyun Alanı, araç çağırma demolarıyla birlikte gelir.

Bunu şu amaçlarla kullanın:

araç çağırma biçimini görmek
modelin fonksiyon seçimini test etmek
API entegrasyonuna geçmeden önce hızlı prototip yapmak

3. Qianfan API

Üretim entegrasyonu için geliştirici uç noktası Qianfan API'dir. Baidu, OpenAI uyumlu istek şekli ve Bearer token doğrulaması sunar.

Daha ayrıntılı uygulama akışı için ERNIE 5.1 API'si Nasıl Kullanılır yazısına bakabilirsiniz.

Birden fazla Çin modeli sağlayıcısını aynı anda değerlendiriyorsanız, Apidog ile her sağlayıcı için istek gövdelerini kaydedebilir, anahtarları yönetebilir ve yanıtları aynı çalışma alanında karşılaştırabilirsiniz.

Apidog ile ERNIE 5.1 değerlendirme akışı

ERNIE 5.1'i mevcut modelinizle karşılaştırmak için basit bir test akışı kurabilirsiniz.

1. Sağlayıcı uç noktalarını ayırın

Örneğin şu koleksiyonları oluşturun:

LLM Eval
├── ERNIE 5.1 / Qianfan
├── DeepSeek V4
├── Kimi K2.6
└── GLM 5.1

Her koleksiyonda aynı görevleri farklı sağlayıcılara gönderin.

2. Ortam değişkenleri tanımlayın

QIANFAN_API_KEY=...
DEEPSEEK_API_KEY=...
KIMI_API_KEY=...
GLM_API_KEY=...

Böylece anahtarları istek gövdelerine gömmeden test edebilirsiniz.

3. Aynı istem setini kullanın

Örneğin araç kullanımı için 20-50 vaka seçin:

{
  "task": "Müşterinin son 3 siparişini bul ve geciken teslimat varsa destek kaydı aç.",
  "expected_tools": ["get_customer", "list_orders", "create_ticket"],
  "success_criteria": [
    "Doğru müşteri sorgulanmalı",
    "Siparişler filtrelenmeli",
    "Yalnızca gecikme varsa destek kaydı açılmalı"
  ]
}

Her model için aynı görevi çalıştırın ve şu metrikleri izleyin:

doğru araç seçimi
doğru argüman üretimi
gereksiz araç çağrısı
hatalı yanıt sonrası toparlanma
toplam gecikme
toplam token maliyeti

4. Model yanıtlarını yan yana karşılaştırın

Karşılaştırmada yalnızca “cevap güzel mi?” diye bakmayın. Üretim için daha faydalı puanlama şeması şöyle olabilir:

0 = başarısız, yanlış araç veya yanlış sonuç
1 = kısmen doğru, manuel düzeltme gerekiyor
2 = doğru, ancak gereksiz adım var
3 = doğru, kısa ve üretime uygun

Bu yaklaşım, halka açık benchmark sonuçlarından daha güvenilir bir karar zemini sağlar.

Fiyatlandırma ve dağıtım

Baidu, ERNIE 5.1'in piyasaya çıkışını takip eden haftalarda 10'dan fazla yaratıcı üretim platformunda kullanılabilir olacağını duyurdu.

Qianfan üzerindeki token başına fiyatlandırma duyuru yazısında paylaşılmadı. Bu nedenle fiyat varsayımıyla mimari kurmayın. Üretime geçmeden önce şunları kontrol edin:

canlı Qianfan fiyat sayfası
giriş ve çıkış token fiyatı
oran limitleri
kurumsal kota
bölgesel erişim
faturalandırma para birimi
veri saklama politikaları

Yaklaşık %6 ön eğitim maliyeti iddiası önemli, ancak bunun API fiyatına nasıl yansıyacağını görmek için resmi Qianfan konsolunu baz almak gerekir.

Üretim entegrasyonu için öneriler

ERNIE 5.1'i uygulamanıza eklemeden önce şu adımları izleyin.

1. Halka açık benchmark yerine kendi eval setinizi kullanın

τ³-bench iyi bir sinyal olabilir, ancak sizin iş yükünüz değildir. Kendi araç kullanım desenlerinizi yansıtan küçük ama gerçekçi bir test seti oluşturun.

Örnek kategoriler:

müşteri destek otomasyonu
sipariş ve envanter sorguları
finansal tablo işlemleri
belge özetleme
çok adımlı API çağrıları
hata durumunda retry mantığı

Apidog ile benzer bir test yaklaşımı için LLM'leri API olarak test etme rehberine bakabilirsiniz.

2. Çin bulutu gereksinimlerini baştan değerlendirin

Qianfan Çin merkezli bir altyapıdır. Veri ikameti, uyumluluk veya müşteri sözleşmeleriniz “ÇHC altyapısı kullanılamaz” diyorsa, ERNIE 5.1 teknik olarak iyi sonuç verse bile uygun seçenek olmayabilir.

Kontrol etmeniz gerekenler:

veri işleme bölgesi
günlükleme politikası
kurumsal sözleşme koşulları
müşteri verisi sınıflandırması
regülasyon kapsamı

3. Fiyatlandırma duyurusunu bekleyin

ERNIE 5.1'in en dikkat çekici iddialarından biri maliyet tarafında. Baidu bu maliyet avantajını API fiyatına yansıtırsa, DeepSeek, Zhipu ve Moonshot gibi sağlayıcılar üzerinde fiyat baskısı oluşabilir.

Üretim kararı için önerilen sıra:

teknik kalite testi
araç çağırma doğruluğu testi
gecikme testi
maliyet testi
uyumluluk kontrolü
küçük trafik yüzdesiyle canlı deneme

Sıkça Sorulan Sorular

ERNIE 5.1 açık kaynak mı?

Hayır. ERNIE 5.1, Baidu'nun sohbet arayüzü, Baidu AI Studio ve Qianfan API üzerinden erişilebilen barındırılan bir modeldir. Yazının yazıldığı tarihte Hugging Face üzerinde halka açık ağırlıklar bulunmamaktadır.

ERNIE 5.1 görsel veya resim girişini destekliyor mu?

Hayır. ERNIE 5.1 lansmanda yalnızca metin tabanlıdır. Görsel görevler için Baidu'nun ERNIE-VL ailesi veya başka bir multimodal model gerekir. Tek bir çok modlu Çin modeli arıyorsanız Qwen 3.5 Omni değerlendirilebilir.

Bağlam uzunluğu nedir?

Baidu, ERNIE 5.1 için net bir bağlam penceresi uzunluğu açıklamadı. Bu bilgi doğrulanana kadar uzun belge iş akışlarında parçalama, özetleme ve retrieval tabanlı tasarım kullanmak daha güvenlidir.

ERNIE 5.1'i Çin dışından kullanabilir miyim?

Sohbet arayüzü ve Qianfan API çoğu bölgeden erişilebilir olabilir; ancak gecikme, hesap doğrulaması ve kurumsal özellikler değişebilir. Bazı özellikler anakara Çin telefon numarası veya iş lisansı gerektirebilir. Ayrıntılı erişim akışı için ERNIE 5.1 API'si Nasıl Kullanılır rehberine bakabilirsiniz.

ERNIE 5.1, DeepSeek-V4-Pro'dan daha iyi mi?

Baidu'nun paylaştığı sonuçlara göre ERNIE 5.1, τ³-bench ve SpreadsheetBench-Verified'da DeepSeek-V4-Pro'yu geçiyor. Ancak açık ağırlık erişimi tarafında DeepSeek avantajlıdır. Araç kullanmadan saf matematik muhakemesinde ise mevcut halka açık veriler kesin bir cevap vermiyor. En doğru yaklaşım, iki modeli kendi iş yükünüzde karşılaştırmaktır.

Sonuç

ERNIE 5.1, Baidu'nun araç kullanımı, arama destekli yanıtlar ve maliyet verimliliği tarafında daha agresif konumlandığı bir sürüm. Üretim için doğrudan geçiş kararı vermek yerine küçük bir eval seti oluşturun, mevcut modelinizle aynı görevlerde test edin ve Qianfan fiyatlandırmasını netleştirin.

Geliştirmeye başlamaya hazırsanız, Apidog'u kullanarak Qianfan OpenAPI spesifikasyonunu içe aktarabilir ve ERNIE 5.1'i mevcut modelinizle aynı çalışma alanında karşılaştırabilirsiniz.

Apidog Spec-First Modu ile Bir Sabah: Görsel Tasarımcı Artık Tek Yetkili Değil

Tobias Hoffmann — Thu, 14 May 2026 07:09:01 +0000

Çalıştığım her API ekibinde aynı ayrım vardı: OpenAPI dosyasını Git’te tek doğruluk kaynağı yapanlar ve görsel tasarım aracı üzerinden ilerleyip gerektiğinde spesifikasyon dışa aktaranlar.

Apidog'u bugün deneyin

İlk yaklaşım başlangıçta daha yavaştır ama uzun vadede daha öngörülebilirdir. İkincisi hızlı başlatır; ancak zamanla “araçtaki API” ile “depodaki OpenAPI dosyası” arasında fark oluşabilir.

Apidog uzun süre daha çok ikinci akışa uygundu: güçlü bir görsel tasarımcı, dokümantasyon, test ve mock özellikleri vardı; fakat YAML/JSON dosyasını doğrudan Git merkezli yönetmek isteyen ekipler için akış tam oturmuyordu.

Nisan ortasında Spec-First Modu (Beta), Yeni Proje ekranına eklendi. Bir yan projemdeki OpenAPI spesifikasyonuyla denedim. Bu yazıda, Spec-First Modu’nun pratikte ne değiştirdiğini, nasıl kurulduğunu ve hangi ekipler için anlamlı olduğunu anlatıyorum.

Spec-First Modu neyi değiştiriyor?

Apidog artık iki farklı proje akışı sunuyor:

Genel Mod: Uç noktaları görsel formlarla tasarlarsınız. OpenAPI çıktısı arka planda oluşur.
Spec-First Modu: OpenAPI dosyası doğrudan .yaml veya .json olarak düzenlenir. Git deposu dosyanın ana kaynağıdır.

Spec-First Modu’nda Apidog, form tabanlı düzenleyicinin yerine kod düzenleyici verir:

OpenAPI şemasına göre otomatik tamamlama
Sözdizimi vurgulama
Dosyadan gerçek zamanlı uç nokta taslağı çıkarma
Git deposuyla çift yönlü senkronizasyon
Commit ve push işlemlerini arayüzden yapma

Buradaki temel fark şu: Spesifikasyon artık görsel arayüzün ürettiği bir çıktı değil, deponuzdaki dosyanın kendisi.

Bu özellikle OpenAPI’yi elle yazan ekipler için önemli. YAML dosyası üzerinde çalışırken yapı bazen gözden kaçar. Apidog’un sol taraftaki canlı taslak görünümü, dosyayı bırakmadan gezinmeyi kolaylaştırır. Spesifikasyonu yazarsınız; Apidog aynı anda endpoint ağacını çıkarır.

Uçtan uca kurulum

Aşağıdaki akışla mevcut bir Git deposundaki OpenAPI dosyasını Apidog Spec-First projesi olarak açabilirsiniz.

1. Yeni projeyi Spec-First Modu ile oluşturun

Apidog’da:

+ Yeni Proje → Genel → Spec-first Modu

Genel Mod varsayılan olarak öne çıkarıldığı için bu ekranda doğru kutucuğu seçtiğinizden emin olun. Spec-First Modu beta etiketiyle görünür.

2. Git deponuzu bağlayın

Ardından Git Deposu ile Bağlan seçeneğini kullanın.

Seçmeniz gerekenler:

Organizasyon
Depo
Ana dal

Örneğin:

Organizasyon: my-org
Depo: petstore-api
Ana dal: main

Apidog, seçilen daldaki .yaml ve .json dosyalarını çalışma alanına senkronize eder.

3. Proje ayarlarını tamamlayın

Bir proje adı girin, ekip erişimlerini ayarlayın ve Oluştur düğmesine tıklayın.

İlk senkronizasyonda depodaki OpenAPI dosyaları Apidog çalışma alanına alınır.

4. Spesifikasyonu dosya olarak düzenleyin

Bir OpenAPI YAML dosyası açın.

Örneğin aşağıdaki gibi bir endpoint eklediğinizde:

paths:
  /orders/{orderId}:
    get:
      summary: Sipariş detayını getir
      parameters:
        - name: orderId
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Başarılı yanıt

Apidog, sol taraftaki taslak görünümde ilgili route’u otomatik olarak gösterir. Endpoint’e tıkladığınızda dosyadaki ilgili satıra gidersiniz.

VS Code’da OpenAPI uzantılarıyla çalışmaya alışkınsanız deneyim tanıdık gelir. Fark, Apidog’un aynı çalışma alanında API dokümantasyonu, test ve proje görünümünü de sağlamasıdır.

5. Commit ve push yapın

Sağ üstten Commit & Push düğmesine tıklayın.

Açılan pencerede:

Değişen dosyaları görürsünüz
Commit mesajı yazarsınız
Push işlemini başlatırsınız

Örnek commit mesajı:

Add order detail endpoint to OpenAPI spec

Ayrı bir staging adımı yoktur. Değişiklikler bölümündeki dosyalar commit’e dahil edilir.

6. Senkronizasyon durumunu kontrol edin

Sol alt köşedeki senkronizasyon göstergesini takip edin.

Duruma göre şunu anlarsınız:

Yerel değişiklikler push edilmeyi bekliyor mu?
Uzak depo sizden ileride mi?
Çalışma alanı depoyla aynı durumda mı?

Gösterge “Şimdi senkronize edildi” durumundaysa Apidog’daki dosya ve Git deposundaki dosya aynı noktadadır.

Deneyimde öne çıkan noktalar

Canlı endpoint taslağı hızlı çalışıyor

Bazı OpenAPI düzenleyicilerinde kenar çubuğu yalnızca dosya kaydedildiğinde veya belirli aralıklarla güncellenir. Burada endpoint taslağı yazarken güncellendi.

Bu küçük görünse de pratikte önemli. Büyük bir OpenAPI dosyasında çalışırken sol taraftaki yapı görünümünü gerçek navigasyon aracı olarak kullanabiliyorsunuz.

Git entegrasyonu çift yönlü

Apidog açıkken aynı dosyada yerel klondan değişiklik yapıp terminalden push ettiğinizde Apidog bunu algılıyor. Senkronizasyon durumu değişiyor ve uzaktaki güncellemeler çalışma alanına alınabiliyor.

Bu, karma ekipler için kullanışlı:

Bir geliştirici Vim veya VS Code ile çalışabilir
Başka biri Apidog arayüzünü kullanabilir
İkisi de aynı Git deposundaki OpenAPI dosyasını günceller

Tek doğruluk kaynağı yine depo olur.

Proje modu sonradan değiştirilemiyor

Spec-First Modu’nda oluşturulan proje, aynı proje içinde Genel Mod’a dönmüyor. Bu bilinçli bir ayrım; çünkü veri modeli ve çalışma şekli farklı.

Aynı spesifikasyon için iki akışa ihtiyaç varsa uygulanabilir seçenek şu:

OpenAPI dosyasını Git deposunda tutun.
Bu depoyu bir Spec-First projesine bağlayın.
Görsel mod kullanacak ekipler için aynı kaynaktan ayrı bir proje oluşturun.

Bu tamamen sorunsuz bir geçiş değil; ancak tek dosya kaynağını korumak isteyen ekipler için uygulanabilir.

Ne zaman kullanmalı?

Spec-First Modu şu durumlarda iyi uyuyor:

OpenAPI dosyalarını zaten elle yazıyorsanız
Spesifikasyonun Git’te kalması gerekiyorsa
CI sürecinizde spectral lint gibi kontroller varsa
SDK veya dokümantasyon üretimini OpenAPI dosyasından yapıyorsanız
Pull request üzerinden API değişikliği incelemek istiyorsanız
“Apidog’daki spec” ile “depodaki spec” arasında fark oluşmasını istemiyorsanız

Örnek CI akışı şöyle olabilir:

name: OpenAPI checks

on:
  pull_request:
    paths:
      - "openapi/**/*.yaml"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint OpenAPI spec
        run: npx @stoplight/spectral-cli lint openapi/api.yaml

Bu tarz bir akışta Spec-First Modu anlamlıdır; çünkü Apidog’da yaptığınız değişiklikler doğrudan Git’teki dosyaya commit edilir.

Ne zaman kullanmamalı?

Aşağıdaki durumlarda Genel Mod daha doğru olabilir:

Ekibiniz OpenAPI yazmaya alışık değilse
Katkı verecek kişiler YAML/JSON düzenlemek istemiyorsa
Görsel formlar ekip için ana üretim aracıysa
Aynı proje içinde sürekli görsel mod ve spec-first mod arasında geçiş yapmanız gerekiyorsa

Spec-First Modu, kullanım kolaylığının bir kısmını doğruluk ve Git merkezli çalışma karşılığında takas eder. API uzmanlığı az olan ekiplerde bu takas her zaman doğru olmayabilir.

Sonuç

Spec-first geliştirme genelde şu ikileme sıkışıyordu:

Ya OpenAPI dosyasında yaşayıp API platformunun görsel özelliklerinden uzak kalırsınız
Ya da görsel tasarımcıda çalışıp Git’teki dosyayı ikincil çıktı haline getirirsiniz

Apidog Spec-First Modu bu ayrımı azaltıyor. Deponuzdaki OpenAPI dosyası çalışma alanının merkezinde kalıyor; Apidog ise bu dosyanın üzerinde düzenleme, gezinme ve Git senkronizasyonu sağlayan bir arayüz oluyor.

OpenAPI’yi Git’te tek doğruluk kaynağı olarak yönetiyorsanız, Spec-First Modu denemeye değer. Güvenli bir depoda yeni bir proje oluşturun, Spec-First Modu’nu seçin ve ilk commit’i yapın. Kurulum kısa sürüyor; ekibinizin akışına uyup uymadığını görmek için birkaç gerçek değişiklik üzerinde denemek yeterli.

Claude Planınız ile Claude Agent SDK Nasıl Kullanılır?

Tobias Hoffmann — Thu, 14 May 2026 04:03:20 +0000

Anthropic, 15 Haziran 2026'dan itibaren Claude Agent SDK'yı mevcut Claude aboneliğinizle kullanmanıza izin veriyor. Önceden Agent SDK ile geliştirme yapmak için Claude Pro veya Max aboneliğinizden ayrı, kullandıkça öde faturalandırmalı bir API anahtarı gerekiyordu. Artık aylık Claude planınız, Agent SDK kullanımı için ayrı bir kredi bakiyesi içeriyor. API anahtarı gerekmez.

Apidog'u bugün deneyin

Özel bir aracı oluşturmak istiyorsanız (dağıtım botu, araştırma asistanı, ön eleme aracı gibi) ancak sadece prototip için Anthropic'e ayrı bir fatura kartı tanımlamak istemiyorsanız, bu önemli bir değişiklik. Pro aboneliği ayda 20 dolarlık Agent SDK kredisiyle geliyor. Max 20x için 200 dolar, Team Premium koltukları için 100 dolar kredi sağlanıyor.

15 Haziran 2026'da ne değişti?

Kısa hali: Agent SDK kullanımı artık Claude planınıza bağlı aylık krediden düşülüyor. Daha önce bu kullanım, Anthropic API üzerinden ayrı bir konsol bakiyesiyle faturalandırılıyordu.

Planlara göre kredi miktarları:

Plan	Aylık Agent SDK kredisi
Pro	$20
Max 5x	$100
Max 20x	$200
Team Standard (koltuk başına)	$20
Team Premium (koltuk başına)	$100
Enterprise (kullanıma dayalı)	$20
Enterprise Premium koltuğu	$200

Dikkat etmeniz gereken kurallar:

Enterprise Standard koltuk üyeleri kredi almaz. API anahtarı kullanmaları veya Premium koltuğa yükseltmeleri gerekir.
Krediler kullanıcı başına verilir ve devredilemez. Kendi kredinizi ekip arkadaşınızın kredisiyle birleştiremezsiniz.
Kullanılmayan krediler devretmez. Fatura döneminin sonunda kalan bakiye sıfırlanır.
Bir defalık katılım gerekir. Krediyi bir kez talep etmeden hesabınızda etkinleşmez. Sonrasında her ay otomatik yenilenir.
API anahtarıyla kimlik doğrulayanlar bu krediyi kullanmaz. ANTHROPIC_API_KEY ile çalışıyorsanız eski faturalandırma modelindesiniz.

Kredi neleri kapsar?

Anthropic, Agent SDK kredisinin kapsamını ayrı tanımlıyor. Faturanızın değişip değişmeyeceği bu ayrıma bağlı.

Agent SDK kredisi tarafından kapsananlar:

Python veya TypeScript projelerinizden yapılan Claude Agent SDK çağrıları
Claude Code içindeki claude -p komutu
Claude Code GitHub Actions entegrasyonu
Agent SDK ile kimlik doğrulayan üçüncü taraf uygulamalar

Kapsanmayanlar:

Etkileşimli Claude Code oturumları
Claude web veya mobil uygulamasındaki konuşmalar
Claude Cowork oturumları

Yani Agent SDK kredisi, özellikle programatik, otomatikleştirilmiş veya etkileşimli olmayan işler içindir. Normal Claude Code kullanımınız, Anthropic'in 13 Temmuz'a kadar %50 artırdığı mevcut plan limitleri içinde kalır.

Pratik sonuç: Claude Code ile günlük kodlama limitlerinizi tüketmeden SDK tabanlı özel araçlar geliştirebilirsiniz.

Kredi bittiğinde ne olur?

Aylık kredi sabit bir dolar tutarıdır. Bu tutarı aştığınızda davranış, ek kullanım ayarınıza bağlıdır:

Ek kullanım etkinse: Aşım, planınızın ödeme yöntemine standart API oranlarıyla kullandıkça öde şeklinde faturalandırılır.
Ek kullanım kapalıysa: İstekler, fatura döngüsü sıfırlanana kadar durur.

Prototip geliştirirken ek kullanımı kapalı tutmak daha güvenlidir. Böylece beklenmedik fatura oluşmaz. Üretim otomasyonları kesintisiz çalışmalıysa ek kullanımı etkinleştirin.

Kredi her zaman önce kullanılır. Aylık hakkınız bitmeden aşım ücreti ödemezsiniz.

Agent SDK kredisi nasıl etkinleştirilir?

Kredi varsayılan olarak aktif değildir. Bir kez etkinleştirmeniz gerekir.

Aboneliğin sahibi olan Claude hesabına giriş yapın.
- Pro/Max için kendi kullanıcı hesabınız
- Team/Enterprise için ilgili koltuk hesabı
Claude Agent SDK plan ayarlarına gidin. Bu bağlantı Anthropic'in resmi destek makalesinde yer alır.
Krediyi talep edin.

Team planında birden fazla koltuk varsa her kullanıcı bunu ayrı ayrı yapmalıdır. Yöneticiler, kullanıcılar adına kredi talep edemez.

Python veya TypeScript ile SDK kurulumu

Agent SDK hem Python hem TypeScript için kullanılabilir. İkisi de plan tabanlı kimlik doğrulama için ham API anahtarı yerine Claude Code CLI oturumunu kullanır.

Python

Kurulum:

pip install claude-agent-sdk

Önce Claude Code'a giriş yapın:

claude login

Bu komut, planınıza bağlı kimlik bilgilerini yerel olarak saklar. Python SDK bunları otomatik kullanır. Plan tabanlı kullanım için ANTHROPIC_API_KEY ayarlamayın.

Minimal bir aracı örneği:

from claude_agent_sdk import Agent

agent = Agent(
    system_prompt="You are a code review assistant.",
)

response = agent.run("Review the diff in /tmp/patch.diff and flag concerns.")
print(response.text)

Bu çağrı daha önce ANTHROPIC_API_KEY ve ayrı API faturalandırması gerektiriyordu. Artık plan kredinizden düşülür.

TypeScript

Kurulum:

npm install @anthropic-ai/claude-agent-sdk

Claude Code ile giriş yapın:

claude login

Minimal TypeScript aracı:

import { Agent } from "@anthropic-ai/claude-agent-sdk";

const agent = new Agent({
  systemPrompt: "You are a code review assistant.",
});

const response = await agent.run(
  "Review the diff in /tmp/patch.diff and flag concerns."
);

console.log(response.text);

CI runner, Docker container veya uzak geliştirme ortamı gibi yerlerde SDK Claude Code kimlik bilgilerini otomatik bulamayabilir. Bu durumda kimlik bilgilerini ortam değişkenleriyle sağlayabilirsiniz. Anthropic, değişken adlarını Agent SDK belgelerinde yayınlıyor.

Claude Code girişiniz SDK kurulumundan önce yapılandırma hatası veriyorsa, geçersiz custom3p kurumsal yapılandırma düzeltmesi yaygın nedeni kapsar.

`claude -p` ile etkileşimsiz iş akışları

Agent SDK kredisini kod yazmadan kullanmanın bir yolu da Claude Code içindeki claude -p komutudur.

-p, Claude Code'u etkileşimsiz moda alır. Komutu verirsiniz, deponuz üzerinde çalışır ve çıkar. Sohbet oturumu açılmaz. Bu mod; CI pipeline'ları, cron işleri ve Git hook'ları için uygundur.

Örnek: staged diff üzerinde güvenlik ve kırıcı değişiklik kontrolü yapan pre-commit hook.

#!/usr/bin/env bash
# .git/hooks/pre-commit

DIFF=$(git diff --cached)

claude -p "Review this diff for security issues, secret leaks, and breaking changes. Return PASS or FAIL with reasoning:\n\n$DIFF"

15 Haziran'dan sonra yapılan her claude -p çağrısı, etkileşimli Claude Code bütçenizden değil Agent SDK kredinizden düşülür.

Bu yaklaşım, otonom döngüler için /goal komutu ve çalıştırmalar arasında bağlamı korumak için AGENTS.md dosyaları ile iyi çalışır.

GitHub Actions entegrasyonu

Claude Code GitHub Actions entegrasyonu da SDK kredisi kapsamındadır.

Claude'u PR incelemelerine, issue ön elemesine veya sürüm notu üretimine bağladıysanız, bu workflow çalıştırmaları artık GitHub App'i kuran kullanıcının Agent SDK kredisinden düşülür.

Bu, otomasyonun sürekli çalıştığı ve faturanın API anahtarına yazıldığı Claude Code üzerine kurulu GitHub ön eleme botu Clawsweeper gibi projeler için kullanışlıdır.

Gerçek aracılar oluşturma: SDK + Apidog

Agent SDK'nın asıl değeri, yalnızca metin üretmeyen; gerçek API'lere bağlanan, veritabanlarını sorgulayan veya dağıtım yapan aracılarda ortaya çıkar.

Bunun güvenilir çalışması için aracının çağırdığı her API'nin açık bir sözleşmesi olmalıdır. Aksi halde aracı endpoint yapılarını tahmin eder ve siz zamanınızı hatalı payload'ları düzeltmeye harcarsınız.

Apidog bu iş akışına şu şekilde oturur:

API sözleşmesini önce Apidog'da tanımlayın. Endpoint'leri, request/response şemalarını ve örnek payload'ları belirleyin.
OpenAPI çıktısını dışa aktarın. Bunu aracınıza bağlam olarak verin.
SDK ile aracı gerçek endpoint'lere bağlayın. Aracı, doğruluğu tanımlı şemalara göre API çağrısı yapar.
Apidog CLI ile doğrulayın. Her aracı çalıştırmasında API'nin sözleşmeye uygun yanıt verdiğini test edin.

MCP sunucuları üzerinden başka araçları yöneten aracılar için Apidog ile MCP sunucu test iş akışı da kullanılabilir. Böylece aracınızın çağırdığı araçlar için uçtan uca test kapsamı elde edersiniz.

Daha geniş yaklaşım için tasarım odaklı API iş akışı kılavuzuna bakabilirsiniz. Aracının doğrulayabileceği bir sözleşme olduğunda, JSON şema hatalarını kovalamak yerine daha iyi API sözleşmeleri yazmaya odaklanırsınız.

Agent SDK projeleriniz için sözleşme katmanı istiyorsanız Apidog'u ücretsiz indirebilirsiniz.

Ne zaman ayrı API anahtarı kullanmalısınız?

Plan tabanlı kredi çoğu geliştirici için iyi varsayılandır. Ancak bazı durumlarda ayrı API anahtarı daha uygundur:

Tahmin edilebilir bütçeye ihtiyaç duyan üretim araçları: Plan kredileri sabit tutarlıdır. Daha yüksek veya sınırsız ölçek gerekiyorsa, kullanıma dayalı API anahtarı daha temiz faturalandırma sağlar.
Çoklu organizasyon erişimi: API anahtarları tek bir kullanıcı koltuğuna bağlı değildir. Ekip ortak bir faturalandırma kaynağı istiyorsa API anahtarı daha uygundur.
Enterprise Standard koltukları: Bu koltuklar Agent SDK kredisi almaz. SDK kullanımı için API anahtarı gerekir.

Ücretsiz Claude API erişim kılavuzu, Pro plan veya ücretli API anahtarı gerektirmeyen kullanım yollarını kapsar.

Başlamadan önce kontrol listesi

[ ] Planınızın uygun olduğunu doğrulayın: Pro, Max 5x, Max 20x, Team Standard, Team Premium, Enterprise kullanıma dayalı veya Enterprise Premium koltuk
[ ] Agent SDK kredisi için bir defalık katılımı tamamlayın
[ ] Ek kullanımı açıp açmayacağınıza karar verin
- Prototip: kapalı
- Üretim: açık
[ ] SDK'yı planınıza bağlamak için claude login çalıştırın
[ ] Python veya TypeScript SDK paketini kurun
[ ] Minimal bir aracı oluşturun
[ ] ANTHROPIC_API_KEY ayarlamadan çalıştığını doğrulayın
[ ] İlk çalıştırmalardan sonra hesap ayarlarında kredi bakiyesini kontrol edin

Sıkça Sorulan Sorular

Plan kredisinin çalışması için eski ANTHROPIC_API_KEY değerini kaldırmam gerekir mi?

SDK, Claude Code'un yerel kimlik bilgilerini kullandığında plan tabanlı faturalandırmaya geçmek için claude login yeterlidir. Ortamınızda başka araçlar için ANTHROPIC_API_KEY varsa bırakabilirsiniz; SDK, plan kimlik doğrulaması mevcutsa onu kullanır.

Krediye karşı bir “istek” olarak ne sayılır?

Kredi istek sayısı olarak değil dolar olarak tanımlanır. Her SDK çağrısı, Anthropic'in API kullanım oranlarına göre ücretlendirilir. Model çağrısı, bağlam token'ları ve araç kullanımı maliyeti kredi bakiyenizden düşülür. Ek bir istek başı ücret yoktur.

Kredimi ekip arkadaşımla paylaşabilir miyim?

Hayır. Krediler kullanıcı başınadır ve devredilemez. Her Team veya Enterprise koltuğunun kendi kredi havuzu vardır.

Eski Anthropic API konsol bakiyeme ne olur?

Aynı kalır. Plan kredisi ayrı bir faturalandırma mekanizmasıdır. API konsolundaki ön ödemeli bakiye, API anahtarıyla çalışan işler için kullanılmaya devam eder.

Agent SDK, Claude Code ile aynı mı?

Hayır. Claude Code, Anthropic'in resmi CLI ve IDE uzantılarıdır. Agent SDK ise özel aracılar oluşturmak için kullanılan Python/TypeScript kütüphanesidir. Kredi; SDK'yı, claude -p komutunu, GitHub Actions entegrasyonunu ve üçüncü taraf Agent SDK uygulamalarını kapsar. Etkileşimli Claude Code normal plan kullanımında kalır.

GitHub Actions faturam değişir mi?

Resmi Claude Code GitHub Actions entegrasyonunu kullanıyorsanız ve krediyi kurulumu yapan kullanıcı talep ettiyse, bu çalıştırmalar artık API anahtarı faturalandırması yerine SDK kredisinden düşülür.

Kredi Agent SDK ve claude -p dışında çalışır mı?

Hayır. Kapsam şunlarla sınırlıdır: Python/TypeScript Agent SDK, claude -p, Claude Code GitHub Actions entegrasyonu ve üçüncü taraf Agent SDK uygulamaları. Diğer Claude kullanımları, isteğin kaynağına göre normal plan limitlerinize veya API anahtarınıza döner.

Claude Kod Haftalık Limitleri 13 Temmuz'a Kadar %50 Arttı: Pro, Max ve Takım Kullanıcıları Ekstra Kotayla Ne Yapmalı?

Tobias Hoffmann — Thu, 14 May 2026 03:02:34 +0000

Anthropic, Claude Code haftalık kullanım limitlerini %50 artırdı. Artış hemen geçerli ve 13 Temmuz TSİ 18:00'e (14 Temmuz GMT 01:00) kadar sürecek. Pro, Max, Team ve koltuk tabanlı Kurumsal planlarda; CLI, IDE uzantıları, masaüstü uygulaması ve web dahil Claude Code'un çalıştığı her yerde geçerli. Ek işlem yapmanız gerekmiyor: yeni tavan hesabınızda aktif. Geçen hafta 5 saatlik limitlerin ikiye katlandığını da düşünürsek, kısa süreli kotada 2 kat, haftalık tavanda 1,5 kat kapasiteyle çalışabilirsiniz. Bu yazıda, bu ek kapasiteyi ajan iş akışları, MCP kullanımı ve Apidog ile API tasarımı/testi gibi gerçek mühendislik işlerine nasıl uygulayacağınızı adım adım ele alıyoruz.

Apidog'u bugün deneyin

Haftalık limitler nelerdir ve %50 daha fazla ne anlama geliyor?

Claude Code ücretli planlarda iki katmanlı bir kullanım limiti uygular:

5 saatlik limitler: Herhangi bir 5 saatlik pencerede tüketebileceğiniz token üst sınırı. Uzun hata ayıklama, özellik geliştirme veya refactor oturumlarında bu limite takılırsınız. Anthropic bunu önceki hafta ikiye katladı.
Haftalık limitler: Hafta boyunca toplam token tüketiminiz için üst sınır. Yoğun sprint sonunda genellikle bu limit hissedilir. Yeni güncellemeyle %50 artırılan limit budur.

Tam token sayıları plan katmanına bağlıdır ve Anthropic bunları sabit değerler olarak yayınlamaz. Pratikte değişiklik şu anlama gelir:

Pro kullanıcıları, haftalık uyarıya ulaşmadan önce daha fazla çalışma alanı kazanır.
Max kullanıcıları, karmaşık bir kod tabanında çok günlük derin çalışma bloklarını daha rahat sürdürebilir.
Team ve koltuk tabanlı Kurumsal kullanıcılar, koltuk başına aynı %50 artışı alır. 10 koltuklu bir ekipte bu, organizasyon genelinde anlamlı bir kapasite artışıdır.

Yeni kullanımı şu noktalardan kontrol edebilirsiniz:

/usage

Ayrıca IDE uzantılarındaki durum çubuğunu ve web hesap ayarlarını kontrol edin.

Anthropic neden şimdi bunu yapıyor?

İki pratik neden öne çıkıyor.

İlki kapasite. Anthropic, 2026'nın ilk ve ikinci çeyreğinde yeni işlem kapasitesi sağladı. Boş kapasite olduğunda, mevcut ücretli kullanıcılara aynı ücretle daha fazla kullanım sunmak platform bağlılığını artırmanın doğrudan bir yoludur.

İkincisi rekabet. Codex kısa süre önce kendi /goal otonom ajan döngüsünü yayınladı ve OpenAI da geliştirici planlarında oran limitlerini artırıyor. 13 Temmuz'a kadar süren %50 artış, iş yüklerini farklı sağlayıcılara bölen mühendislik ekipleri için Claude Code'u daha cazip hale getiriyor.

Önemli nokta: Bu artış geçici olarak duyuruldu. 13 Temmuz TSİ 18:00'de sona eriyor. Anthropic, yeni tavanın kalıcı olup olmayacağını veya başlangıç seviyesine dönüp dönmeyeceğini açıklamadı. Bu yüzden önümüzdeki haftaları ölçüm ve doğrulama dönemi gibi kullanın.

%50'lik artış pratikte neyi değiştiriyor?

“Daha fazla kullanım” ifadesi fazla genel kalıyor. Ek haftalık kota, özellikle aşağıdaki iş akışlarında fark yaratır.

1. Daha uzun otonom ajan çalıştırmaları

İkiye katlanan 5 saatlik limitler ve %50 artan haftalık kapasite birlikte çalıştığında, /goal otonom döngüsü daha uzun süre kesintisiz çalışabilir.

Örnek görev:

/goal
Bu modüldeki ödeme akışını yeniden düzenle.
Başarı kriterleri:
- Mevcut testler geçmeli
- Yeni edge case testleri eklenmeli
- API sözleşmesi değişmemeli
- Kod tekrarları azaltılmalı

Önceden bu tür uzun bir refactor çalışması 5 saatlik bütçeyi tüketip sizi beklemeye zorlayabilirdi. Yeni pencerede Claude Code'a ölçülebilir başarı kriterleri verip daha uzun süre kendi başına ilerlemesine izin verebilirsiniz.

2. Daha büyük kod tabanı bağlamı

Claude Code'un değeri, kod tabanınızın ne kadarını bağlamda tutabildiğine göre artar. Daha yüksek limitlerle:

Daha geniş dizin ağaçlarını bağlama dahil edebilirsiniz.
Monorepo içinde daha derin analiz yaptırabilirsiniz.
“Bu klasörü çıkaralım, yoksa kota biter” gibi manuel kapsam daraltmalarını azaltabilirsiniz.

Test etmek için iyi bir yaklaşım:

# Önce mevcut kullanım durumunu kontrol edin
/usage

# Daha büyük bir çalışma alanı ile Claude Code'u başlatın
# Ardından refactor, test üretimi veya dokümantasyon görevi verin

Daha önce “Claude Code için fazla büyük” görünen bir monorepo varsa, bu dönem yeniden denemek için uygun.

3. Çoklu ajan iş akışları

Ruflo gibi Claude Code üzerinde çalışan çoklu ajan orkestratörleri, aynı göreve karşı birden fazla Claude örneği çalıştırır ve çıktıları birleştirir.

Bu modelde kullanım hızla artar çünkü paralel olarak 3-5 kat daha fazla çağrı yapılabilir. Yeni limitlerle bu yapı, yalnızca deneysel görevler için değil, günlük mühendislik işlerinde de daha uygulanabilir hale gelir.

Kullanım alanları:

Bir ajan testleri yazar.
Bir ajan uygulamayı refactor eder.
Bir ajan güvenlik ve edge case kontrolü yapar.
Bir ajan dokümantasyonu günceller.

4. Daha yoğun MCP sunucu kullanımı

Claude Code, MCP (Model Context Protocol) üzerinden harici araçları çağırabilir. Bu çağrılar da kotanıza dahil olur.

Ek kapasiteyle daha rahat zincirleyebileceğiniz MCP kullanım örnekleri:

Veritabanı sorgulama
API testi
Tarayıcı otomasyonu
GitHub issue/PR triyajı
Log analizi
Sözleşme doğrulama

Örnek akış:

1. GitHub issue'yu oku
2. İlgili servis kodunu analiz et
3. Veritabanı şemasını kontrol et
4. API testlerini çalıştır
5. Fix uygula
6. PR açıklamasını üret

Önceden bu zincir, haftalık bütçeyi hızlı tüketebilirdi. Yeni tavanda 5-6 MCP sunucusunu ardışık kullanan iş akışları daha yönetilebilir hale gelir.

Claude Code'da MCP sunucu kurulumunu engelleyen yapılandırma hatalarıyla karşılaşıyorsanız, geçersiz custom3p kurumsal yapılandırma düzeltmesi en yaygın nedeni kapsar.

Önümüzdeki sekiz hafta için uygulanabilir plan

Bu artıştan verimli faydalanmak için 13 Temmuz'a kadar üç şey yapın.

1. Ertelediğiniz ajan iş akışını devreye alın

Eski kotada sınırda kalan /goal tabanlı veya çoklu ajan kurulumunuz varsa, şimdi test edin.

Başlangıç için basit görev formatı:

/goal
Hedef: Kullanıcı profil API'sini mevcut OpenAPI sözleşmesine göre tamamla.

Başarı kriterleri:
- GET /users/{id} çalışmalı
- PATCH /users/{id} validasyonları geçmeli
- Hata yanıtları sözleşmeyle uyumlu olmalı
- Tüm mevcut testler geçmeli
- Yeni entegrasyon testleri eklenmeli

Limitler 13 Temmuz'dan sonra eski seviyeye dönse bile, iş akışının değerini ölçmüş olursunuz. Sonrasında Pro'da kalma, Max'e geçme veya iş yükünü sağlayıcılar arasında bölme kararını veriye dayalı alabilirsiniz.

2. Yan kanal işleri Claude Code'a taşıyın

Daha önce manuel yaptığınız veya daha ucuz araçlara böldüğünüz işleri Claude Code içine alın:

AGENTS.md dosyaları yazma
Kod inceleme
MCP sunucu yapılandırması
OpenAPI spec oluşturma
Test senaryosu üretimi
Migration kontrolü
Dokümantasyon güncelleme

Örneğin:

Bu repodaki ajanların nasıl çalışması gerektiğini açıklayan bir AGENTS.md dosyası oluştur.
Şunları dahil et:
- Kod stili
- Test komutları
- PR kontrol listesi
- Yasaklı değişiklikler
- API sözleşmesi kuralları

Daha kolay kazanımlardan biri için AGENTS.md dosyaları yazma kılavuzuna bakabilirsiniz.

3. Yeni tavanı gerçek iş yükünüzle test edin

Claude Code'u, yeni limitler kalıcıymış gibi kullanın. Şunları takip edin:

Haftalık kaç kez /usage kontrol ediyorsunuz?
En çok kota tüketen görevler hangileri?
Ajan çalıştırmaları nerede takılıyor?
MCP çağrıları gerçekten değer üretiyor mu?
API/test iş akışları manuel süreden ne kadar tasarruf sağlıyor?

Basit bir ölçüm tablosu tutabilirsiniz:

| Görev | Süre | Claude Code kullanımı | Çıktı | Manuel yapsaydım |
|---|---:|---:|---|---:|
| Payment API refactor | 3 saat | Orta | PR + testler | 1 gün |
| OpenAPI spec üretimi | 45 dk | Düşük | İlk spec | 3 saat |
| MCP ile test döngüsü | 2 saat | Yüksek | Fix + doğrulama | 1 gün |

Temmuz geldiğinde kararınız tahmine değil, gerçek kullanım verisine dayanır.

API çalışması için en iyi kullanım alanı

Backend ve platform mühendisleri için ek kotanın en yüksek getirili kullanımı API işleridir. Claude Code özellikle şu görevlerde güçlüdür:

Handler yazma
OpenAPI spec üretme
Sözleşme uyuşmazlıklarını bulma
Entegrasyon testi oluşturma
Hata yanıtlarını standartlaştırma
Mock ve örnek payload üretme

Bu görevler yoğun token tüketir çünkü hem dosya bağlamı hem de sık araç çağrısı gerektirir.

Aşağıdaki sözleşme öncelikli akış doğrudan yeni limitlerden faydalanır.

1. API sözleşmesini Apidog'da tasarlayın

Apidog içinde şunları tanımlayın:

Endpoint'ler
Request schema'ları
Response schema'ları
Örnek payload'lar
Hata durumları
Test durumları

Bu sözleşme doğruluk kaynağınız olur.

2. OpenAPI spec'i dışa aktarın

Apidog'dan OpenAPI dosyasını dışa aktarın ve Claude Code'a bağlam olarak verin:

Bu OpenAPI spec'i backend uygulaması için doğruluk kaynağı olarak kullan.
Uygulama bu sözleşmeden sapmamalı.
Eksik endpoint'leri uygula, mevcut endpoint'leri doğrula.

3. `/goal` ile sözleşmeye göre uygulama yaptırın

Claude Code'a net başarı kriterleri verin:

/goal
OpenAPI spec'e göre User API'yi tamamla.

Başarı kriterleri:
- Tüm endpoint'ler spec ile uyumlu olmalı
- Request validation eksiksiz olmalı
- Response body ve status code'lar spec ile eşleşmeli
- Apidog testleri geçmeli
- Yeni entegrasyon testleri eklenmeli

Yeni limitlerle bu döngüyü birden fazla oturuma bölmeden daha rahat tamamlayabilirsiniz.

4. Apidog CLI testlerini doğrulayıcı olarak çalıştırın

Apidog CLI testlerini doğrulama katmanı olarak kullanın. Böylece ajan, kendi uydurduğu sözleşmeye göre değil, gerçek API sözleşmesine göre kontrol edilir.

Örnek doğrulama döngüsü:

1. Claude Code endpoint'i uygular
2. Apidog testleri çalışır
3. Hatalar Claude Code'a geri verilir
4. Claude Code düzeltir
5. Testler tekrar çalışır

Yapay zeka ajanlarıyla sözleşme öncelikli API geliştirme için daha detaylı akış, tasarım öncelikli API iş akışı kılavuzunda yer alıyor.

Apidog'u daha önce kullanmadıysanız, Apidog'u indirin ve ek Claude Code kotasıyla tasarım öncelikli iş akışını deneyin.

Ücretsiz Claude API erişimi ne olacak?

Claude Code planı için ödeme yapmak istemeyenler için ücretsiz Claude API erişim kılavuzu, Anthropic ve iş ortaklarının sunduğu yolları kapsar.

Ancak bu erişimler Claude Code'un ücretli kotasından ayrıdır. %50 haftalık limit artışı yalnızca şu planlar için geçerlidir:

Pro
Max
Team
Koltuk tabanlı Kurumsal

Doğrudan Anthropic API kullanıyorsanız, oran limitleriniz ayrı şekilde yönetilir.

Bu güncelleme neyi değiştirmez?

Beklentiyi doğru ayarlamak için, bu artış şunları yapmaz:

Doğrudan API kullanıcıları için Claude API oran limitlerini değiştirmez.
Fiyatlandırmayı değiştirmez.
Claude Code'a yeni özellik eklemez.
Kurumsal koltuk tabanlı planlar için faturalandırma modelini değiştirmez.

Bu bir özellik güncellemesi değil, kullanım tavanı artışıdır. Değer, ek alanı hangi iş akışlarına taşıdığınızla ortaya çıkar.

Sıkça Sorulan Sorular

%50'lik artış tam olarak ne zaman sona eriyor?

13 Temmuz 2026, TSİ 18:00'de (14 Temmuz GMT 01:00). Anthropic sonrasında tavanın ne olacağını açıklamadı. Aksi duyurulmadıkça başlangıç seviyesine dönebileceğini varsayın.

Bunu etkinleştirmek için bir şey yapmam gerekiyor mu?

Hayır. Limitler hesabınızda otomatik olarak artırıldı. CLI'da kontrol etmek için:

/usage

%50'lik artış 5 saatlik limiti de kapsıyor mu?

Hayır. %50 artış haftalık limit için geçerli. 5 saatlik limit önceki hafta ayrı olarak ikiye katlandı. İkisi de 13 Temmuz'a kadar eş zamanlı olarak geçerli.

Süre içinde farklı bir plana yükseltirsem ne olur?

Anthropic bu konuda özel bir açıklama yayınlamadı. Geçmiş kullanım pencerelerine göre, yükselttiğiniz andan itibaren yeni planın yükseltilmiş limitlerinin uygulanması beklenir.

Bu, Anthropic API planlarındaki Claude kullanımını etkiliyor mu?

Hayır. Değişiklik yalnızca Claude Code planları içindir: Pro, Max, Team ve koltuk tabanlı Kurumsal. Claude'u doğrudan Anthropic API ile çağırıyorsanız, oran limitleriniz ayrı yönetilir.

Bu kalıcı olacak mı?

Bilinmiyor. Anthropic bunu 13 Temmuz'a kadar geçerli bir pencere olarak duyurdu. Önümüzdeki haftaları daha yüksek tavana gerçekten ihtiyaç duyup duymadığınızı test etmek için kullanın.

/goal Komutu: Codex ve Claude Kodunu 7/24 Otonom Ajanlar Olarak Çalıştırma

Tobias Hoffmann — Thu, 14 May 2026 02:48:18 +0000

Son altı hafta içinde büyük yapay zeka laboratuvarlarının çoğu aynı temel özelliği yayımladı: ölçülebilir bir hedefe ulaşana kadar kapalı döngüde çalışan aracı komutu. Anthropic bunu Claude Code’a /goal olarak ekledi. OpenAI, Codex CLI ve Codex masaüstü uygulamasına dahil etti. Nous Research ise Hermes’e entegre etti. Ortak fikir basit: Aracıya bir hedef verirsiniz; aracı planlar, uygular, doğrular ve yalnızca hedef tamamlandığında ya da durması gerektiğinde size döner.

Apidog'u bugün deneyin

Manuel olarak “onayla, istem gönder, devam etmesini söyle, tekrar et” döngüsünü yönetiyorsanız, /goal bu işi aracıya devreder. Siz hedefi ve başarı koşulunu tanımlarsınız; aracı hedefe ulaşana kadar iterasyon yapar.

Bu rehber geliştiriciler ve API ekipleri içindir. /goal’ın nasıl çalıştığını, Codex ve Claude Code’da nasıl kullanılacağını, iyi hedef istemlerinin nasıl yazılacağını ve bunu Apidog ile API geliştirme iş akışınıza nasıl bağlayabileceğinizi ele alacağız.

Rehberdeki API örneklerini takip etmek isterseniz, Apidog’u ücretsiz indirebilirsiniz.

`/goal` aslında ne yapar?

Kısa tanım:

/goal, bir yapay zeka aracısının belirli bir durma koşulu gerçekleşene kadar bir görev üzerinde kapalı döngüde çalışmasını sağlar.

Tipik akış şöyledir:

Siz hedefi yazarsınız.
Ana model bir adım planlar ve uygular.
Daha küçük bir doğrulayıcı model şu soruyu kontrol eder: “Hedefe ulaşıldı mı?”
Cevap hayırsa döngü devam eder.
Cevap evetse aracı durur ve sonucu raporlar.

Normal aracı kullanımından farkı:

/goal olmadan: Döngü sizsiniz. Çıktıyı okur, doğrular, sonraki adımı istersiniz.
/goal ile: Döngü aracıdadır. Planlar, çalışır, kendi çıktısını kontrol eder ve yalnızca tamamlandığında döner.

Örneğin:

/goal create a landing page

Bu komut; dosya oluşturma, stil yazma, hata düzeltme ve önizleme alma gibi adımları tek bir sürekli çalıştırmaya dönüştürebilir.

Neden `/goal` aniden her yerde?

Uzun süren aracı görevleri genellikle iki nedenle başarısız olur:

Kayma (drift): Model, başlangıçtaki hedeften uzaklaşır.
Sürekli gözetim: Model işi yapabilir ama her adımda sizden onay ister.

/goal yaklaşımı bu iki sorunu azaltır. Doğrulayıcı model, her adımda hedefe göre kontrol yapar. Böylece aracı hem bağımsız çalışır hem de ölçülebilir bir durma koşuluna bağlı kalır.

Codex’te `/goal` kurulumu

Codex CLI, /goal için en fazla kontrolü sağlar.

1. Hedefleri etkinleştirin

Codex masaüstü uygulamasında:

Settings → Configuration → goals = true

CLI bu ayarı devralır.

2. CLI’ı tam otomatik modda başlatın

codex --approval-mode full-auto

Bu mod, sürekli onay istemlerini azaltır.

3. Hedefi çalıştırın

/goal [hedefiniz buraya]

Örnek:

/goal tüm başarısız testleri düzelt ta ki npm test 0 ile çıkana kadar

CLI yerine masaüstü uygulamasını da kullanabilirsiniz. İşlev aynıdır; ancak duraklatma, temizleme ve token kullanımını izleme için görsel arayüz sağlar.

Claude Code’da `/goal` kurulumu

Claude Code CLI’da kullanım benzerdir:

/goal [görev açıklaması]

Resmi belgeler için Claude Code dokümantasyonuna bakabilirsiniz.

Claude Code başlatılırken yapılandırma hataları alıyorsanız, geçersiz custom3p kurumsal yapılandırma düzeltmesi en yaygın hata senaryosunu kapsar.

Çoklu aracı iş akışları için ayrıca Claude Code üzerinde çoklu aracı katmanı olan Ruflo analizine bakabilirsiniz.

Pratik ipucu: Claude Code, /goal sırasında token kullanımını ve ilerlemeyi gösterir. İlerleme olmadan token tüketimi artıyorsa hedefiniz yakınsamıyor olabilir. Bu durumda:

/pause

veya:

/goal clear

kullanın.

İyi çalışan `/goal` istemi nasıl yazılır?

/goal komutunun sözdizimi basittir. Zor olan, aracının gerçekten tamamlayabileceği ve doğrulayabileceği bir hedef yazmaktır.

Her iyi /goal isteminde üç parça bulunur:

İş: Ne yapılacak?
Ölçülebilir son durum: Tamamlandı nasıl anlaşılacak?
Kısıtlamalar: Aracı hangi sınırların dışına çıkmayacak?

Temel şablon:

/goal [işi yap] ta ki [ölçülebilir son durum] olana kadar [kısıtlamalar]

Örnek:

/goal tüm başarısız testleri düzelt ta ki npm test 0 ile çıkana kadar /auth dizini dışındaki hiçbir dosyayı değiştirmeden

Bu iyi bir hedeftir çünkü:

npm test doğrulanabilir bir sinyal üretir.
Başarı koşulu nettir: çıkış kodu 0.
Kısıtlama açık ve uygulanabilirdir: /auth dışına dokunma.

Kötü örnek:

/goal bu UI'ı daha modern yap

Bu hedef belirsizdir. Doğrulayıcı “modern” kelimesini ölçemez.

Daha iyi versiyon:

/goal ana sayfa UI'ını güncelle ta ki Lighthouse erişilebilirlik puanı 90+ olana ve mobil görünümde yatay kaydırma kalmayana kadar

Daha uzun görevler için yapı

Büyük hedeflerde tek satır yerine bloklu format kullanın:

/goal
Hedef: [tek satırlık hedef]

Başarı kriterleri:
  - [ölçülebilir kriter 1]
  - [ölçülebilir kriter 2]

Kısıtlamalar:
  - [sınır 1]
  - [sınır 2]

Bağlam:
  - [ilgili dosyalar]
  - [çalıştırılacak komutlar]
  - [API sözleşmesi veya doküman yolu]

Örnek:

/goal
Hedef: Kullanıcı giriş endpoint'indeki hataları düzelt.

Başarı kriterleri:
  - npm test 0 ile çıkmalı
  - POST /auth/login geçerli kullanıcı için 200 dönmeli
  - Hatalı şifre için 401 dönmeli

Kısıtlamalar:
  - /auth dışındaki dosyaları değiştirme
  - Veritabanı şemasını değiştirme

Bağlam:
  - OpenAPI dosyası: ./openapi.yaml
  - Test komutu: npm test

Bu format, doğrulayıcıya her iterasyonda kontrol edeceği somut sinyaller verir.

Kullanılabilir `/goal` örnekleri

Araştırma

/goal Nisan 2026'dan bu yana yayınlanan Claude Opus 4.7 için tüm genel karşılaştırmaları topla, kaynakları kaydet ve en az 10 farklı karşılaştırmayı içeren tarihe göre sıralanmış bir markdown tablosu oluştur

Depo bakımı

/goal bu depoda ölü kod, kullanılmayan bağımlılıklar ve eski dosyalar bul, ardından her öğe için gerekçe içeren güvenli kaldırma önerilerinden oluşan bir PR açıklaması hazırla

Dokümantasyon

/goal README.md'yi yeni bir katkıcının projeyi kurabilmesi, çalıştırabilmesi, test edebilmesi ve anlayabilmesi için yeniden yaz; bu dört adımın her biri çalışan bir komut ve beklenen çıktı içersin

Özellik geliştirme

/goal koyu/açık tema geçişi ekle, seçimi localStorage'da kalıcı hale getir, her iki tema için stilleri güncelle ve geçişin sayfa yenilemesi olmadan çalıştığını tarayıcıda doğrula

Ortak desen: Her örnekte doğrulanabilir bir son durum var.

`/goal` ve API geliştirme iş akışları

API çalışmaları /goal için özellikle uygundur. Çünkü API görevlerinde başarı çoğu zaman net biçimde ölçülebilir:

İstek 200 döner.
Hata senaryosu doğru status code üretir.
Yanıt şeması OpenAPI sözleşmesiyle eşleşir.
Test paketi yeşile döner.

Örnek hedef:

/goal POST /users endpoint'ini OpenAPI sözleşmesine göre uygula ta ki tüm Apidog test durumları geçene kadar

Önerilen iş akışı

Sözleşmeyi Apidog’da tasarlayın.

Endpoint, request schema, response schema ve örnek payload’ları Apidog içinde tanımlayın.
OpenAPI spesifikasyonunu dışa aktarın.

Codex veya Claude Code’a bağlam olarak verin.
/goal çalıştırın.

Aracıya endpoint’i uygulamasını ve testler geçene kadar çalışmasını söyleyin.
Doğrulayıcı test komutunu çalıştırsın.

Her döngüde API testleri çalışan servise karşı koşar. Aracı yalnızca tüm testler geçtiğinde durur.

Örnek:

/goal
Hedef: GET /orders/{id} endpoint'ini OpenAPI sözleşmesine göre uygula.

Başarı kriterleri:
  - Apidog testleri tamamen geçmeli
  - 200, 404 ve validation error senaryoları beklenen şemaya uymalı
  - npm test 0 ile çıkmalı

Kısıtlamalar:
  - Mevcut response alan adlarını değiştirme
  - Migration ekleme

Bağlam:
  - OpenAPI dosyası: ./openapi.yaml
  - Test komutu: npm test

Bu yaklaşım, aracının kendi testlerini icat etmesinden daha güvenilirdir. Çünkü doğruluk kaynağı önceden tanımlanmış API sözleşmesidir.

Apidog; API tasarımı, mocking, test ve dokümantasyonu tek platformda birleştirir. Bu, /goal için önemlidir çünkü aracı tek bir test komutuyla ilerleme durumunu doğrulayabilir.

Sözleşme odaklı kurulum için tasarım odaklı API iş akışı rehberine, test senaryoları için ise QA mühendisleri için API test aracı genel bakışına bakabilirsiniz.

MCP sunucularıyla çalışıyorsanız da aynı desen geçerlidir. Kurulum için Apidog ile MCP sunucusu testi makalesini kullanabilirsiniz.

Üretimde `/goal` kullanırken pratik ipuçları

Tek seferde bir hedef çalıştırın

Codex ve Claude Code genellikle tek aktif hedefle çalışır. Yeni hedefe geçmeden önce:

/goal clear

kullanın.

Önce `/plan`, sonra `/goal`

Daha kontrollü akış:

/plan kullanıcı kayıt endpoint'ini OpenAPI sözleşmesine göre uygulamak için plan çıkar

Planı gözden geçirdikten sonra:

/goal planı uygula ta ki tüm API testleri geçene kadar

Bu, aracının döngü ortasında yaklaşımı tekrar tekrar değiştirmesini azaltır.

İlerleme dosyası kullandırın

Aracıya bir ilerleme dosyası tutturun:

/goal görevi tamamla ve her iterasyondan sonra progress.md dosyasını güncelle

Böylece:

Denetlenebilir bir iz oluşur.
Aracı iterasyonlar arasında daha net bağlam tutar.
Siz de ne yaptığını hızlıca okuyabilirsiniz.

Modelden hedefi yeniden yazmasını isteyin

Kaba fikrinizi önce normal istemle verin:

Bu görevi ölçülebilir başarı kriterleri ve kısıtlamalar içeren iyi bir /goal komutuna dönüştür.

Model çoğu zaman doğrulayıcının kontrol edebileceği daha iyi kriterler önerir.

Sorun ana modelde değil, çoğu zaman doğrulayıcı kriterindedir

Döngü kapanmıyorsa genellikle başarı koşulu ölçülebilir değildir.

Kötü kriter:

kod temiz olsun

Daha iyi kriter:

npm run lint 0 ile çıksın ve npm test geçsin

Küçük işler için `/goal` kullanmayın

Tek satırlık refactor veya küçük açıklama değişiklikleri için normal istem daha hızlıdır. /goal, uzun süren ve doğrulanabilir görevlerde daha anlamlıdır.

`/goal` ne zaman iyi çalışmaz?

Maliyet

Uzun çalışan döngüler daha fazla token tüketir. Başlamadan önce bütçe veya süre sınırı belirleyin.

Örnek kısıtlama:

Kısıtlamalar:
  - En fazla 5 iterasyon dene
  - Başarısız olursa yapılanları raporla ve dur

Net sinyali olmayan görevler

Şu hedefler zayıf çalışır:

“UX’i iyileştir”
“Metni daha iyi yap”
“Tasarımı daha premium hissettir”

Bunların yerine ölçülebilir hedef yazın:

/goal form erişilebilirliğini iyileştir ta ki Lighthouse accessibility puanı 95+ olana ve tüm input'ların label'ı bulunana kadar

Harici yan etkiler

E-posta gönderen, ödeme yapan veya üretim API’lerini çağıran hedeflerde çok net kısıtlamalar gerekir.

Örnek:

Kısıtlamalar:
  - Üretim API'sine istek atma
  - Gerçek ödeme işlemi başlatma
  - Sadece sandbox ortamını kullan

API erişim kontrolü ve ekip kullanımı tarafında daha geniş bağlam için ekipler için GitHub Copilot kullanım ve faturalandırma API’si yazısına bakabilirsiniz.

Eski bağlam

Uzun süren hedef sırasında kod tabanı değişirse aracı eski bağlamla devam edebilir. Bu durumda durdurup hedefi yeniden başlatmak daha güvenlidir.

Yapay zeka ile geliştirme pratiği nasıl değişiyor?

/goal, yapay zekayı “otomatik tamamlama”dan “hedef verdiğiniz ve denetlediğiniz aracı” modeline taşır.

Bu değişiklikte geliştiricinin işi şuna kayar:

Daha net başarı kriterleri yazmak
Daha iyi kısıtlamalar tanımlamak
Test edilebilir sözleşmeler üretmek
Aracının çıktısını otomatik doğrulamak

Bundan en çok faydalanan ekipler genellikle şunlara sahiptir:

OpenAPI dokümanı
Güçlü test paketi
CI akışı
Net API sözleşmeleri
Tek komutla çalıştırılabilen doğrulama

API’niz yalnızca ekip üyelerinin zihnindeyse, aracının doğrulayacağı somut bir şey yoktur. Ancak API sözleşmeniz Apidog gibi bir platformda tanımlıysa, /goal aracı bu sözleşmeye göre uygulama yapabilir ve testlerle kendini doğrulayabilir.

Sözleşme odaklı akışı kurmak isterseniz Apidog’u indirin.

Sıkça sorulan sorular

`/goal` Codex web uygulamasında çalışır mı?

Evet. Codex CLI, Codex masaüstü, Codex uygulaması ve Claude Code CLI’da desteklenir. Hermes de aynı komutu destekler.

`/goal` normal istemden nasıl farklıdır?

Normal istem tek adım çalışır ve durur. /goal, her adımdan sonra hedefe ulaşılıp ulaşılmadığını doğrulayan kapalı bir döngüde çalışır.

Aracı kısıtlamaların dışına çıkabilir mi?

Kısıtlamalar açık yazılırsa doğrulayıcı bunları her iterasyonda kontrol edebilir.

İyi kısıtlama:

/auth dizini dışındaki hiçbir dosyayı değiştirme

Zayıf kısıtlama:

hiçbir şeyi bozma

`/goal` daha pahalı mı?

Genellikle evet. Ana model işi yapmaya devam eder, doğrulayıcı model de her adımı kontrol eder. Bu nedenle uzun görevlerde token tüketimi artar.

Aracının çıktısını gerçek API’ye karşı nasıl test ederim?

API sözleşmesini Apidog ile tanımlayın ve test durumlarını çalışan uygulamaya karşı koşturun. Böylece /goal için ölçülebilir bir son durum elde edersiniz.

Claude destekli servisleri düşük bütçeyle kuruyorsanız, ücretsiz Claude API rehberine de bakabilirsiniz.

GPT API Hız Limitleri: Katmanlar, Kullanım Sınırları ve Apidog ile Nasıl Test Edilir

Tobias Hoffmann — Wed, 13 May 2026 07:15:13 +0000

GPT API'yi çağıran bir fonksiyon yayınladınız. Staging ortamında her şey sorunsuz, ancak üretimde ilk yüz kullanıcı geldiğinde loglarınız 429 Çok Fazla İstek hatalarıyla doluyor. Sorun dakikadaki istek sayısı mı, dakikadaki token kullanımı mı, günlük kota mı, yoksa kullandığınız modelin limitleri mi? Bunu tahmin etmek yerine ölçmeniz gerekir.

Apidog'u bugün deneyin

💡 Bu makalede, mevcut GPT modeliniz için hız limitlerini nasıl okuyacağınızı, birkaç API çağrısı ve Apidog’da küçük bir yük testiyle canlı limitlerinizi nasıl doğrulayacağınızı göreceksiniz. Sonuçta, hız limiti sorunu yaşadığınızda tekrar çalıştırabileceğiniz bir iş akışı ve ekibinizle paylaşabileceğiniz kaydedilebilir bir istek koleksiyonu elde edeceksiniz.

OpenAI ile çalıştıysanız, her yeni modelle hız limiti takibinin daha karmaşık hale geldiğini bilirsiniz. GPT-5.5’in GPT-4.1’den farklı limitleri olabilir, görüntü modelleri metin modellerinden farklı sayılır ve harcamanız arttıkça kullanım seviyeniz değişebilir. Apidog; yanıt başlıklarını incelemek, eş zamanlı trafiği simüle etmek ve kodu dağıtmadan önce hangi limite takıldığınızı doğrulamak için tek bir çalışma alanı sağlar.

Gerçekten Önemli Olan Dört Limit

OpenAI, GPT API anahtarları için birden fazla hız limiti uygular. Üretim ortamında genellikle şu dört boyutla karşılaşırsınız:

RPM: Dakikadaki istek sayısı. Dakikada kaç API çağrısı gönderebileceğinizi belirler.
TPM: Dakikadaki token sayısı. Girdi ve çıktı tokenlarının toplamıdır.
RPD: Günlük istek sayısı. Özellikle ücretsiz ve 1. seviye anahtarlarda önemlidir.
IPM / TPD / toplu işlem kuyruğu limitleri: Görüntü, ses, embedding ve batch uç noktaları için modele veya uç nokta ailesine özel limitlerdir.

Bir istek reddedildiğinde API genellikle HTTP 429 ve buna benzer bir JSON gövdesi döndürür:

{
  "error": {
    "message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
    "type": "tokens",
    "param": null,
    "code": "rate_limit_exceeded"
  }
}

Burada kritik alan message ve type değerleridir. Hata size hangi boyutu aştığınızı söyler:

tokens: TPM limitine takıldınız.
requests: RPM limitine takıldınız.
tokens_usage_based: token kullanımına bağlı bir sınıra takıldınız.

Bir 429, her zaman aynı anlama gelmez. RPM aşımı ile TPM aşımının çözümü farklıdır.

HTTP düzeyinde 429 için MDN 429 belgelerine ve RFC 6585 spesifikasyonuna bakabilirsiniz. OpenAI’ye özgü davranışlar için resmi hız limiti sayfasını yer imlerinize ekleyin.

Seviyeler Nasıl Çalışır?

GPT API anahtarınız bir OpenAI kullanım seviyesine bağlıdır. Bu seviye, RPM ve TPM limitlerinizin arkasındaki gerçek sayıları belirler.

Seviye geçişleri genellikle iki faktöre bağlıdır:

Hesaptaki toplam harcama
İlk ödeme tarihinden bu yana geçen süre

Genel görünüm şu şekildedir:

Seviye	Harcama sınırı	Bekleme süresi	Metin RPM	Metin TPM
Free	none	none	3	40k
1	$5 paid	none	500	30k–200k by model
2	$50 paid	7 days	5,000	450k
3	$100 paid	7 days	5,000	1M
4	$250 paid	14 days	10,000	2M
5	$1,000 paid	30 days	10,000	2M+

Bu değerler açıklayıcıdır. Kesin limitler zamanla ve modele göre değişebilir. Üretim kapasitesi planlaması yapmadan önce canlı limitlerinizi yanıt başlıklarından doğrulayın.

Pratik olarak iki noktayı unutmayın:

Ödeme sonrası seviye değişimi otomatik olabilir. Harcama ve bekleme koşulları sağlandığında istekleriniz yeni limitlerle çalışmaya başlar.
Seviye düşüşü olabilir. Uzun süre kullanılmayan hesaplar veya başarısız ödeme yöntemleri daha düşük limitlere neden olabilir.

Diğer sağlayıcılarla karşılaştırma yapmak isterseniz şu kılavuzlara bakabilirsiniz:

Canlı Limitlerinizi Yanıt Başlıklarından Okuyun

Kontrol panelinde arama yapmak yerine, her GPT API yanıtındaki rate limit başlıklarını okuyabilirsiniz.

Özellikle şu başlıklara bakın:

x-ratelimit-limit-requests: Bu uç nokta için RPM limitiniz.
x-ratelimit-remaining-requests: Bu dakika içinde kalan istek hakkınız.
x-ratelimit-limit-tokens: TPM limitiniz.
x-ratelimit-remaining-tokens: Bu dakika içinde kalan token hakkınız.
x-ratelimit-reset-requests: İstek kotasının ne zaman sıfırlanacağı.
x-ratelimit-reset-tokens: Token kotasının ne zaman sıfırlanacağı.

Örnek reset değerleri:

6s
1m30s

Bu başlıkları okumak için en basit yol, tek bir düşük maliyetli chat completion isteği göndermek ve dönen başlıkları incelemektir.

Adım 1: Apidog’da GPT İsteğini Yapılandırın

Apidog’u açın, yeni bir proje oluşturun ve yeni bir istek ekleyin.

Method: POST
URL: https://api.openai.com/v1/chat/completions

Headers sekmesine şunları ekleyin:

Anahtar	Değer
`Authorization`	`Bearer {{OPENAI_API_KEY}}`
`Content-Type`	`application/json`

{{OPENAI_API_KEY}}, Apidog ortam değişkeninden okunur. Böylece API anahtarını isteğin içine sabitlemezsiniz.

Örnek ortam değişkenleri:

OPENAI_API_KEY=sk-...
OPENAI_ORG_ID=org-...
OPENAI_PROJECT_ID=proj_...

Body sekmesinde JSON seçin ve şu gövdeyi ekleyin:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "ping"
    }
  ],
  "max_tokens": 10
}

İsteği gönderin. Yanıt geldikten sonra response panelindeki Headers sekmesini açın ve şu değerleri kaydedin:

x-ratelimit-limit-requests
x-ratelimit-remaining-requests
x-ratelimit-limit-tokens
x-ratelimit-remaining-tokens

Bunlar mevcut hesabınız, modeliniz ve uç noktanız için canlı limitlerdir.

Chat completion isteğini daha ayrıntılı kurmak için Apidog ile ChatGPT API’sini test etme kılavuzuna bakabilirsiniz.

Adım 2: Limitleri Küçük Bir Ani Yük Testiyle Doğrulayın

Başlıklar size limiti gösterir; ancak limit noktasındaki davranışı görmek için küçük bir ani yük testi çalıştırmanız gerekir.

Apidog’da kayıtlı isteğinizi açın. Send düğmesinin yanındaki menüden test senaryosunda çalıştırmayı seçin.

Başlangıç için şu değerleri kullanın:

Iterations: 50
Concurrency: 10
Delay between iterations: 0 ms

Bu test iki olası sonucu gösterir:

Bazı istekler 429 döner.

Limitin gerçekten devreye girdiğini doğrularsınız.
Tüm istekler başarılı olur.

RPM limitiniz düşündüğünüzden yüksek olabilir. Yanıt başlıklarındaki remaining-requests değerini kontrol edin.

Apidog test çalıştırıcısı her yanıtı kaydeder. Durum koduna göre sıralayarak tüm 429 yanıtlarını tek ekranda görebilirsiniz.

Bir 429 satırını açın ve gövdedeki message alanını okuyun. Bu alan genellikle sorunun RPM, TPM veya günlük kota olduğunu açıkça söyler.

Ek okuma için hız limiti aşıldı kılavuzuna bakabilirsiniz.

Adım 3: RPM Aşımını TPM Aşımından Ayırın

İlk test küçük isteklerle yapıldığı için çoğunlukla RPM davranışını ölçer. TPM’yi test etmek için daha az istek göndermeli, ancak her isteği daha büyük hale getirmelisiniz.

Örnek gövde:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "system",
      "content": "<3,000 tokens of context here>"
    },
    {
      "role": "user",
      "content": "Summarise the above in one sentence."
    }
  ],
  "max_tokens": 200
}

Bu kez daha düşük eş zamanlılıkla çalıştırın:

Iterations: 20
Concurrency: 5
Delay between iterations: 0 ms

Eğer 30k TPM limitli 1. seviye bir hesap kullanıyorsanız, istek sayısı limitinden önce token limitine takılabilirsiniz.

Çözüm, hangi limite takıldığınıza göre değişir:

Sorun	Belirti	Çözüm
RPM aşımı	Çok fazla küçük istek	Kuyruk, batching, eş zamanlılık sınırı
TPM aşımı	Az sayıda büyük istek	Prompt kırpma, context azaltma, cache, isteği bölme
Günlük kota	Gün sonunda `429`	Kota/plan/faturalandırma kontrolü

Adım 4: Eş Zamanlı Kullanıcıları Simüle Edin

Ani yük testleri üst sınırı gösterir. Üretim trafiği ise genellikle daha karmaşıktır:

Birden fazla kullanıcı
Farklı prompt boyutları
Sabit trafik üzerine gelen ani yükler
Değişken response süreleri

Apidog’da bir test senaryosu oluşturup küçük, orta ve büyük istek gövdelerini sırayla çalıştırabilirsiniz.

Test senaryosunda şunları ölçün:

Her yanıtın status code değeri
x-ratelimit-remaining-tokens
x-ratelimit-remaining-requests
429 yanıtlarının hangi noktada başladığı
200 ve 429 yanıtlarının latency farkı

Apidog’un JavaScript pre-request ve post-response script desteğiyle her iterasyonda farklı mesaj uzunlukları da seçebilirsiniz.

Örnek mantık:

const prompts = [
  "ping",
  "Bu metni tek cümlede özetle: ...",
  "Uzun bağlam: ..."
];

const selected = prompts[Math.floor(Math.random() * prompts.length)];

apidog.variables.set("USER_PROMPT", selected);

Body içinde değişkeni kullanın:

{
  "model": "gpt-5.5",
  "messages": [
    {
      "role": "user",
      "content": "{{USER_PROMPT}}"
    }
  ],
  "max_tokens": 100
}

Senaryo bittiğinde status code histogramını kaydedin. Bu rapor, ekip içinde “hız limitine mi takılıyoruz?” sorusunu hızlıca yanıtlamak için tekrar çalıştırılabilir bir referans olur.

Kısıtlandığınızda Ne Yapmalısınız?

Limitin nerede olduğunu ölçtükten sonra üç temel seçeneğiniz vardır.

1. Geri Çekilme ve Yeniden Deneme Ekleyin

Her GPT çağrısını retry mantığıyla sarın. 429 aldığınızda mümkünse reset başlığını okuyun:

x-ratelimit-reset-tokens
x-ratelimit-reset-requests

Basit bir yaklaşım:

async function callWithRetry(fn, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      return await fn();
    } catch (error) {
      const status = error.response?.status;

      if (status !== 429 || attempt === maxAttempts - 1) {
        throw error;
      }

      const reset =
        error.response?.headers?.["x-ratelimit-reset-tokens"] ||
        error.response?.headers?.["x-ratelimit-reset-requests"];

      const delayMs = parseResetHeader(reset) ?? Math.pow(2, attempt) * 1000;

      await new Promise((resolve) => setTimeout(resolve, delayMs));
    }
  }
}

function parseResetHeader(value) {
  if (!value) return null;

  if (value.endsWith("ms")) return Number(value.replace("ms", ""));
  if (value.endsWith("s")) return Number(value.replace("s", "")) * 1000;

  return null;
}

2. Kuyruk Kullanın

Trafiğiniz ani yüklenmeler içeriyorsa, istekleri doğrudan OpenAI’ye göndermek yerine kuyruğa alın. Ardından worker’ları RPM ve TPM limitlerinin altında çalışacak şekilde sınırlandırın.

Temel yaklaşım:

API request -> queue -> rate-limited worker -> OpenAI API

Bu model özellikle şu durumlarda işe yarar:

Arka plan işleme
Belge sınıflandırma
Çok sayıda küçük analiz görevi
RAG pipeline işlemleri

Uygulama detayları için şu yazılara bakabilirsiniz:

3. Toplu İşleme Geçin

İş yükünüz gerçek zamanlı yanıt gerektirmiyorsa, OpenAI Batch API daha uygun olabilir. Örneğin:

Gece çalışan zenginleştirme işleri
Belge sınıflandırma
Embedding yeniden oluşturma
Büyük veri seti üzerinde asenkron analiz

Bu sayede kullanıcıya dönük canlı trafiğiniz için eş zamanlı kotayı korursunuz.

Kısıtlama ve hız limiti farkını netleştirmek için kısıtlama vs. hız limiti yazısına da bakabilirsiniz.

Yaygın GPT 429 Hataları

Gerçek dünyadaki 429 hatalarının çoğu şu üç kategoriye girer.

`Rate limit reached ... requests per min (RPM)`

Kodunuz dakikada çok fazla çağrı yapıyor.

Yapılacaklar:

Eş zamanlılık sınırı koyun.
Her kaydı aynı anda Promise.all ile göndermeyin.
Worker sayısını RPM limitinize göre ayarlayın.
Küçük istekleri mümkünse batch haline getirin.

`Rate limit reached ... tokens per min (TPM)`

İstekleriniz token açısından çok büyük.

Yapılacaklar:

Sistem prompt’unu kısaltın.
RAG context boyutunu sınırlayın.
Uzun belgeleri parçalara bölün.
Gereksiz geçmiş mesajlarını göndermeyin.
max_tokens değerini gerçekçi bir üst sınıra düşürün.

`You exceeded your current quota`

Bu teknik olarak 429 gibi görünse de genellikle hız limiti değil, faturalandırma sorunudur.

Kontrol edin:

Aylık harcama limiti
Kayıtlı kart durumu
Ön ödemeli bakiye
Organizasyon veya proje kotası

Bu durumda çözüm retry değil, faturalandırma panelidir.

SSS

Apidog, GPT hız limitlerini test etmek için ücretli mi?

Hayır. Ücretsiz plan, tek istek testini ve küçük eş zamanlı test çalıştırmalarını kapsar. Daha büyük test yükleri, ekip çalışma alanları veya zamanlanmış çalıştırmalar için ücretli plana ihtiyaç duyabilirsiniz. Detaylar için Apidog fiyatlandırmasına bakın.

Gerçek token harcamadan hız limitlerini test edebilir miyim?

Kısmen. En ucuz temel kontrol için max_tokens: 1 ve tek karakterlik bir mesaj gönderebilirsiniz. Bu çok düşük maliyetlidir ve rate limit başlıkları yine döner.

Ani yük testleri gerçek token harcar, ancak her çağrıyı küçük tutabilirsiniz. Tamamen çevrimdışı test için Apidog’un mock server özelliğiyle 429 yanıtlarını simüle edip retry mantığınızı OpenAI’yi çağırmadan doğrulayabilirsiniz.

1. seviye anahtarım neden başka bir 1. seviye anahtardan daha yavaş?

Limitler genellikle tek anahtar yerine organizasyon düzeyinde paylaşılır. Aynı organizasyonda başka yoğun kullanıcılar varsa, aynı kotayı tüketiyor olabilirsiniz.

Bunu doğrulamak için aynı isteği iki farklı anahtarla çalıştırın ve şu başlıkları karşılaştırın:

x-ratelimit-remaining-requests
x-ratelimit-remaining-tokens

Hangi modelin hangi limite sahip olduğunu nasıl anlarım?

Yanıt başlıklarını okuyun. Blog yazılarındaki tabloları yalnızca başlangıç noktası olarak kullanın.

Her model için tek bir düşük maliyetli istek gönderin ve şu başlıkları kaydedin:

x-ratelimit-limit-requests
x-ratelimit-limit-tokens

Aynı model ailesindeki farklı snapshot sürümleri farklı limitlere sahip olabilir.

Streaming istekleri farklı mı sayılır?

TPM açısından evet. Streaming istekleri max_tokens değerine göre token ayırabilir. Bu yüzden gerçek yanıt kısa olsa bile yüksek max_tokens değeri TPM bütçenizi gereksiz tüketebilir.

max_tokens değerini ihtiyacınız olan en düşük gerçekçi üst sınıra indirin. Streaming davranışı için Apidog ile ChatGPT API’sini test etme kılavuzuna bakabilirsiniz.

Apidog hız limiti testimi ekibimle paylaşabilir miyim?

Evet. İsteği ve test senaryosunu paylaşılan bir projeye kaydedin. Ekip üyeleri kendi ortam değişkenlerini kullanarak aynı testi kendi anahtarlarıyla çalıştırabilir.

Bu, “benim anahtarım mı, organizasyon kotası mı, yoksa model limiti mi?” sorusunu hızlıca yanıtlamanızı sağlar.

GPT-5.5 Pro ve Instant Karşılaştırması: 6 Kat Fiyat Farkına Değer mi?

Tobias Hoffmann — Tue, 12 May 2026 07:03:07 +0000

OpenAI, GPT-5.5 için iki seçenek sunar: milyon belirteç başına 5 dolar giriş ve 30 dolar çıkış maliyetli Instant, ayrıca 30 dolar giriş ve 180 dolar çıkış maliyetli Pro. Bu, pratikte sabit bir 6 kat prim anlamına gelir. Mühendislik ekipleri için asıl soru şudur: Pro’ya ne zaman ödeme yapmaya değer, ne zaman yalnızca bütçe yakarsınız?

Apidog'u bugün deneyin

Bu rehber, kararı ölçülebilir hale getirir: gerçekçi iş yükleriyle maliyet hesabı, Pro’nun öne geçtiği doğruluk senaryoları, gecikme etkisi ve kendi projenize kopyalayabileceğiniz bir Apidog test düzeneği.

TL;DR

Varsayılan olarak şu işlerde GPT-5.5 Instant kullanın:

sohbet
özetleme
sınıflandırma
retrieval QA
müşteri destek akışları
yanlış cevabı tespit etmenin veya düzeltmenin ucuz olduğu görevler

GPT-5.5 Pro yalnızca kötü bir çıktının maliyeti, aynı konuşmadaki 6 kat belirteç priminden yüksekse anlamlıdır. Bu genellikle şu alanlarda geçerlidir:

yasal belge taslağı ve inceleme
tıbbi triyaj
finansal analiz
çok adımlı ajan planlama
çoklu dosya kod refactoring’i

Bir özellik için “yanlış cevabın dolar maliyeti”ni ifade edemiyorsanız, o özellik için Pro’ya ödeme yapmaya hazır değilsinizdir.

Giriş

GPT-5.5 fiyatlandırması, eskiden sezgiyle verilen model seçimi kararını sayısal hale getiriyor. Artık her özellik, her API çağrısı ve her kullanıcı akışı için maliyet farkını hesaplayabilirsiniz.

Örneğin günde 100.000 müşteri destek mesajı işleyen bir ekip, aynı hacim için yaklaşık olarak:

Instant ile ayda 34.500 dolar
Pro ile ayda 207.000 dolar

ödeyebilir.

Bu tek bir özellikte aylık 172.500 dolarlık farktır. Bu farkı “daha iyi model” hissiyle değil, ölçülen hata maliyetiyle gerekçelendirmelisiniz.

Bu yazıda şunları uygulamalı olarak göreceksiniz:

Instant ve Pro’nun fiyat/maliyet hesabı
Pro’nun gerçekten avantaj sağladığı görev tipleri
Gecikme ve reasoning_effort etkisi
Python ile küçük bir benchmark düzeneği
Apidog ile tekrar çalıştırılabilir regresyon testi

GPT-5.5 ailesine yeni başladıysanız, GPT-5.5 Instant erişim ve API rehberi, giriş seviyesi katmanı ayrıntılı olarak açıklar. OpenAI API harcama izleme kılavuzu, bu maliyetleri üretimdeki özelliklere nasıl atayacağınızı gösterir. Daha geniş API yüzeyi için GPT-5.5 API referans kılavuzu, parametreleri, streaming’i ve yapılandırılmış çıktıyı kapsar.

GPT-5.5 ailesindeki iki model

Instant ve Pro aynı model ailesini, aynı bağlam penceresini ve aynı API yüzeyini paylaşır. Farklar üç noktadadır:

uç noktanın arkasındaki model kapasitesi
varsayılan akıl yürütme bütçesi
belirteç başına fiyat

Model kimlikleri:

gpt-5.5
gpt-5.5-pro

Her ikisi de:

272.000 belirteç giriş bağlamını
128.000 belirteç çıktıyı
reasoning_effort değerlerini
Responses API üzerinden streaming’i

destekler.

Desteklenen reasoning_effort değerleri:

minimal
low
medium
high

Bu uyumluluk önemlidir. Üretim kodunda çoğu durumda yalnızca model adını değiştirerek Instant ve Pro arasında geçiş yapabilirsiniz.

Fiyat tarafı ise kararı değiştirir:

Katman	Giriş / 1M token	Çıkış / 1M token
GPT-5.5 Instant	5 dolar	30 dolar
GPT-5.5 Pro	30 dolar	180 dolar

Pro, girişte ve çıkışta yaklaşık 6 kat pahalıdır.

Batch katmanı bu fiyatları yarıya indirir:

Katman	Batch giriş / 1M token	Batch çıkış / 1M token
Instant	2.50 dolar	15 dolar
Pro	15 dolar	90 dolar

İstem önbellekleme ile önbelleğe alınmış giriş token’ları daha da düşer:

Katman	Cached input / 1M token
Instant	0.50 dolar
Pro	3 dolar

Eğer mümkün olan yerlerde Batch veya önbellekleme kullanmıyorsanız, gereksiz yere fazla ödeme yapıyorsunuz demektir.

Gecikme farkı

Gecikme, model seçiminde çoğu zaman maliyet kadar önemlidir.

Tipik davranış:

gpt-5.5 + reasoning_effort=minimal: kısa istemlerde ilk token 200–400 ms içinde gelebilir.
gpt-5.5-pro + reasoning_effort=high: model cevap üretmeden önce daha uzun bir akıl yürütme döngüsü çalıştırdığı için ilk token 8–30 saniye sürebilir.

TechCrunch’taki GPT-5.5 Pro sürüm notları bu farkı açıkça belirtmiştir.

Bu farkın etkisi ürün tipine bağlıdır:

Canlı sohbet arayüzü: kullanıcı gecikmeyi hisseder.
Asenkron belge işleme pipeline’ı: gecikme çoğu zaman sorun değildir.
Arka plan batch işi: maliyet gecikmeden daha önemlidir.

reasoning_effort ayrı bir parametre gibi görünse de model seçiminin parçası olarak düşünülmelidir. Örneğin Pro’daki low, çoğu durumda Pro’daki high yerine Instant’taki high ile daha anlamlı karşılaştırılır.

Doğruluk farkı: Pro nerede öne geçer?

OpenAI’nin yayınladığı değerlendirme sonuçlarında net bir desen var: Pro, hataların birleştiği çok adımlı görevlerde öne geçer. Modelin yalnızca bilgi alması, formatlaması veya özetlemesi gereken görevlerde Instant çoğu zaman yeterlidir.

Yayınlanmış örnek sonuçlar:

GPQA Diamond bilim kıyaslaması: Pro yaklaşık %87, Instant yaklaşık %71
SWE-bench Verified: Pro yaklaşık %78, Instant yaklaşık %61
MMLU ve HellaSwag: iki model de %90 üzeri, fark çoğu durumda daralır
Güvenlik açısından kritik tıbbi ve yasal istemlerde Pro, Instant’a göre daha az kendinden emin yanlış yanıt üretir

Pro’nun öne çıktığı alanlar:

yasal sözleşme taslağı ve inceleme
tıbbi ayırıcı tanı
finansal belge analizi
çok adımlı ajan planlaması
çoklu dosyayı etkileyen kod görevleri

Instant’ın maliyet/doğruluk açısından daha mantıklı olduğu alanlar:

müşteri destek sohbeti
SSS alma
içerik özetleme
duygu sınıflandırması
basit niyet yönlendirme
iyi tanımlanmış fonksiyon çağırma
tek dosya kod tamamlama

Minimal API karşılaştırması

Aşağıdaki örnek, aynı istemi Instant ve Pro ile çalıştırır. Responses API şekli aynıdır; yalnızca model ve reasoning.effort değişir.

from openai import OpenAI

client = OpenAI()

prompt = """Analyze this contract clause for unilateral termination risk:
'Either party may terminate this agreement for convenience upon
thirty (30) days written notice, provided that the terminating party
shall pay any amounts then due.'"""

instant = client.responses.create(
    model="gpt-5.5",
    reasoning={"effort": "minimal"},
    input=prompt,
)

pro = client.responses.create(
    model="gpt-5.5-pro",
    reasoning={"effort": "high"},
    input=prompt,
)

print("INSTANT:", instant.output_text)
print("PRO:", pro.output_text)

Bu tür bir testte bakmanız gereken metrikler:

cevap doğruluğu
eksik risk maddeleri
maliyet
gecikme
çıktı uzunluğu
insan değerlendirici tercihi

Tek bir örnek yeterli değildir. Gerçek trafiğinize benzeyen 50–200 istemle ölçüm yapın.

Küçük benchmark script’i

Aşağıdaki script, aynı istem setini dört konfigürasyonla çalıştırır:

Instant + minimal
Instant + high
Pro + minimal
Pro + high

import time
import csv
from openai import OpenAI

client = OpenAI()

PROMPTS = open("eval_prompts.txt").read().split("\n---\n")

CONFIGS = [
    ("gpt-5.5", "minimal"),
    ("gpt-5.5", "high"),
    ("gpt-5.5-pro", "minimal"),
    ("gpt-5.5-pro", "high"),
]

with open("results.csv", "w", newline="") as f:
    w = csv.writer(f)
    w.writerow([
        "model",
        "effort",
        "prompt_id",
        "latency_s",
        "in_tokens",
        "out_tokens",
        "cost_usd",
        "output"
    ])

    for i, prompt in enumerate(PROMPTS):
        for model, effort in CONFIGS:
            t0 = time.time()

            response = client.responses.create(
                model=model,
                reasoning={"effort": effort},
                input=prompt,
            )

            latency = time.time() - t0

            input_tokens = response.usage.input_tokens
            output_tokens = response.usage.output_tokens

            rate_in = 5 if model == "gpt-5.5" else 30
            rate_out = 30 if model == "gpt-5.5" else 180

            cost = (
                input_tokens * rate_in +
                output_tokens * rate_out
            ) / 1_000_000

            w.writerow([
                model,
                effort,
                i,
                round(latency, 2),
                input_tokens,
                output_tokens,
                round(cost, 5),
                response.output_text[:500]
            ])

eval_prompts.txt dosyasını şu formatta tutabilirsiniz:

İstem 1
---
İstem 2
---
İstem 3

Sonra CSV’yi açıp her satırı insan değerlendirmesiyle puanlayın:

Alan	Örnek
doğruluk	1–5
eksik bilgi	evet/hayır
kabul edilebilir mi	evet/hayır
manuel düzeltme süresi	dakika
hata maliyeti	dolar

Gerçek iş yükünüzdeki doğruluk farkı, yayınlanmış benchmark farkıyla birebir aynı olmayacaktır. Zaten testi çalıştırmanın amacı da budur.

Daha kapsamlı değerlendirme için yapay zeka ajan API test rehberi, derecelendirme iş akışını detaylandırır. Yapay zeka odaklı test üretimi, üretim izlerinden istem seti oluşturmayı gösterir.

Maliyet matematiği: 6 kat ne zaman değerlidir?

Örnek 1: Müşteri destek botu

Varsayım:

günde 100.000 mesaj
ortalama giriş: 800 token
ortalama çıkış: 250 token

Günlük hacim:

80 milyon giriş token’ı
25 milyon çıkış token’ı

Instant maliyeti:

80M * 5 / 1M = 400 dolar
25M * 30 / 1M = 750 dolar
Toplam = 1.150 dolar / gün
Aylık ≈ 34.500 dolar

Pro maliyeti:

80M * 30 / 1M = 2.400 dolar
25M * 180 / 1M = 4.500 dolar
Toplam = 6.900 dolar / gün
Aylık ≈ 207.000 dolar

Aylık prim:

207.000 - 34.500 = 172.500 dolar

Karar: Instant kullanın.

Bu iş yükünde Pro’nun ek doğruluğu genellikle bu farkı haklı çıkarmaz. Bütçeyi daha iyi retrieval, daha temiz sistem istemi ve daha iyi fallback akışlarına harcayın.

Örnek 2: Kod inceleme yardımcısı

Varsayım:

günde 5.000 inceleme yorumu
ortalama giriş: 8.000 token
ortalama çıkış: 1.200 token

Günlük hacim:

40 milyon giriş token’ı
6 milyon çıkış token’ı

Instant:

40M * 5 / 1M = 200 dolar
6M * 30 / 1M = 180 dolar
Toplam = 380 dolar / gün
Aylık ≈ 11.400 dolar

Pro:

40M * 30 / 1M = 1.200 dolar
6M * 180 / 1M = 1.080 dolar
Toplam = 2.280 dolar / gün
Aylık ≈ 68.400 dolar

Aylık prim:

68.400 - 11.400 = 57.000 dolar

Burada karşılaştırma API maliyeti değil, mühendis zamanıdır.

Eğer Pro, Instant’ın kaçırdığı her 1.000 incelemede 5 ek gerçek hata yakalıyorsa ve her hata 150 dolarlık 1 mühendis-saatine denk geliyorsa:

5 hata * 1 saat * 150 dolar = 750 dolar / 1.000 inceleme
5.000 inceleme / gün = 3.750 dolar / gün
Aylık ≈ 112.500 dolar

Bu durumda 57.000 dolarlık prim mantıklı olabilir.

Karar: Pro kullanın, ancak yalnızca gerçek yakalama oranını ölçüyorsanız.

Örnek 3: Yasal belge özetleyici

Varsayım:

günde 500 belge
ortalama giriş: 40.000 token
ortalama çıkış: 3.000 token

Günlük hacim:

20 milyon giriş token’ı
1.5 milyon çıkış token’ı

Instant:

20M * 5 / 1M = 100 dolar
1.5M * 30 / 1M = 45 dolar
Toplam = 145 dolar / gün
Aylık ≈ 4.350 dolar

Pro:

20M * 30 / 1M = 600 dolar
1.5M * 180 / 1M = 270 dolar
Toplam = 870 dolar / gün
Aylık ≈ 26.100 dolar

Aylık prim:

26.100 - 4.350 = 21.750 dolar

Bir satıcı anlaşmasında kaçırılan tek bir tazminat maddesi, yıllık Pro priminden daha pahalıya mal olabilir.

Karar: Pro kullanın.

Gerçek zamanlı yanıt gerekmiyorsa Batch katmanı kullanarak Pro faturasını yaklaşık yarıya düşürün.

Pratik başabaş kuralı

Pro için ödeme yapın, eğer:

Önlenen hata değeri > aynı konuşmadaki 5x ek token maliyeti

Daha pratik ifade:

Pro'nun ek doğruluk getirisi * hata maliyeti > Pro primi

Örneğin:

Hata maliyeti 50 dolar
Pro doğruluğu %1 artırıyor
Beklenen kazanç: 0.50 dolar / çağrı

Eğer Pro primi çağrı başına 0.50 dolardan azsa mantıklıdır.

Başka senaryo:

Hata maliyeti 5.000 dolar
Pro doğruluğu %1 artırıyor
Beklenen kazanç: 50 dolar / çağrı

Bu durumda Pro’nun token maliyeti çok daha yüksek olsa bile rasyonel olabilir.

Modeli çağrı hacmine göre değil, yanlış olmanın maliyetine göre seçin.

Apidog ile Pro/Instant karşılaştırmasını test edin

Bu kararı yalnızca benchmark güvenine dayanarak üretime taşımayın. Apidog’da küçük bir regresyon paketi oluşturun ve her istem değişikliğinde çalıştırın.

1. Yeni proje oluşturun

Apidog’u açın ve yeni bir proje oluşturun.

İki istek ekleyin:

gpt55-instant-minimal
gpt55-pro-high

Her ikisi de aynı endpoint’e gitsin:

https://api.openai.com/v1/responses

2. Ortam değişkeni tanımlayın

API anahtarınızı gövdeye yazmayın. Ortam değişkeni kullanın:

OPENAI_KEY

Header’lar:

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

3. Instant isteğini ekleyin

Body:

{
  "model": "gpt-5.5",
  "reasoning": {
    "effort": "minimal"
  },
  "input": "{{prompt}}"
}

4. Pro isteğini ekleyin

Body:

{
  "model": "gpt-5.5-pro",
  "reasoning": {
    "effort": "high"
  },
  "input": "{{prompt}}"
}

5. Test veri dosyası bağlayın

Her satırda bir istem olacak şekilde 50–200 örnek hazırlayın.

Örnek:

Bu sözleşme maddesindeki fesih risklerini analiz et.
Bu hasta özetinde kritik eksik bilgi var mı?
Bu pull request'te güvenlik açığı riski var mı?

{{prompt}} değişkenini bu veri dosyasına bağlayın.

6. Token ve gecikme metriklerini yakalayın

Her istekte şu alanları kaydedin:

response.usage.input_tokens
response.usage.output_tokens
yanıt süresi
çıktı metni
model adı
reasoning effort

Apidog yanıt gövdesini ve zamanlamaları otomatik olarak saklar.

7. Sonuçları karşılaştırın

Her iki isteği veri kümenize karşı toplu çalıştırın. Apidog’un diff görünümü ile Instant ve Pro yanıtlarını yan yana inceleyin.

Ardından CSV olarak dışa aktarın ve şu sütunları hesaplayın:

input_cost = input_tokens * input_rate / 1_000_000
output_cost = output_tokens * output_rate / 1_000_000
total_cost = input_cost + output_cost

Model oranları:

Instant input: 5
Instant output: 30
Pro input: 30
Pro output: 180

Bir saatlik testle, çeyreklik tahmin yapmak yerine özellik başına karar kuralı çıkarabilirsiniz.

Projeyi regresyon paketi olarak kaydedin. OpenAI yeni model yayınladığında veya sistem istemini değiştirdiğinizde tekrar çalıştırın. Apidog, çalışma alanı geçmişi tuttuğu için doğruluğun ne zaman gerilediğini ve hangi istem değişikliğinin buna neden olduğunu gösterebilirsiniz.

Apidog’u indirin ve QA mühendisleri için API test iş akışı ile regresyon paketini adım adım kurun.

Gelişmiş teknikler

Model seçimini kullanıcıya göre değil, özelliğe göre yapın

“Premium kullanıcılar Pro alır” yaklaşımı genellikle pahalıdır.

Bunun yerine her çağrıyı şu metadata ile etiketleyin:

{
  "feature": "contract_review",
  "risk_class": "high",
  "error_cost_usd": 5000
}

Sonra routing kuralını bu alanlara göre uygulayın.

Çoğu üründe çağrıların büyük kısmı Instant’ta kalır, yalnızca yüksek riskli özellikler Pro’ya gider.

Pro’yu yükseltme yolu olarak kullanın

İyi çalışan desen:

İsteği önce Instant’a gönderin.
Yanıtı doğrulayın.
Yanıt şema doğrulamasından, güven kontrolünden veya araç çağrısından geçmezse Pro’ya yükseltin.

Örnek akış:

response = run_model("gpt-5.5", "minimal", prompt)

if not passes_validation(response):
    response = run_model("gpt-5.5-pro", "high", prompt)

Bu şekilde Pro primi yalnızca gerçekten ihtiyaç duyan küçük yüzdeye uygulanır.

İstem önbelleklemesini takip edin

Sistem isteminiz uzunsa ve sık değişmiyorsa caching kritik hale gelir.

Kontrol etmeniz gereken metrik:

response.usage.cached_tokens

Uyarı kuralı örneği:

cached_tokens / input_tokens < 0.6 ise alarm üret

Önbellek isabet oranı düştüğünde maliyet hızla artar.

Batch kullanın

Gerçek zamanlı olmayan işler Batch katmanına taşınmalıdır:

gece içerik üretimi
haftalık özetleme
geriye dönük sınıflandırma
arşiv belge analizi

Batch, model kalitesini değiştirmez; teslimat süresi karşılığında yaklaşık %50 indirim sağlar.

Bağlam penceresini doldurmayın

Her iki model de 272.000 token giriş bağlamını destekler. Ancak maliyet doğrusal artar.

Eğer bağlamı sürekli dolduruyorsanız:

gereksiz token için ödeme yaparsınız
modelin dikkat yoğunluğu düşebilir
retrieval kalitesi bozulabilir

Daha iyi desen:

Belgeleri parçalara ayırın.
Retrieval ile ilgili parçaları seçin.
Modele yalnızca gerekli bağlamı gönderin.

Yaygın hatalar

Model seçimini routing katmanı yerine istemci koduna gömmek
Kendi istemleriniz yerine yalnızca benchmark sonuçlarına güvenmek
Basit görevlerde Pro + reasoning_effort=high kullanmak
max_output_tokens ayarlamayı unutmak
Önbellek kaçırmalarını takip etmemek
Batch’e uygun işleri gerçek zamanlı API’de çalıştırmak
Hata maliyetini ölçmeden Pro’ya geçmek

Daha geniş model karşılaştırmaları için Gemini 3 Flash Önizleme API rehberi, Google tarafındaki benzer katmanı açıklar. Ücretsiz GPT-5.5 API erişim seçenekleri, geliştirici katmanı ücretsiz kredilerini kapsar.

Gerçek dünya kullanım örnekleri

Sigorta talepleri triyajı

Orta ölçekli bir sigorta şirketi, ilk başvuru özetlerini Instant ile işler. Karmaşık poliçe sorularını Pro’ya yükseltir.

Sonuç:

taleplerin yaklaşık %12’si Pro’ya gider
toplam harcama, tüm çağrıları premium modelle çalıştırmaya göre düşer
Pro, zor vakalarda daha fazla işlem bütçesi kullanır

Kod inceleme yardımcısı

Bir geliştirici araçları şirketi şu routing’i uygular:

stil ve bariz hatalar: Instant
üçten fazla dosyaya dokunan PR’lar: Pro
kritik path pattern’leri: Pro

Pro, ek API harcamasına karşılık daha fazla gerçek hata yakalar. Değer, erken hata tespitinden kazanılan mühendislik zamanı ile ölçülür.

Hastane giriş özetleyici

Hasta özetleri yüksek hata maliyetine sahiptir. Bu nedenle ekip, kritik özetleri Pro + reasoning_effort=high ile işler.

Gerçek zamanlı gerekmeyen özetlerin büyük kısmı gece Batch ile çalıştırılır. Böylece kalite korunurken fatura düşürülür.

Sonuç

Instant ve Pro arasındaki 6 kat prim bir sorun değil, karar mekanizmasıdır. Sizi “daha iyi model” yerine “doğru cevabın değeri” hakkında düşünmeye zorlar.

Pratik karar özeti:

Varsayılan olarak Instant kullanın.
Pro’ya yalnızca hata maliyetini dolar cinsinden ifade edebildiğinizde geçin.
Model seçimini özellik bazında yapın.
reasoning_effort değerini maliyet ve gecikmeyle birlikte değerlendirin.
Sistem istemlerini önbelleğe alın.
Gerçek zamanlı olmayan işleri Batch’e taşıyın.
Üretime almadan önce Apidog üzerinde regresyon paketi oluşturun.
Her model sürümünde ve fiyat değişiminde kararı yeniden ölçün.

Bir sonraki planlama döngüsünden önce kendi istemleriniz üzerinde maliyet ve doğruluk karşılaştırmasını çalıştırmak için Apidog’u indirin. GPT-5.5 ailesi hakkında daha geniş bağlam için GPT-5.5 Instant erişim rehberi ve OpenAI özellik başına harcama atıf kılavuzu resmi tamamlar.

SSS

GPT-5.5 Pro, Instant’tan 6 kat daha mı iyi?

Hayır. Belirteç başına 6 kat daha pahalıdır. Çoğu iş yükünde yalnızca biraz daha iyi olabilir. Az sayıda yüksek riskli, çok adımlı görevde ise anlamlı fark yaratır.

Her iki model için aynı API kodunu kullanabilir miyim?

Evet. İstek şekli aynıdır. Genellikle yalnızca şu alanı değiştirirsiniz:

{
  "model": "gpt-5.5-pro"
}

Parametre detayları için GPT-5.5 API rehberine bakın.

`reasoning_effort` her iki modelde de aynı mı çalışır?

Aynı değerleri kabul eder:

minimal
low
medium
high

Ancak etkisi Pro’da daha belirgin olabilir çünkü Pro’nun daha fazla akıl yürütme kapasitesi vardır.

Pro’da istem önbelleklemesi ne kadar tasarruf sağlar?

Önbelleğe alınmış giriş token’ları:

Pro’da 30 dolar / 1M token’dan 3 dolara
Instant’ta 5 dolar / 1M token’dan 0.50 dolara

düşer.

Uzun ve kararlı sistem istemleriniz varsa caching hızlıca kendini amorti eder.

Varsayılan olarak Pro’ya mı geçmeliyim, yoksa Instant’tan mı yükseltmeliyim?

Varsayılan olarak Instant kullanın ve yalnızca doğrulama başarısız olduğunda Pro’ya yükseltin. Bu desen genellikle daha düşük maliyetlidir.

Pro + high gecikmesi ne kadar olabilir?

Pro’da high ayarında ilk token gecikmesi 8–30 saniye olabilir. Uzun cevaplarda uçtan uca süre 20–60 saniyeye çıkabilir. Kullanıcı deneyimini buna göre tasarlayın.

Batch katmanı aynı cevapları mı verir?

Evet. Batch model değişimi değildir; teslimat süresi karşılığında fiyat indirimi sağlar. Aynı model ağırlıkları kullanılır, ancak tamamlanma penceresi daha uzundur.

Seçimi ne zaman yeniden değerlendirmeliyim?

Her OpenAI model duyurusunda, fiyat değişiminde veya sistem istemi değişikliğinde regresyon paketini tekrar çalıştırın. Regresyon paketi iş akışı, bu karşılaştırmayı tekrarlanabilir hale getirir.

DEV Community: Tobias Hoffmann

Bitwarden Yapay Zeka Kodlama Aracısı Güvenli Kasa Erişim Paylaşımı

Agent Access nedir?

2026’da neden önemli?

Kurulum

macOS Apple Silicon

macOS Intel

Linux x86_64

Windows x86_64

Hızlı başlangıç: kimlik bilgisi eşleştirme ve alma

En önemli desen: aac run ile ortam enjeksiyonu

Python ve Rust SDK’ları

Python

Rust

AI kodlama aracılarıyla entegrasyon

Claude Code

OpenAI Codex

Cursor

OpenClaw

Güvenlik modeli

1. Uçtan uca şifreleme

2. Kapsamlandırılmış kimlik bilgisi

3. Varsayılan olarak diske sır yazılmaz

Agent Access’in korumadığı durumlar

Pratik CI deseni: aracı kod yazar, Apidog test eder

Sınırlamalar ve uyarılar

Sıkça sorulan sorular

Agent Access ücretsiz mi?

Bitwarden dışındaki parola yöneticileriyle çalışır mı?

Parola yöneticisi olmadan kullanabilir miyim?

Tüketici sürecin ağ erişimine ihtiyacı var mı?

.env dosyasından farkı ne?

HashiCorp Vault veya AWS Secrets Manager’ın yerini alır mı?

Anthropic, OpenAI veya diğer aracı satıcıları bunu doğrudan entegre edecek mi?

Hata bildirmek veya katkı yapmak için nereye gitmeliyim?

Hemen deneyin

2026'da En İyi 7 API Yönetim Aracı (G2 Sıralaması)

Özet

G2 İlkbahar 2026 Çizelgesi Ne Anlatıyor?

Yedi Araca Hızlı Bakış

Apidog: Uçtan Uca API İş Akışları İçin Lider

Apidog ile pratik iş akışı

Apidog’un güçlü olduğu yerler

viaSocket: Kodsuz Entegrasyon Ekipleri İçin Lider

Ne zaman kullanılır?

Ne zaman kullanılmaz?

Traefik Labs: API Yönetimi Üzerine Açık Kaynak Ağ Geçidi

Traefik’i uygulamada nasıl konumlandırabilirsiniz?

Güçlü olduğu yerler

Zorlayıcı olduğu yerler

Rasayel: WhatsApp Business API Platformu

Ne zaman seçilir?

Ne zaman seçilmez?

Backendless: Otomatik Oluşturulan API’ler ile BaaS

Örnek kullanım senaryosu

Güçlü olduğu yerler

Zayıf olduğu yerler

Moesif Bir WSO2 Şirketi: API Analitiği ve Para Kazanma

Moesif ne sağlar?

Ne zaman kullanılır?

Ne zaman kullanılmaz?

Thunder Client: VS Code’un REST İstemci Uzantısı

Ne için iyi?

Ne değildir?

Ekibiniz İçin Doğru Aracı Nasıl Seçersiniz?

1. “API yönetimi” sizin yığınınızda ne demek?

2. Kaç kişi kullanacak?

3. Başlangıç kısıtınız ne?

4. Pratik karar akışı

İlkbahar 2026 Çizelgesinden Çıkarılacak Dersler

Apidog A2A Debugger ile Agent-to-Agent (A2A) Protokolü Nasıl Debug Edilir

A2A Nedir?

A2A Hata Ayıklayıcı Ne Sağlar?

Adım 1: İlk A2A Ajanına Bağlanın

Adım 2: Test Mesajı Gönderin

Dosya eki

Meta veri

Adım 3: Yanıtı Üç Görünümle İnceleyin

Önizleme

İçerik

En önemli desen: `aac run` ile ortam enjeksiyonu

`.env` dosyasından farkı ne?