Yapay Zekâ Ajanları Bir VPS Üzerinde Gece Boyunca Çalışacak Şekilde Nasıl Zamanlanır

Sabahın ikisinde, hiç uykuya geçmemiş bir VPS üzerinde zamanlanmış bir iş tetiklenir. Headless bir claude -p çalışma, klonlanmış bir depodaki sıradaki görevi kimseye hiçbir şey sormadan tamamlar ve çıkar. Sabah baktığınızda sizi bir commit, bir rapor ya da nerede ve neden durduğunu tam olarak gösteren bir günlük bekliyor olur. Kimse başında beklemedi.

Bu, bir terminali gece boyunca açık bırakıp SSH bağlantısının kopmamasını ummaktan farklı bir kurulumdur. Gece boyu süren bir ajan çalışmasında sık görülen bir arıza noktası ana makinedir: dizüstü bilgisayar uykuya geçer, kapak kapanır, ağ düşer ya da bir işletim sistemi güncellemesi makineyi görev ortasında yeniden başlatır. Kimlik doğrulama hataları, API hataları ve izin beklemeleri işi hâlâ öldürebilir, ancak sürekli açık bir ana makine en kolay arıza yolunu ortadan kaldırır.

Bu rehber gerçek mekanizmayı ele alıyor: her büyük kodlama ajanı CLI'sinin sunduğu headless bayraklar, bir çalışmayı zamanlamanın iki yolu ve hangisini seçmeniz gerektiği, altındaki ana makinenin neye ihtiyacı olduğu ve gözetimsiz bir çalışmanın sonradan açıklamak zorunda kalacağınızdan daha fazlasına mal olmasını ya da bozmasını engelleyen korumalar.

Kısa Versiyon

• Her büyük kodlama ajanı CLI'si, tek bir istemi sonuna kadar çalıştırıp çıkan, belgelenmiş bir etkileşimsiz mod sunar. Claude Code'da bu claude -p, Codex CLI'de codex exec, Gemini CLI'de ise gemini -p. Bu bir geçici çözüm değil, resmî bir özellik.
• Claude Code'un kendi zamanlaması da var: Routines, Desktop zamanlanmış görevleri ve /loop. Bazı okuyucular için bu gerçekten yeterlidir ve bakımı bir VPS'ten daha azdır.
• Gecelik bir iş için cron gayet iyi çalışır. Yeniden başlayabilecek bir makinede systemd zamanlayıcısı daha iyi bir varsayılandır, çünkü Persistent=true cron'un sessizce atlayacağı bir çalışmayı yakalar.
• CLI'nin kendisi hafiftir, çünkü çıkarım sağlayıcının API'sinde yapılır. VPS'i çalıştıracağı komutlara göre boyutlandırın (testler, derlemeler, konteynerler, paralel işler), modele göre değil.
• Bir zamanlamayı kendi haline bırakmayı güvenli kılan şey korumalardır: kapsamı daraltılmış araçlar, tur sınırı ve çıkış koduna göre dallanma. Zamanlamanın kendisi bir güvenlik mekanizması değildir.

Neye İhtiyacınız Olacak

Tek bir crontab satırı ya da unit dosyası yazmadan önce şu beş şeyi hazırlayın:

• SSH ile bağlanabileceğiniz, systemd tabanlı bir Linux dağıtımı çalıştıran bir VPS.
• O VPS'e kurulmuş ajan CLI'si: Claude Code, Codex CLI veya Gemini CLI.
• Seçtiğiniz CLI için etkileşimsiz bir kimlik bilgisi. Claude Code'un bare modu hiçbir hesap oturumunu okumaz, bu yüzden ortamda ANTHROPIC_API_KEY ya da ayarlarda bir apiKeyHelper ayarlanmış olması gerekir. Normal print modundaki bir çalışma, Codex ve Gemini belgelenen hesap oturum bilgilerini de kullanabilir.
• Ajanın üzerinde çalışacağı bir depo ya da görev dizini.
• Bir crontab düzenleme ya da systemd unit dosyası yazma iznine sahip kabuk erişimi.

Oturuma Bağlı Olmadan Bir Ajan Çalıştırmak

Her büyük kodlama ajanı CLI'si tam da bunun için tasarlanmış bir etkileşimsiz mod sunar. Claude Code -pseçeneğini alır, uzun yazımıyla --print. Codex CLI codex execkomutunu alır. Gemini CLI ise -pseçeneğini alır, uzun yazımıyla --promptseçeneğini alır. Her biri bir istem alır, sonuna kadar çalıştırır ve çıkar. Sohbet döngüsü yok, açık tutulacak bir terminal yok, yeniden bağlanılacak bir şey yok.

Claude Code canlı bir oturum olmadan çalışabilir mi? Evet. Şu seçeneği vermek: -p istemi etkileşimsiz modda çalıştırır. Claude Code istemi sonuna kadar yürütür, sonucu yazdırır ve çıkar. Sohbet döngüsü ya da canlı tutulacak bir şey yoktur ve etkileşimli CLI'yi çalıştıran aynı Agent SDK üzerinde koşar; kaynak: Anthropic'in kendi headless mod belgeleri.

Burada en çok Claude Code'un kendi bayrakları önemlidir, çünkü asıl onlara göre betik yazacaksınız. Bunlardan ikisi, kimsenin uyanık olmadığı bir saatte izin istemek için durmadan çalışmanın sürmesini sağlar: --allowedTools, belirli araçları önceden onaylar, ve --permission-mode, tüm çalışma için temel seviyeyi belirler. --max-turns bir çalışmanın hata vererek çıkmadan önce kaç ajan turu alabileceğini sınırlar.

--bare hook'ları, skill'leri, eklentileri, MCP sunucularını ve şu gibi proje talimatlarını atlar: CLAUDE.md. Böylece betikle çalışan bir koşu daha hızlı ve daha belirlenimci olur. Bu aynı zamanda işin bağlı olduğu her talimatın istemde ya da komutta bulunması gerektiği anlamına gelir. Bare modu hesap oturumunuzu da okumaz, bu yüzden Anthropic'in belgeleri ortamda bir API anahtarı tanımlamanızı söylüyor çalıştırmadan önce. Claude Code, --bg seçeneğini ile birlikte kullanıldığında doğrudan reddeder: -payrıca --cloud bir görev açıklamasıyla verildiğinde de aynı şekilde reddeder. Çakışmayı adıyla belirtir ve belirsiz bir şey yapmak yerine durur.

Örnek bir çağrı; istemi ve araç listesini kendi görevinize göre uyarlayın:

claude --bare -p "Review open PRs in this repo and summarize any blockers in NOTES.md" \
  --allowedTools "Bash(gh pr list *),Bash(gh pr view *),Bash(gh pr diff *),Read,Edit" \
  --permission-mode dontAsk \
  --max-turns 8 \
  --max-budget-usd 5.00 \
  --output-format json

Bütçeyi ve komut kalıplarını göreve göre ayarlayın; bu örnek ayrıca GitHub CLI kimlik doğrulamasının çalıştıran hesap için hâlihazırda yapılandırıldığını varsayar.

Claude Code'u sıfır bir VPS'e kuruyorsanız ve tarayıcısı olmayan bir makinede kimlik doğrulama adımlarını istiyorsanız, bu ayrı olarak şurada anlatılıyor: Claude Code'u headless bir sunucuda nasıl doğrularsınız; yukarıdaki kısa özet, zamanlanmış bir çalışmayı çalıştırmaya yeter.

Codex CLI'nin exec modu, şurada anlatılıyor: OpenAI'nin etkileşimsiz mod belgelerive şu seçeneği alır: --sandbox bir politika seçmek için. read-only varsayılandır, workspace-write ajanın kendi çalışma alanına yazmasına izin verir, ve --json stdout'u düz metin yerine makine tarafından ayrıştırılabilir bir olay akışına dönüştürür. Gözetimsiz bir işte danger-full-access bu seçenekten kaçının, süreç izole edilmiş ve bu risk bilinçli olarak alınmış değilse.

Gemini CLI'nin headless modu, şurada belgelenmiştir: projenin kendi headless belgeleriTTY olmayan bir ortamda otomatik olarak, ya da açıkça şu seçenekle etkinleşir: -p. Tek bir genel hata kodu yerine; genel hata, girdi hatası ve tur sınırına ulaşma için ayrı ayrı sıfırdan farklı çıkış kodlarıyla sonlanır.

Zamanlama Nerede Yaşamalı

Bütün bu kurulum işine girişmeden önce: ajan sağlayıcısı bunu sizin yerinize zaten zamanlıyor olabilir. Claude Code üç yerleşik seçenek sunar ve bunlardan biri kendi yönettiğiniz bir VPS'ten gerçekten daha uygun olabilir.

Anthropic'in kendi zamanlanmış görevler belgeleri bunu VPS'in tepede olduğu bir hiyerarşi olarak değil, gerçek bir üç yönlü seçim olarak ortaya koyuyor. Göreviniz makineye özgü bir duruma ihtiyaç duymuyorsa, bir saatlik alt sınıra katlanabiliyorsa ve yalnızca Claude Code kullanıyorsanız, Routines aşağıda anlatılanlardan daha az bakım ister: makineniz kapalıyken Anthropic onu bulutta, sıfırdan bir klonla çalıştırır.

/loop bilmeye değer ama bu kullanım senaryosuna uymaz, çünkü açık ve boşta bir oturum gerektirir; bu da tam olarak ortadan kaldırmaya çalıştığınız kısıttır. Aynı belgeler dördüncü bir seçenek olarak GitHub Actions'a da işaret ediyor; tetikleyicisi belirli bir makineye bağlı bir zamanlamada değil, zaten CI'da yaşayan ekipler için.

Kendi yönettiğiniz VPS, iş tam yerel dosya sistemi ve araç erişimi gerektirdiğinde, aynı mekanizmanın Claude Code, Codex CLI ve Gemini CLI'de birebir aynı şekilde çalışmasını istediğinizde ya da Routines'in izin verdiği aralık fazla kaba geldiğinde yerini hak eder. Klasik bir sunucusuz işlev burada genellikle sırıtır, çünkü kimlik bilgilerini geri yüklemesi, depoyu klonlaması ve platformun çalışma süresi sınırları içinde bitirmesi gerekir. GitHub Actions gibi geçici bir CI koşucusu, her çalışmada sıfırdan bir checkout kabul edilebilir olduğunda hâlâ geçerli bir üçüncü yoldur. Zaten boşta duran, sürekli açık bir donanımınız varsa bir homelab makinesi de iş görür; takas, bir sağlayıcınınki yerine kendi ev ağınızın güvenilirliği ve uzaktan erişiminizdir.

Cron mu, systemd Zamanlayıcı mı?

Her iki araç da aynı komutu aynı zamanlamayla tetikleyebilir, ancak makine yeniden başladığında ne olacağı ve her birinin kurulum maliyeti konusunda ayrışırlar:

Nadiren yeniden başlayan bir makinede gecelik bir iş için sade cron yeterlidir. İşin püf noktası ortamdır: cron asgari bir PATHile başlar, sizin yerinize deponuza girmez ve ilki hâlâ çalışırken ikinci bir kopyayı gönül rahatlığıyla başlatır. Depo yolunu, dar kapsamlı ajan komutunu ve kimlik bilgisi yüklemeyi korumalı bir sarmalayıcı betiğe koyun, ardından çakışan çalışmaları önlemek için flock kullanın.

# /usr/local/bin/agent-nightly
#!/usr/bin/env bash
set -euo pipefail
export PATH=/usr/local/bin:/usr/bin:/bin
export ANTHROPIC_API_KEY="$(
  cat "$HOME/.config/agent-nightly/anthropic_api_key"
)"
cd /srv/myrepo
exec /usr/local/bin/claude --bare -p \
  "Run the nightly dependency audit and write the findings to NOTES.md" \
  --allowedTools "Bash(npm audit *),Read,Edit" \
  --permission-mode dontAsk \
  --max-turns 8 \
  --max-budget-usd 5.00 \
  --output-format json

# crontab -e
0 2 * * * /usr/bin/flock -n "$HOME/.local/state/agent-runs/nightly.lock" /usr/local/bin/agent-nightly >> "$HOME/.local/state/agent-runs/nightly.log" 2>&1

Kimlik bilgisi ve günlük dizinlerini bir kez oluşturun, ardından sarmalayıcıyı çalıştırılabilir yapın:

install -d -m 700 \
  "$HOME/.config/agent-nightly" \
  "$HOME/.local/state/agent-runs"
touch "$HOME/.config/agent-nightly/anthropic_api_key"
chmod 600 "$HOME/.config/agent-nightly/anthropic_api_key"
"${EDITOR:-nano}" \
  "$HOME/.config/agent-nightly/anthropic_api_key"
sudo chmod 755 /usr/local/bin/agent-nightly

Kimlik bilgisi dosyasına yalnızca API anahtarını yapıştırın. Doğrudan crontab'a koymayın.

systemd zamanlayıcısı daha fazla kurulum ister ve size cron'da olmayan iki şey kazandırır: elle yönlendirme yapmadan journald ile günlükleme ve Persistent=true. Aşağıdaki örnek, ayrılmış bir agent-runner hesabının /srv/myreposahibi olduğunu varsayar. API anahtarını unit dosyasına gömmek yerine yalnızca root'un okuyabileceği bir kimlik bilgisi dosyasında saklayın.

Göre systemd.timer kılavuzuuyarınca Persistent=true ayarı şu anlama gelir: "Zamanlayıcının etkin olmadığı süre içinde en az bir kez tetiklenecek olsaydı, servis birimi hemen tetiklenir." Yani VPS'iniz çekirdek güncellemesi için yeniden başlarken tetiklenecek olan bir çalışma, sonraki zamanlanmış slota kadar sessizce yok olmak yerine sistem geri gelir gelmez başlar.

Servisin kullandığı, yalnızca root'un erişebildiği kimlik bilgisi dosyasını oluşturun:

sudo install -d -m 700 /etc/agent-nightly
sudo touch /etc/agent-nightly/anthropic_api_key
sudo chmod 600 /etc/agent-nightly/anthropic_api_key
sudoedit /etc/agent-nightly/anthropic_api_key

Dosyaya yalnızca API anahtarını yapıştırın.

# /etc/systemd/system/agent-nightly.service
[Unit]
Description=Nightly scoped agent run
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent-runner
Group=agent-runner
WorkingDirectory=/srv/myrepo
Environment=HOME=/home/agent-runner
Environment=PATH=/usr/local/bin:/usr/bin:/bin
LoadCredential=anthropic_api_key:/etc/agent-nightly/anthropic_api_key
ExecStart=/bin/sh -c 'export ANTHROPIC_API_KEY="$(cat "$CREDENTIALS_DIRECTORY/anthropic_api_key")"; exec /usr/local/bin/claude --bare -p "Run the nightly dependency audit and write the findings to NOTES.md" --allowedTools "Bash(npm audit *),Read,Edit" --permission-mode dontAsk --max-turns 8 --max-budget-usd 5.00 --output-format json'
StandardOutput=journal
StandardError=journal
UMask=0077

# /etc/systemd/system/agent-nightly.timer
[Unit]
Description=Run agent-nightly.service at 2am daily, catching up missed runs

[Timer]
# Uses the VPS's configured local timezone
OnCalendar=*-*-* 02:00:00
Persistent=true
Unit=agent-nightly.service

[Install]
WantedBy=timers.target

systemd'yi yeniden yükleyin, zamanlayıcıyı etkinleştirin ve servisi bir kez hemen çalıştırın; böylece kimlik bilgisi, izin ve yol sorunları sabahın ikisinde değil şimdi ortaya çıksın:

sudo systemctl daemon-reload
sudo systemctl enable --now agent-nightly.timer
sudo systemctl start agent-nightly.service
systemctl list-timers agent-nightly.timer
sudo journalctl \
  -u agent-nightly.service \
  -n 100 \
  --no-pager

Persistent=true belirleyici farktır: zamanlayıcı, kaçırılan bir takvim çalışmasını sessizce düşürmek yerine hatırlar.

VPS'in Aslında Neye İhtiyacı Var

İşte bunu ilk kez boyutlandıranları şaşırtan kısım: CLI'nin kendisi hafiftir, çünkü çıkarım sağlayıcının API'sinde yapılır. Ama ajan yine de yerelde derlemeler, testler, paket yöneticileri, dil sunucuları ve konteynerler başlatabilir; yani gerçek alt sınırı deponun iş yükü belirler.

Tek bir hafif zamanlanmış iş için başlangıç noktası olarak 1-2 vCPU ve 2-4 GB RAM ile NVMe depolamayı esas alın. Büyük depolar, derleyiciler, Docker derlemeleri, test paketleri veya eşzamanlı çalışmalar bundan çok daha fazlasını isteyebilir. Ölçeği büyütmeye iten şey, API'nin arkasındaki model değil, ajanın çalıştıracağı en ağır yerel komuttur. Bu VPS'te zaten Docker iş yükleri çalıştırıyorsanız ve bütçeye dair daha bütün bir resim istiyorsanız, bir derleme makinesini boyutlandırmak ve güvenceye almak aynı ödünleşimi başka bir gözetimsiz iş yükü için adım adım anlatıyor.

Planlamaya değer bir şey daha: gözetimsiz bir çalışma, bir şey ters gitse de gitmese de her gece günlük üretir. cron bir dosyaya yazıyorsa logrotate ekleyin ve journald'ın varsayılanlarının VPS diskine uyduğunu varsaymak yerine saklama sınırlarını kontrol edin.

Bütün yaklaşım, sabahın ikisinde uyanık olan ve dizüstünüz ne yaparsa yapsın öyle kalan bir ana makineye dayanır. Bu tam olarak kök erişimli bir Linux VPS Linux VPS'in tam da işidir. Hiçbir şey onu uykuya sokmaz ve onu başkasının cron işleriyle paylaşmazsınız.

Gözetimsiz Bir Çalışmanın Ters Gitmesini Önlemek

İşleyen bir zamanlanmış çalışma ile işlemeyen arasındaki en büyük fark, görevin ortada bir insanın soruya cevap vermesine gerek kalmadan bitecek kadar dar tanımlanmış olup olmadığıdır. İddialı istemler, kimsenin veremeyeceği bir kararı bekleyerek takılır; dar ve kendi kendine yeten görevler tamamlanıp temiz biçimde çıkar.

İki izin bayrağı, bir çalışmanın sabahın ikisinde bir izin istemine takılmaması için vardır; ancak çıplak Bash erişimi dar bir koruma değildir: servis hesabının yapabildiği neredeyse her şeyi yapabilir. Bunun yerine komuta özgü kurallar tercih edin, örneğin Bash(git status *), bunları şununla eşleştirin: --permission-mode dontAskve servisi kök olmayan, ayrılmış bir hesap altında çalıştırın. Tur sayısı ile harcamanın kendi tavanları vardır: --max-turns ajanın ne kadar dolaşabileceğini sınırlar, --max-budget-usd ise tek bir çalışmanın API çağrılarına ne kadar harcayabileceğine tavan koyar.

İpucu: şu seçenekle çalıştırın: --output-format json ve her çağrının total_cost_usd alanını günlüğe yazın. Zamanlanmış bir çalışmanın gerçekte gece başına ne kadara mal olduğunu izlemek ve bir çalışma diğerlerinden gözle görülür biçimde pahalıya patladığında uyarı almak için en temiz kancadır. Kurmanın aldığı beş dakikaya değer, çünkü izlediği şey soyut bir kavram değil, sizin faturanız.

Gözetimsiz maliyet aşımları varsayımsal değildir. Hacker News'teki bir gönderide, bir kullanıcı, istem önbelleklemesinin yalnızca kısmen işe yaradığı ve yaklaşık 6,47 milyar girdi belirtecinin önbelleğe alınmadan kaldığı günlük bir kodlama ajanı iş akışından doğan 37.901,73 dolarlık brüt AWS Bedrock faturası bildirdi. Bu, Claude Code'un headless modunda değil, başka bir yığında yaşandı; ama maliyet günlüklemesinin ve çalışma başına katı bir bütçenin neden zamanlamanın parçası olması gerektiğini gösteriyor.

İpucu: Claude Code başarıda 0, başarısızlıkta sıfırdan farklı bir kodla çıkar. Çıkış durumunu kontrol eden bir sarmalayıcı betik, başarısızlıkta size bildirim gönderebilir; böylece kötü bir gece, üç gün sonra tesadüfen bakarken değil, ertesi sabah ortaya çıkar.

En azından her işi ayrı bir dalda ya da tek kullanımlık bir worktree'de çalıştırın ve birleştirmeden önce insan incelemesi şart koşun. Kapsamı daraltılmış kimlik bilgileri, dosya sistemi yalıtımı ve sunucu düzeyinde etki alanı denetimi, bir zamanlama rehberinin sonuna iliştirilmiş bir paragraftan çok kendi başına ele alınmayı hak eden daha büyük bir konudur.

Zamanlamayı kendi haline bırakmayı güvenli kılan şey korumalardır: zamanlamanın kendisi bir güvenlik mekanizması değildir.

Cron Ne Zaman Yetmemeye Başlar

Bir zamanlayıcı üzerindeki tek bir istem, burada anlatılanlardan fazlasına ihtiyaç duymaz. Koşullu, yeniden denemeli ve Slack bildirimli üç zincirleme adım ise başka bir şey ister.

Bilmeye değer üç seçenek var; her biri farklı bir nedenle bir üst basamak:

• Dagu en hafif üst basamaktır: YAML ile tanımlanan, kendi kendine yeten işler; DAG bağımlılıkları, yeniden denemeler ve neyin çalıştığını izlemek için bir web arayüzü.
• n8n ajan çalışmasının tüm iş akışı değil, birkaç entegrasyon ve bildirim arasında tek bir düğüm olduğu durumlarda en iyi oturur.
• Kestra üçünün en ağırıdır; veri ve altyapı hatlarını orkestre etmek için yapılmıştır ve ajanı zamanlamak daha büyük bir hattın amacı değil de parçası olduğunda doğru cevaptır.

Gecede tek bir istem çalıştıran okuyucu için üçü de fazladır; bunu, ihtiyacınızdan ağır bir kuruluma sizi ikna etmeye çalışmak yerine açıkça söylemekte fayda var. Bir adım zinciri zamanla bunlardan birini gerçekten gerektirirse, Dagu, n8n, ve Kestra hepsi tek tıkla kurulur; bu da tam olarak kurulum maliyetinin buna değip değmediğini tarttığınız anda gerçek bir kolaylıktır.

LangChain veya CrewAI gibi çoklu ajan orkestrasyon çerçeveleri bambaşka bir konudur: hâlihazırda var olan bir CLI'yi zamanlamak değil, ajan sistemleri inşa etmek.

Sıkça Sorulan Sorular

Claude Code Canlı Bir Oturum Olmadan Çalışabilir mi?

Evet. Şu seçeneği vermek: -p istemi etkileşimsiz modda çalıştırır. Claude Code istemi sonuna kadar yürütür, sonucu yazdırır ve çıkar; sohbet döngüsü ya da açık tutulacak bir oturum olmadan.

Claude Code'da Zaten Routines Varken VPS'e İhtiyacım Var mı?

Her zaman değil. Routines, makineniz kapalıyken Anthropic'in bulutunda çalışır ve sıfırdan bir klonla başlar; ancak yalnızca sizin makinenizde bulunan dosyalara erişemez ve bir saatlik asgari aralığı vardır. Kendi yönettiğiniz bir VPS ise görev yerel dosyalara, keyfî aralıklara ya da birden fazla sağlayıcının CLI'sinde aynı çalışan bir mekanizmaya ihtiyaç duyduğunda yerini hak eder.

Zamanlanmış Bir Ajan İçin Cron mu systemd Zamanlayıcı mı Kullanmalıyım?

VPS bakım için hiç yeniden başlıyorsa, systemd zamanlayıcı. Persistent=true kesinti sırasında tetiklenecek olan bir işi, sistem geri gelir gelmez çalıştırır; cron'da bunun karşılığı yoktur. Sürekli açık kalan bir makinede gecelik bir iş için cron gayet uygundur.

Zamanlanmış Bir Yapay Zekâ Ajanı VPS'te Ne Kadar RAM İster?

Hafif bir zamanlanmış iş için 1-2 vCPU ve 2-4 GB RAM civarında başlayın, sonra ajanın çalıştıracağı en ağır yerel komuta göre boyutlandırın. Derlemeler, testler, Docker, büyük depolar ve eşzamanlı çalışmalar, uzaktaki model çıkarımından çok daha belirleyicidir.

Bir Ajanı Zamanlanmış Çalıştırmak Faturalandırmayı Değiştirir mi?

Zamanlama ayrı bir faturalandırma modu oluşturmaz. Claude Code -p abonelik kimlik bilgilerini ya da bir API anahtarını kullanabilir, ancak --bare abonelik oturumunu yok sayar, bu yüzden ortamda ANTHROPIC_API_KEY ya da ayarlarda bir apiKeyHelper ayarlanmış olmasını ister. Codex ve Gemini, kendi CLI'leri için hangi kimlik doğrulama yöntemini yapılandırdıysanız onu izler. Fiyatlar ve kullanım koşulları hızla değiştiğinden, bunu kurarken sağlayıcının güncel fiyatlarını ve kendi kullanım verilerinizi kontrol edin. API üzerinden yapılan Claude Code çalışmaları için ayrıca total_cost_usd alanını JSON çıktısından günlüğe yazabilirsiniz.