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

AI providers and API keys

Add API keys for the AI providers you want to use — Claude, Gemini, DeepSeek, or a local Ollama model. You can configure more than one provider and mix them across different pipeline steps.

Settings view
The Settings view for configuring AI providers and pipeline behavior.

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.

Continue in Provider

For providers with their own web chat UI (e.g. Claude.ai), a "Continue in [Provider]" button next to a task's conversation opens the same conversation in that provider's own interface, for manual or interactive follow-up outside AITM.

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.

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.