L’ANALISI
Otari 0.29.0: identità workload, bridge Messages-Responses e costi per tool
Analisi pratica di Otari 0.29.0: workload identity, bridge Anthropic Messages verso OpenAI Responses, costo dei tool, credenziali gestite e checklist per un test controllato.
In breve: Otari 0.29.0 riduce due ambiguità operative dei gateway multi-provider: come autenticare un workload senza distribuire una chiave Otari a lunga durata e come attribuire i costi delle chiamate tool. Aggiunge anche un bridge opt-in tra Messages e Responses, ma endpoint compatibile, credenziale valida e copertura delle singole API restano tre verifiche separate.
Che cosa cambia nella release
La release pubblicata il 19 ottobre 2026 raggruppa cinque delta operativi: token di workload identity per autenticare i backend, bridge opt-in da Anthropic Messages a OpenAI Responses, prezzi dei tool per etichetta, rifiuti più espliciti per credenziali gestite non applicabili e pagina di uso dell’organizzazione disponibile anche nelle installazioni standalone.
Identità workload al posto di un segreto lungo
Il nuovo percorso consente a un backend di presentare un token a vita breve emesso da un issuer configurato. Otari applica regole esplicite e non accetta quel token dove è richiesta la master key. La federazione è disattivata per impostazione predefinita: va configurata, limitata e provata senza trasformarla in un accesso generale.
Il bridge Messages-Responses è opt-in
Un client che parla il protocollo Anthropic Messages può essere instradato verso modelli esposti tramite OpenAI Responses. Il comportamento predefinito non cambia. Questa compatibilità di trasporto non dimostra che ogni tool, elemento di reasoning, cache o errore mantenga la stessa semantica: serve una prova sul client e sul modello realmente usati.
Il costo dei tool diventa più leggibile
Otari può distinguere il prezzo delle chiamate tool per etichetta e privilegiare il costo riportato dal provider. La logica descritta non fattura una chiamata fallita. Per un controllo economico serio vanno comunque riconciliati log del gateway, risposta del provider e fattura, perché un contatore locale non sostituisce la fonte contabile finale.
Le credenziali gestite hanno un perimetro
Una credenziale valida per Chat Completions, Messages o Responses non abilita automaticamente gli endpoint pass-through. Embeddings, immagini, audio, rerank, moderazioni e batch possono richiedere credenziali o configurazioni diverse. Il gateway deve rifiutare in modo chiaro il percorso non coperto invece di creare un fallback ambiguo.
Standalone non significa senza costi esterni
Il repository è Apache 2.0 e il gateway può essere eseguito in proprio, ma i modelli possono continuare a essere serviti da API cloud. Restano separati costo dei provider, calcolo, database, storage, osservabilità, aggiornamenti e gestione delle chiavi. Self-hosted descrive il controllo sul gateway, non la località di ogni inferenza.
Condizioni e limitazioni
Le funzioni sono configurabili e non equivalgono a compatibilità universale. La federazione e il bridge Messages-Responses restano opt-in; le credenziali gestite non coprono automaticamente embeddings, immagini, audio, rerank, moderazioni o batch. In questo ciclo sono stati verificati release e cambiamenti upstream, ma non è stato eseguito un test end-to-end con provider reali.
Checklist pratica
- Fissare Otari alla release v0.29.0 e conservare configurazione e rollback della versione precedente.
- Mappare per ogni client protocollo, endpoint, modello, provider e credenziale effettivamente richiesti.
- Abilitare workload identity solo per issuer, audience e subject necessari, lasciando separata la master key.
- Provare un token valido, uno scaduto, uno con audience errata e la revoca della regola di federazione.
- Abilitare il bridge Messages-Responses soltanto in un ambiente di prova e verificare streaming, tool, reasoning, cache ed errori.
- Confrontare il costo dei tool registrato da Otari con risposta e rendicontazione del provider.
- Provare separatamente embeddings, immagini, audio, rerank, moderazioni e batch senza assumere ereditarietà delle credenziali.
- Ripetere almeno tre esecuzioni dello stesso task con budget fisso e conservare log e failure case.