İçeriğe geç

OpenAI Agents API mi Claude Managed Agents mı? Hangi ajan işi için hangisi?

Yönetilen ajan seçimini Codex düzeni, sürümleme, oturum bütçesi, sandbox, veri saklama ve gerçek görev tiplerine göre yapan uygulanabilir rehber.

Kaynakdoğrulandı
  1. [01]OpenAI — Introducing the Agents API2026-10-06
  2. [02]OpenAI — Agents API (beta) FAQ2026-10-06
  3. [03]Anthropic — Using the Messages API2026-10-06
  4. [04]Anthropic — Start a Managed Agents session2026-10-06
  5. [05]Anthropic — API and data retention2026-10-06

Kısa cevap: Uzun süren kodlama veya araştırma işinde Codex çalışma düzeni, OpenAI araçları ve farklı sandbox seçenekleri senin için önemliyse OpenAI Agents API'yi dene. Sürüm sabitleme, oturum başına bütçe, zamanlanmış çalışma ve Claude tarafında ayrıntılı oturum kontrolü istiyorsan Claude Managed Agents daha hazır bir seçenek. Tek istek, kısa araç zinciri ya da sıkı veri saklama sınırı varsa ikisini de seçmeden önce doğrudan model API'siyle kendi döngünü kurmayı değerlendir.

Bu yazı bağımsız performans testi değil. Ürünlerin beta durumunu, resmi belgelerde açıklanan çalışma biçimlerini ve sınırlarını karşılaştırıyor. "Daha iyi" kararı model benchmark'ından çok, ajan döngüsünü kimin yöneteceğine ve verinin nerede tutulabileceğine bağlı.

En kısa karar

  • OpenAI Agents API: Codex arkasındaki yönetilen ajan düzenini, OpenAI barındırmalı, kendi altyapındaki veya iş ortağı sandbox'ıyla kullanmak için.[1]
  • Claude Managed Agents: sürümlenmiş ajan, ortam ve kalıcı oturumu; bütçe, olay akışı ve zamanlanmış çalışmayla yönetmek için.[4]
  • Kendi ajan döngün: iş kısa ve öngörülebilir olduğunda ya da oturum kaydının sağlayıcı tarafında kalması uygun olmadığında.

İki ürün de yalnızca modele istek gönderen ince bir katman değil. Oturumun sürmesini, araç çağrılarını ve uzun işin bağlamını sağlayıcı yönetiyor. Bunun karşılığında altyapı işi azalıyor ama yürütme biçiminin bir bölümü sağlayıcının beta ürününe bağlanıyor.

Asıl seçim model değil, kontrol katmanı

Bir kodlama ajanında iki ayrı karar var. Birincisi modelin hangi kodu veya kararı üreteceği. İkincisi oturumu kimin açık tutacağı, araçları kimin çağıracağı, bağlam dolunca ne yapılacağı ve kesilen işin nasıl devam edeceği.

OpenAI, Agents API'yi Codex'i çalıştıran harness ve altyapının API'ye açılmış hali olarak tanımlıyor. OpenAI ajan döngüsünü işletiyor; geliştirici görev, model, araç ve ortamı seçiyor. Uzun oturumlarda bağlam sıkıştırma, araç arama ve alt ajan koordinasyonu bu yönetilen katmanda bulunuyor.[1]

Anthropic tarafında Managed Agents; ajan, ortam ve oturum kaynaklarını ayırıyor. Bir oturum konuşma geçmişini birden fazla etkileşim boyunca koruyor, belirli bir ajan sürümüne sabitlenebiliyor ve olaylarla yönlendiriliyor.[4]

Bu ayrım, tek ajan mı alt ajanlar mı rehberindeki karardan önce gelir. Paralel çalışmayı düşünmeden önce oturumun, dosya sisteminin ve onay kapılarının kimde olduğunu netleştir.

OpenAI Agents API ne zaman daha mantıklı?

OpenAI tarafını şu durumda ilk pilot olarak seçerdim: mevcut uygulama Responses API ve OpenAI modellerini kullanıyor, iş birkaç dakikadan uzun sürüyor ve Codex'in araç kullanma düzenini yeniden kurmak istemiyorsun.

OpenAI üç ortam seçeneği anlatıyor: ortam kullanmamak, OpenAI barındırmalı sandbox ve kendi altyapında sandbox. Dosya ve kabuk gerektirmeyen ajan ortam olmadan çalışabilir. Kod çalıştırma ve dosya üretme gerekiyorsa barındırmalı sandbox; özel ağ, yazılım veya altyapı gerekiyorsa self-hosted yol seçilebilir.[2]

Bu esneklik özellikle şu işler için anlamlı:

  • Bir depoyu açıp dosya değiştiren, test çalıştıran ve çıktı üreten uzun kodlama oturumu.
  • Özel ağdaki araçlara ulaşması gereken ama ajan koordinasyonunu OpenAI'ye bırakmak istediğin iş.
  • Araştırma, analiz ve kodlama parçalarını bağımsız alt ajanlara ayırabilen görev.
  • Bağlam dolduğunda sıkıştırma ve devam mantığını sıfırdan yazmak istemediğin uygulama.

OpenAI'nin kendi iddiasına göre API, önceki bağlamı oturum sınırına yaklaşırken otomatik sıkıştırıyor; araç tanımlarını ihtiyaç oldukça yüklüyor ve bağımsız işleri alt ajanlara dağıtabiliyor.[1] Bunlar üretici özellikleri. Senin kod tabanında daha yüksek tamamlama oranı sağlayacağını varsaymak yerine, aynı kabul testiyle ölçmek gerekir.

Claude Managed Agents ne zaman daha mantıklı?

Claude tarafı, uzun işin operasyonel sınırlarını oturum oluştururken açıkça tanımlamak isteyen ekip için daha güçlü bir ilk aday. Anthropic bir oturumu belirli ajan sürümüne sabitlemeye, yalnız o oturum için model veya araçları değiştirmeye ve dolar cinsinden azami liste maliyeti koymaya izin veriyor.[4]

Şu kullanım biçimleri öne çıkıyor:

  • Ajan sürümünü kademeli dağıtmak ve eski oturumları aynı sürümde tutmak.
  • Tek bir pahalı göreve sert maliyet tavanı koymak.
  • OAuth isteyen MCP araçlarını credential vault üzerinden bağlamak.
  • Kullanıcı mesajı ve beklenen sonuçla oturumu tek çağrıda başlatmak.
  • Aynı ajanı düzenli aralıklarla çalıştırıp koşu geçmişini incelemek.

Bütçe sınırının küçük bir dipnotu var. Anthropic, sınırı model istekleri arasında uyguluyor; limiti aşan son istek tamamlanabildiği için nihai tutar tavanın biraz üstüne çıkabilir.[4] Bu yine de kontrolsüz uzun koşuya göre daha açık bir maliyet kapısıdır.

Anthropic ayrıca Messages API ile Managed Agents arasındaki ayrımı doğrudan yapıyor: Messages API özel ajan döngüsü ve ince kontrol, Managed Agents ise uzun ve eşzamansız işler için yönetilen harness.[3] Kısa ve deterministik bir araç zincirinde Managed Agents kullanmak gereksiz katman ekleyebilir.

Self-hosted sandbox tam self-hosting değildir

İki üründe de "self-hosted" sözü kolay yanlış anlaşılır. Kodu ve araçları kendi ortamında çalıştırmak, ajan oturumunun tüm kontrol düzeyini kendi sistemine taşımak anlamına gelmez.

OpenAI, self-hosted sandbox kullansan bile Agents API oturum durumunu sakladığını ve ürünün Zero Data Retention desteklemediğini açıkça söylüyor. Beta döneminde veri yerleşimi yalnız ABD ile sınırlı.[2]

Anthropic de Managed Agents oturum metinlerinin sen silene kadar kaldığını belirtiyor.[5] Yürütme ortamını kendin barındırmak, sağlayıcının yönettiği oturum kaydını ortadan kaldırmıyor.

Bu yüzden veri kararı için üç ayrı soru sor:

  1. Kod ve komutlar nerede çalışıyor?
  2. İstemler, araç sonuçları ve oturum geçmişi nerede tutuluyor?
  3. Dosya, artefact ve oturum ne zaman, hangi API çağrısıyla siliniyor?

Müşteri verisi, sağlık verisi, gizli kaynak kod veya bölgesel veri zorunluluğu varsa ürün adındaki "self-hosted" etiketine bakarak karar verme. Hukuk ve güvenlik incelemesini gerçek veri akışı üzerinden yap.

Hangi görev hangi ürüne gider?

Bir saat süren depo migration'ında, Codex düzeni ve kendi VPC sandbox'ın gerekiyorsa OpenAI Agents API mantıklı pilot. Aynı migration'da ajan sürümünü sabitlemek, oturum bütçesini baştan kesmek ve düzenli koşular kurmak daha önemliyse Claude Managed Agents öne çıkar.

Bir PR için yalnız diff okuyup beş maddelik inceleme döndüreceksen yönetilen uzun oturuma ihtiyacın olmayabilir. Doğrudan Responses veya Messages API çağrısı daha az hareketli parçayla yeterli olur. Anthropic'in belgesi Messages API'yi özel döngü ve ince kontrol için konumluyor; bu seçim kısa işler için iyi bir hatırlatma.[3]

Yerel dosyalara sürekli dokunan etkileşimli çalışma için bu karşılaştırma tek başına yetmez. Yerel ve bulut kodlama ajanı rehberi gecikme, izin ve ortam erişimi kararını ayrıca ele alıyor.

Solo geliştirici için düşük riskli pilot

İki ürünü aynı anda bütün projeye bağlama. Tek bir gerçek ama geri alınabilir görev seç. Örneğin bağımlılık güncellemesi, sınırlı bir refactor veya dokümantasyon ile test uyumsuzluğu.

Her iki pilotta şunları sabit tut:

  • Aynı başlangıç commit'i ve görev metni.
  • Aynı dosya ve ağ izinleri.
  • Aynı süre ve maliyet tavanı.
  • Aynı test, lint ve build komutları.
  • Aynı insan inceleme listesi.

Ardından yalnız token maliyetini değil; geçen süreyi, araç çağrısı sayısını, başarısız tekrarları, insan müdahalesini ve ilk denemede geçen kabul testini kaydet. Başarılı iş başına maliyet yaklaşımı bu ölçümü token fiyatından ayırıyor.

İlk pilotta tam erişim verme. Kodlama ajanı izin modu rehberindeki gibi önce okuma ve planlama sınırıyla başla; yazma, ağ ve üretim erişimini görevin ihtiyacına göre aç.

Tamamlandı mesajı neden yeterli değil?

OpenAI, tamamlanmış bir turun bütün araçların başarılı olduğu anlamına gelmediğini; boşta görünen oturumun da işin başarıyla bittiğini kanıtlamadığını yazıyor.[2] Bu, hangi ürünü seçersen seç aynı kalan sınır.

Pilotun son kapısı sağlayıcının durum etiketi değil, senin kabul kanıtın olmalı:

  • Değişen dosya listesi beklenen kapsamda mı?
  • Diff istenmeyen yan etki taşıyor mu?
  • Odak testleri ve geniş build gerçekten geçti mi?
  • Güvenlik, veri ve üretim davranışı ayrıca kontrol edildi mi?
  • Ajan başarısız veya eksik adımı sonuç özetinde açıkça söyledi mi?

Kodlama ajanı çıktısı doğrulama kontrol listesi bu kapıyı yedi adıma bölüyor. Yönetilen harness bakım işini azaltabilir; ürün kabulünü senin yerine yapmaz.

Son karar

OpenAI Agents API'yi Codex düzeni, geniş sandbox seçimi ve OpenAI araçları için seç. Claude Managed Agents'ı sürümlü ajan dağıtımı, oturum bütçesi ve zamanlanmış çalışma gibi açık operasyon kontrolleri için seç. Kısa işte ya da sıkı veri saklama şartında yönetilen ajan kullanmamak daha doğru olabilir.

Ben olsam ilk kararı marka üzerinden vermezdim. Bir geri alınabilir görevi iki ayrı oturumda koşturur, aynı doğrulama kapısından geçirir ve ancak başarı başına toplam maliyet ile müdahale sayısını gördükten sonra tek üründe genişlerdim. Model adı değişir; kötü tanımlanmış kabul testi ikisinde de aynı sorunu üretir.