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%.
Le modifiche vengono salvate nel .env con backup automatico
(max 5, vedi "Backups .env" sopra). Il reload è automatico
per le chiavi che lo supportano (es. USD_TO_EUR,
MODEL_PRICING). Per cambiamenti strutturali potrebbe servire
un restart.
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).
Modelli che i client hanno richiesto via /v1/messages e che non
sono in nessun model_aliases configurato. Con passthrough mode
vengono comunque inoltrati al provider (potrebbe restituire 400 se non
supportato). I modelli marcati in alias sono già gestiti
esplicitamente. Gli altri sono raw e meritano una decisione:
aggiungerli come passthrough a una key specifica, o ignorarli.
Tentativi di autenticazione tracciati per IP. Un IP con
+ fallimenti in min
(e nessun successo nelle ultime h) viene bloccato
con HTTP 429. Mostra solo tentativi su endpoint protetti
(non login UI).
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.
Confronta 4 pipeline sullo stesso golden set: A=direct LLM, B=direct+ratio,
C=proxy no ESD, D=proxy+ESD. Misura l'impatto reale del proxy+ESD.
~8 LLM call per prompt (4 generation + 4 judge). Judge consigliato: Zai
(evita bias auto-approvazione M3). Vedi docs/EVAL.md#benchmark.
Registry delle capability (builtin + HTTP dichiarativi da data/capabilities/http/*.yaml
+ skill da data/skills/*/ + tool MCP mcp__server__tool).
Le capability non-builtin sono OFF per default: il garante le abilita
per tenant con la policy firmata (HMAC server-side, audit trail). Rate limit e
risk cap sono enforced dal registry a ogni esecuzione. Vedi README sezione
"Capability Seam 0.1.8".
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.