BYOK gerçeklik kontrolü: bugün Open Design'da bozulan 5 şey

İnsanlara Open Design'ın temelden BYOK olduğunu söylüyoruz. Bu hâlâ doğru. BYOK tasarım iş akışı üzerine ilk yazı, işleyen yolu anlatıyor — daemon'u OpenAI uyumlu herhangi bir uç noktaya yöneltin, anahtarınızı yapıştırın, işiniz bitti. Kurulumların çoğu için hikâyenin tamamı budur ve öyle de kalır.

Ama "BYOK" tek bir özellik değildir. Sohbet düzenleyicisine, sonlandırma uç noktasına, model seçiciye, CLI başlatma yoluna ve analitik katmanına uzanan bir sözleşmedir. Bunların her biri, sözleşmenin bozulabileceği bir yerdir — ve şu anda bunlardan birkaçı, son 48 saat içinde kullanıcılar tarafından bildirilen, herkese açık takipçimizdeki açık sorunlardır.

İlk yazıyı yazıp orada durabilirdik. Bunun yerine, işte dürüstlük turu: bu hafta gelen başlıklar, neyin bozulduğu, neden bozulduğu, bugün ne yapılacağı ve hangi PR'ın (veya yol haritası yuvasının) onu düzelttiği. Bunların hiçbiri gizli değil. Aşağıda dosyalanmış, etiketlenmiş ve bağlanmış durumda — ve bunları bir cuma günü sunumun ortasında keşfetmeniz yerine bizden okumanızı tercih ederiz.

Vaat ile hata listesi

Çerçeveleme önemli, çünkü kolay yanlış okuma "BYOK yarım pişmiş" demek. Değil. Aşağıdaki beşin hiçbiri "BYOK çalışmıyor" hatası değil. Her biri, sahip olduğumuz bir adaptör — OpenAI uyumlu katman, model seçici, sonlandırma yolu — ile sahip olmadığımız biri arasındaki sınırda yaşar: yukarı akış sağlayıcısının CLI'si, paketleme tercihleri veya barındıran platformun süreç modeli.

O sınır, herhangi bir açık kaynaklı CLI orkestratöründe gerçekliğin yaşadığı yerdir. Çıkarım çalıştırmıyoruz, her sağlayıcı için çatallanmış bir CLI sunmuyoruz ve her şeyi pürüzleri yumuşatan (ve token'larınızı sessizce vergilendiren) bir proxy'ye sarmıyoruz. Bu tutumun bedeli şudur: bir sağlayıcının CLI'si biçim değiştirdiğinde veya Windows, macOS'un uygulamadığı bir sınır dayattığında, dikiş yeri belli olur. Bu hafta, bu dikiş yerlerinden beşi aynı anda belli oldu.

İşte geliş sıralarına göre beşi de.

Gemini, "Finish Design"e giderken kayboluyor

Issue #1619 — bug, açık

Belirti

BYOK, Gemini için yapılandırılmış. Ayarlardaki bağlantı testi başarılı oluyor. Model seçici Gemini modellerini döndürüyor. Normal sohbet çalışıyor — kendi Gemini anahtarınıza karşı sorunsuz şekilde tam bir konuşma yürütebilirsiniz. Ama kullanıcı Finish Design'a bastığı anda, daemon, hangi sağlayıcıyla konuştuğunu birden unutmuş gibi, Anthropic biçimli bir hata fırlatıyor.

Neden olduğu

Başlıktaki bakım sorumlusu yanıtı bunu doğruluyor: normal API modlu sohbet, seçilen Gemini BYOK sağlayıcısını baştan sona onurlandırıyor, ancak Finish Design henüz Anthropic uyumlu sonlandırma yolunun ötesine genelleştirilmedi. Diğer her şey, her yukarı akışın lehçesini konuşmayı bilen sağlayıcı farkındalıklı proxy üzerinden yönlendiriliyor. Finish Design hâlâ daha önceki bir sürümden kalma, sabit kodlanmış bir Anthropic sonlandırma uç noktasından geçiyor — bu yüzden Anthropic dışı bir biçimde gelen bir Gemini yanıtı ayrıştırıcıyı takılıyor.

Geçici çözüm

Gemini'yi Anthropic uyumlu sağlayıcı yuvası altında OpenRouter üzerinden yönlendirin. Finish Design yolu o zaman OpenRouter'ın uyumluluk katmanından geri gelen Anthropic biçimli bir yanıt görür ve doğru şekilde sonlandırır. Ekstra bir atlama gerekir ve Gemini'yi doğrudan çağırmak yerine OpenRouter'ın yönlendirmesine ödeme yaparsınız, ama bugün kararlıdır ve zaten çalışan sohbet yoluna dokunmadan bozulan tek yolu kapsar.

Kim düzeltiyor

Finish Design genelleştirmesi artık BYOK yol haritasında P1 olarak yer alıyor. Henüz PR yok — bu, daemon ekibinin ele alacağı bir sonraki şey ve beşinin içinde, bir sınır uyuşmazlığı yerine tamamen bize ait koddaki bir kusur olan tek olanı.

Gemini 3 Flash, Windows'ta istem ulaşmadan ölüyor

Issue #1611 — bug, açık

Belirti

Gemini 3 Flash Preview, Windows'ta Open Design içinde yaklaşık 1,5 saniye sonra stdin: write EOF ile başarısız oluyor — istem modele hiç ulaşmadan önce. Gemini 3 Pro, tam olarak aynı kurulumda sorunsuz çalışıyor. Ve doğrudan Gemini CLI'si (gemini --model gemini-3-flash-preview ...), GEMINI_CLI_TRUST_WORKSPACE=true ayarlandığında başarılı oluyor. Yani sorun anahtar değil, hesap değil ve tek başına CLI değil.

Neden olduğu

Teşhis iki tur sürdü ve bunu göstermeye değer, çünkü bunların nasıl çözüldüğüne dair güzel bir örnek. Raporlayanın ekran görüntüsünün ilk okuması, bir yukarı akış 429 RESOURCE_EXHAUSTED kota hatası gibi görünüyordu. OD_GEMINI_3_FLASH_OK değerini stdout'a yazan temiz bir PowerShell yeniden üretiminin ardından tablo değişti: model erişilebilir, CLI sağlıklı, başarısızlık özellikle Open Design → Gemini CLI başlatma yolunda ve Windows'taki Flash varyantına özgü. Pro aynı başlatma yolunu izliyor ve hayatta kalıyor; Flash kalamıyor.

Geçici çözüm

Model seçicide Gemini 3 Pro Preview'i seçin. Aynı başlatma yolundan geçer ve çalışır. Ayrıca — ve bu kısım hatanın kendisinden daha fazla zaman aldı — ~/.gemini/hooks/ klasörünü kontrol edin. Yavaş bir gsd-check-update.js hook'u (Hook execution error: Hook timed out after 60000ms), bu kullanıcının durumunda her çalıştırmaya kabaca 104 saniyelik ek yük ekliyordu ve bu, Flash başarısızlığından tamamen bağımsızdı. Her halükârda Gemini hook'larınızı temizleyin; takılı kalmış bir güncelleme kontrolü hook'u, herhangi bir ajanı bozuk hissettirir.

Kim düzeltiyor

Flash'a özgü ve OD tarafı olarak işaretlendi. Daemon'un stdin yazma yolu üzerinde araştırma devam ediyor — write EOF, daemon istemi yazmayı bitirmeden önce alt sürecin stdin'inin kapandığını söylüyor, dolayısıyla düzeltme, bu belirli varyantın nasıl başlatıldığında yatıyor.

DeepSeek TUI'nin Windows'ta 30 KB'lık bir istem tavanı var

Issue #1610 — bug, açık

Belirti

Windows paketli bir derlemedeki DeepSeek sarmalayıcısı v0.8.33'te, uzun bir oluşturulmuş istem, ön kontrol korumamızı 81397 > 30000 bytes ile başarısız kılıyor. Kullanıcı yanlış bir şey yapmadı — sadece 30 KB'yi aşacak kadar zengin (sistem bağlamı, tasarım sistemi, referanslar) bir istem oluşturdu.

Neden olduğu

O koruma kasıtlıdır ve sizi daha kötü bir hatadan koruyor. DeepSeek TUI adaptörü şu anda istemi konumsal bir komut satırı argümanı olarak gönderiyor — argv'ye bağlı — ve Windows, toplam komut satırını macOS ve Linux'tan çok daha düşük bir seviyede sınırlıyor. Ön kontrol olmasaydı, aynı istem daha sonra, başlatmanın daha derininde, çok daha az faydalı bir ENAMETOOLONG hatasıyla ve nedenin istem boyutu olduğuna dair hiçbir ipucu olmadan başarısız olurdu. Bu yüzden erken başarısız oluyor ve sayıyı belirtiyoruz. Sorunun ortaya çıkardığı uyuşmazlık dokümanlarda: üst düzey yönlendirme, Windows uzun istem yedeklerinin geniş çapta uygulandığını ima ediyor, ama DeepSeek TUI yolunun henüz böyle bir yedeği yok — taşıması hâlâ argv, stdin veya bir istem dosyası değil.

Geçici çözüm

DeepSeek TUI adaptörüyle Windows'taysanız, oluşturulan istemi 30 KB'nin altında tutun veya stdin tabanlı bir adaptöre geçin — Claude Code, Codex ve OpenCode'un üçü de istemini stdin üzerinden alır ve karşılaştırılabilir bir tavanı yoktur. macOS ve Linux'ta bu sorun hiç ortaya çıkmaz; oradaki argv sınırı, gerçek dünya istemlerinin ona ulaşamayacağı kadar yüksektir.

Kim düzeltiyor

Doğru düzeltme, DeepSeek TUI adaptörü için argv tavanını tamamen kaldıran ve onu stdin adaptörleriyle aynı hizaya getiren bir stdin veya istem dosyası taşımasıdır. Adaptör ekibinin kuyruğunda takip ediliyor.

OpenCode yerel CLI testi, model ısınmadan önce zaman aşımına uğruyor

Issue #1603 — bug, priority:p0, açık

Belirti

Ayarlar → BYOK → OpenCode'da, bağlantı testi güvenilir şekilde 45 saniyede zaman aşımına uğruyor. Garip kısım: kullanıcı önce OpenCode Desktop'ın terminalini açıp orada yerel bir LLM eklerse, aynı Open Design testi bir sonraki denemede başarılı oluyor.

Neden olduğu

O "önce Desktop terminalini aç" ayrıntısı tüm ipucu. Open Design, çalışan bir OpenCode Desktop oturumuna bağlanmaz. Bir Ayarlar deneme testi için daemon, kendi taze OpenCode CLI alt sürecini başlatır ve bir ok yanıtı bekler. Soğuk bir yerel modelle — henüz belleğe yüklenmemiş olan biriyle — o ilk yanıt 45 saniyelik bütçeden daha uzun sürebilir, çünkü model herhangi bir şeyi yanıtlayabilmeden önce diskten okunup ısıtılıyor. Desktop terminalini açıp bir isteme yanıt vermesine izin vermek, modeli işletim sistemi önbelleğinde, daemon'un taze alt sürecinin hemen yararlanabileceği bir şekilde ısıtır. Yani bu aslında bir OpenCode hatası değil; yerel modeller için yanlış olan bir soğuk başlangıç zamanlama varsayımı.

Geçici çözüm

OpenCode'u Open Design'da test etmeden önce, OpenCode Desktop'ı açın, yerel LLM'inizi ekleyin ve bir isteme yanıt vermesine izin verin. Sonra OD bağlantı testini çalıştırın — model ısınmıştır ve yanıt bütçenin içinde gelir. v0.7.0 itibarıyla, bağlantı testi bütçesi de yapılandırılabilir, böylece yerel modeliniz gerçekten yüklenmesi yavaşsa, onu elle ısıtmak yerine pencereyi artırabilirsiniz.

Kim düzeltiyor

Daemon tarafındaki düzeltme, özellikle yerel model adaptörleri için daha uzun veya yapılandırılabilir bir ısınma penceresidir, böylece soğuk bir yerel model, barındırılan bir API ile aynı saatte değerlendirilmez. p0'da takip ediliyor — beşinin en yüksek önceliği, çünkü yerel model kullanıcıları tam olarak BYOK'un hizmet etmesi gereken kitledir.

Paketli web uygulaması düz HTTP üzerinden yüklenmeyi reddediyor

Issue #1620 — bug, açık

Belirti

Biraz farklı bir hata, aynı aile. Raporlayan, paketli web uygulamasını düz HTTP üzerinden bir LAN IP'sinde çalıştırıyor ve sayfa yüklenirken hata fırlatıyor — hiçbir zaman kullanılabilir bir duruma ulaşmıyor.

Neden olduğu

PR #1428'den sonra, analitik sağlayıcısı ve PDF dışa aktarma nonce'u, güvenli kripto API'si mevcut olmadığında zarif şekilde yedeğe düşen ve PR #900'de tanıtılan kademeli yardımcıyı atlayarak doğrudan crypto.randomUUID() çağırmaya başladı. Chromium, crypto.randomUUID'yi güvenli olmayan bağlamlarda açığa çıkarmaz — ve düz HTTP üzerinden çıplak bir LAN IP'si, Chromium'un tanımına göre güvenli bir bağlam değildir. Bu yüzden doğrudan çağrı yükleme anında hata fırlatır ve sayfa onunla birlikte çöker. Tam anlamıyla bir BYOK hatası değil, ama tam olarak aynı kitleyi vuruyor: kendi altyapısını çalıştıran, genellikle hava boşluklu, genellikle düz HTTP üzerinden çalışan insanlar — çünkü bir dahili araç için sertifika ayağa kaldırmak sürtünmeye değmez.

Geçici çözüm

Web uygulamasını HTTPS üzerinden veya localhost üzerinden sunun. Her ikisi de Chromium'un güvenli bağlam gereksinimini karşılar — localhost, sertifika olmadan bile güvenli sayılır — ve sayfa normal şekilde yüklenir. Hızlı bir dahili kurulum için localhost sıfır maliyetli yoldur; LAN erişimi için HTTPS üzerinden kendinden imzalı bir sertifika kalıcı olanıdır.

Kim düzeltiyor

PR #1621, kalan çağrı noktalarını PR #900'deki kademeli UUID yardımcısı üzerinden geri yönlendirir, böylece güvenli bağlam yedeği yalnızca zaten bağlı olduğu yerde değil, her yerde tekrar uygulanır. Açık ve inceleme altında.

Bu, Open Design'daki BYOK hakkında gerçekte ne söylüyor

Listeyi bir kalite hükmü olarak değil, bir sözleşme haritası olarak okuyun. Bu beş sorunun dördü adaptör sınırlarında yer alıyor — Gemini'nin CLI başlatma yolu, DeepSeek'in argv'ye bağlı CLI taşıması, OpenCode'un soğuk başlangıç başlatma modeli, barındıran platformun güvenli bağlam kuralları. Beşincisi, Finish Design olanı, kendi sonlandırma uç noktamızda; bir sürüm önce Anthropic biçimli bir yanıtı sabit kodladığımız ve henüz genelleştirmediğimiz yer. O bizim sorumluluğumuz; diğer dördü, sizin inşa etmediğiniz araçlara saygı duymanın bedelidir.

Ve yapısal nokta budur. Yeniden markalanmış bir proxy olmayan her BYOK sistemi sonunda burada biter. Ya çıkarımın sahibi olursunuz — ve BYOK'u kaybedersiniz, çünkü artık token alıp üzerine kâr koyan siz olursunuz — ya da yukarı akış araçlarına saygı gösterip onların pürüzlerini miras alırsınız: CLI'lerini, paketleme tuhaflıklarını, her birinin farklı şekilde ele aldığı platform sınırlarını. Biz ikinci tutumu kasıtlı olarak seçtik ve tekrar seçerdik. Bedeli, daemon ve adaptör ekiplerinin iki günde beş yüzeyde iş dosyaladığı, bu hafta gibi görünen haftalardır.

Ödünleşim hâlâ doğru. macOS'ta Claude Code, Codex, Cursor, Gemini Pro ve Linux'ta DeepSeek üzerinde çalışan bir kurulum — gerçek kullanıcılarımızın kabaca %90'ını kapsayan matris — bugün proxy vergisi olmadan ve token'larınızda kâr marjı olmadan temiz çalışıyor. Yukarıdaki beş başlık, mayıs 2026 ortasında matrisin diğer %10'unun nasıl göründüğüdür: adlandırılmış, dosyalanmış ve her biri yolda bir düzeltmeyle. Dürüst dikiş yerleri, faturanın nereye gittiğini gizleyen pürüzsüz bir yüzeyi yener.

Bugün ne kullanılmalı (matris)

Bu, yukarıdaki bölümün pratik versiyonu — aynı beş dikiş yeri, şu anda neye güvenle uzanılabileceğine eşlenmiş. Bir ✓, yolun olduğu gibi çalıştığı anlamına gelir; bir ✗, onu engelleyen sorunu bağlar, geçici çözüm ilgili bölümdedir.

Sağlayıcı	macOS	Linux	Windows	Finish Design yolu
Claude Code (Sonnet / Opus)	✓	✓	✓	yerel
Codex	✓	✓	✓	yerel
Cursor (BYOK)	✓	✓	✓	yerel
Gemini 3 Pro Preview	✓	✓	✓	OpenRouter uyumluluk katmanı (#1619)
Gemini 3 Flash Preview	✓	✓	✗ (#1611)	OpenRouter uyumluluk katmanı (#1619)
DeepSeek (API)	✓	✓	✓	OpenRouter uyumluluk katmanı
DeepSeek TUI (uzun istemler)	✓	✓	✗ (#1610)	OpenRouter uyumluluk katmanı
OpenCode (yerel model)	✓	✓	✓ (önce ısıtın, #1603)	uygulanamaz

Bu tablonun iki okuması var. Yığınınız tümü-✓ bloğundaysa — Claude Code, Codex, Cursor veya Gemini Pro — temiz yoldasınız ve yukarıdaki hiçbir şey gününüzü değiştirmez. ✗ satırlarından birindeyseniz, eşleşen bölümde, bağlı düzeltme gelene kadar sizi bugün çalışır hale getiren geçici çözüm var. Her iki durumda da, bir satır ✗'den ✓'ye döndüğünde bildirim almak isterseniz takipçideki BYOK etiketine abone olun.

Sırada ne yapılmalı

Open Design'ın beceri kütüphanesi, tüm bunların altındaki işleyen katmandır — bağlantı sağlıklı olduğunda BYOK adaptörünün beslediği dosya odaklı sözleşmeler. Yukarıdaki dikiş yerleri, baytları anahtarınızdan modele ve geri taşımakla ilgilidir; beceriler ise modelin onlarla gerçekte ne yaptığıdır. Bir becerinin modelden ne tükettiğini ve neyi umursamadığını görmek isterseniz — ki bu da bu adaptör pürüzlerinin neden çıktıyı değil, yalnızca ona ulaşıp ulaşmadığınızı değiştirdiğinin nedenidir — o dizin, başlanacak doğru yerdir.

Beceri kütüphanesine göz atın.

İlgili okumalar

• BYOK tasarım iş akışı: Claude, Codex veya Qwen'i kendi anahtarınızla çalıştırın — orijinal BYOK açıklaması ve yukarıdaki beş dikiş yerinin kenarında durduğu işleyen yol
• Open Design'ı neden bir ürün değil, bir beceri katmanı olarak inşa ettik — yukarı akış araçlarını bir proxy'ye sarmak yerine neden onlara saygı gösterdiğimiz, ki bu da bu sınırların var olmasının tüm nedeni
• 31 beceri, 72 sistem — kütüphane nasıl çalışır — bağlantı sağlıklı olduğunda BYOK'un gerçekte neye beslediği