Claude Code e Goose a confronto: costi, controllo e flusso di lavoro degli sviluppatori

Claude Code e Goose a confronto: la domanda sulla sostituzione che interessa davvero agli sviluppatori

Un team con cui ho lavorato di recente aveva un problema di costi apparentemente semplice: otto ingegneri usavano intensamente Claude Code durante una migrazione, e la voce di spesa dell'abbonamento mensile era improvvisamente diventata abbastanza evidente da spingere il reparto finanziario a chiedere se un agente open source potesse sostituirlo. Goose è stato proposto subito perché privilegia l'esecuzione locale, è estensibile e può collegarsi a più fornitori di modelli. Sulla carta, la proposta sembra lineare: mantenere il flusso di lavoro con un agente nel terminale, evitare un altro abbonamento per utente e instradare le chiamate ai modelli dove si vuole.

Nella pratica, «gratuito» non significa «equivalente».

Il vero confronto non riguarda la possibilità per Goose di modificare file o eseguire comandi shell. Può farlo. La domanda è se Goose possa sostituire Claude Code nel modo in cui i tuoi sviluppatori lavorano davvero: refactoring su più file, cicli di lavoro guidati dai test, ragionamento basato sul contesto del repository, controlli aziendali, comportamento dei modelli nativamente legato a Claude e la banale affidabilità di arrivare alla fine di un martedì senza passare metà mattina a fare il debug del proprio assistente.

Questo è un confronto pratico per gli sviluppatori che valutano Claude Code rispetto a Goose, mantenendo circoscritto l'intento di ricerca: Goose può realisticamente sostituire Claude Code e in quali casi cambia la risposta?

In breve

L'errore è considerare Goose come «Claude Code, ma gratis». È più corretto vedere Goose come un ambiente di esecuzione aperto per agenti, che può essere eccellente se abbinato al modello e alla configurazione giusti. Claude Code offre un'esperienza di prodotto con scelte più definite, costruita attorno al flusso di lavoro di sviluppo di Anthropic.

Cosa offre Claude Code fin da subito

Il punto di forza principale di Claude Code non è un singolo comando. È il fatto che il percorso predefinito sia già strutturato attorno al lavoro concreto di sviluppo software.

Una sessione normale si presenta così:

cd ~/work/payments-service
claude

Poi, all'interno della sessione:

Read the failing test output, inspect the relevant code paths, and make the smallest fix.
Run the focused test before changing anything else.

Per un'attività diretta da eseguire in un'unica richiesta:

claude "Find why invoice retries are duplicating events and propose a minimal patch"

In pratica, Claude Code è utile perché incorpora correttamente molte delle aspettative sul flusso di lavoro:

• Comprende che il contesto del repository è importante.
• Può esaminare i file prima di modificarli.
• Può eseguire test e intervenire in caso di errori.
• Richiede l'autorizzazione per le operazioni sensibili, a seconda della configurazione.
• È ottimizzato per modelli Claude come Sonnet 4.6 e Opus 4.8, che eccellono nel ragionamento sul codice e nelle modifiche di ampio respiro.

Nel lavoro quotidiano, vedo spesso usare Claude Code per richieste come:

• «Spiega questo confine tra servizi prima che ci metta mano.»
• «Aggiungi un test che fallisca per questo bug.»
• «Esegui il refactoring di questo modulo senza modificare l'API pubblica.»
• «Trova dove viene letto questo valore di configurazione in produzione.»
• «Aggiorna questo endpoint e tutti i componenti che lo chiamano.»
• «Esamina questo diff per individuare eventuali regressioni.»

Il dettaglio importante è che l'interfaccia di Claude Code non è soltanto una chat nel terminale. È un ciclo di sviluppo: leggere, ragionare, modificare, eseguire, iterare.

Uno schema di configurazione comune consiste nel mantenere esplicite le autorizzazioni per le azioni rischiose. Ad esempio, i team usano spesso impostazioni locali al progetto per limitare ciò che l'assistente può fare:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(pytest:*)",
      "Bash(git diff:*)",
      "Bash(git status:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Bash(rm -rf:*)",
      "Bash(kubectl delete:*)"
    ]
  }
}

La policy specifica varia in base all'ambiente, ma il principio resta lo stesso: consentire all'assistente di eseguire gli stessi comandi di verifica sicuri che eseguirebbe uno sviluppatore e bloccare quelli che modificano l'infrastruttura condivisa o pubblicano codice.

Cosa offre realmente Goose

Goose è interessante per un motivo diverso: offre agli sviluppatori un maggiore controllo sul livello degli agenti. Invece di adottare l'assistente di sviluppo completo di un unico fornitore, è possibile eseguire localmente un agente open source e collegarlo al provider e agli strumenti preferiti.

Una configurazione tipica di Goose si avvicina di più a questo schema:

# Install Goose using the current recommended installer for your platform
goose configure
goose session

Durante la configurazione si scelgono un provider e un modello. I dettagli dipendono dall'ambiente, ma a livello concettuale la configurazione è questa:

provider: anthropic
model: claude-sonnet-4-6
extensions:
  developer:
    enabled: true
  memory:
    enabled: true

Oppure, per un esperimento con un modello locale:

provider: ollama
model: qwen2.5-coder:32b
extensions:
  developer:
    enabled: true

Questa flessibilità è il punto centrale. Goose può essere usato con modelli Anthropic, modelli locali e backend di altri provider. Può integrarsi tramite estensioni e, a seconda della configurazione, connessioni agli strumenti di tipo MCP.

Un semplice flusso di lavoro con Goose potrebbe essere:

cd ~/work/billing-api
goose session

Poi:

Inspect the retry scheduler and explain why duplicate invoice events are possible.
Do not edit files yet.

Oppure:

Create a patch that makes the retry operation idempotent.
Run the focused unit tests if available.

Quando Goose è configurato bene e abbinato a un modello valido, l'esperienza può avvicinarsi al ciclo di lavoro di Claude Code. Quando invece viene abbinato a un modello più debole, a una configurazione incompleta degli strumenti o a presupposti fragili sull'ambiente locale, il divario emerge rapidamente.

Questo è il compromesso fondamentale: Goose offre controllo, ma richiede di farsi carico di una parte maggiore del lavoro di integrazione.

Costi: un client gratuito non significa sviluppare gratis

Il più grande equivoco in questo confronto riguarda i costi.

Il fatto che Goose sia open source può ridurre o eliminare il costo dell'abbonamento al client. Non elimina magicamente il costo dell'inferenza del modello. Se si collega Goose a un modello ospitato a pagamento, si continuano a pagare i token. Se lo si collega a un modello locale, il costo si traduce in hardware, latenza, compromessi sulla qualità, tempo di configurazione e manutenzione operativa.

Un confronto pratico dei costi si presenta così:

Per un singolo sviluppatore, Goose abbinato a un modello locale può essere sufficiente per piccole modifiche, spiegazioni e assistenza nella scrittura di script. Per un team che svolge attività complesse in un grande monorepo TypeScript o in un servizio Python con comportamenti di concorrenza sottili, la qualità del modello conta più dello strato software che gestisce l'agente.

Questo vale soprattutto nel confronto con l'attuale gamma Claude. Sonnet 4.6 è spesso il modello più pratico per lo sviluppo quotidiano, perché bilancia capacità e costi. Opus 4.8 è il tipo di modello che riserverei ad attività di architettura più difficili o al debugging in più passaggi. Haiku 4.5 è utile quando velocità e costi contano più del ragionamento approfondito. Il contesto di 1M di Fable 5 cambia la valutazione per i flussi di lavoro con un contesto molto ampio, anche se un contesto ampio non sostituisce un buon recupero delle informazioni e una definizione rigorosa dell'attività.

Se si usa Goose con i modelli Claude tramite API, il confronto sui costi riguarda meno «Claude Code contro Goose» e più l'offerta in abbonamento rispetto a un'infrastruttura fatturata in base ai token.

Controllo locale e vincoli aziendali

L'argomento più forte a favore di Goose è il controllo.

Se l'organizzazione ha requisiti rigorosi su dove vengono eseguiti gli strumenti, quali provider sono consentiti e come sono configurate le macchine degli sviluppatori, Goose offre più aspetti da gestire direttamente. È possibile standardizzare una configurazione, fissare le versioni, definire le estensioni e instradare il traffico dei modelli attraverso gateway approvati.

Ad esempio, un wrapper aziendale potrebbe impostare la configurazione del provider tramite variabili d'ambiente:

export GOOSE_PROVIDER=anthropic
export ANTHROPIC_API_KEY="$AI_GATEWAY_ANTHROPIC_KEY"
export GOOSE_MODEL=claude-sonnet-4-6

goose session

Oppure instradare il traffico attraverso un proxy interno:

export ANTHROPIC_BASE_URL="https://ai-gateway.internal.example.com/anthropic"
export ANTHROPIC_API_KEY="$DEVELOPER_AI_TOKEN"
goose session

Questo tipo di configurazione è interessante quando servono registrazione centralizzata dei log, controlli sul budget, elenchi di elementi consentiti o ispezione del traffico.

Claude Code, invece, è più interessante quando l'azienda accetta già i controlli di prodotto di Anthropic e desidera un'esperienza supportata e nativa per Claude, con meno componenti da assemblare localmente. Servono comunque una policy di sicurezza, formazione per gli sviluppatori e misure di protezione a livello di repository, ma si deve costruire in proprio una parte minore della piattaforma degli agenti.

Un'insidia comune degli strumenti che privilegiano l'esecuzione locale è che «lo controlliamo noi» può diventare «lo manteniamo noi». Qualcuno deve rispondere a queste domande:

• Quale modello è approvato?
• Quali estensioni sono installate?
• Come si impedisce che i segreti finiscano nei prompt?
• Come vengono conservati o disabilitati i log?
• Quali comandi può eseguire l'agente?
• Come si diagnosticano gli errori tra macOS, Linux, shell, versioni di Python, versioni di Node e strumenti aziendali per gli endpoint?

Claude Code non fa sparire queste domande, ma il perimetro del prodotto supportato è più chiaro.

Flusso di lavoro quotidiano: dove emerge la differenza

La domanda sulla possibilità di sostituzione diventa concreta quando si osservano i normali cicli di lavoro degli sviluppatori.

1. Comprensione del repository

Claude Code dà buoni risultati quando gli si chiede di costruire un modello mentale prima di apportare modifiche:

Map the request flow for POST /invoices from route handler to database write.
List the files involved and identify where idempotency should live.
Do not make changes yet.

Una buona configurazione di Goose può fare lo stesso, soprattutto con un modello capace. Il rischio è che i modelli di qualità inferiore possano riassumere con sicurezza senza esaminare abbastanza file. Non è un problema specifico di Goose: è un limite del modello operativo degli agenti. Tuttavia, poiché Goose incoraggia la flessibilità nella scelta del provider, è più probabile che i team provino modelli più deboli in flussi di lavoro impegnativi.

2. Modifiche a più file

Per una modifica mirata, entrambi gli strumenti possono funzionare:

Rename RetryPolicy.maxAttempts to RetryPolicy.maximumAttempts across the repo.
Update tests and run the focused suite.

È quando la modifica coinvolge codice generato, fixture di test e convenzioni del framework che il modello e gli strumenti fanno la differenza. Claude Code offre generalmente un'esperienza più coerente nell'intero ciclo, perché l'esperienza nativa di Claude è ottimizzata proprio per questo. Goose può eguagliarlo quando il modello del provider è potente e gli strumenti per gestire i file sono affidabili, ma l'onere ricade sulla tua configurazione.

3. Esecuzione dei test

Un assistente utile non dovrebbe limitarsi a modificare. Dovrebbe anche verificare.

pytest tests/billing/test_invoice_retries.py -q
npm test -- --run retry-policy
cargo test retry_policy

Con entrambi gli strumenti, preferisco fornire comandi di test espliciti anziché chiedere genericamente all'agente di «eseguire i test». Questo riduce il tempo sprecato ed evita che l'agente avvii per errore un'intera suite di test di integrazione.

Un buon prompt è:

Make the minimal fix, then run:
pytest tests/billing/test_invoice_retries.py -q

If it fails, show the failure and inspect before making a second edit.

Claude Code tende a gestire questo ciclo senza intoppi. Anche Goose può farlo, ma l'integrazione con la shell e le autorizzazioni devono essere configurate correttamente.

4. Lavorare con contesti lunghi

Un contesto ampio è utile, ma è facile usarlo male. Inserire un intero repository nel contesto è raramente la scelta migliore per iniziare.

Con i modelli Claude, soprattutto con l'aumentare delle finestre di contesto, gli sviluppatori sono tentati di porre domande generiche come:

Review the whole repo and tell me what to refactor.

Questo produce risposte vaghe. Meglio:

Inspect the authentication middleware, route registration, and user repository.
Find one concrete reason session refresh fails after password rotation.
Return the evidence before suggesting a patch.

Questa indicazione vale sia per Goose sia per Claude Code. Lo strumento non elimina la necessità di definire il compito con precisione.

Flussi di lavoro API a supporto di entrambi gli strumenti

Alcuni team non dovrebbero sceglierne uno solo. Uno schema comune è:

• Claude Code per lo sviluppo interattivo.
• Chiamate API per l'automazione ripetibile.
• Goose per esperimenti locali o instradamento personalizzato verso i provider.

Per esempio, uno script a supporto della CI potrebbe chiamare direttamente l'API di Claude per ottenere commenti di revisione strutturati:

import os
import anthropic

client = anthropic.Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

diff = open("diff.txt", "r", encoding="utf-8").read()

message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1200,
    messages=[
        {
            "role": "user",
            "content": (
                "Review this diff for likely regressions. "
                "Return JSON with fields: risk_level, findings, tests_to_run.\n\n"
                f"{diff}"
            ),
        }
    ],
)

print(message.content[0].text)

Struttura prevista della risposta:

{
  "risk_level": "medium",
  "findings": [
    {
      "file": "src/retry.ts",
      "issue": "Backoff state is shared across tenants",
      "why_it_matters": "A noisy tenant can slow retries for unrelated tenants"
    }
  ],
  "tests_to_run": [
    "npm test -- --run retry"
  ]
}

Questo non sostituisce un agente interattivo, ma mostra dove si trovano i confini. Claude Code e Goose sono strumenti rivolti agli sviluppatori. L'API è più adatta a flussi di lavoro deterministici e ripetibili, nei quali controlli il prompt, lo schema e la gestione degli errori.

Goose può realisticamente sostituire Claude Code?

Sì, per alcuni sviluppatori.

No, per molti team.

Goose ha maggiori probabilità di sostituire Claude Code quando:

• Ti senti a tuo agio nel configurare credenziali dei provider ed estensioni.
• Preferisci un controllo incentrato sull'ambiente locale a un'esperienza predefinita curata.
• I tuoi compiti hanno una complessità bassa o media.
• Sei disposto a usare modelli a pagamento potenti quando quelli locali non bastano.
• La tua organizzazione dispone di persone in grado di mantenere la configurazione dell'agente.

Claude Code è più difficile da sostituire quando:

• Gli sviluppatori lo usano tutto il giorno per cicli di programmazione in più passaggi.
• Hai bisogno di un percorso di adozione semplice.
• Ti interessano il comportamento nativo di Claude e l'integrazione con gli attuali modelli Anthropic.
• Vuoi meno componenti da gestire nella catena di strumenti.
• I controlli aziendali, la facilità di supporto e un'esperienza prevedibile per gli sviluppatori contano più dell'apertura del client.

La risposta onesta è che Goose può sostituire parte del flusso di lavoro di Claude Code. La possibilità di sostituirlo interamente dipende meno da Goose in sé e più dal modello, dalla configurazione e dalla disciplina operativa che lo supportano.

Se la tua valutazione si basa soltanto sul costo dell'abbonamento, fai una prova di due settimane con attività reali. Tieni traccia di:

• Tempo necessario per ottenere la prima patch utile.
• Numero di chiamate agli strumenti non riuscite.
• Numero di correzioni umane per attività.
• Spesa per i token nelle sessioni di Goose basate su API.
• Tempo dedicato dagli sviluppatori alla configurazione e al debug.
• Qualità dei diff finali dopo la revisione.

Questo ti dirà più di un elenco di funzionalità.

Indicazioni pratiche

«Claude Code vs Goose» non è una semplice scelta tra pagamento e gratuità. Claude Code è la scelta predefinita più solida per gli sviluppatori che desiderano un flusso di lavoro di programmazione curato e nativo di Claude, con meno configurazione. Goose è interessante quando il controllo locale, la flessibilità dei provider e l'estensibilità aperta contano più della fluidità d'uso immediata.

Per i singoli sviluppatori, vale assolutamente la pena provare Goose. Per i team, valutalo con ticket reali, repository reali e un monitoraggio effettivo dei costi. Non dare per scontato che un client gratuito significhi un utilizzo gratuito, né che un modello locale possa eguagliare Sonnet 4.6 o Opus 4.8 nel ragionamento su codice complesso.

Il mio consiglio di base è pragmatico: mantieni Claude Code dove la produttività degli sviluppatori conta di più, prova Goose dove controllo e personalizzazione sono prioritari e usa direttamente l'API di Claude per l'automazione ripetibile. La risposta giusta potrebbe essere un flusso di lavoro misto, anziché un unico vincitore.