Tars

TARS is a local AI agent runtime that runs on your machine, under your control. Homepage: tars.marvin-42.com — project overview, features, and quickstart.

TARS is a local agent runtime for people who want an inspectable AI workbench without handing workspace control to a hosted service. It packages a browser console, API server, CLI, background jobs, memory, and extension system into one Go binary.

The core promise is direct control:

• Run agent chat, subagents, cron jobs, watchdog checks, and reflection on your own machine.
• Inspect sessions, tool calls, memory candidates, run history, approvals, usage, logs, and config from the console.
• Route work across heavy, standard, and light model tiers with role-level defaults and traceable runtime logs.
• Extend behavior with skills, companion CLIs, plugins, MCP servers, Telegram, webhooks, and local APIs without bloating the default prompt.

The name comes from the TARS in Interstellar — practical, direct, dependable when things get complicated. TARS aims for that. Not affiliated with the film; the name is borrowed.

Comparison

| | OpenClaw | Hermes Agent | TARS | |---|---|---|---| | Language | TypeScript | Python | Go (single binary) | | Primary UI | CLI | CLI + Agent Runtime API | Browser console (CLI / Telegram / webhooks also) | | Sub-agents | ACP + subagent runtimes, push-based completion, Docker sandbox | ThreadPoolExecutor (max 3), ephemeral prompt, credential override | Agent Runtime executor with per-task model tier, allowlist policy, depth control | | Model routing | Per-agent model override | Per-child provider/model override, MoA (4 frontier models) | 3-tier named bundles (heavy/standard/light) with role→tier config mapping | | Memory | Session transcripts | Honcho/Holographic plugin hooks | Durable Markdown memory + semantic search + review-before-store extraction + nightly reflection | | Background | None | None | Pulse watchdog (1-min) + Reflection nightly batch | | Scheduling | None | None | Session-bound cron jobs with audit logs | | Channels | CLI | CLI + Agent Runtime API | Console + Telegram + webhooks | | Context mgmt | Per-session | ContextCompressor (50% threshold, protect-last-N) | Structured compaction with identifier preservation + light-tier LLM summary | | Extensibility | Built-in tools | Toolsets (terminal, file, web, delegation) | Skills + companion CLIs first, plus gated plugins/MCP from Skill Hub |

Key Features

Public Agent Packages

Public packages under pkg/ turn the runtime primitives into a small Go agent-building kit. Lightweight apps can reuse provider-normalized LLM contracts, the tool registry, the iterative agent loop, memory helpers, skill loading, and MCP adaptation without copying internal/ code.

• pkg/llm, pkg/tools, and pkg/agentloop are the core loop: provider client, registered tools, and tool-calling iterations.
• pkg/memory, pkg/skill, and pkg/mcp expose the first helper surfaces for durable memory, SKILL.md loading, and MCP tool adaptation.
• examples/min-agent shows the minimal no-network composition, while [docs/public-agent-packages.md](docs/public-agent-packages.md) documents package boundaries and what still intentionally remains internal.

Chat + Memory

The primary interface is the browser console at http://127.0.0.1:43180/console.

• Multi-session chat with tool-calling loops, session search, pins, archives, cleanup review, and message-level forks.
• Dockable panels for sessions, files, terminal, Git inspection, tool calls, prior context, Tasks, Session Health, and session-specific policy.
• Durable memory through MEMORY.md, reviewed experiences, daily logs, semantic search, structured compaction, and a Memory Inbox review queue.
• Explicit context injection through @ file/directory mentions, / command autocomplete, and user-invocable skills.
• Configurable system prompts through USER.md, IDENTITY.md, AGENTS.md, and TOOLS.md.
• A locale-aware companion surface for Poke, Suggest, Feedback, runtime signals, and bounded handoff into Chat.

See [docs/console.md](docs/console.md) for the detailed console page and panel inventory.

Sub-Agent Orchestration

Spawn read-only agents for research, planning, and specialized tasks:

# workspace/agents/explorer/AGENT.md
---
name: explorer
tier: light
tools_allow: [read_file, list_dir, glob, memory_search]
---

Use subagents_run when tasks are independent and can fan out in parallel:

{"tasks": [
  {"prompt": "find all API endpoints", "tier": "light"},
  {"prompt": "design the migration plan", "tier": "heavy"}
]}

Use compare mode when 2-3 safe subagents should inspect the same prompt independently and TARS should keep their outputs side-by-side:

{"mode":"compare","tasks": [
  {"agent": "explorer", "title": "Explorer pass", "prompt": "find the root cause"},
  {"agent": "reviewer", "title": "Reviewer pass", "prompt": "find the root cause"}
]}

In Console Chat, subagents_run renders as a progress card with running/completed/failed counts, elapsed time, compact task titles, and direct links to each Agent Runtime run once they are available. Compare-mode results add common findings, conflict candidates, sourced evidence snippets, and side-by-side output panes.

Advanced staged-flow tools are available only when explicitly allowed for a session: subagents_orchestrate runs dependency-aware parallel / sequential steps, and subagents_plan uses the heavy-tier planner model to draft such a flow. When staged-flow tools run from chat, TARS mirrors the generated plan and live step lifecycle into the session Tasks panel so the right rail shows pending, in-progress, completed, and cancelled subagent work.

Experimental consensus mode remains hidden from the default subagents_run schema unless agentruntime.consensus.enabled is explicitly set.

Tier resolution priority: task tier > agent YAML tier > config default.

The Console Agent Runtime page keeps run history, run topology, replay, restart checkpoints, cost/token flow, file attention, git diff attribution, and subagent profile management in one operational surface. See [docs/console.md](docs/console.md) and [docs/tutorials/22-agentruntime.md](docs/tutorials/22-agentruntime.md) for details.

3-Tier Model Routing

Route workloads to different models for cost and quality optimization:

| Tier | Purpose | Example | |------|---------|---------| | heavy | Planning, complex reasoning, architecture | claude-opus-4-6, gpt-5.4 | | standard | General chat, agent loops, tool calling | claude-sonnet-4-6, gpt-5.4 | | light | Summarization, classification, pulse, reflection | claude-haiku-4-5, gpt-4o-mini |

# tars.config.yaml
llm:
  providers:
    default:
      kind: anthropic
      auth_mode: api-key
      api_key: ${ANTHROPIC_API_KEY}
  tiers:
    heavy:
      provider: default
      model: claude-opus-4-6
    standard:
      provider: default
      model: claude-sonnet-4-6
    light:
      provider: default
      model: claude-haiku-4-5
  default_tier: standard
  role_defaults:
    pulse_decider: light
    agentruntime_planner: heavy

System roles such as chat, pulse, reflection, compaction, cleanup, and agent runtime agents map to tiers. Background work defaults to light, Chat can recommend a tier before the first expensive turn, and runtime logs record the resolved role, tier, provider, model, and source for traceability. Console Settings includes a typed llm.tiers editor for tier bindings.

Background Surfaces

Two isolated surfaces run independently from user chat:

• Pulse — 1-minute watchdog scanning cron failures, stuck runs, stalled chats, disk pressure, Telegram delivery health, and reflection status. LLM classifier picks ignore / notify / autofix. The Console renders recent signals as incident cards with likely cause, evidence, recommended action, safe navigation, and re-check controls, while repeated chat-attention notifications are grouped with occurrence counts instead of inflating unread rows. Autofixes are whitelisted in config, cleanup-like autofixes are opt-in, and stalled-chat continuation requires per-session auto-resume consent.
• Reflection — Nightly batch (default 02:00–05:00) running memory reflection (Memory Inbox candidate extraction) and stale empty-session pruning.

Both use the light tier by default and have no access to user-facing tools (enforced at compile time via RegistryScope).

Scheduling

Native cron with session binding:

• Cron expressions and one-shot at: schedules
• Session-bound jobs inherit the session's tool policy, work dirs, and prompt override
• Audit logs: artifacts//cronjob-log.jsonl
• Console Cron page for global job management plus per-session Cron tabs in chat context

Channels

Multi-channel I/O beyond the web console:

• Telegram — Bidirectional messaging with pairing-based access control
• Webhooks — Inbound HTTP triggers for external integrations
• Assistant — macOS popup and voice helpers that share the core ~/.tars/workspace default unless overridden
• Local — Direct API calls for scripts and automation
• Remote Access — Tailscale Serve can publish the loopback-only console over tailnet HTTPS with a TARS-owned target, while browser sessions use admin/user password auth and remote/mobile logins stay user-scoped.

Embodiment

TARS has a core embodiment subsystem for body providers. The shipped default is enabled: false with no providers, so existing chat/runtime behavior is unchanged and no LLM tools are registered. When enabled, known providers can post Percepts; owner audio becomes an autonomous directive turn, while ambient/stranger observations stay non-triggering by default. Cognition turns can emit structured tars-body-action blocks, which TARS routes back to the bound provider only when the provider declares the matching capability.

In the Console, open Settings and use the Quick Start Embodied Bot and Embodied Bot providers cards to edit the same settings without switching to raw YAML. The providers card opens a structured form with Mac Host, StackChan, and Custom presets, field hints, and grouped capability toggles. For MCP providers, endpoint must match an mcp.servers key from the companion server config.

embodiment:
  enabled: true
  providers:
    - name: stackchan
      enabled: true
      transport: mcp
      endpoint: tars-stackchan
      capabilities: [vision, hearing, speech, expression, motion, led]
      session_id: sess_main
      owner_only_directive: true
      min_trigger_interval: 30s
      max_triggers_per_hour: 60
    - name: host
      enabled: true
      transport: mcp
      endpoint: tars-stackchan-host
      capabilities: [hearing, speech]
      session_id: sess_main
      owner_only_directive: false
      trigger_observations: true
      min_trigger_interval: 30s
      max_triggers_per_hour: 60

Providers may also use the existing webhook inbox path /v1/channels/webhook/inbound/{provider} or the direct percept path /v1/embodiment/percept/{provider}. TARS persists the Percept in the channel inbox first, then routes self-sensory Percepts through the embodiment gate and agent runtime. Successful percept intake also publishes an ephemeral live Console companion signal so camera and microphone providers can make the pet react without creating desktop notifications. Body actions map to provider capabilities (speak → speech, express → expression, move → motion, led → led); unsupported capabilities are dropped gracefully instead of failing the cognition loop. MCP providers receive actions through their existing MCP server, so this does not add any built-in LLM tool surface.

Remote Access

TARS can expose the local console to your phone or another trusted device through Tailscale without binding the server to 0.0.0.0.

# Create or rotate console passwords
tars auth init
tars auth passwd admin
tars auth passwd user

# Publish the loopback console through Tailscale Serve
tars remote status
tars remote enable
tars remote url

Remote Access requires api_auth_mode: required, configured admin/user passwords, and a logged-in Tailscale client. The Settings page shows both the saved YAML value and the effective runtime value when environment variables override config, so a local dev launch such as TARS_API_AUTH_MODE=off is visible before enabling remote access.

Extensibility

TARS favors on-demand extension over always-resident tool registrations. Domain-specific capabilities are shipped as skills (plus optional companion CLIs) from the Skill Hub rather than compiled into the TARS binary — this keeps the chat system prompt small no matter how many capabilities a user installs.

• Skill Hub — Public registry of skills, plugins, MCP servers, and domain packs. Install individual packages with tars skill install , tars plugin install , tars mcp install , or install a reviewed bundle with tars pack install . Skill, plugin, MCP, and pack member installs/updates are first materialized in a temporary workspace and sandbox-validated before the real workspace/skills//, workspace/plugins//, workspace/mcp-servers//, or skillhub.json changes. Hub entries can publish quality metadata such as score, last update, passing tests, required tools, permissions, companion CLI presence, and install count; the Extensions console renders these trust signals before install. Update commands report updated, skipped, and failed entries so failed package refreshes are visible. The hub is the first place to look before writing a new capability, and the only place to publish one.
• External skill hubs (federation) — tars skill also federates across external MIT-compatible hubs. Pass --from to install from openclaw (steipete/openclaw), hermes (NousResearch/hermes-agent), or anthropic (anthropics/skills). External installs always preview first (--dry-run or the console hub-selector + dry-run modal showing per-file sha256, adapter warnings, and the ATTRIBUTION notice), generate an ATTRIBUTION.md carrying the source's license body and copyright, and refuse to materialize source-available content (Anthropic's docx/pdf/pptx/xlsx skills are blocked at the attribution layer). Both tars skill search (no --from) and the console Hub Skills list span every registered source. See docs/tutorials/14-skill-hub.md for the federation architecture.
• Skills — Markdown instruction files (YAML frontmatter + body) with optional companion scripts. A skill's frontmatter can set recommended_tools: [bash], slash: /name, aliases: [...], and smoke_tests: [...]; users can invoke eligible skills directly from chat via /name autocomplete. Companion CLIs keep their interface out of the system prompt until the skill itself is picked. The Chat Skill Inbox can extract reusable skill candidates from a session, preserve provenance/evidence, and save approved candidates as local workspace/skills// drafts. The Extensions console can also draft, sandbox-test, and save local skills before you publish them to the hub, and shows sandbox pass/fail reports for hub skill installs. See daily-briefing in the hub for the canonical pattern.
• Plugins — Advanced packages that bundle skill directories and optional MCP server declarations with manifest metadata and runtime gating. Plugin-declared MCP servers are disabled by default and require extensions.plugins.allow_mcp_servers: true before they can launch. Built-in Go plugins and plugin HTTP routes are not an active extension surface.
• MCP — Configured, h

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: devlikebear
• Source: devlikebear/tars
• License: MIT
• Homepage: https://tars.marvin-42.com

Install and usage instructions live in the source repository linked above.