Settings è il punto in cui si configurano i provider AI utilizzati da AITM, il comportamento di ogni passo della Pipeline e il modo in cui l'app gestisce le proprie risorse e la propria affidabilità.

Settings

Sezioni principali

  • Projects & Memory — schede, progetti e istruzioni permanenti per l'AI.
  • AI & Models — provider e modelli predefiniti per la Pipeline, Chat e Brainstorm.
  • AI Providers — una scheda per ogni provider: Claude, Gemini, DeepSeek, OpenAI, NVIDIA, Ollama e Web Chat (Playwright).
  • Pipeline — numero massimo di tentativi, limiti di turni, budget del merge agent, Max concurrently running tasks, Task paralleli per scheda, passaggio del contesto (Continue / Handoff), Global Projects.md path (un unico file di istruzioni inserito nella Pipeline di ogni progetto), interruttore dei test completi, tentativi di correzione automatica dopo il merge.
  • Skills — schede di convenzioni riutilizzabili per l'AI.
  • Design Patterns — design pattern preferiti per il codice generato.
  • Response Style — tono e formato delle risposte dell'AI.
  • Watchdog & Resources — conservazione del Disk Janitor, budget in GB del Disk Watchdog, riserve di CPU/RAM per i test.
  • Limits — limiti di token e dimensione per l'inserimento dei contratti, l'indicizzazione della documentazione e i blocchi di traduzione.
  • Git & Storage — remote di push, riavvio dopo il self-merge, backup.
  • Editor — comportamento dell'editor di codice integrato.
  • Appearance — tema e layout del Dashboard.
  • Font & Style — preferenze di tipografia e stile.
  • DOM Coverage — copertura degli elementi UI tracciati per i progetti frontend.
  • System — dimensione dello swap, thread CPU riservati, profili CPU diurno/notturno, tmp sweeper, origini CORS consentite.
  • Project Check — controlli sullo stato di salute del progetto.
  • License — attivazione della licenza e slot di progetto.
  • Release Manager — gestione e sincronizzazione delle release.
  • Shortcuts — scorciatoie da tastiera del Dashboard.
  • Languages & Translation — lingua dell'interfaccia, traduzione dei testi UI e traduzione del contenuto dei Task.

Settings si apre con il pulsante Settings nell'intestazione; tutte le 20 schede si trovano su un'unica riga in alto nel pannello Configuration, nell'ordine indicato sopra. Le sovrascritture per singolo progetto (modello, modalità di errore e2e, policy di verifica, variabili d'ambiente) si trovano nella scheda del progetto stesso in Projects & Memory e prevalgono sempre sul valore globale.

Per l'elenco completo delle operazioni obbligatorie prima di iniziare a lavorare, vedere Setup Essentials.

Provider AI e chiavi API

La scheda AI Providers contiene una scheda per ogni provider — con una casella Enabled, un'etichetta di stato (Active / Not configured), la chiave API o l'indirizzo con un pulsante Test, il modello predefinito, i limiti di turni e i timeout. È possibile configurare più provider e combinarli tra i diversi passi della Pipeline.

  • Claude — i modelli di Anthropic; è il provider predefinito. Funziona tramite la CLI di Claude con accesso effettuato in locale oppure tramite chiave API; la scheda offre anche un login OAuth per server Docker/headless.
  • Gemini — i modelli di Google, chiave API.
  • DeepSeek — i modelli di DeepSeek, chiave API.
  • OpenAI — i modelli GPT di OpenAI, chiave API.
  • NVIDIA — modelli aperti ospitati da NVIDIA, chiave API.
  • Ollama — modelli ospitati in proprio (oppure Ollama Cloud). Al posto della chiave si inserisce una Base URL; la chiave API è facoltativa.
  • Web Chat (Playwright) — controlla la chat web di un provider in un browser automatizzato, senza chiave API. Non può usare strumenti né eseguire passi di Agent, quindi è adatta solo a conversazioni semplici.
Settings → AI Providers
La scheda AI Providers — una scheda per ogni provider.

Configurazione del modello per singolo passo e ottimizzazione dei costi

La scheda AI & Models imposta il provider e il modello predefiniti globali, nonché i modelli separati usati da Chat, Brainstorm, dalla guida e dai riepiloghi dei Task. Sotto si trova la tabella per passo per Branch, Architect, Code, Compliance-check, Review, Fix, Test, E2E, Snapshot e Docs. Dove applicabile, si impostano Model, Provider, Max Turns e Max Runtime (min). Ai sette passi AI standard si aggiunge Compliance-check, che esegue un controllo AI isolato solo per i Task complessi. Branch e Snapshot sono automazioni; Verify e Chain-audit non hanno una riga del modello. Qui sta la chiave per controllare i costi: assegnare i modelli costosi e ad alto ragionamento ai passi che richiedono giudizio — in genere Architect — e instradare modelli più economici o locali verso i passi in gran parte meccanici, come l'esecuzione dei test.

Settings → AI & Models
La scheda AI & Models con la tabella dei modelli per passo.

Limiti di turni (maxTurns)

Un turno corrisponde grosso modo a un passo di ragionamento/azione di un Agent — leggere un file, modificarlo, eseguire un comando. Più turni significano in genere un tentativo più accurato, a costo di più tempo e (per i provider a pagamento) di più denaro. Un limite globale stabilisce fino a che valore si può impostare il limite di turni di un singolo passo, come rete di sicurezza contro un Task configurato male o fuori controllo che consumi risorse senza limite.

Interruttore API | WEB

I pannelli Chat e Brainstorm hanno un interruttore API | WEB: la modalità API chiama l'API programmatica del provider usando la chiave configurata; la modalità WEB apre la stessa conversazione nell'interfaccia di chat web del provider (ad es. Claude.ai), per chi ha un abbonamento web e non vuole pagare separatamente l'accesso API.

Timeout del Watchdog e preset di affidabilità

Si configura per quanto tempo un passo può restare in esecuzione prima che il Watchdog lo consideri bloccato, e si sceglie un preset di affidabilità che bilancia la velocità rispetto all'aggressività con cui AITM ritenta i passi falliti o bloccati.

Monitoraggio delle risorse e concorrenza

AITM mostra in tempo reale l'utilizzo di CPU/memoria. Il numero di Task eseguiti contemporaneamente si imposta in Settings → Pipeline → Max concurrently running tasks e dipende da CPU e memoria della macchina. Da non confondere con gli slot della licenza: uno slot è un progetto coperto dalla licenza, non un Task in esecuzione — vedere Licensing.

Settings → Pipeline
La scheda Pipeline — tentativi, concorrenza dei Task, passaggio del contesto e Global Projects.md path.

Scheda Project Check

La diagnostica Self-Check che prima veniva eseguita direttamente nella vista principale di Settings ora si trova in una scheda dedicata, Project Check. Serve a verificare lo stato di salute di un progetto — stato di git, stato dei Worktree, integrità del database e altri controlli preliminari — senza appesantire la schermata principale di Settings. Conviene aprire la scheda Project Check ogni volta che un Task della Pipeline fallisce in modo inatteso, oppure prima di avviare un grande lotto di Task, per accertarsi che il progetto sia in uno stato pulito e funzionante.

Profili CPU diurno/notturno e riserva di core

Settings consente di definire profili CPU separati per il giorno e la notte, così che AITM limiti o liberi automaticamente la quantità di CPU utilizzabile dai sottoprocessi della Pipeline in base all'ora — ad esempio restando prudente durante l'orario di lavoro e andando a piena velocità di notte. La quota di CPU di ciascun profilo viene applicata ai sottoprocessi tramite il confinamento AllowedCPUs, in modo che il lavoro della Pipeline non invada i core che si desidera riservare ad altri usi. AITM riserva inoltre in modo dinamico uno o più core CPU per il proprio processo principale (tramite AllowedCPUs di systemd), garantendo che il server AITM resti reattivo anche quando i sottoprocessi della Pipeline saturano il resto della macchina.

Gestione della dimensione dello swap

Build e test possono generare brevi ma intensi picchi di memoria. La scheda System mostra quindi la dimensione e l'utilizzo attuali dello swap e una dimensione raccomandata, calcolata in base alla RAM totale e allo spazio libero su disco. La raccomandazione si accetta con un clic (Use recommendation) oppure si digita una dimensione obiettivo personalizzata; il valore viene salvato immediatamente. Apply ridimensiona lo swap alla dimensione obiettivo e mostra l'avanzamento. Il pulsante è abilitato quando AITM è in grado di ridimensionare lo swap su questo host; in caso contrario resta disabilitato e il pannello mostra i comandi sudo esatti da eseguire manualmente (e, se manca soltanto un permesso, la riga da aggiungere affinché Apply funzioni la volta successiva).

Settings → System
La scheda System — swap, thread CPU riservati, profili diurno/notturno e CORS.

Origini CORS consentite

Se il Dashboard viene aperto da un'altra macchina tramite un nome host, l'indirizzo del browser (origine) deve essere consentito. localhost e gli indirizzi LAN privati sono sempre consentiti automaticamente. Per tutto il resto, la scheda System offre CORS Allowed Origins — indirizzi esatti come http://myhost:3333, uno per riga — e CORS Allowed Origin Patterns per nomi host con caratteri jolly come *.local o 192.168.1.*. Per rendere effettiva una modifica occorre riavviare AITM.

Dimensione del carattere delle tabelle

Font & Style contiene cursori per le dimensioni dei caratteri dell'applicazione — la dimensione generale dell'interfaccia, il contenuto dei modali, l'output di Chat e Brainstorm e il Dev Panel. Il cursore Table font (row text) imposta la dimensione del testo delle righe nelle tabelle di tutto il Dashboard; le dimensioni di intestazioni e pulsanti nelle tabelle lo seguono automaticamente. Reset all to defaults ripristina tutto ed è possibile esportare e importare l'intera configurazione dell'aspetto.

Languages & Translation

  • Interface language — Primary language (AI communication) è la lingua in cui AITM dialoga con l'AI; Secondary language (display) è la lingua in cui si legge e si scrive. È possibile aggiungere altre lingue tramite codice. Il linguaggio di programmazione è sempre l'inglese.
  • UI text translation — quale provider e modello AI traducono i testi dell'interfaccia, un pulsante Test connection, un timeout, l'opzione Translate my messages to primary language before sending, il Language Mode e Edit translations per correggere singoli testi.
  • Content translation — Target Languages per il contenuto dei Task, una Default Response Language, Translation Timing (subito al termine di un Task oppure su richiesta), Task Detail Auto-Translate, la modalità di chiamata (Direct API o CLI), il provider e il modello utilizzati e Translate Archive per tradurre in un'unica operazione tutti i Task archiviati del progetto corrente (può consumare molto credito AI).
Settings → Languages & Translation
La scheda Languages & Translation.

AI-translate per le lingue secondarie

Se si aggiunge una lingua secondaria per l'interfaccia/la guida non ancora completamente supportata, Settings offre un pulsante AI-translate che traduce automaticamente in quella lingua i testi mancanti di interfaccia e guida usando il modello di traduzione configurato, invece di lasciarli vuoti o di ricadere sull'inglese. Una verifica complementare, Test connection, permette di controllare che il modello di traduzione configurato sia raggiungibile e risponda correttamente prima di impegnarsi a tradurre l'intero insieme di stringhe — individuando subito una chiave API errata o un endpoint non raggiungibile, anziché dopo il fallimento di una lunga esecuzione di traduzione.

Editor di traduzione paginato con ricerca

L'editor di traduzione delle stringhe di interfaccia/guida è ora paginato, in modo che anche grandi insiemi di stringhe restino veloci e gestibili invece di mostrare tutte le righe insieme. Una casella di ricerca sulla colonna inglese (EN) consente di trovare rapidamente la riga da modificare o verificare digitando parte del testo inglese originale, senza scorrere pagine di traduzioni.

Backup e sovrascritture per progetto

Consente di eseguire il backup della configurazione di AITM e della cronologia dei Task, e di sovrascrivere le impostazioni globali (modelli, timeout, affidabilità) per singolo progetto quando uno di essi richiede un trattamento diverso dagli altri.

Suggerimenti

  • Assegnare il modello più capace ad Architect e Review — sono i passi che traggono maggior vantaggio da un ragionamento solido.
  • Usare un modello economico o locale per i passi Test/E2E, dove il lavoro è soprattutto esecuzione meccanica e non giudizio.
  • Se un progetto ha esigenze particolari (codebase molto grande, test più rigorosi), usare una sovrascrittura per progetto invece di modificare i valori predefiniti globali.