AIDiveIntro: stessi controlli, doppio contatore, cinque limiti
Ultracode è la parola chiave, o l'interruttore, che trasforma una richiesta digitata in Claude Code in un intero team di agenti. In un test in coppia con la stessa specifica, entrambe le run hanno superato gli stessi controlli nascosti, e la run con ultracode ha consumato più del doppio del contatore di sessione. Il motivo non è un modello più intelligente: è una frase che l'harness inietta e tre protezioni che spegne.
Questo articolo copre quattro cose:
- il test in coppia, letto sul contatore del piano;
- il moltiplicatore di token su altre coppie;
- l'unico tipo di lavoro in cui un team ha trovato 66 bug piantati mentre un singolo agente ne ha trovati 14;
- le cinque impostazioni che limitano una run prima che si mangi la tua settimana, una delle quali la ferma al limite di utilizzo stesso.
Cosa attiva ultracode: la parola chiave, l'interruttore, un workflow di agenti
Ultracode sono due interruttori. Digitare ultracode dentro un prompt esegue quel singolo task come workflow, senza toccare il livello di effort della sessione. Attivare l'interruttore con il comando /effort fa sì che Claude pianifichi un workflow per ogni task sostanziale, quindi una richiesta può diventare più workflow di fila.
Un workflow è uno script che Claude scrive per sé stesso; quello script fa girare un team di agenti a fasi. Su una piccola sandbox (un paio di file con una gestione sciatta delle promise, revisione in sola lettura), Claude ha esplorato i file, ha lanciato un workflow chiamato "unhandled promise audit", e sotto il campo del prompt è comparsa una riga di task con una barra di avanzamento, il numero di agenti, il tempo trascorso e un totale di token in crescita. Il comando /workflows elenca una riga per agente con il suo conteggio di token, più i tasti per mettere in pausa, fermare o riavviare.
In quella run, ogni finder aveva letto circa 45.000 token prima ancora che i verificatori partissero, per poche righe di codice.
Ogni sessione porta anche una linea guida sulla dimensione, il numero di agenti entro cui Claude è invitato a restare:
| Linea guida sulla dimensione | Agenti consigliati |
|---|---|
| small (predefinita su Pro) | meno di 5 |
| medium | meno di 10 |
Ogni agente invia le proprie richieste in aggiunta alla tua conversazione. Un workflow non è mai un unico conto; è un conto per agente, e il contatore li conta tutti.
Il test in coppia: stessi 136 controlli, 8 percento contro 18, e non si ferma mai
Uno sviluppatore ha misurato il costo sul piano di abbonamento più alto con una configurazione pulita: la stessa specifica per una piccola app di fogli di calcolo, lo stesso modello con lo stesso effort, una run normale e una run con ultracode. Entrambe sono state valutate con controlli nascosti, test che il modello non vede mai. Entrambe ne hanno superati 136 su 136.
| Run | Conclusa | Limite di sessione usato | Controlli superati |
|---|---|---|---|
| Normale | da sola, 25 min | 8 % | 136 / 136 |
| Ultracode | interrotta dall'orologio a 76 min, ancora a controllare | 18 % | 136 / 136 |
Dentro la run con ultracode, Claude ha scritto uno script il cui unico compito era far girare un team: 12 agenti contati, tester, qualche giudice e, più avanti, dei "breaker" incaricati di rompere la pagina. Un breaker ha davvero trovato un bug nella barra delle formule, che continuava a mostrare il vecchio testo dopo aver cliccato un'altra cella.
Al minuto, la run con ultracode ha consumato il limite più o meno alla stessa velocità di quella normale, in media un po' più lentamente. Non bruciava più in fretta; semplicemente non si fermava. Ultracode non rende Claude più intelligente, lo fa controllare, e paghi ogni controllo. È una sola coppia su una piccola specifica, e la seconda run è stata interrotta da un orologio, ma la forma è chiara: stessa risposta, più del doppio della finestra di sessione, e il tempo extra è stato tutto controllo.
Perché costa: una frase e tre protezioni spente
Il modello è lo stesso. Cambia il testo che l'harness gli consegna; l'harness è Claude Code stesso, i suoi strumenti e le istruzioni attorno al modello.
Quando ultracode è attivo, Claude Code carica un riferimento prima di scrivere qualsiasi workflow. Quel testo dice al modello di eseguire un workflow per ogni task sostanziale per impostazione predefinita, e contiene la frase che spiega il conto: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." È il testo dell'harness stesso, e una issue pubblica su GitHub cita le stesse righe.
Tre protezioni si spengono nello stesso momento:
- L'avviso di workflow grande, che di solito scatta quando una run pianifica troppi agenti, non compare.
- Il limite della sessione su quanti agenti possono girare contemporaneamente non viene applicato agli agenti che Claude avvia.
- In modalità auto, il primo lancio non viene mai sottoposto ad approvazione.
La linea guida sulla dimensione è un consiglio, non un tetto: impostata su small (meno di 5 agenti) sulla sandbox, la run con ultracode ne ha avviati comunque 9. Per essere onesti, la frase è un'impostazione predefinita che il modello può ancora ponderare, e le protezioni vengono tolte di proposito per i lavori molto grandi. La risposta sta in una riga: ultracode non cambia il modello, cambia le istruzioni in "un team per tutto, e il costo non è un vincolo".
Il moltiplicatore: tre coppie, la scala dell'effort, la coppia 30x
Un secondo sviluppatore ha eseguito diverse coppie di agente singolo contro workflow sul piano Pro, con script in stile revisione, leggendo il contatore di utilizzo prima e dopo ciascuna.
| Misura | Agente singolo | Workflow |
|---|---|---|
| Token su uno script di revisione | circa 115.000 | 972.000 |
| Moltiplicatore di token sulle coppie | 1x | fino a 18x, per più o meno gli stessi risultati |
| Movimento del contatore | 1x | fino a 3x |
| Tempo reale | quasi identico | quasi identico |
Il workflow non è finito prima; ha speso di più mentre aspettavi lo stesso tempo. L'unico posto in cui il parallelo ha pagato è stato un gruppo di lavori di ricerca indipendenti, dove gli agenti hanno finito prima, comunque per più del doppio dei token.
Un terzo test ha costruito alcune piccole app a ogni livello di effort ai prezzi API. Ogni gradino della scala raddoppiava più o meno il conto, e ultracode è arrivato a diverse volte quanto costava max senza mai spuntarla. La maggior parte di quei token erano letture dalla cache, quelli economici; la minuscola fetta di token di output rappresentava quasi metà del costo.
Un'altra coppia, una scena di città: un agente singolo ha impiegato circa un'ora per pochi dollari di prezzo API. La run con ultracode ha richiesto la maggior parte di un giorno, decine di subagenti, e circa 30 volte il costo.
Sono letture del contatore a numeri interi, app da zero a prezzi API e una scena di città, quindi nessuna è una classifica da sola. Insieme, lo schema è sempre lo stesso: il fan-out compra controllo e copertura, non una risposta migliore, a meno che il lavoro si divida in pezzi indipendenti.
Dove il fan out conviene: una suite di test come giudice, e la regola in una riga
Alcuni lavori hanno davvero questa forma: una migrazione, un audit, una scansione di tutto il codebase.
Bun è stato riscritto da Zig a Rust con circa 50 workflow dinamici in Claude Code, in esecuzione continua per 11 giorni. Sono oltre mezzo milione di righe di Zig, dall'inizio fino a tutta la suite di test che passa su ogni piattaforma in quei giorni. A farlo funzionare non è stato il numero di agenti ma il giudice: una enorme suite di test già esistente diceva superato o fallito senza l'opinione di nessuno.
La caccia ai bug di Anthropic mostra la stessa cosa. Sono stati piantati settanta bug in un grande codebase e un singolo agente è stato eseguito più volte.
| Agente | Bug trovati su 70 |
|---|---|
| Agente singolo (3 run) | 14, 15, 27 |
| Workflow (3 run) | 66 a ogni run |
Una precisazione: quel test girava su Claude Managed Agents, il prodotto API, non su Claude Code, e non è stato indicato alcun costo.
Il thread di lancio aggiunge gli altri successi riportati, e si assomigliano tutti: revisione rispetto a un file di regole, traduzione di un intero codebase, pulizia di una pila di pagine scansionate. Il blog di lancio lo dice chiaramente: la maggior parte dei compiti di programmazione tradizionali non ha bisogno di un panel di cinque revisori.
La regola: fai il fan-out solo quando una suite di test o un insieme di regole giudica l'output, e il lavoro si divide in pezzi indipendenti. Tutto il resto gira normale, a high. Chi ha fatto il test in coppia lo ha detto con parole sue: tienilo per i lavori in cui il controllo è il lavoro, come una migrazione su centinaia di file.
Cinque impostazioni che limitano una run
Ogni limite sta in un posto che già conosci.
| # | Impostazione | Dove | Effetto |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config sotto Dynamic workflow size, o settings.json |
consiglio (meno di 5 agenti), abbassa anche la soglia dell'avviso di workflow grande |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
variabile d'ambiente, esportata prima dell'avvio | fino a 16 agenti contemporanei per impostazione predefinita; con 4 gli altri restano in coda, rallentando il consumo senza uccidere la run |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
variabile d'ambiente | fa girare ogni agente del workflow su un modello a tua scelta mentre gli altri subagenti tengono il loro; un modello più economico rende il controllo più economico |
| 4 | la parola chiave ultracode, mai l'interruttore |
nel prompt; mai la chiave ultracode nelle impostazioni |
la parola chiave esegue un task come workflow e si ferma; l'interruttore lo rende permanente finché non lo spegni |
| 5 | autoContinueAtUsageLimit |
impostazioni | attivo: una run che raggiunge il limite si mette in pausa, aspetta il reset e riprende, anche più di una volta; disattivo: gli agenti falliscono contro il muro e la run finisce lì |
Tre abitudini accompagnano questi limiti. Il blog di lancio dice che un budget scritto nel prompt, come "use 10k tokens", imposta il tetto. Dopo ogni run, /usage mostra quanta parte dell'utilizzo recente è andata a subagenti e workflow, con un avviso quando dominano. Se una run sembra sbagliata mentre è in corso, il pannello /workflows e il tasto x la fermano, e il lavoro già fatto di solito viene conservato.
Niente di tutto questo rende un agente più economico. Limita quanti agenti una run può spendere, e per quanto tempo può continuare a spendere.
La run fuori controllo, i limiti e il verdetto
Una segnalazione pubblica mostra come sparisce una settimana. Uno script scritto dal modello sul piano più grande ha avviato 221 agenti in meno di un'ora. Dopo il primo errore di limite di sessione lo script ha continuato a lanciare, e altri 189 agenti sono partiti nei minuti successivi. La tabella di chi ha segnalato conta decine di milioni di token nelle varie fasi prima del muro.
| Fase | Token, cache inclusa |
|---|---|
| Ground | 11.063.801 |
| Find | 35.885.272 |
| Merge | 516.226 |
| Totale | 47.465.299 |
Il colpevole era una riga nello script generato, un fallback che diceva: se l'agente non ha restituito nulla, usa la lista grezza e vai avanti. Il merge è fallito e la run è andata avanti. Quella versione precede la pausa al limite di utilizzo, e chi ha segnalato dice che quei token non venivano dagli agenti falliti. Un tetto di concorrenza avrebbe diradato quella run, e l'auto-continue disattivato l'avrebbe chiusa al muro.
Il verdetto: sullo stesso task, con gli stessi controlli superati, ultracode ha preso più del doppio del contatore di una run normale. Non perché sia più intelligente, ma per la frase iniettata e le protezioni che toglie. Conviene quando una suite di test o un insieme di regole giudica l'output e i pezzi non si aspettano a vicenda. Ovunque altrove, lo digiti e paghi il controllo. Cinque impostazioni limitano quello che una run può spendere: la linea guida sulla dimensione, il tetto di concorrenza, il modello del workflow, la parola chiave al posto dell'interruttore, e lo stop al limite.
