Gestisci le chiavi di accesso per i tenant. Ogni key è isolata: ha la sua KB, i suoi prompt, le sue statistiche.
Grafici e metriche separate per ogni API key (richiesti da usage_log). Costi in EUR (USD→EUR 0.92).
Quote LLM per provider (M3 via /v1/token_plan/remains,
Z.ai via /api/monitor/usage/quota/limit).
Stesso formato della colonna Quota 5h usata nella tabella upstream:
barra + % usata + reset time. Per ogni key mostriamo 5h (finestra breve) e 7d (finestra settimanale).
Refresh automatico ogni 5 min in background; refresh on-demand dopo un 429.
Colori: verde ≤ 40% usata,
giallo 41-70%,
rosso > 70%.
Come si configura: questi slider indicano la frequenza desiderata di ogni key.
Il proxy li usa come target e nel tempo bilancia il traffico per avvicinarsi a queste percentuali.
• Strategia: il motore di selezione si imposta in Config ▾ → Setup → "Strategia di selezione"
(smart consigliata: usa questi pesi + quota + health; weighted: usa solo i pesi).
• Doppio click su uno slider: bilancia tutte le key alla stessa %.
• Salvataggio: automatico al rilascio (effetto su nuove richieste, senza riavvio).
Queste sono le API key M3 che il proxy usa per parlare con il backend
(configurate via ANTHROPIC_UPSTREAMS in .env). Le richieste dei tenant
vengono ruotate tra queste key (round-robin di default). Pinning per
conversation_id: stessa chat → stessa key, per sfruttare la cache M3.
In strategia smart il selettore consulta la quota 5h del provider
(colonna "Quota 5h usata") per bilanciare il consumo: preferisce le key con più remaining
(= meno usata) e skippare il pinning se la key pinned sta per esaurirsi. Clic su ⋮
per modificare, ruotare la key, gestire gli aliases o eliminare. Backups automatici
prima di ogni modifica (max 5, rollback sotto).
Tool diagnostico per misurare la qualità delle risposte con un modello LLM come giudice.
Solo il master può lanciare eval e vedere lo storico (i tenant non hanno accesso).
Costo: ~1 LLM call extra per judge. Limiti: bias di auto-approvazione (~+0.3 punti se judge==modello testato).
Vedi docs/EVAL.md per 5 use case + API reference.
Copia subito — non sarà più mostrata in chiaro.
Aggiunge un'API key in ANTHROPIC_UPSTREAMS nel .env.
⚠ Key API: il campo è vuoto per sicurezza. Lascialo vuoto per mantenere la key esistente; inserisci un nuovo valore solo se vuoi ruotarla.
Mappature input_model → output_model per questa upstream key.
Definiscono come rinominare il modello prima di inviarlo al provider.
| Input model | Output model |
|---|
ESD (Endogenous Self-Distillation) migliora le risposte LLM con un loop
bozza→critica→riscrittura. Costo: +1..N chiamate extra per risposta. Vedere
/Users/fulvio/Documents/llm-proxy/ESD/README.md.
X-ESD-Mode: auto,
il server attiva selfRefine. A budget esaurito, ritorna la bozza normale.
Tutti i limiti di questo tenant in un posto. Rate limit conta quante richieste arrivano in un minuto; concorrenza conta quante sono in corso adesso; sessioni aperte conta quante conversazioni distincte il tenant ha aperte di recente; sticky decide quante conversazioni si ricordano per la cache locality.
X-Mavis-Session-Id) si conta quella ed è esatto: niente liveness,
niente approssimazione. Se il client non dichiara nulla (misurato su Pi: nessun
header di sessione) si conta la conversazione, ricavata dal primo
messaggio, e lì la finestra di liveness (—s)
decide quanto è ampio il margine: due conversazioni che aprono con lo stesso
testo vengono contate come una. Nessuna delle due approssimazioni blocca mai
chi sta lavorando.
Whitelist provider (alias upstream) per questa API key. Tenant viene instradato solo verso le upstream selezionate. Se la allow-list non include nessuna upstream abilitata → 403 upstream_not_allowed_for_tenant.