Modello da $18 (GLM) come Worker in Claude Code e Codex — Ottimizzazione dei costi senza cambiare setup

Modello da $18 (GLM) come Worker in Claude Code e Codex — Ottimizzazione dei costi senza cambiare setup

Sono le 14:00, la funzionalità è completata a metà e il limite del tuo piano da 200 dollari è stato raggiunto. Le tre reazioni più ovvie sono tutte negative: ripiegare sulle tariffe API (più costose dell'abbonamento), acquistare un secondo abbonamento (un altro limite) o passare il pomeriggio a migrare il progetto su uno strumento sconosciuto. Ce n'è una quarta: cambiare il provider del modello e mantenere tutto il resto.

Gestiamo il lavoro dei nostri agenti trasversalmente su modelli ospitati e open source, e la domanda operativa è raramente "quale modello è più intelligente". La vera domanda è: quale parte del lavoro ha una definizione di completato così chiara da poter essere svolta da un modello più economico, senza che le successive rielaborazioni ne annullino il vantaggio economico?

I quattro elementi che vengono costantemente confusi

Nate B. Jones nella sua analisi separa quattro livelli che nel dibattito sui "modelli più economici" vengono quasi sempre trattati come uno solo (Video, 22 agosto 2026). Questa separazione è il fulcro del trucco:

1. Il modello. La parte che ragiona e produce i token. Intercambiabile.
2. L'Harness (l'infrastruttura). Claude Code, Codex — il programma che legge i file, esegue i comandi, richiede i permessi e mostra i risultati. Rimane.
3. Il contesto del progetto nei file. CLAUDE.md, AGENTS.md, Skills, Hooks, comandi di test, regole del progetto. Portabile — ogni sessione li rilegge, indipendentemente dal provider.
4. La conversazione. La cronologia volatile di una sessione. Non portabile.

Chi pensa che il cambio di modello sia un'operazione da una sola riga di codice di solito confonde il punto 1 con il punto 4. È proprio da qui che nasce l'effetto per cui un modello più economico diventa più costoso: le decisioni dell'ultima ora si trovano nella cronologia e in nessun'altra parte, la nuova sessione non le conosce e le deve rielaborare da capo.

Da ciò deriva la prima regola: Ciò che scrivi nei file sopravvive al cambio di provider. Ciò che si trova solo nella chat, no. L'igiene del contesto a questo punto non è una mania per l'ordine, ma una questione di costi.

Claude Code: una seconda riga di comando, non un secondo strumento

Z.ai fornisce un endpoint compatibile con Anthropic. Claude Code ha quindi bisogno solo di alcune variabili d'ambiente, documentate nella Guida per Sviluppatori Z.ai:

Il modo pratico non è quello di sovrascrivere la configurazione esistente, ma di creare un secondo comando di avvio:

# ~/.zshrc — l'installazione normale rimane intatta
claude-glm() {
  ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic" \
  ANTHROPIC_AUTH_TOKEN="$ZAI_API_KEY" \
  ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5.3" \
  ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5.3" \
  ANTHROPIC_DEFAULT_HAIKU_MODEL="glm-5.3-flash" \
  API_TIMEOUT_MS=3000000 \
  claude "$@"
}

claude continua ad aprire una sessione Anthropic, claude-glm una sessione Z.ai. Entrambe vedono lo stesso repository, lo stesso CLAUDE.md, gli stessi hook e server MCP. Se la connessione GLM non funziona bene, basta chiudere la finestra: non è stato modificato nulla nell'installazione normale.

La chiave API deve stare nel tuo ambiente shell o in un secret manager, non nel progetto. Per chi preferisce la via automatica: npx @z_ai/coding-helper scrive la configurazione da solo.

Cosa non viene trasferito: la cronologia della conversazione precedente, il prompt cache e qualsiasi decisione che non hai mai annotato fuori dalla chat.

Codex: un profilo anziché una seconda sessione

Codex risolve lo stesso problema un livello più in basso, tramite profili nel file ~/.codex/config.toml (Documentazione Z.ai):

[model_providers.ZAI]
name = "ZAI"
base_url = "https://api.z.ai/api/v1"
experimental_bearer_token = "<La tua chiave API>"
wire_api = "responses"

[profiles.glm]
model_provider = "ZAI"
model = "glm-5.3"
model_reasoning_effort = "max"

Dopodiché, codex --profile glm avvia un'esecuzione con GLM, mentre codex continua a funzionare con la tua configurazione OpenAI. Anche in questo caso: stesso progetto, stesso AGENTS.md, stesse regole, ma una nuova conversazione.

Questa è la differenza nel metodo di lavoro: Claude Code sembra una cabina di pilotaggio, dove rimani vicino al lavoro e lo comandi direttamente; Codex assomiglia più a una console da dispatcher, da cui invii incarichi e controlli i risultati. Entrambi gli stili vengono mantenuti quando un'azienda diversa fornisce l'intelligenza: dipendono dall'Harness, non dal modello.

Il documento di consegna: sei righe invece di 40 turni di cronologia

Quando un'attività viene passata a metà esecuzione al modello più economico, la tentazione di copiare la cronologia della conversazione è forte. È la via più costosa: il nuovo modello deve prima capire quale parte di essa fosse effettivamente rilevante. È meglio usare un documento di consegna (handover note) con sei campi, scritto dal modello uscente stesso:

Obiettivo:   Aggiornare queste 38 chiamate API al nuovo nome del campo.
Stato:       Il branch è pulito; le chiamate interessate sono in src/api/ e src/jobs/.
File:        src/api/*.ts, src/jobs/sync.ts, tests/api.spec.ts
Vincoli:     Non modificare l'API pubblica. Nessuna nuova dipendenza.
Completato:  Il vecchio nome del campo non compare più da nessuna parte, tutti i test passano.
Verifiche:   pnpm test && pnpm lint && pnpm build

Queste sei righe sono allo stesso tempo uno strumento di diagnostica. Se un'attività non può essere strutturata in questo formato, non è adatta al modello più economico. Non perché GLM sia troppo debole, ma perché l'attività non è ancora ben definita.

Lead e Worker: due sessioni, un Git Worktree

L'idea più ovvia in Claude Code: assegnare il sub-agente a un altro modello. Questo non funziona. Un normale sub-agente si avvia volutamente con un contesto pulito, e un sub-agente forkato, che eredita l'intera cronologia, deve usare lo stesso modello del processo padre. Non esiste in modo nativo un provider separato per ogni agente figlio.

Il pattern sostenibile è più grezzo e robusto:

• Lead: la consueta sessione Anthropic. Decide qual è il compito e, alla fine, verifica.
• Worker: una sessione claude-glm che riceve il documento di consegna.
• Separazione: Il Worker lavora nel proprio git worktree, in modo che le due sessioni non si modifichino reciprocamente i file sotto il naso.

git worktree add ../progetto-worker -b feature/api-nome-campo
cd ../progetto-worker && claude-glm

Il Worker restituisce: file modificati, controlli eseguiti e tutto ciò che non è riuscito a risolvere. Il Lead controlla, se la modifica è rilevante. Rimane un unico progetto e uno strumento familiare, solo con un passaggio di consegne esplicito nel mezzo. Come questo si inserisca in un flusso di lavoro multi-agente più ampio lo abbiamo descritto nella Guida per Builder per Claude Code 2.0.

Quali compiti assegnare al modello economico — e quali no

La linea di demarcazione non è tra "difficile" e "facile", ma tra verificabile e poco chiaro:

Un esempio per la colonna di destra: un problema di autenticazione sporadico. A un Worker economico può essere concesso di raccogliere i log e tracciare i percorsi del codice, ma l'indagine vera e propria rimane al modello più potente di cui ti fidi.

E il consiglio sulle tempistiche che fa risparmiare più soldi: Inizia un'attività complessa con il modello che dovrà anche concluderla. Creare quaranta turni di cronologia per poi cambiare provider in dirittura d'arrivo è esattamente il caso in cui il modello economico diventerà sicuramente più costoso.

Quanto costa veramente

Qui serve onestà, altrimenti uno strumento diventa una falsa promessa:

• Il piano da 18 dollari non è il piano da 200 dollari. Limiti diversi, budget di token diverso, diverse capacità di risoluzione dei problemi. Z.ai opera con finestre di cinque ore e settimanali.
• Calcola il costo completo. Il prezzo onesto è dato dai token più le esecuzioni ripetute più il tuo tempo di revisione. Un'esecuzione che avvii due volte e poi devi sistemare tu stesso non è stata affatto economica.
• Fai i test sul tuo codice. È la complessità del tuo repository a decidere, non un benchmark. Dai deliberatamente al Worker anche compiti impegnativi e fai un passo indietro dove fallisce: è così che troverai il limite reale.
• Non fare avanti e indietro nel bel mezzo della conversazione. La cronologia visibile non è l'intero stato; i prompt cache e il comportamento del modello cambiano di conseguenza.

Lo stesso principio vale anche senza cambiare provider: persino un modello più piccolo della stessa azienda è un Worker. Abbiamo inquadrato le capacità di base di GLM 5.3 in GLM-5.3: Coding di frontiera con capacità cyber emergenti; la logica di migrazione tra due generazioni di Harness si trova nella Checklist di migrazione Fast Mode per Codex e Opus 4.7.

Costruire questa suddivisione per uno stack specifico — quali compiti vanno al Worker, che aspetto ha il documento di consegna e in base a cosa valuti i ritorni — rientra tra i progetti a cui lavora il nostro team.

Domande frequenti

Devo cambiare strumento per usare GLM 5.3? No. Sia Claude Code che Codex accettano Z.ai come provider del modello: Claude Code tramite ANTHROPIC_BASE_URL, Codex tramite un profilo in config.toml. File, hook, permessi e server MCP rimangono invariati (Fonte).

La nuova sessione mantiene la cronologia delle mie conversazioni precedenti? No. È portabile solo ciò che si trova nei file: CLAUDE.md, AGENTS.md, Skills, comandi di test. La cronologia e il prompt cache vengono lasciati indietro. Da qui la necessità del documento di consegna con obiettivo, stato, file, vincoli, definizione di completato e verifiche.

Posso assegnare un sub-agente in Claude Code a GLM? Non in modo nativo. Un sub-agente forkato deve usare lo stesso modello del processo padre, e non esiste un provider dedicato per ogni agente figlio. Il metodo praticabile consiste nell'usare due sessioni — Lead e Worker — con il Worker in un proprio git worktree (Fonte).

Quali compiti sono adatti al modello più economico? Quelli con un obiettivo chiaro, un ambito limitato di file, esempi nel repo e test che decidono se il compito è completato. La ricerca delle cause con stati nascosti e le decisioni sul "cosa fare" spettano al modello potente.

Risparmio davvero soldi così facendo? Solo se calcoli il costo completo: token più ripetizioni più tempo di revisione. Il piano da 18 dollari ha limiti inferiori e non sostituisce un abbonamento da 200 dollari, ma offre una corsia secondaria per compiti limitati e verificabili.

Fonti

1. Documentazione per sviluppatori Z.AI — Claude Code
2. Documentazione per sviluppatori Z.AI — Codex
3. Nate B. Jones — Smetti di pagare $200 per il lavoro che un modello da $18 può fare su Claude Code e Codex (YouTube, 22 agosto 2026)
4. Anthropic — Sub-agenti Claude Code
5. Git — worktree