Baseten Grid pone una domanda concreta. Quanto costa completare un’attività di sviluppo?

Un agente di sviluppo produce una modifica pulita per un test che fallisce. La modifica non supera la CI, quindi lo sviluppatore chiede all’agente di riprovare. Il secondo tentativo tocca una parte più ampia del repository e chi revisiona la patch ci passa mezz’ora, anche se il lavoro doveva richiedere cinque minuti. Quale modello è costato meno?

Il 4 novembre Baseten ha presentato Grid in anteprima pubblica. Il servizio combina un gateway per modelli approvati, un router e controlli centrali per l’utilizzo e le misure di protezione. Può inserirsi fra gli strumenti di sviluppo compatibili e i loro modelli, consentendo a un team di applicare una politica comune alle richieste. La pagina di accesso anticipato rimanda a una lista d’attesa.

Scegli il denominatore giusto

Costo per attività accettata. Illustrazione originale di Telli.sh.

Il prezzo di un token misura un’unità di consumo del modello. Un team deve consegnare qualcosa che rispetti i criteri di accettazione. Una richiesta può ricevere una risposta e un’esecuzione può produrre un diff, anche se l’attività resta incompleta. Contare separatamente questi eventi rende utile un esperimento di instradamento.

Supponiamo che due percorsi ricevano ciascuno 100 attività simili. Il percorso economico spende $50 nei vari tentativi e completa 50 attività in modo accettabile. L’altro spende $90 e ne completa 90. In questo calcolo illustrativo, entrambi spendono $1 di utilizzo del modello per risultato accettabile. Aggiungendo tempo di revisione, costi degli strumenti e attesa dei nuovi tentativi, il confronto può cambiare. Questi costi possono favorire l’uno o l’altro percorso.

Includi i tentativi falliti nel numeratore. Un percorso che abbandona le richieste difficili può sembrare efficiente se i tentativi interrotti scompaiono dal conto. Mantieni stabile anche la definizione di successo. Per una modifica alla documentazione può bastare un diff approvato. Una migrazione richiede prove sui dati esistenti e un modo per annullare la modifica.

Conta la categoria di lavoro. Una migrazione API in tutto il repository può essere difficile perché richiede contesto, coordinamento e molte piccole modifiche. Una patch di una riga può esserlo ancora di più se interviene su un difetto sottile di concorrenza. Il numero di file e la lunghezza del prompt sono segnali utili solo se anticipano i risultati nel tuo ambiente.

Leggi l’esperimento del router come un compromesso

Esperimento di instradamento. Illustrazione originale di Telli.sh.

Il rapporto tecnico di Baseten confronta l’uso sistematico di Opus 5.5 con l’instradamento delle attività fra quel modello e GLM 5.3 Flash. Nel suo insieme di attività tratte da DeepSWE, SWE Atlas QnA e Terminal-Bench, l’azienda riporta un punto con un costo inferiore del 72% e un tasso di superamento entro 0,8 punti percentuali da quello ottenuto usando sempre Opus. Il rapporto confronta anche il router con un instradamento casuale a un costo comparabile. È importante perché inviare più lavoro a un modello economico ridurrebbe il costo medio anche affidandosi al caso.

La soglia esprime quanto vale la pena pagare per la probabilità di successo. Aumentare la priorità del costo può spostare più attività verso il percorso economico. Un’altra impostazione può favorire il modello più capace quando il risultato conta di più. I dati di Baseten riguardano i modelli, le attività e i prezzi ipotizzati nello studio. Il tuo team avrà una diversa composizione del lavoro e un diverso costo degli errori.

L’annuncio del prodotto presenta una cifra arrotondata distinta, fino al 70% di costo in meno nei primi benchmark. Tienila separata dal 72% dell’esperimento e dal relativo confronto dei tassi di superamento. Il rapporto tecnico è utile perché mostra come si distribuisce il compromesso. Un team può scegliere un punto in base alle proprie priorità e verificare se regge nel lavoro quotidiano.

Un gateway può rendere visibile la politica

Nell’annuncio di Grid, Baseten descrive modelli approvati, controlli per team e visibilità sui consumi. Il team che gestisce la piattaforma può offrire agli sviluppatori modelli già valutati dall’organizzazione e vedere come si distribuisce l’uso. Questo aiuta a capire dove finisce il budget, anche prima di delegare la selezione del percorso.

In pratica, le decisioni sono diverse. Quale fornitore può vedere codice proprietario? Quale modello è approvato per un repository specifico? A quale team fanno capo i costi dei tentativi ripetuti? Chi può ignorare il percorso predefinito dopo un incidente? Un gateway può collocare queste decisioni in un punto condiviso, se gli amministratori sanno che cosa governa ciascun controllo.

Il gateway dei modelli e l’ambiente in cui opera l’agente sono due punti di controllo distinti. Il gateway può decidere quale modello riceve una richiesta. Lo strumento o l’ambiente di esecuzione decide se un agente può leggere credenziali, scrivere un file o effettuare una chiamata di rete. Le restrizioni sui percorsi sono utili insieme ai permessi di esecuzione. Anche il percorso più economico richiede le stesse limitazioni sugli strumenti privilegiati.

C’è anche una questione di tracciabilità. I log di instradamento aiutano a spiegare come sono cambiati i costi, ma le tracce possono contenere codice, percorsi o dettagli su un incidente di un cliente. Decidi che cosa la piattaforma può registrare, chi può vederlo e per quanto tempo può conservarlo. Se lo sviluppatore non può esaminare la politica, sarà difficile capire perché una richiesta sia stata respinta o inviata a un percorso inatteso.

Prova l’instradamento prima di cambiare il comportamento predefinito

1. Scegli due o tre famiglie di attività ricorrenti. Includi un gruppo semplice, come normali aggiornamenti ai test, e uno più difficile, come migrazioni che devono mantenere la retrocompatibilità.
2. Definisci prima le prove richieste per l’accettazione. Per un’attività di sviluppo possono includere un test di regressione superato, un diff pulito, l’approvazione di un revisore e la verifica che non siano stati toccati file inattesi.
3. Registra un riferimento usando il modello predefinito attuale. Includi tentativi falliti, ripetizioni e attività concluse a mano da uno sviluppatore. Mantieni i vincoli di sicurezza e sui dati applicati in produzione.
4. Confronta l’instradamento su attività equivalenti. Se hai accesso, verifica nella documentazione ufficiale quali strumenti e permessi supporta il gateway prima di collegare un account.
5. Decidi quando passare a un modello più capace. Un primo tentativo fallito può far intervenire un secondo modello, ma riprovare senza limiti può costare più che scegliere subito il modello più forte. Fissa un limite e annota perché hai cambiato percorso.
6. Mantieni la possibilità di scegliere un altro percorso per le attività in cui un errore avrebbe conseguenze pesanti. Al termine esamina le eccezioni insieme ai dati aggregati di costo e accettazione.

Per una prova interna, confronta un periodo in cui gli sviluppatori scelgono il modello con un periodo in cui decide il router, usando attività simili. Nel primo gruppo può aiutare la conoscenza del repository da parte degli sviluppatori. Nel secondo possono aiutare criteri uniformi e una migliore visibilità. Documenta le differenze fra le attività, così il confronto mostra dove serve l’automazione e dove il giudizio umano ripaga.

Esamina un registro di attività comparabili

Un buon punto di partenza è un mese di pull request concluse. Classifica il lavoro in base alla richiesta iniziale, per esempio l’aggiornamento di una dipendenza, un bug con un test riproducibile, una modifica che coinvolge più repository o la richiesta aperta di indagare su una distribuzione non riuscita. Salva la revisione del repository e una verifica di accettazione per ogni attività. Ripeti un campione con un riferimento stabile e con il router. Usa gli stessi strumenti, lo stesso tempo e lo stesso ambiente di test.

L’aggiornamento di una dipendenza è un caso con poca ambiguità. L’attività riesce quando cambia la dipendenza indicata, le verifiche di compatibilità passano e la pull request non include modifiche estranee. Un intervento sul funzionamento della fatturazione richiede un esame più rigoroso. Può anche richiedere che una persona interpreti requisiti incompleti. Tenere distinte queste famiglie chiarisce da dove viene la riduzione della spesa media. Se il percorso economico funziona sugli aggiornamenti ma deve riprovare più volte sulla fatturazione, il team può instradarli diversamente.

Registra quanto tempo impiega una persona per decidere se accettare il risultato. Supponi che il riferimento dia 19 risultati accettati su 20 a un costo di $19, mentre il router ne dia 18 a $9. In questo confronto illustrativo, il costo del modello per risultato accettato è rispettivamente di $1,00 e $0,50. Se i revisori devono dedicare altri 20 minuti a correggere un risultato fallito del router, il confronto cambia. L’organizzazione può includere il lavoro aggiuntivo nella propria misura, mantenendo distinti dollari e minuti.

Guarda su quali dati ha imparato il router

Nel rapporto tecnico, Baseten nomina DeepSWE 1.1, SWE Atlas QnA e Terminal-Bench 2.1. Lo studio confronta Claude Opus 5.5 e GLM 5.3 Flash e valuta il router su dati tenuti da parte. I dettagli contano quando si decide quanto generalizzare. Le domande su come orientarsi in un repository hanno costi diversi dalle attività che eseguono comandi, usano strumenti esterni o modificano più file. La valutazione di un cliente dovrebbe rappresentare le richieste che prevede davvero di inviare.

Il rapporto descrive Cost, Balanced e Intelligence come impostazioni che modificano la soglia al momento della richiesta. Un team può usare questa distinzione per un confronto in parallelo. Confronta le impostazioni su un insieme fisso di esecuzioni autorizzate e registra il modello scelto, se l’integrazione lo rende visibile. Esamina i casi in cui le scelte divergono. Se i modelli costosi sono selezionati soprattutto per le attività che il team considera sensibili o difficili, la politica può funzionare bene. Se i disaccordi si concentrano in una comune attività semplice, può valere la pena rivedere la classificazione o la politica.

Osserva le attività più lente e costose

La latenza media può nascondere l’attesa per una patch difficile che ha coinvolto più modelli. Registra il tempo effettivo dalla richiesta al risultato accettato e segna ogni nuovo tentativo, passaggio a un altro modello, timeout o trasferimento a un operatore. Una dashboard che mostra solo il tempo di risposta del primo modello può segnalare un vantaggio anche quando la persona ha dovuto ricominciare. Includi spesa e tempo dopo ogni passaggio.

Fissa limiti prima di estendere la prova. Stabilisci un budget per l’intera attività e una regola per fermarti o passare a un modello più capace. Un tentativo fallito dovrebbe lasciare elementi sufficienti a far proseguire il successivo. Evita di ripetere i test o rileggere gli stessi file solo perché il router ha scelto un altro modello. La misura utile è quanto è avanzato il lavoro.

Per l’introduzione, parti da una famiglia ristretta in cui la regola di accettazione è automatizzata e una persona può esaminare le eccezioni. Aggiungi poi una famiglia che richiede giudizio. Confronta separatamente il costo per attività accettata, la quota dei passaggi a un altro modello e il tempo di revisione. Se il vantaggio resiste al cambiamento, l’organizzazione dispone di una base migliore per scegliere il comportamento predefinito.

Mantieni utile il riferimento quando cambia un modello

Il risultato di una settimana può diventare obsoleto se cambia un modello, uno strumento o un repository. Salva l’identificativo del modello, la revisione del test e le regole di accettazione insieme alla decisione di instradamento. Quando cambi la politica, ripeti poche attività rappresentative. Includi qualche fallimento costoso, perché il suo peso tende a scomparire nelle medie.

Chiedi a chi revisiona di esaminare un caso in cui i percorsi divergono senza mostrargli quale modello è stato scelto. Se non riesce a stabilire quale risultato sia accettabile, affina il criterio prima di raccogliere altre esecuzioni. Una politica di instradamento è più facile da confrontare quando il team concorda su come riconoscere un successo.

La politica deve evolversi insieme al lavoro

L’instradamento è utile quando libera il team dalla stessa piccola decisione ripetuta. Lo è in particolare quando prestazioni e prezzo possono essere misurati sulla stessa unità di lavoro. Modelli, prezzi e repository cambieranno. Conserva le attività di riferimento e aggiorna l’insieme di test, così la politica può seguirli.

Il numero da portare a una riunione di pianificazione è quanto è costato consegnare il lavoro accettato, con un resoconto chiaro dei compromessi. È un dato su cui possono agire insieme sia chi guida lo sviluppo sia chi è responsabile del budget.

Fonti

• Annuncio dell’anteprima di Grid di Baseten del 4 novembre
• Rapporto tecnico di Baseten sul router del 4 novembre

---

Per conservare e ritrovare le conversazioni e le decisioni che accompagnano il tuo lavoro, crea un account Telli.sh.