BYOK tasarım iş akışı: Claude, Codex veya Qwen'i kendi anahtarınızla çalıştırın
Çoğu yapay zeka tasarım aracı, harcadığınız her token'a sessizce bir kâr payı ekler. Open Design ise tam tersi bir tutum sergiler — kendi model anahtarınızı getirin, doğrudan sağlayıcıya ödeme yapın ve çıkarımın nerede çalıştığı üzerinde tam kontrolü elinizde tutun. İşte BYOK katmanının gerçekte nasıl çalıştığı.
2026'da barındırılan bir yapay zeka tasarım ürünü kullandıysanız, faturanın yavaşça arttığını muhtemelen fark etmişsinizdir. Koltuk başına ücretin üzerine bir abonelik, onun da üzerine kimsenin açıklamadığı bir çıkarım kâr marjı. Hesap, bilerek belirsizdir.
Open Design çıkarım çalıştırmaz. Token'lar üzerinde bir kâr marjımız yok. Tüm iş akışı bring-your-own-key (BYOK) etrafında kuruludur — daemon'u OpenAI uyumlu herhangi bir uç noktaya yöneltir, kendi API anahtarınızı yapıştırır ve işiniz biter.
Bu yazı, bu tercihi neden yaptığımızı, perde arkasında nasıl çalıştığını ve günlük iş akışınızda gerçekte neyi değiştirdiğini açıklıyor. Bunun arkasındaki daha geniş felsefi argümanı isterseniz, Open Design'ı neden bir ürün değil, bir beceri katmanı olarak inşa ettik tamamlayıcı yazıdır — bu ise uygulamaya dönük versiyonudur.
"BYOK" burada gerçekte ne anlama geliyor
Yapay zeka araç ekosisteminde dolaşan BYOK'un iki tanımı var ve bunlar aynı şey değil:
- Yüzeysel BYOK — araç bir anahtar yapıştırmanıza izin verir, ancak çıkarımı yine kendi sunucuları üzerinden yönlendirir, istemlerinizi kaydeder ve hız sınırları uygulayabilir.
- Gerçek BYOK — araç, model sağlayıcısını doğrudan kendi makinenizden (veya altyapınızdan) çağırır. İstemleriniz hiçbir zaman tedarikçinin sunucularına dokunmaz. Tedarikçi hiçbir kâr marjı almaz.
Open Design ikinci türdendir. Daemon, yapılandırdığınız uç noktaya, kendi anahtarınızla, kendi makinenizden HTTP çağrıları yapar. Proxy yapmayız. Kayıt tutmayız. İstemlerinizi görmeyiz.
Çağrı gerçekte nereye gidiyor
Daemon bir işi aldığında, istemi oluşturur — görev için ilgili SKILL.md ve DESIGN.md dosyalarını çeker — ardından ayarladığınız base URL'e tek bir HTTP isteği yapar. Yanıt makinenize akış halinde geri döner, ajan eseri diske yazar ve tüm döngü bundan ibarettir. Yolda hiçbir Open Design sunucusu yoktur. Becerilerinizi keşfeden aynı daemon ağ çağrısının da sahibidir; bu yüzden "bu nerede çalışıyor?" sorusu bir satış görüşmesi değil, bir ayardır.
OpenAI uyumlu adaptör
2026'daki çoğu yapay zeka çıkarım uç noktası OpenAI Chat Completions API'sini konuşur. Biz bunu en düşük ortak payda protokolü olarak kullanırız. Sağlayıcınız bunu konuşuyorsa (ki neredeyse hepsi konuşur), varsayılan olarak desteklenirsiniz — eklenti yok, beklenecek sağlayıcıya özel entegrasyon yok.
Yönlendirebileceğiniz sağlayıcılar
| Sağlayıcı | Tipik base URL biçimi | Şunun için iyi |
|---|---|---|
| OpenAI | https://api.openai.com/v1 | gpt-image-2, gpt-5.x, en güçlü genel geçişler |
| Anthropic | OpenAI uyumluluk katmanı veya özel Claude adaptörü | zevk ağırlıklı rötuşlar, uzun brief'ler |
| DeepSeek | https://api.deepseek.com/v1 | maliyet açısından verimli uzun bağlamlı taslaklar |
| Groq | sağlayıcı base URL'i | düşük gecikmeli taslak döngüleri |
| OpenRouter | https://openrouter.ai/api/v1 | herhangi bir öncü model, tek faturalandırma ilişkisi |
| Kendi sunucunuzdaki vLLM / TGI / Ollama | kendi sunucunuz, örn. http://localhost:11434/v1 | tamamen yerel, müşteri gizliliği gerektiren işler |
| Qwen / Kimi / Hermes | sağlayıcı base URL'i | OAI uyumlu uç noktalara sahip bölgesel modeller |
Liste, sabit kodlanmış bir izin listesi değil — sadece insanların yaygın olarak tercih ettiği yerler. Chat Completions biçimine yanıt veren her şey çalışır.
İki alan, sonra yeniden başlatma
Yapılandırma iki alandan ibaret:
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…Bunları .env.local içine bırakın, daemon'u yeniden başlatın ve farklı bir modeldesiniz. Hassas bir proje için yerel bir Ollama kutusuna geçmek de aynı iki satırdır:
OPENAI_BASE_URL=http://localhost:11434/v1
OPENAI_API_KEY=ollamaGüncellenecek bir model kayıt defteri, yeniden bağlanacak bir hesap, bir geçiş süreci yok. Anahtar ve uç nokta, tüm yüzeyi oluşturur.
Bunun tasarım işi için neden önemli olduğu
Tasarım iş akışlarının, barındırılan çıkarım ürünlerinin başa çıkamadığı belirli bir maliyet yapısı vardır:
- İterasyon, işin birimidir. Gerçek bir tasarım geçişi, üç değil 30–50 istem döngüsü demektir. Barındırılan planlar 50 döngü noktasında sert şekilde kısıtlar.
- Uzun bağlam normaldir. Ciddi bir brief; marka belgelerini, önceki çalışmaları, sistem spesifikasyonlarını ve referans görsellerini içerir. Bu bağlam, barındırılan arayüzlerdeki token bütçelerini fazlasıyla aşar.
- Model seçimi anlık olmalıdır. Bazı geçişler hızlı ve ucuz bir model ister. Bazıları mevcut en güçlüsünü ister. Bazıları hassas içerik için yerel bir model ister. Barındırılan bir ürün, sizin yerinize birini seçer.
BYOK üçünü de çözer. Token başına ödersiniz, modeli siz seçersiniz, kısıtlanmazsınız.
İterasyon artık tayınlanmıyor
Çalışma şeklinizi sessizce değiştiren şey budur. Her ek döngü bir plana karşı sayaçlandığında, kendi kendinizi sansürlemeye başlarsınız — dördüncüsü pahalı geldiği için üçüncü taslağı alırsınız. BYOK'ta bir geçiş daha yapmanın marjinal maliyeti, model sağlayıcısında birkaç sent olduğundan, karar tekrar sayaçla ilgili olmaktan çıkıp işle ilgili olur. Tasarımın iyileştiği yer genellikle üçüncü taslaktır; iterasyonu vergilendiren bir araç, tam olarak önemli olan adımı vergilendiriyor demektir.
Peki ya maliyet?
Yaygın bir endişe: "Doğrudan ödüyorsam, daha pahalı olmaz mı?"
Pratikte hayır. İşte iç kullanımımızda tipik bir tasarım iş günü:
| Görev | Token | Sağlayıcı | Maliyet |
|---|---|---|---|
| Brief alımı (3 belge) | 30K girdi | Claude Sonnet | $0.09 |
| İlk taslak geçişi | 80K girdi + 20K çıktı | Claude Sonnet | $0.54 |
| 5 iterasyon döngüsü | 250K girdi + 80K çıktı | Claude Sonnet | $1.95 |
| Son rötuş | 50K girdi + 30K çıktı | Claude Opus (tek geçiş) | $1.35 |
| Günlük toplam | ~$3.93 |
Bu; bir sunum, iki açılış sayfası varyantı ve bir marka keşfi demek. Barındırılan eşdeğeri — aşım ücretleri olan aylık 30 dolarlık bir "creator" planı varsayarsak — aynı iş için yaklaşık 50 dolara çıkar, size daha az iterasyon verir ve sizi tek bir modele kilitler.
Daha ucuza gitmek isterseniz, Claude Sonnet'i DeepSeek V3.2 ile değiştirin ve gün 1 doların altına iner. Mesele bir modelin doğru olması değil — mesele, fiyat/kalite ayarının bir abonelik kademesine gömülmek yerine sizin elinizde olmasıdır.
Gizlilik ve uyumluluk
BYOK'un önemli olmasının ikinci bir nedeni var: istemler müşterinizin markasını içerir.
Barındırılan çıkarım, marka belgelerini, henüz duyurulmamış ürün adlarını, dahili fiyatlandırmayı ve lansman öncesi yaratıcı çalışmaları üçüncü bir tarafın sunucuları üzerinden yönlendirmek demektir. Çoğu şirketin bu konuda bir görüşü vardır. Bazılarının ise bir sözleşmesi.
BYOK ile istem gidiş-dönüşü, dizüstü bilgisayarınız ile zaten incelediğiniz (veya kendiniz barındırdığınız) model sağlayıcısı arasındadır. Open Design devrede değildir. Mahkeme celbi çıkarılacak bir kaydımız, sızdıracak bir ihlal yüzeyimiz, açıklayacak bir denetim boşluğumuz yoktur.
"Kayıt tutmamanın" pratikte size sağladığı şey
Ajans işleri, düzenlemeye tabi sektörler veya lansman öncesi herhangi bir şey için ayakta kalabilen tek tutum budur. Bir güvenlik incelemesi "marka varlıklarımız nereye gidiyor?" diye sorarsa, yanıt "sözleşmemizdeki model sağlayıcısına, başka hiçbir yere değil" olur — "kontrol etmediğimiz bir tedarikçi panosuna" değil. Bir Ollama veya vLLM uç noktasını kendiniz barındırmak bunu daha da sıkılaştırır: baytlar ağınızdan hiç çıkmaz. Bu, BYOK gerçeklik kontrolünde incelenen aynı ödünleşimdir ve o yazı, pürüzlerin hâlâ nerede olduğu konusunda dürüsttür — yerel modeller ve öncü modeller zevk açısından birbirinin yerine geçemez ve istem enjeksiyonu yüzeyinin sahibi sizsinizdir.
Proje ortasında sağlayıcı değiştirme
BYOK'un hak ettiği değeri görmeyen avantajlarından biri, bir proje sırasında sağlayıcı arbitrajıdır:
- Taslak — soru formunda ve ilk iterasyonda ucuz bir model kullanın (DeepSeek V3.2, Qwen 3)
- Rötuş — zevkin önemli olduğu orta geçişler için Claude Sonnet veya GPT-5'e geçin
- Hassas içerik — müşteri gizliliği gerektiren istemler için yerel bir Ollama modeline geçin
- Son rötuş — mevcut en güçlü modelde bir geçiş harcayın (Opus, GPT-5 Pro)
Open Design'da geçiş yapmak, .env.local içindeki iki satırı düzenlemektir. Geçiş süreci yok, yeniden katılım yok, plan yükseltmesi yok.
Tek bir brief için işlenmiş bir yönlendirme
Somut olarak, tek bir açılış sayfası brief'i şöyle işleyebilir:
# draft + first iterations — cheap and fast
OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…
# then, for the passes where taste decides the outcome:
OPENAI_BASE_URL=https://api.anthropic.com/v1 # via the compat shim
OPENAI_API_KEY=sk-ant-…Aynı beceriler, diskteki aynı tasarım sistemi, aynı eserler — yalnızca iş akışının arkasındaki motor değişti. Beceriler ve sistemler sadece dosya olduğu için (SKILL.md ve DESIGN.md), kurulumunuzla ilgili hiçbir şey belirli bir modele bağlı değildir. İş akışına sahip olmanın gerçek anlamı budur: araç yoldan çekilir ve model, brief'in gerektirdiğinde değiştirdiğiniz bir parametredir.
Deneyin
Depoyu klonlayın, .env.local içinde OPENAI_BASE_URL ve OPENAI_API_KEY değerlerini ayarlayın, pnpm tools-dev komutunu çalıştırın. Daemon, yönelttiğiniz uç noktayı, ödediğiniz modeli, istediğiniz zaman çizelgesiyle kullanacaktır.
Tüm BYOK hikayesi bundan ibaret. Özel bir kademe, yükseltme akışı, bizimle bir faturalandırma ilişkisi yok. Model sağlayıcısına ödersiniz, anahtarlarınızı saklarsınız, istemlerinizi saklarsınız. Biz katmanı sağlarız.
İlgili okumalar
- Open Design'ı neden bir ürün değil, bir beceri katmanı olarak inşa ettik — barındırılan bir uygulama yerine ince bir katman sunma bahsi
- BYOK gerçeklik kontrolü: bozulan 5 şey — kendi anahtarınızı getirmenin dürüst ödünleşimleri ve pürüzleri
- 31 beceri, 72 sistem: Open Design kütüphanesi nasıl çalışır — hangi modeli çalıştırırsanız çalıştırın sabit kalan
SKILL.md/DESIGN.mddosyaları