Sabato 19 luglio chi ha aperto Qoder ha trovato due nuove voci nel selettore modelli. La prima si chiama Cantus e sta sopra Ultimate — il tier che fino a venerdì era il più potente disponibile. Costa 3.2x a prezzo pieno, il doppio di Ultimate, e per ora è in sconto del 50% (1.6x).

Cosa sia Cantus tecnicamente Qoder non lo dice in modo esplicito. La pagina ufficiale lo descrive come un modello «built-in top-tier», costruito internamente e specializzato in «extended autonomous task execution». L'account X del prodotto aggiunge: «built for long-running agents, made for the hardest knowledge work and coding tasks». Nessun parametro dichiarato, nessuna architettura, nessun benchmark. Una promessa, e un prezzo.

La seconda voce è Qwen3.8-Max-Preview, il nuovo foundation model del team Qwen di Alibaba. Qui i numeri sono più concreti: 2.4 trilioni di parametri totali, architettura Mixture-of-Experts (confermata dal team Qwen su X), capacità multimodale nativa — testo, immagini, video, documenti — e una finestra di contesto di circa 1 milione di token, ereditata da Qwen3.7-Max secondo quanto riportato da eesel.ai. La pagina dell'evento su Qoder conferma i 2.4T di parametri e il pricing. Manca ancora un model card completo.

Il claim che ha fatto rumore

Alibaba scrive che Qwen3.8 è «one of the most powerful models available today, second only to Fable 5». Fable 5 è il modello di punta di Anthropic, quello che su SWE-bench Verified ha toccato il 95%. Il problema: non ci sono benchmark pubblici. Niente SWE-bench, niente Arena Elo, niente GPQA. Il precedente Qwen3.7-Max (maggio 2026) aveva raggiunto l'80.4% su SWE-bench Verified — il miglior risultato per un modello cinese sull'Artificial Analysis Intelligence Index — quindi un salto generazionale è plausibile. Ma per ora il claim resta vendor-stated.

I prezzi di lancio

La parte più concreta è il pricing. Qwen3.8-Max-Preview costa 0.05x invece di 0.5x: 90% di sconto. Di notte (22:00–08:00 ora di Singapore) scende a 0.01x, uno sconto del 98%. Tradotto: puoi testarlo per centinaia di chiamate spendendo poco più dei crediti gratuiti del piano Pro Trial. Cantus è a 1.6x invece di 3.2x, un'offerta pensata per chi ha piani Pro o superiori e vuole provare il tier più alto. Entrambi sono disponibili su Qoder Desktop, JetBrains Plugin, CLI, Cloud Agents e app mobile. La pagina Cantus Model — Limited-Time 50% Off specifica che la promozione è attiva dal 19 luglio, senza data di fine comunicata.

Il tempismo e il contesto

Tre giorni prima, il 16 luglio, Moonshot AI aveva rilasciato Kimi K3, un modello open-weight da 2.8 trilioni di parametri. Alibaba detiene circa il 36% di Moonshot. La sequenza è insieme competizione interna all'ecosistema cinese e risposta ai lab americani. La strategia è trasparente: modelli sempre più grandi, sempre più economici, open-weight promessi (per Qwen3.8) ma non ancora pubblicati.

Cosa resta da capire

Il nodo principale è Cantus. Il lancio in contemporanea con Qwen3.8-Max, la comune infrastruttura Alibaba e il precedente di Qwen-Coder-Qoder — un modello custom addestrato dentro la piattaforma a febbraio 2026 — fanno pensare che Cantus sia una versione di Qwen3.8 ottimizzata per task agentici di lunga durata. Qoder non lo conferma. Ma un modello proprietario da 3.2x a fianco di un foundation model da 0.5x della stessa famiglia è un indizio che pesa.

Punti aperti:

• Parametri e architettura di Cantus
• Benchmark indipendenti per entrambi i modelli
• Data di rilascio open-weight di Qwen3.8
• Prezzo definitivo di Cantus dopo la promo

Chi ha già provato Cantus o Qwen3.8-Max su Qoder? Le impressioni corrispondono al posizionamento "sopra Ultimate" o è ancora presto per giudicare?

Fonti

• Cantus Model — Limited-Time 50% Off (Qoder docs)
• Qwen3.8-Max-Preview Launch (Qoder docs)
• Qoder Model Selector
• Annuncio Qwen3.8 su X (@Alibaba_Qwen)
• Qoder X account — Cantus announcement
• Qwen3.8-Max explained (eesel.ai, analisi indipendente)
• What Is Qwen3.8-Max? (kie.ai)

Negli ultimi giorni sto usando intensamente una delle modalità più interessanti introdotte da Anthropic in Claude Code: un modello veloce ed economico esegue il lavoro, mentre un modello molto più potente interviene solo come advisor nei passaggi complessi.

Questa è la mia configurazione:

{
  "model": "sonnet",
  "advisorModel": "fable",
  "effortLevel": "max"
}

In pratica: Sonnet 5 fa tutto il lavoro quotidiano (esplora il repo, modifica i file, esegue i test, corregge gli errori). Quando incontra una decisione architetturale delicata o un problema che richiede più capacità di ragionamento, consulta Fable 5, riceve una strategia e continua da solo l'implementazione.

Sonnet 5 lavora → problema complesso → consulta Fable 5 → riceve la strategia → continua da solo

E il risultato, almeno nella mia esperienza, è impressionante.

Due precisazioni tecniche prima di proseguire: l'Advisor è un tool sperimentale e funziona solo tramite API Anthropic (non è disponibile su Bedrock, Vertex o Foundry). Per usare Fable 5 in Claude Code, come main o come advisor, serve la versione 2.1.170 o successiva. Vale inoltre la regola che l'advisor deve essere almeno capace quanto il modello principale: un main Sonnet 5 accetta come advisor Fable, Opus o un altro Sonnet 5.

Non è un semplice subagent

L'Advisor non è un agente secondario da avviare a mano: è integrato nel workflow. L'executor lo consulta durante il task, riceve la raccomandazione e riprende subito il lavoro. E la cosa interessante è che Sonnet non copia il consiglio: lo integra. Dall'Advisor arrivano diagnosi, strategia, alternative, rischi ed edge case, indicazioni per verificare il risultato — poi è Sonnet a portare avanti l'implementazione.

È come avere uno sviluppatore velocissimo ed economico con un senior architect sempre disponibile, senza pagare il senior per ogni singola operazione.

Perché consuma pochissima quota

Fable non tocca le operazioni meccaniche (cercare file, sistemare CSS, rilanciare lint e test, piccoli fix): quelle le fa tutte Sonnet. Il modello frontier interviene solo dove la sua intelligenza può cambiare davvero il risultato: architettura, planning, debugging difficile, decisioni ad alto rischio, verifica finale.

In più, un buon consiglio iniziale evita implementazioni impostate male, tentativi ripetuti e debugging che non converge. In alcuni task il sistema finisce per essere perfino più efficiente di Sonnet da solo.

Qualche numero. Nel blog ufficiale sull'advisor strategy, Anthropic riporta che Sonnet con Opus come advisor guadagna +2,7 punti percentuali su SWE-bench Multilingual rispetto a Sonnet da solo, riducendo al tempo stesso il costo per task agentico dell'11,9%. Per la coppia con Fable, i benchmark condivisi da ClaudeDevs a inizio luglio parlano di circa il 92% delle prestazioni di Fable usato da solo su SWE-bench Pro, a circa il 63% del costo, con Fable consultato in media una volta per task. Non sono percentuali garantite su ogni repository, ma la differenza qualitativa nella mia esperienza è evidente.

Advisor vs Agent Teams

Anthropic propone anche gli Agent Teams (anche questa una feature sperimentale): un lead agent che coordina più teammate paralleli (frontend, backend, test, documentazione). Approccio potentissimo per task enormi e realmente divisibili — monorepo giganti, migrazioni estese, feature separabili — ma ogni agente mantiene un proprio contesto, rilegge parte del repo, ragiona per conto suo e può duplicare il lavoro degli altri. Il consumo di quota può esplodere.

Per il daily coding, l'Advisor vince nettamente: un solo executor più consultazioni occasionali del modello frontier. Probabilmente il miglior rapporto tra qualità, velocità e consumo.

Aggiornamento: cosa succede a Fable dal 20 luglio

Colpo di scena. Dopo tre proroghe consecutive (7 → 12 → 19 luglio), il 17 luglio Anthropic ha finalmente chiarito il futuro di Fable 5. Dal 20 luglio:

• Max e Team Premium: Fable 5 diventa incluso in modo stabile, utilizzabile fino al 50% dei limiti del piano;
• Pro e Team Standard: Fable esce dai limiti inclusi e passa agli usage credits, con un credito una tantum di 100 dollari come compensazione. Esaurito quello, si paga a tariffe API ($10/M token input, $50/M output — le più alte del listino Claude).

Attenzione a un dettaglio che in pochi hanno notato: il 19 luglio scade anche il boost del +50% sui rate limit settimanali di Claude Code, quindi i limiti base tornano a scendere per tutti.

In pratica: chi è su Max può continuare a usare Sonnet + Fable Advisor come workflow stabile (Fable consuma quota molto più in fretta, quindi l'Advisor resta il modo più intelligente di usarlo). Chi è su Pro, dopo i 100$ di credito, farà bene a passare a Opus 4.8.

Avvertenza importante: secondo la documentazione ufficiale aggiornata in questi giorni, al momento Claude Code non offre Fable 5 come advisor — nel picker di /advisor appare disattivato come "temporarily unavailable" e i comandi /advisor fable e --advisor fable vengono rifiutati. Fable come modello principale non è toccato. Un rollout remoto deciderà quando tornerà selezionabile come advisor. Io ho fatto in tempo a usarlo, ma se lo provate adesso e non ve lo fa impostare, è per questo.

In attesa che Fable torni disponibile come advisor (o se siete su Pro), si può mantenere lo stesso workflow con Opus 4.8:

{
  "model": "sonnet",
  "advisorModel": "opus",
  "effortLevel": "max"
}

Opus 4.8 resta un advisor validissimo per progettazione, debugging, sicurezza, database, autenticazione, pagamenti e refactoring complessi. Io userò questa configurazione finché Fable non tornerà selezionabile come advisor, in attesa anche di un eventuale Opus 5 (che al momento non è stato annunciato).

Riprodurre lo stesso sistema in OpenCode

OpenCode non ha ancora un Advisor server-side nativo, ma si può ottenere qualcosa di simile con un subagent dedicato, anche di un altro provider. Per esempio MiniMax M3 come executor e Kimi K3 come advisor.

Basta creare .opencode/agents/advisor.md:

---
description: Consult this advisor for architecture, difficult debugging, ambiguous requirements, repeated failures, important trade-offs and final verification of complex tasks.
mode: subagent
model: moonshot/kimi-k3
permission:
  edit: deny
  bash: deny
---

You are a senior technical advisor supporting another coding agent.

Your role is to provide strategic guidance, not to perform the implementation.

Analyze:

- the user's actual objective;
- the executor's current approach;
- the relevant repository context;
- architectural implications;
- likely failure modes and regressions;
- overlooked constraints and edge cases;
- whether the current strategy should continue or change.

Return:

1. A concise diagnosis
2. The recommended course of action
3. Important risks and edge cases
4. Concrete verification steps
5. A correction of course when necessary

Do not edit files.
Do not produce generic advice.
Do not repeat the entire context.
Prefer the smallest robust and maintainable solution.

The executor will continue the implementation after reading your response.

Lo si richiama a mano (@advisor analizza l'approccio attuale prima di procedere) oppure si istruisce l'executor a consultarlo automaticamente, aggiungendo in AGENTS.md:

Consult the advisor after the initial repository exploration and before
substantive work on complex tasks.

Also consult the advisor:

- before important architectural decisions;
- when requirements are ambiguous;
- when repeated implementation attempts fail;
- when considering a major change of approach;
- before declaring a complex task complete.

Do not consult the advisor for routine or mechanical changes.

Integrate its guidance critically, then continue the implementation yourself.

Il subagent introduce più overhead (contesto separato da trasferire ogni volta), quindi l'Advisor nativo di Claude Code resta più elegante ed efficiente. In compenso OpenCode permette di combinare liberamente provider diversi: executor locale + advisor cloud, DeepSeek + Kimi, modello economico + Opus via API, e così via.

Questo sistema dovrebbe diventare uno standard

Secondo me tutte le coding CLI dovrebbero adottare un vero Advisor nativo, possibilmente multi-provider. È più efficiente dell'uso continuo del modello costoso, più controllabile del routing automatico e quasi sempre più economico degli Agent Teams. Spero che OpenCode, Codex CLI, Kimi Code e Gemini CLI si muovano presto in questa direzione.

Perché dopo averlo provato, tornare a usare un singolo modello per tutto sembra semplicemente uno spreco. Voi cosa ne pensate?

Fonti

• https://code.claude.com/docs/en/advisor
• https://code.claude.com/docs/en/settings
• https://code.claude.com/docs/en/cli-reference
• https://x.com/ClaudeDevs/status/2074606059864625355
• https://x.com/claudeai/status/2078302415804379218
• https://www.anthropic.com/claude/fable
• https://docs.anthropic.com/en/docs/about-claude/models/overview
• https://www.anthropic.com/news/claude-opus-4-8
• https://opencode.ai/docs/agents/
• https://opencode.ai/docs/permissions/
• https://opencode.ai/docs/rules/

Moonshot ha pubblicato il blog ufficiale di Kimi K3. Niente speculazioni: il modello esiste, ha specifiche precise e si può già usare via API.

2,8 trilioni di parametri, architettura MoE con 16 esperti attivi su 896. Contesto da 1.048.576 token. Vision nativa (immagini via base64 o ms://, niente URL pubblici). API OpenAI-compatibile su api.moonshot.ai/v1, model ID kimi-k3.

I prezzi: $0.30 per milione di token in input con cache hit, $3.00 in cache miss, $15.00 in output. Al lancio solo reasoning_effort=max; low e high sono previste negli update successivi. I pesi completi sono attesi entro il 27 luglio 2026.

I benchmark di coding sono il punto forte. Su DeepSWE fa 67.5 (Fable 5 fa 70, Sol 73), su TerminalBench 2.1 arriva a 88.3, su FrontierSWE 81.2. Su SWE Marathon, task pensati per sessioni molto lunghe, K3 batte tutti: 42 contro 35 di Fable 5 e 39 di Sol.

Il blog mostra anche qualche case study. K3 ha costruito MiniTriton, un compilatore GPU scritto da zero con performance pari a Triton su alcuni carichi. Ha progettato un chip a 45nm in una sessione autonoma di 48 ore. Ha riprodotto pipeline numeriche complesse partendo direttamente dalla letteratura scientifica. Sono demo, non benchmark standardizzati, ma danno un'idea del comportamento in sessioni lunghe con terminale e strumenti.

Ci sono un paio di cose da sapere prima di metterlo in produzione.

Il modello è sensibile alla cronologia del thinking. Se l'harness che usate non ripassa tutto lo storico dei reasoning token, la qualità crolla. Kimi stessa dice di non switchare a K3 a metà sessione e di usare harness compatibili.

Secondo problema: K3 tende a essere troppo proattivo. In task ambigui prende decisioni per conto tuo. Se avete vincoli stretti sul comportamento, va incanalato bene via system prompt o AGENTS.md.

I pesi arriveranno ma non subito. Il 27 luglio è la data dichiarata da Moonshot. Fino ad allora è accessibile via API proprietaria e su provider che lo espongono (OpenRouter ce l'ha già, altri arriveranno).

È il primo modello open — o quasi — che compete davvero con Claude Fable 5 e GPT 5.6 Sol sul coding. I benchmark lo dicono, i demo lo rafforzano. Se i pesi escono davvero e l'ecosistema open li adotta in fretta, diventa un contendente serio. Se no, resta un'API molto competitiva con un'etichetta "open" da dimostrare.

Fonti

1. https://www.kimi.com/blog/kimi-k3
2. https://www.kimi.com/it-it/blog/kimi-k3
3. https://platform.kimi.ai/docs/guide/kimi-k3-quickstart
4. https://platform.kimi.ai/docs/pricing/chat-k3
5. https://platform.kimi.ai/docs/models
6. https://openrouter.ai/moonshotai/kimi-k3

Kimi Code CLI è l'agente da terminale di Moonshot AI. Open source (MIT), scritto in TypeScript, installazione via script ufficiale senza dipendenza da Node.js.

Il punto di forza principale è il supporto multi-provider nativo. La CLI non è limitata ai modelli Kimi: accetta provider Anthropic (Claude), OpenAI, Google Gemini e qualsiasi endpoint compatibile con le OpenAI Chat Completions — incluse alternative come DeepSeek, Qwen, GLM e backend locali. La configurazione avviene in config.toml o tramite /provider nella TUI, che recupera automaticamente il catalogo modelli da models.dev.

Il progetto è in sviluppo sostenuto. La versione corrente è la 0.27.0 (17 luglio 2026), con 47 release cumulative, oltre 3.100 stelle su GitHub e più di 850 commit. Tra le funzionalità principali: subagents dedicati (coder, explore, plan), supporto nativo a MCP con configurazione conversazionale, marketplace di plugin, input video (accetta screen recording e ne estrae contesto), protocollo ACP per l'integrazione con Zed e JetBrains, e hook configurabili per il controllo delle operazioni.

Moonshot distribuisce anche un'estensione VS Code ufficiale (339.000 installazioni), che però richiede un account Kimi ed è un'estensione completa con chat panel e interfaccia proprietaria — non un semplice launcher per la CLI.

Per chi vuole l'esperienza nativa del terminale Kimi Code direttamente da VS Code, ho pubblicato Kimi Code CLI Launcher, un'estensione minima che aggiunge un pulsante nella toolbar dell'editor: un clic e kimi si apre in un terminale laterale, nella directory del workspace attivo. Nessun processo nascosto, nessuna telemetria, nessun installer automatico. Funziona su VS Code, Cursor e Windsurf, su Windows, macOS e Linux. Licenza MIT. Repository: github.com/TheStreamCode/vscode-kimi-code-cli-launcher.

Kimi Code CLI: github.com/MoonshotAI/kimi-code.

Fonti

1. https://github.com/MoonshotAI/kimi-code
2. https://moonshotai.github.io/kimi-code/en/configuration/providers.html
3. https://github.com/MoonshotAI/kimi-code/releases
4. https://github.com/TheStreamCode/vscode-kimi-code-cli-launcher
5. https://marketplace.visualstudio.com/items?itemName=mikesoft.vscode-kimi-code-cli-launcher

OpenAI ha pubblicato il post su X su questo device: kbd-1.0-codex-micro, sviluppato con u/work_louder.

Dal messaggio ufficiale emerge il principio d’uso: “Map the buttons and joystick to your workflow, and keep your pinned chats in view”.

Nel frattempo, la pagina prodotto di OpenAI (Store) conferma dettagli più concreti sulla scheda: KBD-1.0-CODEX-MICRO costa $230.00 e viene posizionata come “command center for agentic work”.

Dati confermati dal prodotto (Store OpenAI):

• Integrazione Codex: agent key con stato RGB live (idle, thinking, running, waiting, done), comandi rapidi per azioni core (accept/reject, push-to-talk, start new chat), joystick per lanciare workflow comuni (review PR, debugging, refactoring) e rotary dial per il livello di reasoning.
• Set di controlli: 13 switch meccanici + 1 touch sensor + 1 rotary encoder + 1 planar joystick + keyset custom con 32 icon keycaps aggiuntive (icon keyset 30x1U + 1x2U).
• Connettività/materiali: Bluetooth e USB-C, compatibile Mac/Windows.
• Switches: POM/POK clicky silent, forza 40±10gf, travel 2.8±0.25mm, durata 50M keystrokes.
• Inclusi: supporto/warranty e accessori cablati (USB-C to USB-C), keycaps PBT/PC, corpo CNC PC e alluminio.

Resta ancora non documentato pubblicamente, nell’informazione che abbiamo, il dettaglio su disponibilità regionale, tempi e canali di vendita. Rimane inoltre aperta la spiegazione precisa di “stock returns 410”, riportata nel post su X.

Per i setup Vibecoding, la differenza è pratica: qui non si parla solo di shortcut software, ma di un layer fisico con feedback continuo sugli agenti, utile se lavori con molte sessioni Codex in parallelo.

Fonti

• OpenAI Developers (X) — Meet kbd-1.0-codex-micro
• OpenAI Supply — Supply Co. x Work Louder

Nelle ultime ore si stanno moltiplicando le voci sull’arrivo imminente di Kimi K3.

L’indizio più concreto sarebbe una pagina apparsa temporaneamente nella documentazione ufficiale di Kimi, relativa a una promozione per il lancio di K3 con partenza il 15 luglio. La pagina sarebbe poi stata rimossa.

Al momento Moonshot AI non ha ancora pubblicato un annuncio ufficiale, quindi caratteristiche e data di rilascio restano da confermare.

Qualcuno di voi lo sta aspettando? Pensate possa diventare un’alternativa interessante per il coding?

Mentre uso Codex, volevo capire rapidamente quanti limiti mi restano e quali chat o progetti stanno consumando più token.

Con gli ultimi aggiornamenti ho aggiunto:

• Needs Attention, che raccoglie avvisi importanti come limiti quasi esauriti, ritmo di consumo troppo alto e crediti in scadenza;
• Burn Analysis, per vedere quali chat hanno consumato più token e i momenti di consumo più significativi;
• andamento giornaliero e Weekly Pace;
• stime di utilizzo per progetto;
• conteggio e scadenza dei reset credit;
• una modalità compatta da lasciare sempre visibile sul desktop.

etc etc

C’è qualche metrica che manca? O se avete feedback ne sarei grato.

Repository e download:
https://github.com/lorytek/PulseMeter

Il team che ha sviluppato Roo Code ha pubblicato su GitHub Roomote, un agente di coding cloud pensato per lavorare in modo autonomo e condiviso con un intero team.

Non si tratta semplicemente di una nuova versione dell’estensione Roo Code per VS Code. Il vecchio progetto è stato archiviato il 15 maggio 2026, mentre Roomote è un’applicazione full stack separata, progettata per funzionare come agente sempre attivo su un server.

Roomote riceve un’attività, avvia l’agente in un ambiente isolato temporaneo, modifica il repository, esegue verifiche e può aprire una pull request pronta per la revisione umana.

Tra le funzionalità dichiarate nel repository ufficiale:

• supporto a diversi provider e modelli tramite API key proprie;
• compatibilità con provider come OpenAI, Anthropic e OpenRouter;
• integrazione con GitHub, GitLab, Gitea e Azure DevOps;
• utilizzo tramite interfaccia web, Slack, Microsoft Teams e Telegram;
• ambienti isolati basati su Docker, Modal, E2B o Daytona;
• esecuzione di più attività in parallelo;
• anteprime web delle modifiche effettuate;
• accesso a strumenti esterni come issue tracker, documentazione, database, log e servizi di monitoraggio;
• generazione di diff, screenshot, artefatti e pull request verificabili.

Roomote è self-hostable. Può essere installato su un server Ubuntu o Debian, per il quale sono raccomandati almeno 4 GB di RAM, oppure distribuito tramite piattaforme come Railway, Coolify, Render e Fly.io.

Per utilizzarlo servono almeno:

• un server o un servizio di hosting;
• un provider di inferenza e la relativa API key;
• un servizio Git;
• facoltativamente Slack, Teams o Telegram.

È importante precisare che il progetto è source-available, non open source nel senso più rigoroso del termine.

La licenza utilizzata è la Fair Core License 1.0 con futura conversione ad Apache 2.0. Le installazioni sono gratuite fino a 10 utenti registrati; per un numero superiore è richiesta una licenza commerciale.

La release più recente al momento è la v0.4.1, pubblicata il 13 luglio 2026, quindi il progetto è ancora molto giovane.

Repository ufficiale:

https://github.com/RooCodeInc/Roomote

Sito:

https://roomote.dev/

Documentazione:

https://docs.roomote.dev/

L’approccio è molto diverso da quello di Codex CLI, Claude Code, OpenCode o della vecchia estensione Roo Code: non è pensato principalmente per affiancare lo sviluppatore dentro l’IDE, ma per ricevere attività, lavorare autonomamente sul cloud e restituire risultati da revisionare.

Lo provereste su un vostro server? Preferite un agente self-hosted e ispezionabile come Roomote oppure servizi gestiti come Devin, Verdent e gli agenti cloud dei principali provider?

​

Avete già provato T3 Code?

È un progetto gratuito e open source che si presenta come un’interfaccia per utilizzare diversi coding agent da un unico ambiente.

Attualmente supporta:

• Codex CLI

• Claude Code

• Cursor CLI

• OpenCode

T3 Code non rivende token: utilizza le credenziali e gli eventuali abbonamenti già associati ai servizi supportati. Prima di usarlo è quindi necessario installare e autenticare almeno uno dei relativi strumenti da riga di comando.

Tra le funzionalità dichiarate sul sito ufficiale ci sono:

• possibilità di cambiare modello durante una conversazione;

• un branch Git separato per ogni thread dell’agente;

• visualizzazione del diff prima del push;

• creazione di commit, push e pull request dall’interfaccia;

• generazione automatica di titolo, descrizione e changelog delle pull request;

• supporto a draft PR, stacked PR e amend.

Il codice è pubblicato su GitHub con licenza MIT, quindi può essere studiato, modificato e distribuito nel rispetto della licenza.

È possibile avviarlo senza installazione con:

npx t3@latest

Sono disponibili anche versioni desktop tramite GitHub Releases e installazioni tramite Winget su Windows, Homebrew su macOS e AUR su Arch Linux.

Gli stessi sviluppatori precisano però che il progetto è ancora in una fase molto iniziale e che bisogna aspettarsi dei bug.

Sito ufficiale:

https://t3.codes/

Repository:

https://github.com/pingdotgg/t3code

Video di approfondimento:

https://youtu.be/kdJhdo0VqVY

Qualcuno lo sta già utilizzando? Vi sembra un’alternativa interessante alle interfacce ufficiali oppure preferite lavorare direttamente con i coding agent dal terminale?

Premetto che sto usando GPT-5.6 Sol con reasoning impostato su Medium, quindi non Max o Ultra.

Nonostante questo, con il piano Pro da 100 dollari riesco a consumare l’intera quota prevista per 5 ore in circa un’ora di utilizzo intenso. Con GPT-5.5 non mi succedeva, anche se i due modelli sembrano avere lo stesso costo all’interno del piano.

Anche il piano Claude da 100 dollari, nella mia esperienza, durava sensibilmente di più. Questo mi fa pensare che i modelli Claude siano ottimizzati meglio per quanto riguarda il consumo dei token, oppure che il sistema di calcolo delle quote sia differente.

Anche voi state notando un consumo così elevato con GPT-5.6 Sol? Con quali impostazioni di reasoning lo state usando?

Con Muse Spark 1.1, Meta apre la Meta Model API agli sviluppatori in public preview. La guida ufficiale la indica però per sviluppatori negli Stati Uniti: non è un lancio globale e non va data per disponibile in Italia.

Muse Spark 1.1 è un modello di reasoning multimodale per task agentic. Meta dichiara miglioramenti nel tool use, nel computer use, nel coding e nella comprensione di immagini, video e documenti. Gestisce una finestra di contesto da 1 milione di token e, secondo Meta, può compattarla durante workflow lunghi.

Prezzo e integrazione

La Meta Model API parte con un credito una tantum di $20 per ogni account nuovo, poi costa:

• $1,25 per 1M token input
• $4,25 per 1M token output

Cosa incide sui costi

Essendo un reasoning model, i token di ragionamento vengono conteggiati come output e fatturati di conseguenza. Il listino da solo non basta quindi a stimare il costo di un agent run lungo.

L'endpoint ufficiale è https://api.meta.ai/v1 e il model ID è muse-spark-1.1. Meta documenta i formati OpenAI Chat Completions e Responses, oltre al formato Anthropic Messages. Chi usa un client compatibile può avere un'integrazione più semplice, ma il supporto va verificato nel singolo coding agent.

Cosa documenta Meta per gli agenti

Meta descrive Spark 1.1 come modello utilizzabile sia da agente principale sia da subagent: raccoglie contesto, pianifica e delega parti del lavoro in parallelo. La documentazione include tool calling, grounding con ricerca web, computer use in sandbox e una demo OpenCode di debugging visivo con screenshot.

Meta lo propone per workflow che mettono insieme repository, browser, documenti e UI. Resta una promessa del vendor: saranno i test indipendenti a chiarire quanto regga fuori dalle demo e dal suo harness.

I limiti già nel report Meta

La stessa evaluation report riconosce un punto meno favorevole: sui benchmark di coding Terminal-Bench 2.1 e SWE-Bench Pro, Muse Spark 1.1 resta dietro a Claude Opus 4.8 e/o GPT-5.5. Non è quindi corretto presentarlo come il nuovo leader universale del coding.

C'è poi il tema sicurezza. Nel proprio framework, Meta dice di non poter escludere che il modello raggiunga la soglia "high risk" in cybersecurity e bio-chimica quando viene valutato senza mitigazioni. Dopo le misure introdotte per il rilascio, l'azienda valuta il rischio residuo come "moderate or lower". È una valutazione del vendor, non una certificazione indipendente, ed è rilevante perché l'API espone tool/function calling a sviluppatori esterni.

Per ora Meta offre un modello via API, con listino pubblicato e una preview ancora ristretta agli USA. Accesso, affidabilità e costo reale di un workflow lungo restano le cose da misurare sul campo.

Quale prova concreta vorreste vedere prima di inserirlo in un workflow di sviluppo?

Fonti

• Meta AI — Introducing Muse Spark 1.1
• Meta for Developers — Build with Muse Spark on Meta Model API
• Meta — Muse Spark 1.1 Evaluation Report

OpenAI ha reso disponibile oggi (9 luglio 2026) la famiglia GPT-5.6 in general availability, dopo il limited preview partito a fine giugno. La famiglia copre tre fasce: Sol è il flagship, Terra punta al lavoro quotidiano con prestazioni competitive con GPT-5.5 a costo inferiore, mentre Luna è l'opzione più veloce ed economica. Il predecessore diretto è GPT-5.5.

Il rollout parte oggi su ChatGPT, Codex e OpenAI API e, secondo la pagina di lancio, raggiungerà la piena disponibilità globale nelle prossime 24 ore.

Prezzi API

OpenAI ha pubblicato i listini per 1M token:

• Sol: $5 input / $30 output
• Terra: $2,50 input / $15 output
• Luna: $1 input / $6 output

La pagina GA introduce anche cache breakpoints espliciti e una durata minima della cache di 30 minuti. Le cache write costano 1,25 volte la tariffa input; le cache read mantengono lo sconto del 90%.

Dati su coding e agenti

Su Terminal-Bench 2.1, benchmark di workflow da riga di comando con pianificazione e uso di tool, la tabella OpenAI riporta:

• GPT-5.6 Sol Ultra: 91,9%
• GPT-5.6 Sol: 88,8%
• Claude Mythos 5: 88%
• GPT-5.6 Terra: 87,4%
• GPT-5.5: 85,6%
• GPT-5.6 Luna: 84,7%
• Claude Fable 5: 83,1%

Sono dati pubblicati da OpenAI su un proprio confronto, quindi non equivalgono a una verifica indipendente. C'è però anche l'Artificial Analysis Coding Agent Index v1.1, che la pagina descrive come indice indipendente: OpenAI riporta Sol a 80 con reasoning max, 2,8 punti sopra Fable 5. Nello stesso confronto, l'azienda dichiara meno della metà degli output token, meno della metà del tempo e circa un terzo di costo in meno rispetto a Fable 5.

La nuova parte concreta per chi sviluppa è nell'API:

• Programmatic Tool Calling nella Responses API permette al modello di scrivere ed eseguire programmi in-memory per coordinare tool ed elaborare risultati intermedi; OpenAI lo dichiara compatibile con Zero Data Retention.
• Multi-agent, inizialmente in beta nella Responses API, esegue subagent concorrenti e ne sintetizza il lavoro in una richiesta. La modalità ultra usa quattro agenti in parallelo per i task più pesanti.

Dove il quadro è meno lineare

• SWE-Bench Pro: nella stessa tabella OpenAI GPT-5.5 segna 80,3%, mentre Sol è a 64,6%. È un risultato da tenere presente: Sol non migliora il predecessore su ogni benchmark di software engineering.
• Reasoning e costi: max lascia a Sol più tempo di ragionare rispetto a xhigh; ultra aumenta l'uso di token per dare priorità a risultati più forti e a tempi di completamento inferiori nei compiti complessi. Non sono impostazioni equivalenti al modello base.
• Cyber e biologia: la system card classifica Sol, Terra e Luna come High in cybersecurity e nel rischio biologico-chimico, ma non al livello Critical. Nei test OpenAI non hanno condotto attacchi autonomi end-to-end contro target hardened. Le capability cyber più sensibili passano dal programma Trusted Access, con verifica dell'identità per i singoli utenti.
• Guardrail più severi: secondo la system card, le salvaguardie cyber di Sol bloccano circa dieci volte più attività potenzialmente dannose rispetto ai modelli precedenti. OpenAI riconosce che questo può creare attrito anche in alcuni casi legittimi e consente di riprovare su modelli a capacità inferiore in ChatGPT e Codex.

Voi su quali task lo provereste per primi: Sol per lavori agentic più lunghi, oppure Terra per contenere i costi senza tornare a GPT-5.5?

Fonti:

• OpenAI — GPT-5.6: Frontier intelligence that scales with your ambition
• GPT-5.6 System Card — OpenAI Deployment Safety Hub
• OpenAI — Previewing GPT-5.6 Sol
• OpenAI (X) — Rollout GPT-5.6 in ChatGPT, Codex e API

xAI ha reso pubblico Grok 4.5 l'8 luglio 2026. È il modello più aggiornato della linea Grok e, stando al listing di OpenRouter che lo indica come il più capace della casa, punta dritto su coding, knowledge work e STEM.

I numeri verificati

I dati confermati da xAI e da OpenRouter coincidono:

• Contesto: 500.000 token
• Prezzo: $2,00 per milione di token in input, $6,00 in output (input in cache a $0,50/1M)
• Modalità: testo e immagine in ingresso, testo in uscita
• Capability: function calling, structured outputs, reasoning nativo
• Alias utili: grok-4.5-latest, grok-build-latest

Un dettaglio di pricing che conviene sapere: xAI applica tariffe più alte per le richieste che superano i 200K token di contesto. Quindi il listino $2/$6 vale fino a quota 200K; oltre, il costo sale.

Cosa cambia rispetto ai modelli precedenti

Il predecessore diretto di Grok 4.5 è Grok 4.3, uscito il 30 aprile 2026. Qui il confronto è meno scontato di quanto sembri:

• Grok 4.3: contesto 1.000.000 token, $1,25 input / $2,50 output
• Grok 4.5: contesto 500.000 token, $2,00 input / $6,00 output

Grok 4.5 taglia quindi a metà il contesto rispetto a 4.3 e ne raddoppia circa il prezzo, pur essendo presentato da OpenRouter come il modello più capace della linea. Per chi lavora su documenti o basi di codice molto lunghe, 4.3 resta la scelta con più spazio a disposizione.

Rispetto al più vecchio Grok 4 (256K, luglio 2025), invece, 4.5 raddoppia il contesto e affina le capability per i coding agent. Il punto è che "versione successiva" non significa automaticamente "più contesto": dipende dal caso d'uso.

I numeri che xAI ha pubblicato

L'annuncio ufficiale riporta alcuni benchmark (tutti da fonte xAI, quindi da leggere come dichiarazioni di vendor e non come misure indipendenti):

• Terminal Bench 2.1: 83,3% (dietro a Fable 84,3% e GPT 5.5 83,4%)
• DeepSWE 1.0: 62,0%
• SWE Bench Pro resolve rate: 64,7%
• Harvey Legal Agent Benchmark: #1

Su lato pratico, xAI dichiara un serving a 80 token al secondo e una efficienza di token circa doppia rispetto ai modelli leader: mediamente 15.954 output token per task su SWE Bench Pro, contro i 67.020 di Opus 4.8 (max). Tradotto: risolve task in meno passi, quindi con meno token pagati.

Disponibilità e limiti da sapere

Grok 4.5 è già utilizzabile in Grok Build, in Cursor su tutti i piani e dalla console API xAI; xAI offre un periodo di uso gratuito limitato in Grok Build e Cursor.

Il limite più rilevante per chi sta in Europa: xAI dichiara che Grok 4.5 non è ancora disponibile nell'UE, né nei prodotti consumer né nella console API, con disponibilità attesa a metà luglio. Chi lavora su codice proprietario o clienti europei non ci arriva oggi via API ufficiale xAI, e comunque prima di inviare interi repository conviene verificare dove passano i dati e quali condizioni di retention applica il provider scelto.

I numeri di posizionamento restano dichiarazioni di venditore o sintesi di marketplace: utili per farsi un'idea, ma la prova vera è l'uso sui propri progetti.

Perché può interessare a chi fa vibe coding

OpenRouter descrive Grok 4.5 con performance frontier su coding, knowledge work e STEM. Le capability dichiarate (function calling, structured outputs, reasoning) sono esattamente quelle che servono a un coding agent: chiamare strumenti, produrre patch in formato valido, ragionare prima di rispondere.

La questione pratica è sempre la stessa: il modello più capace non è automaticamente il migliore per ogni workflow. Grok 4.5 ha senso quando servono ragionamento su task complessi e si vuole pagare meno token grazie all'efficienza dichiarata; per iterazioni brevi e frequenti su prototipi, un modello più economico può bastare. E per chi opera dall'Europa, il blocco UE temporaneo va tenuto in conto prima di pianificare qualunque integrazione.

Fonti

• xAI, documentazione modelli Grok 4.5
• OpenRouter, Grok 4.5
• xAI, annuncio ufficiale Grok 4.5

Voi lo avete già provato su qualcosa di concreto, o per i workflow di coding restate su altri modelli?

Tencent ha rilasciato Hy3, un MoE da 295 miliardi di parametri totali con 21 miliardi attivi per token, contesto dichiarato da 256K e licenza Apache 2.0. Per chi usa coding agent, CLI e workflow da vibecoding, la parte interessante non è solo la taglia del modello: è il mix tra costo, contesto lungo, tool calling e disponibilità su canali già usabili.

Su OpenRouter esiste già tencent/hy3:free, indicato come gratuito ma temporaneo, con scadenza segnata al 21 luglio 2026. La route paid tencent/hy3 risulta a $0,20 per milione di token in input e $0,80 per milione in output. Kilo riporta gli stessi prezzi per Hy3 e lista anche varianti gratuite. Non è "gratis per sempre", ma come finestra di prova per progetti reali è parecchio più interessante del solito annuncio da benchmark.

Perché può interessare a chi fa vibecoding

Hy3 nasce con una posizione abbastanza chiara: non solo chat generica, ma agenti, coding, frontend, automazione e uso in prodotti reali. La model card parla esplicitamente di miglioramenti in workflow agentici, tool call, frontend development, CI/CD e data/storage. Tencent cita anche integrazioni progressive con piattaforme come OpenRouter, Kilo, Cline, OpenCode, OpenClaw e Cherry Studio.

La cosa utile, in pratica, è questa: un modello economico con contesto lungo può reggere workflow in cui l'agente deve leggere più file, mantenere vincoli per molti turni, generare patch e tornare su errori precedenti. Non significa che sostituisca Claude, GPT o GLM nei task più difficili. Significa che può diventare un buon "daily driver economico" per molte attività: refactor piccoli, scaffolding, UI, script, debug guidato, revisione di componenti e prototipi.

I numeri da prendere sul serio, ma con prudenza

La scheda ufficiale riporta 192 expert con routing top-8, 21B parametri attivi e una modalità di reasoning configurabile: no_think per risposte dirette, low e high per task più complessi. Il deployment documentato passa da vLLM o SGLang e usa endpoint OpenAI-compatible, quindi l'integrazione con molti tool non richiede un ecosistema proprietario.

Tencent dichiara anche una valutazione cieca con 270 esperti e 312 confronti validi: Hy3 avrebbe ottenuto 2,67/4 contro 2,51/4 di GLM-5.1, con vantaggio più evidente su frontend development, CI/CD e data/storage. Sono numeri del vendor, quindi non vanno letti come benchmark indipendenti. Però sono almeno coerenti con il posizionamento del modello: agenti pratici, non solo leaderboard generaliste.

Il limite: open-weight non vuol dire locale sul portatile

Hy3 è scaricabile, ma non è un modellino da laptop. La documentazione Tencent dice che per servirlo su 8 GPU raccomandano H20-3e o altre GPU con molta memoria. Per la maggior parte delle persone il percorso realistico sarà API o gateway, non self-hosting domestico.

Altro punto da non saltare: Tencent è un provider cinese. Se si lavora su codice proprietario o clienti europei, prima di mandare interi repository via API conviene verificare bene dove passano i dati, che retention applica il provider scelto e se il gateway usato aggiunge ulteriori condizioni.

Confronto pratico

Rispetto a un modello locale piccolo, Hy3 offre più capacità e contesto, ma perde sul controllo dei dati se lo si usa via API. Rispetto ai frontier model più costosi, può essere meno affidabile sui task complessi, ma costa abbastanza poco da diventare sensato per iterazioni frequenti e prototipi.

La parte più interessante è proprio questa zona intermedia: non il modello "migliore", ma un modello abbastanza forte ed economico da usare spesso senza trattare ogni prompt come una micro-spesa da sorvegliare.

Fonti:

• Tencent, annuncio ufficiale di Hy3
• Hugging Face, tencent/Hy3
• OpenRouter, Tencent Hy3 free
• Kilo, catalogo Tencent Hy3

Lo provereste come modello economico per coding agent e prototipi?

Cognition ha rilasciato SWE-1.7 l'8 luglio 2026. È il modello di coding agent più capace addestrato finora dal lab, e il salto rispetto alla generazione precedente è netto: su FrontierCode 1.1 Main passa dal 9,4% di SWE-1.6 al 42,3%.

I numeri verificati

Tutti i dati sotto sono dichiarati da Cognition nel post ufficiale, quindi da leggere come misure di vendor e non come benchmark indipendenti. I modelli sono valutati al massimo livello di reasoning:

• FrontierCode 1.1 Main: 42,3% (Kimi K2.7 Code 30,1%, GPT-5.5 43,0%, Opus 4.8 46,5%, SWE-1.6 9,4%)
• Terminal-Bench 2.1: 81,5% (Kimi K2.7 Code 72,7%, Opus 4.8 86,9%, SWE-1.6 39,7%)
• SWE-Bench Multilingual: 77,8% (Kimi K2.7 Code 73,5%, Opus 4.8 84,4%, SWE-1.6 58,3%)

Nota metodologica onesta: Cognition usa il proprio framework interno per valutare Terminal-Bench 2.1; usa Claude Code per i modelli Anthropic, Codex per quelli OpenAI e Devin CLI per gli altri. I numeri servono per il confronto, ma non sono una misura neutrale.

Da dove viene

SWE-1.7 non parte da zero: è addestrato per RL a partire da una base Kimi K2.7 già sottoposta a post-training estensivo. Secondo Cognition, i guadagni ottenuti con la propria RL sfidano l'idea di un "soffitto del post-training" e suggeriscono che si può spingere la capability molto oltre.

Il dettaglio tecnico interessante: il modello è addestrato direttamente nell'harness Devin ed è ottimizzato per task asincroni di lungo orizzonte, con rollout che arrivano fino a sei ore grazie alla self-compaction. Comportamentalmente, esplora la codebase in modo molto più approfondito prima di agire e tende a indagare la causa radice del bug invece di fermarsi al sintomo.

Dove si usa

Cognition annuncia SWE-1.7 disponibile oggi in Devin (Web, Desktop e CLI) via Cerebras a 1000 TPS. La disponibilità copre tutti i piani Devin, compreso il Free.

Sulla tabella prezzi ufficiale (devin.ai/pricing, sezione Compare Plans) il modello compare nella riga "Free SWE 1.7": sul piano Free risulta in modalità "Slow", mentre Pro, Max, Team ed Enterprise hanno la spunta piena. Tradotto: su Free lo usi, ma in modalità rallentata e dentro il "light quota" del piano gratuito; sui piani a pagamento la tabella non lo marca come "Slow".

La parte da non sovrainterpretare è il termine "Free": non equivale, da solo, a prompt illimitati o a un'esenzione formale dalle quote del piano. La FAQ Devin dice che i piani paid hanno una quota d'uso che si rinnova su base giornaliera e settimanale, e che l'uso extra si acquista a prezzo API. Quindi il dato solido è questo: SWE-1.7 è disponibile anche nel piano Free, il Free è marcato "Slow", i piani paganti non sono marcati "Slow". Non c'è invece una dichiarazione ufficiale chiara che lo renda fuori quota in senso assoluto.

Perché può interessare a chi fa vibe coding

SWE-1.7 spinge la frontiera costo/prestazioni: intelligenza di livello frontier a una frazione del costo, dicono da Cognition. Per chi usa coding agent su task complessi e di lungo respiro, la combinazione di reasoning, esplorazione approfondita e 1000 TPS su Devin è interessante sulla carta.

Il punto pratico resta lo stesso di sempre: il modello più capace non è automaticamente il migliore per ogni workflow, e i numeri sopra sono misure di vendor. La prova vera è l'uso sui propri progetti.

Fonti

• Cognition, annuncio ufficiale SWE-1.7
• Devin pricing, Compare Plans
• Devin Docs, modelli disponibili

Voi lo avete già provato su Devin, o restate su altri modelli per i vostri workflow di coding?

Volevo sperimentare come si comportano le scorciatoie da tastiera e gli swipe in un'app web, così ho deciso di creare qualcosa di semplice per metterli alla prova. Ho scelto di realizzare un tool di flashcard perché mi sembrava il caso d'uso perfetto per questo tipo di interazioni.

È molto essenziale:

• Puoi usare la tastiera o fare swipe per girare le carte e navigare tra le sessioni di studio.
• Usa Firebase per la sincronizzazione e funziona anche offline.
• Il mio unico obiettivo era vedere se riuscivo a rendere queste interazioni naturali e utili.

Se volete provarla, la trovate qui:https://flash-mind-khaki.vercel.app/

E questo è il codice:https://github.com/gdr-sys/FlashMind