Bilgisayar Kullanımı ve Yapılandırılmış API'ler: Hangisi Ne Zaman Kazanır (2026)

Bir LLM ile bir tarayıcıyı “bilgisayar kullanımı” modelleriyle yönetmek, aynı işi yapılandırılmış bir API çağrısıyla yapmaktan kabaca 45 kat daha pahalı olabilir.

Apidog'u bugün deneyin

Bu rehberde 45 katlık farkın nereden geldiğini, bilgisayar kullanımının hangi durumlarda hâlâ mantıklı olduğunu ve Apidog ile yapılandırılmış API yolunu nasıl daha hızlı, ucuz ve test edilebilir hale getireceğinizi adım adım ele alacağız.

Aşağıdaki karar çerçevesi OpenAI Operator, Anthropic bilgisayar kullanımı, tarayıcı ajanları, Skyvern ve ekran görüntüsü döngüsüyle çalışan benzer araçlar için geçerlidir.

AI ajanları için API yazıyorsanız, agents.md dosyaları nasıl yazılır rehberini de okuyun. Oradaki kurallar, ajanlarınızın varsayılan olarak yapılandırılmış API yolunu seçmesini kolaylaştırır.

TL;DR

• Bilgisayar kullanımı: LLM ekran görüntüsüne bakar, tıklar, yazar, kaydırır ve tekrar ekran görüntüsü alır.
• Yapılandırılmış API: LLM, arka ucunuzun çalıştırdığı JSON araç çağrıları üretir.
• Aynı görevde bilgisayar kullanımı genellikle 30-50 kat daha fazla token harcar.
• Nedeni basit: her adımda yeni ekran görüntüsü gönderilir, yanlış tıklamalar yeniden denenir.
• API varsa, varsayılan olarak API kullanın.
• Bilgisayar kullanımını yalnızca API yoksa, API erişimi engelliyse veya iş akışı otomasyona direniyorsa kullanın.
• En gerçekçi mimari hibrittir: işlemlerin çoğu yapılandırılmış API ile, uzun kuyruk ise bilgisayar kullanımıyla yönetilir.
• JSON araç şemalarını tasarlamak, mock sunucu ile test etmek ve ajan çalıştırmalarını tekrar oynatmak için Apidog kullanabilirsiniz.

Maliyet farkı neden bu kadar büyük?

45 katlık fark özel bir benchmark sonucu değil; iki yaklaşımın token tüketme biçiminden kaynaklanır.

Yapılandırılmış API akışı genelde şu şekildedir:

1. Kullanıcı isteği modele gönderilir.
2. Modele bir araç şeması verilir.
3. Model JSON argümanları üretir.
4. Uygulama bu JSON’u ilgili API çağrısına dönüştürür.
5. Sonuç modele veya kullanıcıya döner.

Tipik maliyet:

• birkaç yüz giriş token’ı,
• birkaç düzine çıkış token’ı,
• bir HTTP çağrısı.

Bilgisayar kullanımı ise döngüsel çalışır:

1. Kullanıcı isteği modele gönderilir.
2. Tarayıcı ekran görüntüsü modele gönderilir.
3. Model tıklama veya yazma aksiyonu üretir.
4. Aksiyon çalıştırılır.
5. Yeni ekran görüntüsü alınır.
6. Döngü tekrar eder.

Basit bir “uçuş rezervasyonu yap” veya “raporu indir” görevi 12-30 tur sürebilir. Her ekran görüntüsü tipik çözünürlükte yaklaşık 1.500 token maliyetindedir. Buna yanlış tıklamalar, çerez banner’ları, kaydırma hataları ve yeniden denemeler eklenir.

Anthropic’in bilgisayar kullanımı belgeleri, ekran görüntüsü token maliyetlerini açıkça belirtir. Computer Use is 45x more expensive than structured APIs başlıklı HN tartışmasında da tipik ceza 30-50 kat aralığında veriliyor. Bu, aynı görevi hem ekran görüntüsü döngüsüyle hem de yapılandırılmış API ile yeniden oynattığınızda pratikte göreceğiniz farkla uyumludur.

Yapılandırılmış API yolu ne zaman kazanır?

Aşağıdaki koşullardan biri bile doğruysa, varsayılan olarak yapılandırılmış API kullanın.

1. Satıcının belgelenmiş bir API’si var

Satıcı OpenAPI spesifikasyonu, GraphQL şeması veya tek sayfalık REST dokümanı yayınlıyorsa, ajan için yapılandırılmış araç yüzeyi oluşturabilirsiniz.

Bir JSON şekli varsa, LLM onu doldurabilir.

Örnek:

{
  "customer_id": "cus_123",
  "status": "failed",
  "from": "2026-01-01",
  "to": "2026-01-02"
}

Bu tür bir yapı, ekran görüntüsünden veri okumaktan daha ucuz, hızlı ve test edilebilirdir.

2. Görev bir veya iki uç noktaya sığıyor

Şu görevler için tarayıcı açmak gereksizdir:

• Stripe müşterisi oluşturmak
• HubSpot anlaşma aşamasını güncellemek
• Slack mesajı göndermek
• CI job’ını yeniden çalıştırmak
• CRM kaydı güncellemek
• fatura listesini çekmek

Bunların her biri doğrudan API çağrısıdır.

3. İş akışı gözetimsiz çalışıyor

Cron job, webhook veya kuyruk worker’ı içinde çalışan bir ajan, ekrana bakıp yanlış yöne kaydıran bir tarayıcı döngüsünü denetleyemez.

Gözetimsiz işlerde yapılandırılmış API çağrıları daha deterministiktir.

4. Gecikme önemli

Yapılandırılmış API çağrısı çoğunlukla 200-800 ms aralığında döner.

15 turluk bilgisayar kullanımı döngüsü ise 30-90 saniye sürebilir. Yeniden denemeler devreye girerse daha da uzar.

Kullanıcı bekliyorsa, neredeyse her zaman API yolunu seçin.

5. Göndermeden önce test etmeniz gerekiyor

JSON uç noktasını mock’lamak kolaydır.

Apidog ile:

1. endpoint’i tasarlarsınız,
2. örnek yanıtı tanımlarsınız,
3. mock sunucuyu açarsınız,
4. ajanı gerçek üretim ortamına bağlamadan test edersiniz.

Tarayıcı ekran görüntüsü döngüsünü aynı doğrulukla mock’lamak ise çok daha zordur.

Bilgisayar kullanımı ne zaman işe yarar?

Bilgisayar kullanımı varsayılan olmamalıdır; ancak bazı durumlarda doğru araçtır.

Eski satıcı portalları

Bazı tedarik, navlun, sigorta veya kamu portalları REST API sunmaz. Eski ASP.NET oturumları ve form tabanlı paneller arkasında çalışırlar.

Bu durumda seçenekleriniz şunlardır:

• kırılgan Selenium script’i,
• manuel operasyon,
• bilgisayar kullanımı.

Eğer işlem düşük hacimliyse ve bakım maliyeti yüksekse, 45 kat token maliyeti kabul edilebilir.

Değiştiremeyeceğiniz dahili araçlar

Örnekler:

• eski CRM,
• eski ERP,
• SharePoint panosu,
• müşteri tarafından kilitlenmiş yönetim paneli.

Entegrasyon geliştiremiyorsanız ve ekip iPaaS satın almayacaksa, ekran görüntüsü döngüsü pratik bir ara çözüm olabilir.

Tek seferlik operatör görevleri

Örneğin:

“Bu 50 rakibi araştır, fiyatlarını çıkar ve Notion’a yapıştır.”

Bu, uzun ömürlü API sözleşmesi gerektiren bir iş akışı olmayabilir. Tek seferlik veya çok düşük hacimli işler için bilgisayar kullanımı yeterlidir.

Hizmet şartlarını ihlal eden scraping işleri

Bunu yapmayın.

“Bu siteyi bilgisayar kullanımıyla scrape edelim” isteklerinin çoğu, satıcı şartlarının yanlış tarafında yer alır. Böyle bir durumda maliyet, sorunun en küçük kısmıdır.

Basit karar çerçevesi

Bilgisayar kullanımına geçmeden önce şu kontrolleri yapın:

Pratik kural:

İlk iki sorudan biri “evet” ise bilgisayar kullanımı kullanmayın.

Müşteri kod tabanlarında görülen iş akışlarının büyük kısmı ilk veya ikinci kontrolde yapılandırılmış API’ye döner.

Yapılandırılmış API bir ajanda nasıl görünür?

Örnek görev:

“Dün başarısız olan ödemeleri göster.”

Yapılandırılmış yaklaşımda ajan, panoya girmez. Bunun yerine bir araç çağrısı üretir.

import json
from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "list_failed_payments",
            "description": "Belirli bir tarih aralığındaki başarısız ödemeleri listele",
            "parameters": {
                "type": "object",
                "properties": {
                    "start": {
                        "type": "string",
                        "format": "date"
                    },
                    "end": {
                        "type": "string",
                        "format": "date"
                    }
                },
                "required": ["start", "end"]
            }
        }
    }
]

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {
            "role": "user",
            "content": "Dün başarısız olan ödemeleri göster."
        }
    ],
    tools=tools,
    tool_choice="auto"
)

call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)

payments = stripe.PaymentIntent.list(
    created={
        "gte": args["start"],
        "lte": args["end"]
    },
    limit=100
)

Bu akışta:

1. kullanıcı isteği modele gider,
2. model list_failed_payments için JSON üretir,
3. uygulama Stripe API’sini çağırır,
4. sonuç kullanıcıya döner.

Ajan hiçbir zaman Stripe panosunu görmez.

Bilgisayar kullanımıyla aynı görev şöyle olurdu:

1. tarayıcı aç,
2. Stripe’a giriş yap,
3. dashboard ekran görüntüsü al,
4. tarih seçiciye tıkla,
5. tekrar ekran görüntüsü al,
6. tarih aralığını seç,
7. tekrar ekran görüntüsü al,
8. “Failed” filtresini bul,
9. tekrar ekran görüntüsü al,
10. sonuçları piksellerden çıkar.

Her ekran görüntüsü yaklaşık 1.500 giriş token’ı maliyetindedir. 12 tur tipiktir. Sonuç: daha yüksek maliyet, daha uzun gecikme ve daha düşük güvenilirlik.

Apidog ile yapılandırılmış yolu tasarlama

Ekipler genellikle maliyeti bildikleri halde bilgisayar kullanımına yönelir. Asıl neden çoğu zaman şudur:

Ajan için temiz bir araç yüzeyi tasarlanmamıştır.

Apidog, bu yüzeyi tasarlamak, mock’lamak ve test etmek için kullanılabilir.

1. Ajanın işlemlerini endpoint olarak modelleyin

Bir Apidog projesi oluşturun ve ajanın yapacağı işlemleri endpoint olarak tanımlayın.

Örnekler:

• POST /payments/failed/search
• POST /crm/deals/update-stage
• POST /messages/slack/send
• POST /reports/export
• POST /tickets/assign

Operatör demolarının büyük kısmı birkaç iyi tasarlanmış endpoint ile tarayıcı otomasyonuna gerek kalmadan çözülebilir.

2. OpenAPI 3.1 çıktısını üretin

Apidog tasarım görünümünden OpenAPI 3.1 belgesi çıkarabilirsiniz.

Bu belgeyi şu araçlara besleyebilirsiniz:

• OpenAI tools
• Anthropic tool use şeması
• LangChain OpenAPI loader
• benzer ajan framework’leri

Böylece ajan, serbest metin yerine tipli fonksiyon çağrıları üretir.

3. Mock sunucuyu açın

Apidog’un mock sunucusu her endpoint için gerçekçi JSON döndürür.

Bu sayede:

• üretim sistemine dokunmadan test edersiniz,
• gerçek ödeme veya CRM kaydı oluşturmazsınız,
• ajan token kredisi harcamadan akışı doğrularsınız,
• frontend, backend ve ajan geliştirmesini paralel yürütebilirsiniz.

Aynı yaklaşım Apidog’un sözleşme öncelikli geliştirme rehberinde de ele alınıyor.

4. İstek ve yanıtları tekrar oynatın

Ajan çalışırken her isteği ve yanıtı kaydedin.

Karşılaştırmanız gereken şeyler:

• başarılı çalıştırmadaki tool call,
• başarısız çalıştırmadaki tool call,
• parametre farkları,
• beklenen JSON ile gelen JSON arasındaki fark,
• modelin yanlış endpoint seçip seçmediği.

Bu, “ajan dün çalışıyordu, bugün bozuldu” problemini azaltır.

5. Aynı projeyi dokümantasyon, QA ve izleme için kullanın

İyi tasarlanmış bir Apidog projesi sadece dokümantasyon değildir.

Aynı proje:

• API sözleşmesi,
• mock sunucu,
• QA test yüzeyi,
• ajan araç şeması,
• hata ayıklama referansı

olarak kullanılabilir.

Hibrit mimari: iki yolu birlikte kullanmak

Üretimde çoğu ajan hibrit hale gelir.

Makul varsayılan:

• işlemlerin yüzde 90’ı yapılandırılmış API araçlarıyla yapılır,
• yüzde 10’u eski portallar veya API’siz sistemler için bilgisayar kullanımına düşer,
• küçük bir router, hangi yolun seçileceğine karar verir.

Örnek router mantığı:

Eğer işlem known_tools içinde varsa yapılandırılmış aracı çağır.
Aksi halde görevi tarayıcı ajanına devret.

Basit bir sistem mesajı:

Sen bir araç yönlendiricisisin.

Kullanıcının istediği işlem known_tools listesinde varsa ilgili aracı çağır.
İşlem listede yoksa ve yalnızca kullanıcı arayüzünden yapılabiliyorsa browser_agent'a devret.
API ile yapılabilecek işlemler için browser_agent kullanma.

Claude 4.5, GPT-5.5 ve DeepSeek V4 gibi modellerde bu yönlendirme deseni uygulanabilir. DeepSeek tarafındaki istek şekli için DeepSeek V4 API nasıl kullanılır yazısına bakabilirsiniz.

İzleme tarafında iki yolu ayrı metriklerle takip edin:

• yapılandırılmış API çağrıları,
• bilgisayar kullanımı çağrıları,
• her yolun token maliyeti,
• her yolun başarı oranı,
• ortalama gecikme,
• retry sayısı.

Beklenen dağılım genellikle şuna benzer:

• yapılandırılmış çağrılar: hacmin büyük kısmı, maliyetin küçük kısmı,
• bilgisayar kullanımı: hacmin küçük kısmı, maliyetin büyük kısmı.

Bu oran tersine dönüyorsa, ajanınız yanlış işleri tarayıcı yoluna gönderiyor olabilir.

Kaçınılması gereken yaygın hatalar

Şema kullanmamak

Sadece düz yazı sistem prompt’u ile ajan göndermeyin.

Kötü:

Kullanıcının istediği CRM işlemini yap.

Daha iyi:

{
  "name": "update_deal_stage",
  "parameters": {
    "type": "object",
    "properties": {
      "deal_id": {
        "type": "string"
      },
      "stage": {
        "type": "string",
        "enum": ["qualified", "proposal", "closed_won", "closed_lost"]
      }
    },
    "required": ["deal_id", "stage"]
  }
}

JSON Schema ne kadar net olursa, araç çağrısı o kadar güvenilir olur.

Şemayı çalışma zamanında ajana tasarlatmak

Bir şema ürün yüzeyidir.

Şemayı:

• elle tasarlayın,
• versiyonlayın,
• review’dan geçirin,
• değişiklikleri API breaking change gibi ele alın.

Ajanın kendi şemasını çalışma zamanında değiştirmesi üretim hatalarına yol açar.

Maliyeti değil sadece token’ı izlemek

Bilgisayar kullanımı token’ları çoğu zaman görüntü girişlerinde saklıdır. Bazı gözlem araçları bunu net göstermeyebilir.

Kontrol etmeniz gereken yerler:

• model sağlayıcısının faturalandırma paneli,
• image input maliyeti,
• retry başına maliyet,
• tamamlanmamış çalıştırmaların maliyeti.

Bilgisayar kullanımını RPA ile karıştırmak

RPA, bilinen DOM öğelerine veya sabit adımlara karşı script çalıştırır.

Bilgisayar kullanımı ise her ekran görüntüsünde yeniden karar verir.

• RPA: tekrarlanabilir, ucuz, kırılgan.
• Bilgisayar kullanımı: esnek, pahalı, daha yavaş.

Eğer Playwright veya Puppeteer yeterliyse bilgisayar kullanımı kullanmayın.

Gecikme maliyetini unutmak

45 kat token faturası önemli. Ama kullanıcı deneyimi açısından 60 saniyelik bekleme daha da önemlidir.

Kullanıcı ekrana bakıyorsa:

• API kullanın,
• gerekirse ince adaptör yazın,
• bilgisayar kullanımını son çare yapın.

Dikkate alınacak alternatifler

Satıcının API’si yoksa ama kullanıcı arayüzü düzenliyse, tam bilgisayar kullanımı ile tam entegrasyon arasında ara seçenekler vardır.

Playwright veya Puppeteer

Başsız tarayıcı script’leri geliştirme sonrası çalıştırma başına model maliyeti getirmez.

Artıları:

• ucuz çalışır,
• hızlıdır,
• CI içinde koşabilir.

Eksileri:

• UI değişince bozulur,
• bakım gerektirir.

Zapier veya Make bağlayıcıları

Bazı satıcılar resmi iPaaS bağlayıcıları sunar.

Bu durumda entegrasyon vergisini platform zaten ödemiştir. Koltuk veya işlem ücreti ödeyip daha hızlı yayına çıkabilirsiniz.

Tersine mühendislik uygulanmış dahili JSON uç noktaları

Bazı paneller, tarayıcı içinde dahili JSON API’leri çağırır.

Geliştirici Araçları’nda Network sekmesini izleyerek bu uç noktaları görebilirsiniz.

Dikkat edilmesi gerekenler:

• hizmet şartlarını ihlal etmeyin,
• uç noktaları yarı kararlı kabul edin,
• değişikliklere karşı test yazın,
• Apidog’da belgeleyin.

Benzer yaklaşım Postman olmadan API testi yazısında da kullanılıyor.

Bilgisayar kullanımı son çaredir, varsayılan değil.

Gerçek dünya kullanım durumları

Bir finansal teknoloji uyumluluk ekibi, 6 adımlık bilgisayar kullanımıyla çalışan Stripe rapor akışını üç yapılandırılmış API çağrısıyla değiştirdi. Token maliyeti yüzde 92 azaldı, çalışma süresi 41 saniyeden 2 saniyeye düştü.

Bir B2B SaaS destek ajanı bilgisayar kullanımını yalnızca tek bir iş akışı için tuttu: API’si olmayan satıcı tedarik portalı. Diğer tüm işlemler Apidog’da tasarlanmış OpenAPI araç çağrılarına taşındı. Aylık token harcaması 4.200 dolardan 310 dolara düştü.

Tek başına çalışan bir kurucu, eski ERP sisteminden Notion panosunu yenilemek için haftada bir kez bilgisayar kullanımı çalıştırdı. Haftada bir çalıştırma için 45 kat maliyet birkaç kuruştu. Alternatif ise haftalar sürecek entegrasyon projesiydi. Bilgisayar kullanımının doğru kullanım şekli budur.

Sonuç

45 katlık fark gerçek, tekrarlanabilir ve mimari kararınızı değiştirmelidir.

Varsayılan yol:

1. işlemi API olarak modelleyin,
2. JSON Schema ile araç yüzeyi oluşturun,
3. Apidog’da mock’layın,
4. ajanı yapılandırılmış çağrılara yönlendirin,
5. yalnızca API yoksa bilgisayar kullanımına düşün.

Gönderilecek beş çıkarım:

• Bilgisayar kullanımı, eşdeğer yapılandırılmış API çağrısından 30-50 kat daha fazla token harcayabilir.
• Belgelenmiş endpoint ve JSON Schema; maliyet, gecikme ve güvenilirlik açısından ekran görüntüsü döngüsünden daha iyidir.
• Hibrit mimari normaldir: yüzde 90 yapılandırılmış API, yüzde 10 uzun kuyruk bilgisayar kullanımı.
• Canlı modele bağlamadan önce araç yüzeyini mock’layın.
• Yapılandırılmış çağrıları ve bilgisayar kullanımını ayrı izleyin.

Sonraki adım: Apidog’da ajanınızın araç yüzeyi için bir proje oluşturun, endpoint’leri modelleyin ve mock sunucuyu açın. Bilgisayar kullanımı olarak göndermeyi düşündüğünüz iş akışının iki yapılandırılmış çağrıya dönüşüp dönüşmeyeceğini bir saat içinde görebilirsiniz.

SSS

Bilgisayar kullanımı yapılandırılmış API’den hiç daha ucuz mudur?

Çalıştırma başına genellikle hayır. Ekran görüntüsü token’ları maliyeti domine eder.

Toplam maliyet açısından yalnızca şu durumda daha ucuz olabilir:

• API yoktur,
• iş akışı çok düşük hacimlidir,
• entegrasyon geliştirme maliyeti yıllarca sürecek çalıştırma maliyetinden fazladır.

Bir ajan için JSON araç yüzeyini nasıl mock’larım?

Apidog’da endpoint’leri tasarlayın, yerleşik mock sunucuyu açın ve ajanı mock URL’ye yönlendirin.

Her istek gerçekçi JSON döner. Böylece üretim sistemine dokunmadan uçtan uca test yapabilirsiniz. Benzer akış QA mühendisleri için API test araçları yazısında ele alınıyor.

Herhangi bir modelde araç çağrıları için OpenAPI kullanabilir miyim?

Evet. OpenAI tools, Anthropic tool_use ve DeepSeek V4 araç çağırma akışları OpenAPI 3.1 şemalarıyla kullanılabilir.

Apidog şemayı dışa aktarmanızı sağlar. DeepSeek istek şekli için DeepSeek V4 API nasıl kullanılır yazısına bakabilirsiniz.

GPT-5.5 hâlâ bilgisayar kullanımını destekliyor mu?

OpenAI, bilgisayar kullanımını Operator ürünü ve Responses API üzerinden sunar. Maliyet profili, ekran görüntüsü başına maliyet nedeniyle Anthropic bilgisayar kullanımına benzer. Bu makaledeki öneri satıcıdan bağımsızdır: API varsa API kullanın.

Skyvern, browser-use ve diğer açık kaynaklı ajanlar ne olacak?

Matematik aynı kalır.

Daha ucuz açık modellerle çağrı başına fiyatı düşürebilirler; ancak tur sayısı ve ekran görüntüsü boyutu benzer kalır. API mevcut olduğunda yapılandırılmış API çağrıları hâlâ daha ucuz ve güvenilirdir.

Bir ajan görevi için eksik endpoint olduğunu nasıl anlarım?

Şunları izleyin:

• başarısız tool call’lar,
• reddedilen tool call’lar,
• tarayıcı ajanına düşen işlemler,
• tekrar eden manuel adımlar.

Ajan sürekli tarayıcıya dönmeye çalışıyorsa, araç yüzeyinizde eksik endpoint olabilir. Endpoint’i Apidog’da ekleyin, şemayı yeniden oluşturun ve ajanı tekrar test edin.