Панель

https://zedproxy.pro/v1 для Zed, https://zedproxy.pro для керування

Перевіряю...
живий стан: очікує
сесія: admin Вийти
Operator cockpit

Очікую живий стан

Очікується актуальний стан сервісу.

Рекомендована дія Перевірити live state Очікується перший live update.
Сервісcheckinghealth очікує
Баланс-policy очікує
Режим-premium/fallback очікує
Останній route-причина очікує
DNSочікуєПеревіряю canonical host
TLSочікуєПеревіряю scheme
Zed APIhttps://zedproxy.pro/v1OpenAI-compatible endpoint
Dashboardhttps://zedproxy.proПанель оператора
IP fallbackhttp://46.202.188.88/zedproxy/Резервний доступ до DNS/TLS
Policyочікує live stateОчікується readiness
1. Підключення Zed застосунок Тут один сценарій: у Zed вставляється API URL, модель auto і згенерований ключ. Відкрити setup Zed
2. Виконання Smart routing всередині Після входу через домен система сама вибирає модель, policy, cache і fallback. Дивитися decisions
3. Контроль Операторська панель Алерти, бюджет, route history і provider incidents живуть окремо від Zed setup. Подивитись схему
Запитів сьогодні0
Витрати за день$0.0000
Середнє за вікном$0.00000
Кеш-хіти0%
Активні генерації0
Балансnormalочікує живий стан
Режимautoпровайдер: ok
Активний рівень-причина: -
Ліміт відповіді-кредитні події: -

Наступні дії

очікує

Оповіщення

очікує
Канал оповіщень очікує перевірку.

Провайдери

очікує

MCP контур

очікує

Активні генерації

онлайн

Поточні правила маршрутизації

Операційна хронологія policy

очікує

Розподіл моделей

Останні запити

Як auto працює без ручного втручання

очікує
Якщо немає стабільної помилки маршрутизації, ручні rules краще не множити. Базова логіка auto вже враховує тип задачі, budget, policy і fallback.

Активні ручні правила

Нове правило маршрутизації

Додавай правило тільки коли треба примусово направляти певний тип задач на конкретну модель.

Порядок дій з версіями

крок 1
Крок 1 Додай версію Тут зберігається окрема модель-версія: назва, провайдер, transport і базовий статус.
Крок 2 Увімкни потрібні У роботу йдуть тільки увімкнені версії. Вимкнені не потрапляють ні в гілки, ні в маршрут.
Крок 3 Перейди до гілок Після цього на сторінці гілок збирається робочий набір версій і вибирається основна гілка. Відкрити гілки
Ця сторінка тепер тільки про версії. Спочатку додаємо або вмикаємо версії, а вже потім з них збираємо робочі гілки.

Версії

Показую список версій у робочому порядку.

Додати або оновити версію

Тут створюється одна конкретна версія. Після збереження її можна буде додати в одну або кілька гілок.
Додаткові transport-налаштування версій

Транспорт моделей

Transport для моделі

Це внутрішнє налаштування шлюзу. Воно визначає, чи модель йде через OpenRouter, прямий ключ або комбінований fallback.
Імпорт нових версій з OpenRouter

Каталог OpenRouter

Це живий список моделей OpenRouter. Імпорт додає модель у локальний каталог proxy, після чого її можна обрати в A/B тестах, Playground або правилах маршрутизації.

Гілки і порядок дій

очікує
Крок 1 Вибери версії Спочатку на сторінці версій мають бути готові ті моделі, які підуть у роботу. Відкрити версії
Крок 2 Створи гілку Гілки ще не завантажені.
Крок 3 Познач основну Одна гілка є основною. Саме вона працює за замовчуванням, якщо ключ не прив'язаний до окремої гілки.
Тут тепер повний сценарій для тестів: збираєш гілку з версій, прив'язуєш або створюєш під неї окремий Zed key, а потім міняєш версії всередині цієї гілки без заміни key у Zed.

Один Zed key на одну гілку

Ще немає окремих key для гілок Тут видно fixed keys, які жорстко прив'язані до конкретних гілок. Саме це головний режим для бюджетного тесту: key лишається сталим, а версії всередині гілки можна міняти окремо.

Кеш у тестах бюджету

очікує
Стан кешу ще не завантажений Після завантаження тут буде видно, чи кеш зараз увімкнений, через яке сховище він працює і чому це впливає на повторні бюджетні тести.
Повні cache налаштування

OpenAI key для GPT

очікує
Direct OpenAI ще перевіряється Для GPT-гілки потрібен внутрішній provider key OpenAI. Це не Zed key: він лишається всередині proxy і використовується тільки для upstream OpenAI.
Усі provider keys

Гілки з версіями

Тут має бути мінімум рішень: назва гілки, які версії в неї входять, чи це основна гілка і який окремий Zed key ти на неї видав для тестів.
Ключі і внутрішня карта гілок

Кольорова карта підключень

очікує
зелений: версія реально доступна активним ключам синій: версія вже в гілках, але ще без активного ключа жовтий: версія увімкнена, але ще ні до чого не прив'язана сірий: версія вимкнена

Гілки і ключі без таблиць

очікує

Створити або оновити гілку

Гілка це набір конкретних версій. Саме гілка визначає, які версії реально доступні для auto route і для ключів, прив'язаних до неї.

Створити Zed key для гілки

Для тестів бюджету зручно тримати окремий fixed key на кожну гілку. Потім ти можеш міняти версії всередині гілки, а сам key у Zed лишається той самий. Повний ключ показується лише один раз.


          

        
      


      

        

          
Системні промпти

          

            
            
            

              
              
              
            

          

        

      


      

        

          
Пісочниця

          

            

            
            
            
          

          
          

        

      


      

        

          
A/B тести

          

            
            
            

              
              
              
            

            
            
          

          
          
Для чесного cold-start порівняння перед A/B тестом очисти кеш у вкладці «Кеш» або тимчасово вимкни його. Інакше повторні однакові запити можуть прийти з кешу й спотворити latency та вартість.

          

        

      


      
Живі логи


      

        

          
Активні інциденти

          

        

        

          

            
Route decisions

            

          

          

            
Provider incidents

            

          

        

      


      

        

          
Бюджет

          

            
            
            
            
            
            
            
            
            
            
            
            
            
            
            
            
            
            
          

          

          

        

      


      

        

          
Налаштування застосунку Zed
auto

          

            

              Крок 1
              Провайдер у Zed
              OpenRouter
            

            

              Крок 2
              API URL
              https://zedproxy.pro/v1
            

            

              Крок 3
              Модель
              auto
            

            

              Крок 4
              API key
              Згенеруй окремий client key нижче.
            

          

          

            

              Що налаштовується в Zed
              Один домен, одна модель, один ключ
              Zed бачить тільки точку входу і не керує моделями напряму.
            

            

              Що керується в панелі
              Маршрути, budget, incidents, cache
              Це внутрішня кухня проксі, а не налаштування самого застосунку Zed.
            

          

          

            Швидкий сценарій
            Завантажую contract для Zed...
          

          
Порядок дій тут один: 1. згенеруй ключ, 2. вибери для нього гілку, 3. встав цей ключ у Zed. Усе інше нижче це перевірка або внутрішня кухня.

          

            

              
Що вставити у Zed

              

            

            

              
Перевірка без spend

              

            

          

          
Для першого безкоштовного тесту не чіпай дорогі моделі. Почни з deepseek-free або llama-free: одна для reasoning smoke, друга для простого baseline.

          

            Тестувати DeepSeek Free
            Тестувати Llama Free
            Порівняти free pair
          

        

        

          
Крок 4. Ключі для Zed

          

            Generated keys
            Ще немає даних.
          

          

        

        

          Карта шляху ключів
          

            
Шлях кожного ключа читається так: Zed -> ключ -> гілка -> auto. Саме гілка визначає, які версії ключ взагалі може зачепити, а фінальна модель уже обирається правилами, budget і policy.

            

          

        

        
          

            
Згенерувати Zed client key

            
Цей ключ вставляється у Zed. Одразу вибери, до якої гілки він належить. Повний секрет показується тільки один раз.

            

              
              
              
              
            

            

          

        
        
          

            
Smoke ключа без spend

            
Встав сюди ключ і, за бажанням, той API URL, який уже прописаний у Zed. Перевірка локальна і не робить upstream spend.

            

              
              
              
            

            

          

        
        

          Перевірка і внутрішні налаштування
          

            

              
Smoke ключа із Zed

              

            

          

          

            
Як система прийме рішення по запиту із Zed
без spend

            
Це dry-run: вставляєш приклад запиту з Zed, а панель пояснює, яку модель, ліміт, cache path і fallback вибере проксі. Це інструмент перевірки після того, як ключ уже створено.

            

              
              
              
              
              
              
              
              
              
              
              
              
            

            
Preview ще не прив'язаний до ключа або гілки.

            

          

          

            
Внутрішні ключі провайдерів

            
Ці ключі не вставляються в Zed. Вони потрібні самому проксі для зв'язку з OpenRouter, Anthropic, Gemini та іншими upstream providers.

            

          

        

      


      
        

          
Додати внутрішній provider key

          
Це внутрішній ключ шлюзу для upstream provider. Він не вставляється в Zed і не показується користувачу редактора.

          

            
            
            
            
            
            
            
          

        

      

      

        

          
Кеш

          

            
            
            
          

          

          
Кеш спільний для всього VPS proxy, а не окремий для кожного проєкту. Ключ кешу залежить від моделі та повного payload запиту, тому однаковий prompt на тій самій моделі може дати кеш-хіт навіть у різних проєктах.

          
          

        

      


      

        

          

            
Канонічна схема роботи

            
    
              
  1. Підключення: Zed працює тільки з https://zedproxy.pro/v1, моделлю auto і окремим client key.
    2. 
              
  2. Виконання: proxy сам вирішує модель, tier, cache, fallback і budget-policy.
    3. 
              
  3. Контроль: оператор дивиться incidents, витрати, route decisions і provider health у dashboard.
    4. 
              
  4. Захист: degraded mode, cheap-only mode, output caps і alerts не дають системі працювати навмання.
    5. 
              
  5. Відновлення: IP fallback і runbook лишаються резервом, а не основним способом роботи.
    6. 
            

          


          

            
Що де робиться

            
    
              
  • Zed застосунок: тільки provider, API URL, модель auto і client key.
    • 
              
  • Сторінка «Zed застосунок»: setup, генерація key, smoke без spend і пояснення flow.
    • 
              
  • Operations: alerts, route decisions, provider incidents.
    • 
              
  • Маршрути, моделі, промпти, кеш: внутрішня логіка шлюзу, а не налаштування клієнта.
    • 
            

          


          

            
Як працює платформа

            
    
              
  1. Zed -> VPS Proxy: локальний Zed працює як клієнт, а всі агентні запити йдуть на https://zedproxy.pro/v1 з моделлю auto.
    2. 
              
  2. Smart Router: proxy визначає тип задачі, складність, бюджетні обмеження й підбирає модель.
    3. 
              
  3. LiteLLM/OpenRouter: фактичний запит іде в обрану upstream модель через LiteLLM.
    4. 
              
  4. Санітизація: reasoning-поля вирізаються, щоб Zed отримував чисту OpenAI-compatible відповідь.
    5. 
              
  5. Логи й витрати: токени, модель, маршрут, ціна та cache-hit записуються в SQLite базу на VPS.
    6. 
            

          


          

            
Автозапуск і сервіси

            
    
              
  • Proxy: https://zedproxy.pro/v1
    • 
              
  • Панель: https://zedproxy.pro
    • 
              
  • Автозапуск: systemd service zedproxy.service на VPS
    • 
              
  • Публічний маршрут: домен або IP reverse proxy перенаправляє /, /v1 і /health у native service.
    • 
              
  • Кеш: Redis service на VPS, з memory fallback
    • 
              
  • Ручні команди: systemctl status zedproxy, journalctl -u zedproxy -f
    • 
            

          


          

            
Доступ і вхід

            
    
              
  • Реєстрації немає: панель відкривається через окреме вікно входу.
    • 
              
  • Обліковий запис адміністратора: вхід працює через логін admin.
    • 
              
  • Пароль адміністратора: задається тільки через ZED_DASHBOARD_PASSWORD.
    • 
              
  • Захист сесії: cookie-session закриває сторінки панелі, керуючі /api endpoint-и і websocket логів.
    • 
              
  • Ключі для Zed: сторінка «Zed застосунок» генерує окремі client keys у форматі OpenRouter (sk-or-v1-...); у базі зберігається hash і маска, а повний ключ показується один раз.
    • 
              
  • Вихід: кнопка «Вийти» очищає поточну сесію браузера.
    • 
              
  • Зміна доступу: через ZED_DASHBOARD_USERNAME, ZED_DASHBOARD_PASSWORD, ZED_DASHBOARD_SESSION_SECRET.
    • 
            

          


          

            
Робота через SSH і Zed

            
    
              
  • SSH вхід: робоча машина для коду тепер VPS, а основний runtime живе на ньому постійно.
    • 
              
  • Папка runtime: /var/www/Zedproxy.
    • 
              
  • Робочий режим: відкривай VPS по SSH у Zed і працюй відразу на сервері, без локального proxy/runtime.
    • 
              
  • Важливо: /var/www/Zedproxy це deploy-копія без .git; для повного git-workflow потрібен окремий git clone на VPS або локальний repo як source of truth.
    • 
              
  • Профіль Zed: у Zed обирай OpenRouter, вставляй URL https://zedproxy.pro/v1, модель auto і згенерований на сторінці «Zed застосунок» ключ sk-or-v1-....
    • 
              
  • Локальний Mac: локальний proxy вимкнений; редактор лише відправляє запити у VPS API.
    • 
              
  • Що перевіряти: якщо щось не відповідає, дивись journalctl -u zedproxy -f і вкладку «Логи».
    • 
            

          


          

            
Кеш, версії й A/B тести

            
    
              
  • Кеш не по проєкту: він спільний для всього VPS proxy.
    • 
              
  • Що входить у ключ: назва моделі + payload запиту без stream полів.
    • 
              
  • Одна й та сама модель + той самий prompt: може повернутися з кешу, навіть якщо тест іде з іншого проєкту.
    • 
              
  • Різні моделі: мають різні cache keys, тому A/B між моделями не ділить один і той самий запис.
    • 
              
  • Cold-тест: очистити кеш або вимкнути кеш.
    • 
              
  • Warm-тест: лишити кеш увімкненим, щоб дивитися поведінку після прогріву.
    • 
              
  • Точні моделі: у A/B формі прапорець «Тестувати точні моделі» не дає budget-router підміняти вибраний варіант.
    • 
            

          


          

            
OpenRouter каталог

            
    
              
  • Живий список: вкладка «Моделі» може завантажити актуальний каталог OpenRouter.
    • 
              
  • Імпорт: обрана модель додається в локальний каталог proxy з цінами за 1M токенів.
    • 
              
  • Тестування: після імпорту модель доступна в A/B тестах, Playground і правилах маршрутизації.
    • 
              
  • Zed: редактор усе одно бачить одну модель auto, а вибір конкретних версій робиться в панелі.
    • 
            

          


          

            
Бюджетна ціль

            
    
              
  • Ціль: тримати одну не кешовану генерацію в діапазоні $0.010-$0.050.
    • 
              
  • Автоліміт: якщо прогнозована вартість вибраної auto-моделі вища за максимум, router шукає найякіснішу модель, яка вкладається в cap.
    • 
              
  • Базовий ліміт відповіді: Zed і proxy стартують із cheap cap 700, tool-cheap 900, strong 2000, premium 3500.
    • 
              
  • Обмежений режим: при critical/exhausted balance premium routes вимикаються, а output cap автоматично зменшується.
    • 
              
  • Якість у межах бюджету: окремий перемикач може піднімати auto до сильнішої моделі, якщо початковий вибір дешевший за мінімальну ціль і сильніша модель вкладається в максимум.
    • 
              
  • Аналітика: вкладка «Бюджет» показує останню генерацію, rolling average, запити в цілі й запити вище цілі.
    • 
              
  • Реальність: точна ціна відома після відповіді OpenRouter, тому cap працює як прогноз за prompt + очікуваними output токенами.
    • 
            

          


          

            
Стан політики

            
    
              
  • Стан балансу: normal, low_balance, critical_balance, balance_exhausted.
    • 
              
  • Тільки дешеві моделі: вимикає strong/premium routes і тримає відповіді коротшими.
    • 
              
  • Коди причин: кожен request log має policy_reason_code, policy_tier і effective_output_cap.
    • 
              
  • Кредитні події: 402 або can only afford N пишуться як policy event, навіть якщо retry потім успішний.
    • 
            

          


          

            
Де лежать дані

            
    
              
  • Моделі: config/models.yaml
    • 
              
  • Routing rules: config/routing.yaml
    • 
              
  • Runtime config: config/.env
    • 
              
  • База платформи: logs/costs.db
    • 
              
  • Логи процесу: journalctl -u zedproxy -f
    • 
            

          

        

        
Практичне правило: якщо порівнюєш саме моделі або ціни, тримай однаковий prompt і контролюй стан кешу. Якщо порівнюєш якість на реальній роботі після прогріву, кеш можна залишити ввімкненим.