---
type: "BlogPosting"
title: "Modello da $18 (GLM) come Worker in Claude Code e Codex — Ottimizzazione dei costi senza cambiare setup"
description: "Scopri come integrare il modello GLM da $18 di Z.ai come \"Worker\" all'interno di Claude Code e Codex per abbattere i costi senza rinunciare al tuo setup di sviluppo attuale. Una guida pratica su come separare i ruoli di Lead e Worker e definire i compiti adatti al modello più economico."
resource: "https://www.contextstudios.ai/it/blog/modello-da-18-dollari-glm-come-worker-in-claude-code-e-codex"
language: "it"
tags: ["Claude Code", "Codex", "GLM", "Kostenoptimierung", "Agenten-Workflows"]
generated:
by: "process:contextstudios-md/1"
at: "2026-10-23T05:49:15.668Z"
status: "stable"
---
# Modello da $18 (GLM) come Worker in Claude Code e Codex — Ottimizzazione dei costi senza cambiare setup
Published: 2026-09-07
Tags: Claude Code, Codex, GLM, Kostenoptimierung, Agenten-Workflows
# 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.
Il piano GLM Coding di Z.ai parte da 18 dollari al mese e può essere impostato come provider del modello sia in Claude Code che in Codex. File, regole, strumenti, permessi e hook rimangono invariati: cambia solo l'azienda che fornisce le risposte.
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](https://www.youtube.com/watch?v=4HvFqhtCb-A)). 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](https://docs.z.ai/devpack/tool/claude):
| Variabile | Valore |
|---|---|
| `ANTHROPIC_BASE_URL` | `https://api.z.ai/api/anthropic` |
| `ANTHROPIC_AUTH_TOKEN` | La tua chiave API Z.ai |
| `ANTHROPIC_DEFAULT_SONNET_MODEL` | `glm-5.3` |
| `ANTHROPIC_DEFAULT_OPUS_MODEL` | `glm-5.3` |
| `ANTHROPIC_DEFAULT_HAIKU_MODEL` | `glm-5.3-flash` |
Il modo pratico **non** è quello di sovrascrivere la configurazione esistente, ma di creare un secondo comando di avvio:
```bash
# ~/.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](https://docs.z.ai/devpack/tool/codex)):
```toml
[model_providers.ZAI]
name = "ZAI"
base_url = "https://api.z.ai/api/v1"
experimental_bearer_token = ""
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:
```markdown
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.
```bash
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](https://www.contextstudios.ai/de/blog/der-komplette-builder-guide-fr-claude-code-20-von-nebenfragen-bis-zum-multi-agent-review).
## Quali compiti assegnare al modello economico — e quali no
La linea di demarcazione non è tra "difficile" e "facile", ma tra **verificabile** e **poco chiaro**:
| Al Worker (GLM) | Da tenere per il modello potente |
|---|---|
| Obiettivo chiaro, stato finale chiaro | La questione di quale debba essere effettivamente l'attività |
| Esempi dello stesso tipo sono presenti nel repo | Stato nascosto, prove contraddittorie |
| I test decidono se è "completato" | Valutazioni del rischio con relative conseguenze |
| Ambito di file limitato | Ricerca delle cause attraverso i confini del sistema |
| Rinominazioni, migrazioni, pattern ricorrenti | Decisioni architetturali |
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](https://www.contextstudios.ai/de/blog/glm-53-frontier-coding-mit-emergenten-cyber-fhigkeiten); la logica di migrazione tra due generazioni di Harness si trova nella [Checklist di migrazione Fast Mode per Codex e Opus 4.7](https://www.contextstudios.ai/de/blog/codex-und-opus-4-7-fast-mode-migrationscheckliste).
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](https://www.contextstudios.ai/de/leistungen).
## 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](https://docs.z.ai/devpack/tool/claude)).
**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](https://www.youtube.com/watch?v=4HvFqhtCb-A)).
**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](https://docs.z.ai/devpack/tool/claude)
2. [Documentazione per sviluppatori Z.AI — Codex](https://docs.z.ai/devpack/tool/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)](https://www.youtube.com/watch?v=4HvFqhtCb-A)
4. [Anthropic — Sub-agenti Claude Code](https://docs.claude.com/en/docs/claude-code/sub-agents)
5. [Git — worktree](https://git-scm.com/docs/git-worktree)
## Related
- [Sviluppo agenti AI](https://www.contextstudios.ai/it/sviluppo-agente-ia.md)
- [Sviluppo AI](https://www.contextstudios.ai/it/sviluppo-ia.md)
- [Integrazione LLM](https://www.contextstudios.ai/it/integrazione-llm.md)
- [Automazione workflow AI](https://www.contextstudios.ai/it/automazione-workflow-ia.md)