Gemini 4 Carbon ve Hydrogen en iyi ikili olarak çalışır: Carbon planlar, Hydrogen inşa eder. Görevi (Task) Carbon üzerinde çalışan planlayıcı bir Agent'a verin; kabul kontrolleri içeren alt görevler hazırlamasını sağlayın, bunları Hydrogen üzerindeki çalışan (worker) ve doğrulayıcı (verifier) Agent'lara aktarın ve iki kez başarısız olan her şeyi yeniden planlayıcıya yönlendirin. Böylece en üst seviye model ücretlerini yalnızca üst düzey muhakeme gerektiren adımlar için ödersiniz.
Gemini 4 Carbon ve Hydrogen neden birlikte kullanılmalı?
Google, Gemini 4 Hydrogen'ı 12 Kasım 2026'da kullanıma sundu ve onu "ajan tabanlı iş akışlarının günlük beygiri" olarak tanımladı. Bundan iki gün önce, 10 Kasım'da, Gemini API sürüm notlarında Gemini 4 Carbon'un genel erişime açıldığı duyuruldu. Böylece bu ay ilk kez, Google'ın en güçlü modeli ile hızlı yürütme modelini aynı Görev arkasında bir araya getirebilirsiniz.
Google'ın Hydrogen için yaptığı tanıtım da doğrudan bu ikili eşleşmeye dayanıyor. Lansman yazısında, Carbon koordinatör görevi görürken Hydrogen'ın "izole çalışma alanlarında değişiklikleri eşzamanlı olarak inşa edip test eden çalışan ve doğrulayıcı ajanlara güç sağladığı" belirtiliyor. Gemini API rehberi ise durumu daha net özetliyor: Arayüzleri planlama veya zorlu engelleri çözme işini Carbon'a bırakın; ardından kod düzenlemelerini, paralel alt ajan görevlerini ve test çalıştırmalarını Hydrogen'a devredin.
Bu bir model özelliği değil, bir orkestrasyon desenidir ve bunu bugün kendi panonuzda kurabilirsiniz. Bu yapının tek bir dizüstü bilgisayardaki bir betik yerine doğrudan panoda yaşamasını istiyorsanız, Görevlerin, Ajanların ve incelemelerin bulunduğu yer Sharkly'dir.
Google’ın Orchestrator aracı ne yapar? Tek paragrafta özet
Orchestrator, tek bir sohbet içinde planlayıcı (Carbon veya Argon) ile Hydrogen arasında geçiş yapan Google Antigravity içindeki bir model seçeneğidir. Antigravity dokümantasyonuna göre planlayıcı salt okunur bir aşamayla başlar, açık yeniden planlama tetikleyicileri içeren bir plan yazar ve yürütmeyi Hydrogen'a devreder. Hydrogen bir pürüzle karşılaştığında kontrolü tekrar geri verir.
Dokümantasyonda örnek almaya değer üç pürüz sinyalinden bahsediliyor:
- İki kez başarısız olan bir doğrulama adımı.
- Planda beklenenden farklı davranan bir arayüz.
- Planın netleştirmediği bir tasarım tercihi.
Google'ın bildirdiğine göre Terminal-Bench testinde Orchestrator, %24 daha az kota harcayarak ve ortalama %19 daha hızlı tamamlayarak Carbon'a yakın bir görev başarısına ulaştı. Google'ın iki blog yazısı kıyaslama sürümü konusunda çelişiyor (lansman yazısı 4.0, Antigravity yazısı 4.1 diyor); bu nedenle Google bunları netleştirene kadar Terminal-Bench olarak anmak en doğrusu.
Orchestrator sohbetinizde tek bir ajan tutar, düşünme seviyesi kontrolü olmayan sabit bir yapılandırma çalıştırır ve Carbon sürümü yalnızca Google AI Ultra için listelenmiştir. Bir ekip panosu ise planı ve görev devirlerini herkesin görebileceği şekilde aynı iş bölümünü birden fazla Ajan arasına yayar.
Maliyet analizi: Gemini 4 Hydrogen ve Carbon fiyat karşılaştırması
Gemini API fiyatlandırma sayfasından 13 Kasım 2026 itibarıyla alınan token fiyatları:
| Model | API model id | Input / 1M | Output / 1M | Free tier |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
30 Kasım'a kadar $2.00, ardından $4.00 | 30 Kasım'a kadar $10.00, ardından $20.00 | Hayır |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1.50 | $7.50 | Evet, hız kotalı (rate-limited) |
Buna göre bir bütçe oluşturmadan önce tarihleri mutlaka dikkate alın. 30 Kasım'a kadar Hydrogen, token başına Carbon'dan yalnızca %25 daha ucuzdur. 1 Aralık'tan itibaren ise %62,5 daha hesaplı hale gelecektir. Her iki oran da Google'ın liste fiyatları üzerinden yaptığımız hesaplamalardır.
Bunun tek bir çalıştırma için ne anlama geldiğini de yine kendi hesaplamalarımızla gösterelim. 200 bin token okuyan ve 40 bin token yazan (çıktı, düşünme token'larını da içerir) bir çalışan sırasını ele alalım. 1 Aralık'tan sonra Carbon'da bu işlem $0.80 + $0.80 = $1.60 tutar. Hydrogen'da ise $0.30 + $0.30 = $0.60 eder. Bir Sprint boyunca bunu günde 30 kez çalıştırdığınızda, aradaki fark göz ardı edilemeyecek boyutlara ulaşır.
Üstelik token başına fiyat farkı tek başına durumu tam yansıtmaz. Google, Carbon'un "hipotezleri test etmek ve sınır durumları doğrulamak için tur başına daha fazla düşünme token'ı harcadığını" belirtiyor ve çıktı fiyatlandırması düşünme sürecini de kapsıyor. Dolayısıyla Carbon'daki aynı düzenleme, daha yüksek bir birim fiyatın yanı sıra muhtemelen daha fazla çıktı token'ı faturalandıracaktır. Google bu ikili için görev başına bir maliyet rakamı yayınlamadığından, tasarruf miktarını belirtmeden önce kendi deponuzda ölçüm yapmanız önerilir.
Hız ise işin diğer önemli boyutu: Google, Hydrogen'ın varsayılan high seviyesinde görevleri Gemini 3.8 Flash'a kıyasla 2,5 kat daha hızlı tamamladığını bildiriyor.
İşi ajan ekibinize paylaştırın: modellere karşılık gelen roller
Planlayıcı/çalışan iş bölümü yazılı bir görev dağılımıdır: Bir Ajan planın ve zor kararların sorumluluğunu üstlenir, daha uygun maliyetli Ajanlar yürütmeyi üstlenir ve bir doğrulayıcı sonuç bir insana ulaşmadan önce her şeyi kontrol eder. Her rol, maliyeti ve derinliği o işe en uygun modele atanır.
| Role | Model | Thinking level | Owns |
|---|---|---|---|
| Planlayıcı (Planner) | gemini-4-carbon |
varsayılan medium, zor Görevler için high |
Kod tabanını okuma, kabul kontrolleri içeren alt görevler yazma, yeniden planlama |
| Çalışan (Worker - 1'den n'e) | gemini-4-hydrogen |
high (varsayılan) |
Düzenlemeler, paket güncellemeleri, testler, her biri için bir alt görev |
| Doğrulayıcı (Verifier) | gemini-4-hydrogen |
high, riskli diff'ler için xhigh |
Planlayıcının kabul kriterlerine göre kontrolleri çalıştırma |
| İnsan (Person) | yok | yok | Büyük Görevlerde planı onaylama, sonucu kabul etme |
Google'ın dokümantasyonundaki iki detay bu tabloyu doğrudan şekillendiriyor: Carbon ve Argon varsayılan olarak medium seviyesindedir ve en fazla high seviyesine çıkar; Hydrogen ise varsayılan olarak high ile başlar ve xhigh seçeneğini sunar. Ayrıca Google, xhigh seviyesinin gecikmeyi ve token kullanımını artırdığı ve "daha basit istemlerde aşırı düşünmeye yol açabileceği" konusunda uyarıyor. Bu nedenle xhigh seviyesini, kimlik doğrulama, ödemeler veya veri geçişlerine (migration) dokunan diff'leri denetleyen doğrulayıcıya saklayın.
Planlayıcı ne yazmalı?
Planlayıcının çıktısı, süreçteki sonraki tüm aşamalar için bir sözleşme niteliğindedir. İyi bir plan; her bağımsız değişiklik için bir alt görev, her biri için dosya kapsamı, çalıştığını kanıtlayan komut ve işin geri gönderilmesini gerektiren koşulu içerir. Eğer bir çalışan görevi ne zaman tamamladığını anlayamıyorsa, o plan henüz bitmemiştir.
İş ne zaman planlayıcıya geri döner?
Google'ın tetikleyici listesini aynen uygulayın ve netleştirin. Bir çalışan; kontrolü iki kez başarısız olduğunda, bir arayüz planla uyuşmadığında veya bir tasarım kararı gerektiğinde alt görevi geri iletir. Geri dönüşü günlük kaydı, o ana kadarki diff ve soruyla birlikte yapar. Asla daha büyük bir modelde sessizce yeniden denemez; çünkü bu, ucuz katmanın maliyetini pahalı olanın faturasına gizlemekten başka bir işe yaramaz.
Sharkly üzerinde kurulum
Sharkly'de bir Ajan (Agent), bağlı bir Bilgisayardaki Çalışma Zamanı (Runtime) aracılığıyla çalışan bir yapay zekâ ekip arkadaşıdır; Ekip (Crew) ise tek bir lider Ajan tarafından koordine edilen Ajanlar ve İnsanlar grubudur. Bu yapı, herhangi bir bağlayıcı koda ihtiyaç duymadan doğrudan planlayıcı/çalışan iş bölümüne eşlenir. Planlayıcı Ekip lideridir; çalışanlar ve doğrulayıcı ise Ekip üyeleridir.
Her Ajan, yukarıdaki panelde olduğu gibi kendi Çalışma Zamanını ve Varsayılan modelini taşır (örnekteki Claude Code çalıştırmaktadır). Bu kurulum için her Ajana Gemini CLI gibi Gemini API'sine erişebilen bir Çalışma Zamanı verin ve modeli Ajan bazında belirleyin: Planlayıcı için Carbon, diğerleri için Hydrogen. Model listesinde yeni kimlikler henüz görünmüyorsa modeli doğrudan Çalışma Zamanının kendi yapılandırmasından ayarlayın. Gemini CLI ayrıca kendi yapılandırma kılavuzuna göre bir GEMINI_MODEL ortam değişkenini de okur ve Ajanlar, Ajan bazında ortam değişkenlerini kabul eder.
Ardından koordinasyon kurallarını Ekip talimatlarına yazın:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
Görevi Ekibe atayın. Crews dokümantasyonuna göre yürütme lider önceliklidir: Lider, Görevi ve Ekip talimatlarını okur, ardından belirli katkılar için üyeleri etiketler ve onların sonuçları aynı Göreve geri döner. Her çalışanın kendi çalışma ağacına (worktree) sahip olması için geçici çalışma dizinleri kullanın. Ekibin paylaşılan Görev dizinini yalnızca alt görevlerin sırayla birbirlerinin yerel değişiklikleri üzerine inşa edilmesi gerektiğinde etkinleştirin.
Engellenen işler her zaman görünür kalır: Başarısız veya takılmış çalıştırmalar Gelen Kutusu'na (Inbox) düşer ve bir insanı bekleyen Ajan, kenar çubuğundaki Görev Sohbetlerinde belirir. Planlayıcı planı düzeltemediğinde kesikli okun vardığı yer tam olarak burasıdır.
Gelişmiş teknikler
Uzun bir Görev için API'nin model değiştirme özelliğini kullanın. Google dokümantasyonu, herhangi bir şema değişikliği yapmadan previous_interaction_id kullanarak çok turlu tek bir oturumda planlama turlarını gemini-4-carbon modeline, yürütme turlarını ise gemini-4-hydrogen modeline yönlendirebileceğinizi belirtir. Bu, Orchestrator'ın yöntemini kendi kodunuza uyarlamanın yoludur ve tek bir Ajan çalıştırması içinde oldukça kullanışlıdır.
Sekme (hop) boyutlarına dikkat edin. Hydrogen akışsız (non-streaming) sekme başına 65.536 tokene kadar yanıt verirken, Carbon ve Argon akışsız REST sekmesi başına 32.768 token verir. Test paketleri ve geçiş (migration) belirtimleri gibi uzun üretimleri çalışan tarafında tutun.
Hydrogen'da açık önbelleğe almayı (explicit caching) devre dışı bırakın. Hydrogen açık bağlam önbelleğe almayı desteklemez. Örtük önbelleğe alma (implicit caching), en az 4.096 tokenlik istemlerde devreye girer ve önbelleğe alınan girdilerde %95 indirim sağlar; bu nedenle paylaşılan depo bağlamını her çalışan isteminin başında tutun.
Planlayıcı/çalışan ayrımına alternatifler
- Yalnızca Hydrogen. Google dokümantasyonu bunu paket yükseltmeleri, kod tekilleştirme, iskelet kod oluşturma (scaffolding), iyi tanımlanmış işlevler için birim testleri ve dokümantasyon için önerir. Planlayıcıya gerek yoktur.
- Yalnızca Carbon. Her adımın derinlemesine analiz gerektirdiği dağıtık sistem tasarımı, yarış durumları (race conditions) veya çoklu repo geçişleri için uygundur.
- Antigravity içindeki Orchestrator. Bu özelliği içeren planlarda tek bir kişi, tek bir sohbet ve otomatik görev devirleri sağlar.
- Statik bir yönlendirici. Görevi en başta sınıflandırıp tek bir modele gönderir. Google, zorluğun görev ortasında değiştiği uzun çalıştırmalarda bu yaklaşımın yetersiz kaldığını savunur. Sürecin başındaki sürümü Gemini Decisions API ile ajan Görevlerini yönlendirme yazımızda ele almıştık.
Gerçek dünya kullanım senaryoları
Yoğun hacimli sorun önceliklendirme (issue triage). Google'ın kendi Antigravity SDK demosu; önceliklendirme ve kodlama için Hydrogen ajanlarını, kod yeniden yapılandırma (refactor), yeni özellik geliştirme ve güvenlik kontrolleri için ise bir Carbon ajanını bir araya getirir. Bir panoda bu yapı, gelen kutusu kuyruğunda bir Hydrogen Ajanı ile refactor veya güvenlik etiketli her işte bir Carbon lideri anlamına gelir.
Paralel alt görevlere ayrılmış bir özellik. Planlayıcı, bir API değişikliğini şema, işleyici (handler) ve istemci güncellemeleri olarak böler; üç çalışan bunları ayrı çalışma ağaçlarında yürütür; doğrulayıcı ise sözleşme testlerini çalıştırır.
Sonuç
Carbon planlar, Hydrogen inşa eder ve bir insan kabul eder. Fiyatlandırma bu ayrımı 1 Aralık'tan itibaren son derece avantajlı kılıyor; pürüz tetikleyicileri ucuz hataların pahalı yeniden denemelere dönüşmesini önlüyor ve pano, her görev devrini ekibin görebileceği şekilde Görev üzerinde tutuyor. Daha geniş kapsamlı model için yapay zekâ ajan orkestrasyonunun ne olduğunu ve Ekipler için model yönlendirme kuralımızı okuyabilirsiniz.
Bir sonraki adımınız: Bir Bilgisayarı Sharkly'ye bağlayın, Carbon üzerinde bir planlayıcı Ajan ve Hydrogen üzerinde bir çalışan oluşturun, bunları yukarıdaki talimatlarla bir Ekibe yerleştirin ve normalde bir insanın bir öğleden sonrasını alacak bir Görevi onlara atayın. Sharkly'nin Ücretsiz planı olduğundan, bu testin tek maliyeti harcanan Gemini token'ları olacaktır.
SSS
Gemini 4 Carbon ve Hydrogen arasındaki fark nedir?
Carbon, Google'ın uzun vadeli muhakeme ile zorlu mimari, hata ayıklama ve güvenlik işleri için geliştirilmiş en güçlü öncü modelidir. Hydrogen ise günlük kodlama ve ajan yürütme süreçleri için tasarlanmış hızlı ve verimli Gemini 4 modelidir. Carbon varsayılan olarak medium düşünme seviyesindedir ve en fazla high seviyesine çıkar; Hydrogen ise varsayılan olarak high ile başlar ve xhigh seçeneğini sunar.
Gemini 4 Hydrogen, Carbon'dan daha mı ucuz?
Evet. Hydrogen'ın 1 milyon girdi token'ı $1.50, 1 milyon çıktı token'ı ise $7.50'dır. Carbon, 30 Kasım 2026'ya kadar $2 ve $10, ardından 1 Aralık'tan itibaren $4 ve $20 olarak ücretlendirilir. Ayrıca Hydrogen, Gemini API üzerinde hız kotalı ücretsiz bir katmana sahiptir; Carbon'da ise bu seçenek yoktur.
Doğrulayıcı Hydrogen yerine Carbon üzerinde mi çalışmalı?
Varsayılan olarak hayır. Google, Hydrogen'ı paralel çalışan ve doğrulayıcı ajanlar için konumlandırmaktadır. Riskli diff'ler için doğrulayıcıda xhigh seviyesini kullanın ve Görevi yalnızca bir kontrol iki kez başarısız olduğunda Carbon planlayıcısına iletin.
Sharkly her Görev için modeli kendisi mi seçer?
Hayır. Modeli Çalışma Zamanı üzerinden her Ajan için siz belirlersiniz ve Ekip talimatları Görevin hangi kısmını hangi Ajanın alacağına karar verir. Sharkly ise Görevi, çalıştırmaları, görev devirlerini ve inceleme sürecini yönetir.
