In den Settings wird festgelegt, welche KI-Provider AITM verwendet, wie sich jeder Pipeline-Schritt verhält und wie die App ihre eigenen Ressourcen und ihre Zuverlässigkeit verwaltet.

Settings

Hauptbereiche

  • Projects & Memory — Tabs, Projekte und dauerhafte Anweisungen für die KI.
  • AI & Models — Standard-Provider und -Modelle für die Pipeline, Chat und Brainstorm.
  • AI Providers — eine Karte pro Provider: Claude, Gemini, DeepSeek, OpenAI, NVIDIA, Ollama und Web Chat (Playwright).
  • Pipeline — maximale Wiederholungen, Turn-Obergrenzen, Budgets des Merge-Agents, Max concurrently running tasks, parallele Tasks pro Tab, Kontextweitergabe (Continue / Handoff), Global Projects.md path (eine Anweisungsdatei, die in die Pipeline jedes Projekts eingespeist wird), Schalter für vollständige Tests, automatische Reparaturversuche nach dem Merge.
  • Skills — wiederverwendbare Konventionskarten für die KI.
  • Design Patterns — bevorzugte Entwurfsmuster für generierten Code.
  • Response Style — Ton und Format der KI-Antworten.
  • Watchdog & Resources — Aufbewahrung des Disk Janitor, GB-Budgets des Disk Watchdog, CPU-/RAM-Reservierungen für Tests.
  • Limits — Token- und Größenobergrenzen für die Contract-Einspeisung, Dokumentationsindizierung und Übersetzungsblöcke.
  • Git & Storage — Push-Remote, Neustart nach Self-Merge, Backups.
  • Editor — Verhalten des integrierten Code-Editors.
  • Appearance — Theme und Layout des Dashboards.
  • Font & Style — Einstellungen zu Typografie und Gestaltung.
  • DOM Coverage — erfasste UI-Element-Abdeckung für Frontend-Projekte.
  • System — Swap-Größe, reservierte CPU-Threads, Tag-/Nacht-CPU-Profile, Tmp-Sweeper, erlaubte CORS-Origins.
  • Project Check — Gesundheitsprüfungen des Projekts.
  • License — Lizenzaktivierung und Projekt-Slots.
  • Release Manager — Release-Verwaltung und Synchronisierung.
  • Shortcuts — Tastenkürzel des Dashboards.
  • Languages & Translation — Oberflächensprache, Übersetzung von UI-Texten und von Task-Inhalten.

Die Settings werden über die Schaltfläche Settings in der Kopfzeile geöffnet; alle 20 Tabs stehen in einer Reihe oben im Panel Configuration, in der oben aufgeführten Reihenfolge. Projektspezifische Überschreibungen (Modell, E2E-Fehlermodus, Verify-Richtlinie, Umgebungsvariablen) befinden sich in der eigenen Karte des Projekts unter Projects & Memory und haben immer Vorrang vor dem globalen Wert.

Die vollständige Checkliste der Pflichtschritte vor Arbeitsbeginn steht unter Setup Essentials.

KI-Provider und API-Schlüssel

Der Tab AI Providers hat eine Karte pro Provider — mit einem Kontrollkästchen Enabled, einer Statusanzeige (Active / Not configured), dem API-Schlüssel oder der Adresse mit einer Schaltfläche Test, dem Standardmodell sowie Turn-Limits und Timeouts. Es können mehrere Provider konfiguriert und über die Pipeline-Schritte hinweg gemischt werden.

  • Claude — Modelle von Anthropic; der Standard-Provider. Funktioniert über das lokal angemeldete Claude CLI oder einen API-Schlüssel; die Karte bietet außerdem einen OAuth-Login für Docker-/Headless-Server.
  • Gemini — Modelle von Google, API-Schlüssel.
  • DeepSeek — Modelle von DeepSeek, API-Schlüssel.
  • OpenAI — GPT-Modelle von OpenAI, API-Schlüssel.
  • NVIDIA — offene Modelle, die von NVIDIA gehostet werden, API-Schlüssel.
  • Ollama — selbst gehostete Modelle (oder Ollama Cloud). Statt eines Schlüssels wird eine Base URL eingetragen; der API-Schlüssel ist optional.
  • Web Chat (Playwright) — steuert den Web-Chat eines Providers in einem automatisierten Browser, ohne API-Schlüssel. Er kann keine Tools verwenden und keine Agent-Schritte ausführen und eignet sich daher nur für einfache Unterhaltungen.
Settings → AI Providers
Der Tab AI Providers — eine Karte pro Provider.

Modellkonfiguration pro Schritt und Kostenoptimierung

Der Tab AI & Models legt den globalen Standard-Provider und das Standardmodell fest sowie die separaten Modelle für Chat, Brainstorm, den Guide und Task-Zusammenfassungen. Darunter folgt die Tabelle pro Schritt für Branch, Architect, Code, Compliance-check, Review, Fix, Test, E2E, Snapshot und Docs. Dort werden, soweit zutreffend, Model, Provider, Max Turns und Max Runtime (min) festgelegt. Zu den sieben Standard-KI-Schritten kommt Compliance-check hinzu, der nur bei komplexen Tasks eine isolierte KI-Prüfung ausführt. Branch und Snapshot sind Automatisierung; Verify und Chain-audit haben keine Modellzeile. Hier liegt der Schlüssel zur Kostenkontrolle: teure Modelle mit hoher Reasoning-Leistung werden auf die Schritte gerichtet, die Urteilsvermögen brauchen — typischerweise Architect — und günstigere oder lokale Modelle auf überwiegend mechanische Schritte wie das Ausführen von Tests.

Settings → AI & Models
Der Tab AI & Models mit der Modelltabelle pro Schritt.

Turn-Limits (maxTurns)

Ein Turn entspricht grob einem Denk-/Handlungsschritt eines Agents — eine Datei lesen, eine Datei bearbeiten, einen Befehl ausführen. Mehr Turns bedeuten im Allgemeinen einen gründlicheren Versuch, auf Kosten von mehr Zeit und (bei kostenpflichtigen Providern) höheren Kosten. Eine globale Obergrenze begrenzt, wie hoch das Turn-Limit eines einzelnen Schritts gesetzt werden kann, als Sicherheitsnetz gegen einen falsch konfigurierten oder außer Kontrolle geratenen Task, der unbegrenzt Ressourcen verbraucht.

Umschalter API | WEB

Die Panels Chat und Brainstorm haben einen Umschalter API | WEB: Im API-Modus wird die programmatische API des Providers mit dem konfigurierten Schlüssel aufgerufen; im WEB-Modus wird dieselbe Unterhaltung in der Web-Chat-Oberfläche des Providers selbst geöffnet (z. B. Claude.ai), für Nutzer mit Web-Abonnement, die den API-Zugang nicht separat bezahlen möchten.

Watchdog-Timeouts und Zuverlässigkeits-Presets

Hier wird festgelegt, wie lange ein Schritt laufen darf, bevor der Watchdog ihn als hängend betrachtet, und es wird ein Zuverlässigkeits-Preset gewählt, das Geschwindigkeit gegen die Aggressivität abwägt, mit der AITM fehlgeschlagene oder hängende Schritte wiederholt.

Ressourcenüberwachung und Nebenläufigkeit

AITM zeigt die aktuelle CPU-/Speicherauslastung live an. Wie viele Tasks gleichzeitig laufen, wird unter Settings → Pipeline → Max concurrently running tasks festgelegt und hängt von CPU und Speicher des Rechners ab. Dies ist nicht mit den Lizenz-Slots zu verwechseln: Ein Slot ist ein Projekt unter der Lizenz, kein laufender Task — siehe Lizenzierung.

Settings → Pipeline
Der Tab Pipeline — Wiederholungen, Task-Nebenläufigkeit, Kontextweitergabe und Global Projects.md path.

Tab Project Check

Die Self-Check-Diagnosen, die früher direkt in der Hauptansicht der Settings liefen, befinden sich jetzt in einem eigenen Tab Project Check. Damit lässt sich die Gesundheit eines Projekts prüfen — Git-Status, Worktree-Zustand, Datenbankintegrität und weitere Vorabprüfungen —, ohne die Hauptansicht der Settings zu überladen. Der Tab Project Check sollte geöffnet werden, wenn ein Pipeline-Task unerwartet fehlschlägt oder bevor ein großer Stapel von Tasks gestartet wird, um zunächst zu bestätigen, dass sich das Projekt in einem sauberen, funktionierenden Zustand befindet.

Tag-/Nacht-CPU-Profile und Core-Reservierung

In den Settings lassen sich getrennte Tag- und Nacht-CPU-Profile definieren, sodass AITM je nach Tageszeit automatisch drosselt oder freigibt, wie viel CPU Pipeline-Subprozesse nutzen dürfen — zum Beispiel zurückhaltend während der Arbeitszeit und mit voller Geschwindigkeit über Nacht. Das CPU-Kontingent jedes Profils wird für Subprozesse per AllowedCPUs-Eingrenzung durchgesetzt, sodass Pipeline-Arbeit nicht auf Kerne übergreifen kann, die anderweitig reserviert bleiben sollen. AITM reserviert außerdem dynamisch einen oder mehrere CPU-Kerne für den eigenen Kernprozess (über AllowedCPUs von systemd) und stellt damit sicher, dass der AITM-Server selbst reaktionsfähig bleibt, auch wenn Pipeline-Subprozesse den Rest der Maschine voll auslasten.

Verwaltung der Swap-Größe

Builds und Tests können kurze, starke Speicherspitzen erzeugen. Der Tab System zeigt deshalb die aktuelle Swap-Größe und -Nutzung sowie eine empfohlene Größe an, die aus dem gesamten RAM und dem freien Speicherplatz berechnet wird. Die Empfehlung wird mit einem Klick übernommen (Use recommendation), oder es wird eine eigene Zielgröße eingegeben; der Wert wird sofort gespeichert. Apply ändert die Swap-Größe auf die Zielgröße und zeigt den Fortschritt an. Die Schaltfläche ist aktiviert, wenn AITM auf diesem Host die Swap-Größe ändern kann; andernfalls bleibt sie deaktiviert, und das Panel zeigt die genauen sudo-Befehle an, die von Hand auszuführen sind (und, falls nur eine Berechtigung fehlt, die Zeile, die hinzuzufügen ist, damit Apply beim nächsten Mal funktioniert).

Settings → System
Der Tab System — Swap, reservierte CPU-Threads, Tag-/Nacht-Profile und CORS.

Erlaubte CORS-Origins

Wird das Dashboard von einem anderen Rechner unter einem Hostnamen geöffnet, muss die Adresse (Origin) des Browsers erlaubt sein. localhost und private LAN-Adressen sind immer automatisch erlaubt. Für alles andere hat der Tab System das Feld CORS Allowed Origins — exakte Adressen wie http://myhost:3333, eine pro Zeile — sowie CORS Allowed Origin Patterns für Hostnamen mit Platzhaltern wie *.local oder 192.168.1.*. Damit eine Änderung wirksam wird, muss AITM neu gestartet werden.

Schriftgröße in Tabellen

Font & Style enthält Schieberegler für die Schriftgrößen der Anwendung — die allgemeine Größe der App-Oberfläche, Modal-Inhalte, die Ausgabe von Chat und Brainstorm sowie das Dev Panel. Der Regler Table font (row text) legt die Größe des Zeilentextes von Tabellen im gesamten Dashboard fest; die Größen von Kopfzeilen und Schaltflächen in Tabellen folgen ihm automatisch. Reset all to defaults setzt alles zurück, und das gesamte Erscheinungsbild kann exportiert und importiert werden.

Languages & Translation

  • Interface language — Primary language (AI communication) ist die Sprache, in der AITM mit der KI kommuniziert; Secondary language (display) ist die Sprache, in der gelesen und geschrieben wird. Weitere Sprachen lassen sich per Code hinzufügen. Die Programmiersprache ist immer Englisch.
  • UI text translation — welcher KI-Provider und welches Modell Oberflächentexte übersetzen, eine Schaltfläche Test connection, ein Timeout, die Option Translate my messages to primary language before sending, der Language Mode und Edit translations zum Korrigieren einzelner Texte.
  • Content translation — Target Languages für Task-Inhalte, eine Default Response Language, Translation Timing (sofort nach Abschluss eines Tasks oder auf Anforderung), Task Detail Auto-Translate, der Aufrufmodus (Direct API oder CLI), der verwendete Provider und das Modell sowie Translate Archive, um alle archivierten Tasks des aktuellen Projekts in einem Durchgang zu übersetzen (das kann viel KI-Guthaben verbrauchen).
Settings → Languages & Translation
Der Tab Languages & Translation.

KI-Übersetzung für sekundäre Sprachen

Wird eine sekundäre UI-/Hilfesprache hinzugefügt, die noch nicht vollständig unterstützt wird, bieten die Settings eine Schaltfläche AI-translate, die fehlende UI- und Hilfetexte mit dem konfigurierten Übersetzungsmodell maschinell in diese Sprache übersetzt, statt sie leer zu lassen oder auf Englisch zurückzufallen. Eine ergänzende Prüfung Test connection erlaubt es zu verifizieren, dass das konfigurierte Übersetzungsmodell erreichbar ist und korrekt antwortet, bevor der gesamte Textbestand übersetzt wird — ein falscher API-Schlüssel oder ein nicht erreichbarer Endpunkt fällt so sofort auf, statt erst nachdem ein großer Übersetzungslauf fehlgeschlagen ist.

Paginierter Übersetzungseditor mit Suche

Der Übersetzungseditor für UI-/Hilfetexte ist jetzt paginiert, sodass auch große Textbestände schnell und handhabbar bleiben, statt alle Zeilen auf einmal darzustellen. Ein Suchfeld über der englischen (EN) Spalte erlaubt es, die gewünschte Zeile zum Bearbeiten oder Prüfen schnell zu finden, indem ein Teil des englischen Originaltexts eingegeben wird, statt durch Seiten von Übersetzungen zu blättern.

Backup und projektspezifische Überschreibungen

Die AITM-Konfiguration und der Task-Verlauf lassen sich sichern, und globale Einstellungen (Modelle, Timeouts, Zuverlässigkeit) können pro Projekt überschrieben werden, wenn ein Projekt anders behandelt werden soll als die übrigen.

Gut zu wissen

  • Das leistungsfähigste Modell gehört auf Architect und Review — diese Schritte profitieren am meisten von starkem Reasoning.
  • Für Test-/E2E-Schritte, bei denen die Arbeit überwiegend mechanische Ausführung statt Urteilsvermögen ist, genügt ein günstiges oder lokales Modell.
  • Hat ein Projekt besondere Anforderungen (sehr große Codebasis, strengere Tests), wird eine projektspezifische Überschreibung verwendet, statt die globalen Standardwerte zu ändern.