Settings is where you configure which AI providers AITM uses, how each pipeline step behaves, and how the app manages its own resources and reliability.
Settings
Main sections
- Projects & Memory — tabs, projects, and permanent instructions for the AI.
- AI & Models — default provider and models for the pipeline, Chat, and Brainstorm.
- AI Providers — API keys and login for Claude, Gemini, OpenAI, DeepSeek, Ollama.
- Pipeline — retry limits, task concurrency, Continue/Handoff Context.
- Skills — reusable convention cards for the AI.
- Design Patterns — preferred design patterns for generated code.
- Response Style — tone and format of AI responses.
- Watchdog & Resources — Disk Janitor, Disk Watchdog, and resource limits.
- Limits — turn limits and other pipeline caps.
- Git & Storage — push remote, restart after self-merge, backups.
- Editor — behaviour of the built-in code editor.
- Appearance — dashboard theme and layout.
- Font & Style — typography and styling preferences.
- DOM Coverage — tracked UI element coverage for frontend projects.
- Project Check — project health checks.
- System — swap, reserved CPU threads, day/night profiles.
- License — licence activation and project slots.
- Release Manager — release management and sync.
- Shortcuts — dashboard keyboard shortcuts.
- Languages & Translation — UI language and AI output language.
For the full must-do checklist before you start working, see Setup Essentials.
AI providers and API keys
Add API keys for the AI providers you want to use — Claude, Gemini, OpenAI, DeepSeek, NVIDIA, or a local Ollama model. You can configure more than one provider and mix them across different pipeline steps.
Per-step model configuration and cost optimization
Each of the 9 pipeline steps can use a different provider, model, and max-turns limit. This is the key to controlling cost: point expensive, high-reasoning models at the steps that need judgment — typically Architect — and route cheaper or local models to steps that are mostly mechanical, like running tests. You don't have to pay frontier-model prices for every step of every task.
Turn limits (maxTurns)
A turn is roughly one step of an agent thinking/acting — reading a file, editing a file, running a command. More turns generally mean a more thorough attempt, at the cost of more time and (for paid providers) more cost. A global ceiling caps how high any single step's turn limit can be set, as a safety net against a misconfigured or runaway task consuming unbounded resources.
API | WEB toggle
The Chat and Brainstorm panels have an API | WEB toggle: API mode calls the provider's programmatic API using your configured key; WEB mode opens the same conversation in the provider's own web chat UI (e.g. Claude.ai), for web-subscription users who don't want to pay for API access separately.
Watchdog timeouts and reliability presets
Configure how long a step can run before the watchdog considers it stuck, and choose a reliability preset that trades off speed against how aggressively AITM retries failed or stuck steps.
Resource monitoring and slots
AITM shows live CPU/memory usage and lets you cap how many pipelines can run concurrently ("slots"), so you can run several tasks in parallel without overwhelming your machine.
Project Check tab
The Self-Check diagnostics that used to run inline on the main Settings view now live in their own dedicated Project Check tab. Use it to verify a project's health — git status, worktree state, database integrity, and other pre-flight checks — without cluttering the main Settings screen. Open the Project Check tab whenever a pipeline task fails unexpectedly or before kicking off a large batch of tasks, to confirm the project is in a clean, working state first.
Day/night CPU profiles and core reservation
Settings lets you define separate day and night CPU profiles so AITM automatically throttles or opens up how much CPU pipeline subprocesses may use depending on the time of day — for example, staying conservative during working hours and running full-speed overnight. Each profile's CPU allowance is enforced on subprocesses via AllowedCPUs confinement, so pipeline work cannot spill onto cores you want reserved for other use. AITM also reserves one or more CPU cores dynamically for its own core process (via systemd's AllowedCPUs), guaranteeing the AITM server itself stays responsive even when pipeline subprocesses are maxing out the rest of the machine.
AI-translate for secondary languages
If you add a secondary UI/help language that isn't fully supported yet, Settings offers an AI-translate button that machine-translates missing UI and help strings into that language using your configured translation model, instead of leaving them blank or falling back to English. A companion Test connection check lets you verify the configured translation model is reachable and responding correctly before you commit to translating your whole string set — catching a bad API key or unreachable endpoint immediately rather than after a large translation run fails.
Paginated translation editor with search
The translation editor for UI/help strings is now paginated, so large string sets stay fast and manageable instead of rendering every row at once. A search box over the English (EN) column lets you quickly find the row you want to edit or verify by typing part of the original English text, rather than scrolling through pages of translations.
Backup and per-project overrides
Back up your AITM configuration and task history, and override global settings (models, timeouts, reliability) on a per-project basis when one project needs different treatment than the rest.
Tips
- Put your most capable model on Architect and Review — those steps benefit the most from strong reasoning.
- Use a cheap or local model for Test/E2E steps where the work is mostly mechanical execution, not judgment.
- If a project has unusual needs (very large codebase, stricter tests), use a per-project override instead of changing global defaults.