{"repo": "ayushparkara/syntra", "files": {"README.md": {"9d58945834d9703eee3761ce739142613227b03b": {"t": 1785746490.788257, "n": 12944, "h": "dd1d8bc9c6b98179", "c": "# Syntra\n\n**Open-source control plane for coding with multiple AI models. Routes planning, execution, and review separately — with durable task state and receipts.**\n\nStop betting an entire coding task on one opaque model. Syntra is a terminal-first coordination layer that lets you inspect, override, and audit how models are used.\n\n> **Early public beta:** Use it, stress it, and report bugs or improvements. Expect rough edges\n> while the core experience is hardened.\n\n![Syntra terminal cockpit running a JWT authentication task, with planning, execution, review, activity, cost, and model-routing panels.](docs/assets/syntra-jwt-auth-demo.png)\n\n*Syntra's terminal cockpit: plan, execute, review, inspect the activity trail, and see the active model route in one workspace.*\n\n---\n\n## The pitch in 10 seconds\n\nYou give Syntra one coding task. It:\n\n1. Picks a **planner** model (high intelligence) to break the task into steps.\n2. Picks an **executor** model (fast/specialized for coding) to do each step.\n3. Picks a **reviewer** model (good at verification) to check the result.\n4. Stores `task.json`, `plan.json`, `decisions.json`, `failures.json`, `summary.json`, `cost.json` — typed state, NOT one fat chat log.\n5. Shows the model route, reason, provider, and estimated/recorded cost.\n\nRouting starts from an editable, capability-tagged catalog. The bundled catalog is an **approximate seed snapshot**, not a guarantee of live benchmark data; inspect routes, refresh available data, override the catalog, or pin models yourself.\n\n**Syntra is TUI-first.** Just run `syntra` (no arguments) to open the full-screen cockpit —\npanels, themes, live trace, and slash commands — the recommended way to use it. If you'd\nrather script it or stay on the command line, the **full CLI is available too**:\n`syntra run \"<task>\"` for a one-shot run, or `syntra --plain` for a simple line session.\nMost core workflows have CLI equivalents; a few cockpit conveniences are TUI-only.\n\n---\n\n## 📖 Documentation (start here)\n\nPlain-English guides for everything Syntra does — what each feature is, how to use it, with examples:\n\n- **[docs/GUIDE.md](docs/GUIDE.md)** — the complete guide + quickstart (read this first).\n- **[docs/COMMANDS.md](docs/COMMANDS.md)** — common `syntra` commands, with pointers to `--help` for advanced commands.\n- **[docs/CONFIG.md](docs/CONFIG.md)** — common settings, files, and environment variables.\n- **[docs/SECURITY.md](docs/SECURITY.md)** — threat model (local-first), the security audit, and what's hardened.\n- **[docs/RELEASING.md](docs/RELEASING.md)** — maintainer checklist for GitHub Releases and PyPI.\n- **[docs/REPOSITORY_SETUP.md](docs/REPOSITORY_SETUP.md)** — GitHub settings needed before the public-beta announcement.\n- **[docs/PUBLIC_BETA_CHECKLIST.md](docs/PUBLIC_BETA_CHECKLIST.md)** — complete community, security, release, and support checklist for maintainers.\n- **[SUPPORT.md](SUPPORT.md)** — where users should ask questions, report bugs, and report security issues.\n- **Feature guides** ([docs/features/](docs/features/)):\n  [Model selection](docs/features/MODEL_SELECTION.md) ·\n  [Reliability & failover](docs/features/RELIABILITY.md) ·\n  [Quality & review](docs/features/QUALITY_AND_REVIEW.md) ·\n  [Providers, caching & MCP](docs/features/PROVIDERS_CACHING_MCP.md) ·\n  [Tools & safety](docs/features/TOOLS_AND_SAFETY.md)\n\n---\n\n## Bugs, issues & contributions\n\nFound a bug, confusing workflow, rough edge, or missing capability? Open a **GitHub Issue** with\nthe steps and context, or a **Pull Request** to propose a fix. The highest-value beta feedback is:\n\n- a real task where routing picked the wrong model;\n- an install, provider, safety, or TUI workflow that was confusing;\n- a reproducible cost, reliability, or verification problem; or\n- a small documentation, provider, routing, safety, or benchmark contribution.\n\nRead [CONTRIBUTING.md](CONTRIBUTING.md) before changing safety-sensitive code. Never post API keys,\nprivate provider configuration, project files, or `.syntra/` task state in an issue.\n\n---\n\n## Install\n\n### Install the public beta from PyPI\n\n```bash\nuv tool install syntra\n# or: pipx install syntra\n# or: python3 -m pip install --user syntra\n```\n\nUse this after `syntra` has been published to PyPI. Confirm the installed version with:\n\n```bash\nsyntra --version\n```\n\n### Install from a source checkout\n\n```bash\ngit clone https://github.com/AyushParkara/syntra.git\ncd syntra\npython3 -m pip install -e .\n```\n\nThis is the right path for contributors and for trying the repository before a PyPI release exists.\n\n### Open the cockpit (the recommended way to use Syntra)\n\n```bash\nsyntra\n```\n\nBare `syntra` launches the full-screen TUI — panels, ~20 themes, a live activity trace, a\ncommand palette (type `/`), and inline `@`-file autocomplete. This is the primary interface;\neverything below is also reachable as a CLI command if you prefer the terminal or scripting.\n\n### Look at the model catalog\n\n```bash\nsyntra catalog\n```\n\nShows every model with intelligence index, speed, price, context window, role suitability, and capability tags. Sorted by intelligence.\n\n### See what the router would pick (no API call made)\n\n```bash\nsyntra route planner\nsyntra route executor\nsyntra route reviewer\nsyntra route executor --quality-bias 0.1   # cost-first\nsyntra route executor --quality-bias 1.0   # quality-first\nsyntra route executor --needs-long-context\n```\n\nEach call prints the picked model, the reason (with capability tags), the provider that would serve it, and the runners-up.\n\n### See your configured providers\n\n```bash\nsyntra providers\n```\n\nReads `~/.config/syntra/providers.json` and lists every endpoint with whether it has a key, how many model IDs it claims to serve, and its base URL.\n\n### Run an actual task end-to-end (requires API key in providers.json)\n\nInside the TUI, just type your task and hit enter. From the CLI, the one-shot equivalent is:\n\n```bash\nsyntra run \"Write a Python function that reverses a linked list, with a small test.\"\n```\n\nYou'll see live `[route]` and `[usage]` lines as planner -> executor -> reviewer runs, then a final summary with total tokens and cost. State is written to `.syntra/tasks/<task-id>/`.\n\n```bash\nsyntra tasks                       # list all past tasks\nsyntra task <task-id>              # inspect one task's stored state\n```\n\n---\n\n## Provider configuration\n\nProvider config lives at `~/.config/syntra/providers.json` (NEVER in this repo). The file shape:\n\n```json\n{\n  \"providers\": [\n    {\n      \"name\": \"openrouter\",\n      \"display_name\": \"OpenRouter\",\n      \"base_url\": \"https://openrouter.ai/api/v1\",\n      \"api_key_env\": \"OPENROUTER_API_KEY\",\n      \"allowed_models\": [\"anthropic/claude-opus-4.7\", \"openai/gpt-5\"]\n    },\n    {\n      \"name\": \"deepseek\",\n      \"display_name\": \"DeepSeek\",\n      \"base_url\": \"https://api.deepseek.com\",\n      \"api_key\": \"YOUR_DEEPSEEK_KEY\",\n      \"allowed_models\": [\"deepseek-chat\", \"deepseek-reasoner\"]\n    }\n  ]\n}\n```\n\nRules:\n\n- `api_key_env` resolves from environment at load time. Use this for keys you want in your shell config, not the JSON.\n- `api_key` accepts the literal key, or `\"no-auth\"` for self-hosted endpoints with no auth.\n- `allowed_models` restricts which model IDs this endpoint will serve. Omit for a wildcard endpoint.\n- Provider order is precedence order. If two endpoints can serve the same model id, the earlier one wins.\n- See `syntra/data/providers.example.json` for a template covering the common providers.\n\nThe file should be `chmod 600` because it contains live API keys. The repo `.gitignore` blocks any `providers.json` from being committed.\n\n---\n\n## How the artificialanalysis.ai catalog works\n\nThe catalog at `syntra/data/aa_catalog.json` is the source of truth for capability-aware routing. It ships with a hand-tuned snapshot of well-known models, tagged with role/specialty metadata that the router uses to score picks. **You do not need to refresh it for Syntra to work** — the seeded data is good enough as a starting point.\n\nArtificial Analysis publishes its benchmark leaderboards publicly and offers a\nfree, rate-limited Data API for primary benchmark, speed, and pricing metrics.\nTo refresh supported catalog values (for example intelligence-style scores, speed,\nprices, and context windows), create an API key in your Artificial Analysis account\nand run:\n\n1. Open your Artificial Analysis account/API dashboard and create or copy an API\n   key. Their free Data API has a published rate limit; consult their current API\n   documentation for the limit and access terms.\n2. Export it: `export ARTIFICIALANALYSIS_API_KEY=\"aa-...\"`\n3. Refresh:\n\n   ```bash\n   syntra catalog refresh           # writes back to the configured catalog path\n   syntra catalog refresh --dry-run # see what would change without writing\n   ```\n\nThe refresh updates supported values for models already in the catalog. It can add\nmodels reported by the upstream source, but those new rows do not automatically gain\nSyntra's role/specialty tags — those remain an editorial layer under your control.\n\nIf you skip refresh forever, the seeded catalog still works. The capability *tags* matter more than the exact numbers for routing decisions.\n\n---\n\n## What the state directory looks like\n\n```\n.syntra/\n└── tasks/\n    └── <task-id>/\n        ├── task.json          # goal, status, timestamps\n        ├── plan.json          # steps produced by the planner\n        ├── decisions.json     # durable choices made during the run\n        ├── failures.json      # attempts that didn't work and why\n        ├── summary.json       # compressed running summary\n        ├── cost.json          # tokens + USD by role+model\n        └── events.jsonl       # append-only audit log\n```\n\nThis is the anti-compaction structure. Compaction can throw away disposable chat reasoning all it wants; the durable state lives in these files and survives across resumes.\n\n---\n\n## Configuration knobs\n\n- `--quality-bias 0.0 .. 1.0` — 1.0 = always pick the smartest model. 0.0 = always pick the cheapest that meets requirements. Default 0.8.\n- `--planner <model_id>`, `--executor <model_id>`, `--reviewer <model_id>` — pin specific models, override the router.\n- `SYNTRA_STATE_DIR` — where to put `.syntra/`. Defaults to current working directory.\n- `SYNTRA_PROVIDERS_FILE` — override provider config path.\n- `SYNTRA_CATALOG_PATH` — override catalog path.\n\n---\n\n## What it does now\n\nThe cognitive loop came first; on top of that solid base, Syntra now also has:\n\n- **Agentic tool use** — read/write/edit files, `apply_patch` (multi-file atomic edit bundles), shell (sandboxed), grep/glob, git, web fetch/search, optional browser tools.\n- **Safety layers** — command classification + Bubblewrap sandbox, an approval gate for writes/exec, sensitive-file protection, and `AGENTS.md`/`CLAUDE.md` auto-loading.\n- **Full-screen TUI** — panels, ~20 themes (light/dark aware), live activity trace, a command palette, and inline `@`-file autocomplete.\n- **Reliability** — multi-provider/multi-key failover, route-health memory, prompt caching, and silent-failure detection.\n- **Quality** — a 3-lens reviewer, a verification gate, proof artifacts, Reflexion retries, and an optional review panel (PoLL).\n- **Memory & MCP** — durable per-session memory/learnings, plus MCP tools attachable over stdio or HTTP.\n- **Per-role reasoning control** — reasoning effort (`low|medium|high|xhigh|max|auto`) and graceful degrade when a model/key doesn't support the param.\n\n---\n\n## Architecture\n\n```\ngoal\n  │\n  ▼\ncatalog ─► router ─► role pick (planner)\n                │\n                ▼\n            registry ─► endpoint (provider+url+key)\n                │\n                ▼\n         provider HTTP call ─► result\n                │\n                ▼\n         step result in plan.json\n                │\n                ▼\n  (repeat for each step with executor)\n                │\n                ▼\n        reviewer pass with full plan+results\n                │\n                ▼\n       verdict + summary.json + cost.json\n```\n\n---\n\n## Code surface\n\n```\nsyntra/\n├── core/          the engine — routing, the planner/executor/reviewer loop, typed\n│                  task state, providers/registry, tools + sandbox + permissions,\n│                  memory, MCP, hooks, and the TUI building blocks (widgets, overlays,\n│                  themes, fuzzy matcher, edit-bundle patch parser, …)\n├── providers/     OpenAI-compatible + anthropic/gemini/responses adapters\n├── skills/        17 built-in skills (see docs/SKILLS_AND_PLUGINS.md)\n└── cli/\n    ├── main.py    the CLI surface — `run`, `route`, `catalog`, `providers`, `doctor`,\n    │              `resume`, `compare`, `tasks`, … and more\n    ├── tui2.py    the full-screen curses cockpit (bare `syntra`)\n    └── inline_tui.py  opt-in native-scrollback \"inline\" mode (`--inline`)\n```\n\nPure-Python, standard-library only — no runtime dependencies. Browse `syntra/core/`\nfor the full engine surface.\n"}, "c1a4380f2d4f01acee12d663a58a738a218d7b24": {"t": 1785764898.7732599, "n": 12637, "h": "8a1fc00ed64346e6", "c": "# Syntra\n\n**Open-source control plane for coding with multiple AI models. Routes planning, execution, and review separately — with durable task state and receipts.**\n\nStop betting an entire coding task on one opaque model. Syntra is a terminal-first coordination layer that lets you inspect, override, and audit how models are used.\n\n> **Early public beta:** Use it, stress it, and report bugs or improvements. Expect rough edges\n> while the core experience is hardened.\n\n---\n\n## The pitch in 10 seconds\n\nYou give Syntra one coding task. It:\n\n1. Picks a **planner** model (high intelligence) to break the task into steps.\n2. Picks an **executor** model (fast/specialized for coding) to do each step.\n3. Picks a **reviewer** model (good at verification) to check the result.\n4. Stores `task.json`, `plan.json`, `decisions.json`, `failures.json`, `summary.json`, `cost.json` — typed state, NOT one fat chat log.\n5. Shows the model route, reason, provider, and estimated/recorded cost.\n\nRouting starts from an editable, capability-tagged catalog. The bundled catalog is an **approximate seed snapshot**, not a guarantee of live benchmark data; inspect routes, refresh available data, override the catalog, or pin models yourself.\n\n**Syntra is TUI-first.** Just run `syntra` (no arguments) to open the full-screen cockpit —\npanels, themes, live trace, and slash commands — the recommended way to use it. If you'd\nrather script it or stay on the command line, the **full CLI is available too**:\n`syntra run \"<task>\"` for a one-shot run, or `syntra --plain` for a simple line session.\nMost core workflows have CLI equivalents; a few cockpit conveniences are TUI-only.\n\n---\n\n## 📖 Documentation (start here)\n\nPlain-English guides for everything Syntra does — what each feature is, how to use it, with examples:\n\n- **[docs/GUIDE.md](docs/GUIDE.md)** — the complete guide + quickstart (read this first).\n- **[docs/COMMANDS.md](docs/COMMANDS.md)** — common `syntra` commands, with pointers to `--help` for advanced commands.\n- **[docs/CONFIG.md](docs/CONFIG.md)** — common settings, files, and environment variables.\n- **[docs/SECURITY.md](docs/SECURITY.md)** — threat model (local-first), the security audit, and what's hardened.\n- **[docs/RELEASING.md](docs/RELEASING.md)** — maintainer checklist for GitHub Releases and PyPI.\n- **[docs/REPOSITORY_SETUP.md](docs/REPOSITORY_SETUP.md)** — GitHub settings needed before the public-beta announcement.\n- **[docs/PUBLIC_BETA_CHECKLIST.md](docs/PUBLIC_BETA_CHECKLIST.md)** — complete community, security, release, and support checklist for maintainers.\n- **[SUPPORT.md](SUPPORT.md)** — where users should ask questions, report bugs, and report security issues.\n- **Feature guides** ([docs/features/](docs/features/)):\n  [Model selection](docs/features/MODEL_SELECTION.md) ·\n  [Reliability & failover](docs/features/RELIABILITY.md) ·\n  [Quality & review](docs/features/QUALITY_AND_REVIEW.md) ·\n  [Providers, caching & MCP](docs/features/PROVIDERS_CACHING_MCP.md) ·\n  [Tools & safety](docs/features/TOOLS_AND_SAFETY.md)\n\n---\n\n## Bugs, issues & contributions\n\nFound a bug, confusing workflow, rough edge, or missing capability? Open a **GitHub Issue** with\nthe steps and context, or a **Pull Request** to propose a fix. The highest-value beta feedback is:\n\n- a real task where routing picked the wrong model;\n- an install, provider, safety, or TUI workflow that was confusing;\n- a reproducible cost, reliability, or verification problem; or\n- a small documentation, provider, routing, safety, or benchmark contribution.\n\nRead [CONTRIBUTING.md](CONTRIBUTING.md) before changing safety-sensitive code. Never post API keys,\nprivate provider configuration, project files, or `.syntra/` task state in an issue.\n\n---\n\n## Install\n\n### Install the public beta from PyPI\n\n```bash\nuv tool install syntra\n# or: pipx install syntra\n# or: python3 -m pip install --user syntra\n```\n\nUse this after `syntra` has been published to PyPI. Confirm the installed version with:\n\n```bash\nsyntra --version\n```\n\n### Install from a source checkout\n\n```bash\ngit clone https://github.com/AyushParkara/syntra.git\ncd syntra\npython3 -m pip install -e .\n```\n\nThis is the right path for contributors and for trying the repository before a PyPI release exists.\n\n### Open the cockpit (the recommended way to use Syntra)\n\n```bash\nsyntra\n```\n\nBare `syntra` launches the full-screen TUI — panels, ~20 themes, a live activity trace, a\ncommand palette (type `/`), and inline `@`-file autocomplete. This is the primary interface;\neverything below is also reachable as a CLI command if you prefer the terminal or scripting.\n\n### Look at the model catalog\n\n```bash\nsyntra catalog\n```\n\nShows every model with intelligence index, speed, price, context window, role suitability, and capability tags. Sorted by intelligence.\n\n### See what the router would pick (no API call made)\n\n```bash\nsyntra route planner\nsyntra route executor\nsyntra route reviewer\nsyntra route executor --quality-bias 0.1   # cost-first\nsyntra route executor --quality-bias 1.0   # quality-first\nsyntra route executor --needs-long-context\n```\n\nEach call prints the picked model, the reason (with capability tags), the provider that would serve it, and the runners-up.\n\n### See your configured providers\n\n```bash\nsyntra providers\n```\n\nReads `~/.config/syntra/providers.json` and lists every endpoint with whether it has a key, how many model IDs it claims to serve, and its base URL.\n\n### Run an actual task end-to-end (requires API key in providers.json)\n\nInside the TUI, just type your task and hit enter. From the CLI, the one-shot equivalent is:\n\n```bash\nsyntra run \"Write a Python function that reverses a linked list, with a small test.\"\n```\n\nYou'll see live `[route]` and `[usage]` lines as planner -> executor -> reviewer runs, then a final summary with total tokens and cost. State is written to `.syntra/tasks/<task-id>/`.\n\n```bash\nsyntra tasks                       # list all past tasks\nsyntra task <task-id>              # inspect one task's stored state\n```\n\n---\n\n## Provider configuration\n\nProvider config lives at `~/.config/syntra/providers.json` (NEVER in this repo). The file shape:\n\n```json\n{\n  \"providers\": [\n    {\n      \"name\": \"openrouter\",\n      \"display_name\": \"OpenRouter\",\n      \"base_url\": \"https://openrouter.ai/api/v1\",\n      \"api_key_env\": \"OPENROUTER_API_KEY\",\n      \"allowed_models\": [\"anthropic/claude-opus-4.7\", \"openai/gpt-5\"]\n    },\n    {\n      \"name\": \"deepseek\",\n      \"display_name\": \"DeepSeek\",\n      \"base_url\": \"https://api.deepseek.com\",\n      \"api_key\": \"YOUR_DEEPSEEK_KEY\",\n      \"allowed_models\": [\"deepseek-chat\", \"deepseek-reasoner\"]\n    }\n  ]\n}\n```\n\nRules:\n\n- `api_key_env` resolves from environment at load time. Use this for keys you want in your shell config, not the JSON.\n- `api_key` accepts the literal key, or `\"no-auth\"` for self-hosted endpoints with no auth.\n- `allowed_models` restricts which model IDs this endpoint will serve. Omit for a wildcard endpoint.\n- Provider order is precedence order. If two endpoints can serve the same model id, the earlier one wins.\n- See `syntra/data/providers.example.json` for a template covering the common providers.\n\nThe file should be `chmod 600` because it contains live API keys. The repo `.gitignore` blocks any `providers.json` from being committed.\n\n---\n\n## How the artificialanalysis.ai catalog works\n\nThe catalog at `syntra/data/aa_catalog.json` is the source of truth for capability-aware routing. It ships with a hand-tuned snapshot of well-known models, tagged with role/specialty metadata that the router uses to score picks. **You do not need to refresh it for Syntra to work** — the seeded data is good enough as a starting point.\n\nArtificial Analysis publishes its benchmark leaderboards publicly and offers a\nfree, rate-limited Data API for primary benchmark, speed, and pricing metrics.\nTo refresh supported catalog values (for example intelligence-style scores, speed,\nprices, and context windows), create an API key in your Artificial Analysis account\nand run:\n\n1. Open your Artificial Analysis account/API dashboard and create or copy an API\n   key. Their free Data API has a published rate limit; consult their current API\n   documentation for the limit and access terms.\n2. Export it: `export ARTIFICIALANALYSIS_API_KEY=\"aa-...\"`\n3. Refresh:\n\n   ```bash\n   syntra catalog refresh           # writes back to the configured catalog path\n   syntra catalog refresh --dry-run # see what would change without writing\n   ```\n\nThe refresh updates supported values for models already in the catalog. It can add\nmodels reported by the upstream source, but those new rows do not automatically gain\nSyntra's role/specialty tags — those remain an editorial layer under your control.\n\nIf you skip refresh forever, the seeded catalog still works. The capability *tags* matter more than the exact numbers for routing decisions.\n\n---\n\n## What the state directory looks like\n\n```\n.syntra/\n└── tasks/\n    └── <task-id>/\n        ├── task.json          # goal, status, timestamps\n        ├── plan.json          # steps produced by the planner\n        ├── decisions.json     # durable choices made during the run\n        ├── failures.json      # attempts that didn't work and why\n        ├── summary.json       # compressed running summary\n        ├── cost.json          # tokens + USD by role+model\n        └── events.jsonl       # append-only audit log\n```\n\nThis is the anti-compaction structure. Compaction can throw away disposable chat reasoning all it wants; the durable state lives in these files and survives across resumes.\n\n---\n\n## Configuration knobs\n\n- `--quality-bias 0.0 .. 1.0` — 1.0 = always pick the smartest model. 0.0 = always pick the cheapest that meets requirements. Default 0.8.\n- `--planner <model_id>`, `--executor <model_id>`, `--reviewer <model_id>` — pin specific models, override the router.\n- `SYNTRA_STATE_DIR` — where to put `.syntra/`. Defaults to current working directory.\n- `SYNTRA_PROVIDERS_FILE` — override provider config path.\n- `SYNTRA_CATALOG_PATH` — override catalog path.\n\n---\n\n## What it does now\n\nThe cognitive loop came first; on top of that solid base, Syntra now also has:\n\n- **Agentic tool use** — read/write/edit files, `apply_patch` (multi-file atomic edit bundles), shell (sandboxed), grep/glob, git, web fetch/search, optional browser tools.\n- **Safety layers** — command classification + Bubblewrap sandbox, an approval gate for writes/exec, sensitive-file protection, and `AGENTS.md`/`CLAUDE.md` auto-loading.\n- **Full-screen TUI** — panels, ~20 themes (light/dark aware), live activity trace, a command palette, and inline `@`-file autocomplete.\n- **Reliability** — multi-provider/multi-key failover, route-health memory, prompt caching, and silent-failure detection.\n- **Quality** — a 3-lens reviewer, a verification gate, proof artifacts, Reflexion retries, and an optional review panel (PoLL).\n- **Memory & MCP** — durable per-session memory/learnings, plus MCP tools attachable over stdio or HTTP.\n- **Per-role reasoning control** — reasoning effort (`low|medium|high|xhigh|max|auto`) and graceful degrade when a model/key doesn't support the param.\n\n---\n\n## Architecture\n\n```\ngoal\n  │\n  ▼\ncatalog ─► router ─► role pick (planner)\n                │\n                ▼\n            registry ─► endpoint (provider+url+key)\n                │\n                ▼\n         provider HTTP call ─► result\n                │\n                ▼\n         step result in plan.json\n                │\n                ▼\n  (repeat for each step with executor)\n                │\n                ▼\n        reviewer pass with full plan+results\n                │\n                ▼\n       verdict + summary.json + cost.json\n```\n\n---\n\n## Code surface\n\n```\nsyntra/\n├── core/          the engine — routing, the planner/executor/reviewer loop, typed\n│                  task state, providers/registry, tools + sandbox + permissions,\n│                  memory, MCP, hooks, and the TUI building blocks (widgets, overlays,\n│                  themes, fuzzy matcher, edit-bundle patch parser, …)\n├── providers/     OpenAI-compatible + anthropic/gemini/responses adapters\n├── skills/        17 built-in skills (see docs/SKILLS_AND_PLUGINS.md)\n└── cli/\n    ├── main.py    the CLI surface — `run`, `route`, `catalog`, `providers`, `doctor`,\n    │              `resume`, `compare`, `tasks`, … and more\n    ├── tui2.py    the full-screen curses cockpit (bare `syntra`)\n    └── inline_tui.py  opt-in native-scrollback \"inline\" mode (`--inline`)\n```\n\nPure-Python, standard-library only — no runtime dependencies. Browse `syntra/core/`\nfor the full engine surface.\n"}}}}