Overview

Jarvis is a personal AI workbench for developers who want one place to:

• run a persistent chat workspace
• launch and inspect coding-agent sessions
• keep long-running work visible without flooding the main conversation with raw terminal output

It is not a general-purpose hosted agent platform. The default shape is local-first: a Python backend, a web UI, SQLite for local state, and runtime adapters for external coding CLIs such as Claude Code, Codex, and OpenCode.

The two core workflows

Persistent chat

The main chat is the control surface. Messages stream over SSE, state is persisted, and reconnects can resume without discarding the conversation.

Coding sessions

A coding session is a runtime-backed worker launched from Jarvis. You can inspect its terminal output, replay its timeline, and respond when it needs a decision.

How Jarvis stays usable during long tasks

Jarvis separates the human-facing chat from the noisy details of runtime execution.

• The main chat receives compact session updates instead of full terminal transcripts.
• A worker can report progress, ask for human input, or declare itself blocked through built-in MCP tools.
• The dedicated session view keeps the detailed terminal and replay timeline available when you need to inspect the work.

This split is the reason Jarvis can supervise multiple active sessions without turning the chat transcript into a terminal dump.

Local architecture at a glance

1. The backend runs locally and serves the API and the built frontend.
2. The frontend opens in the browser at the local Jarvis port.
3. SQLite stores chat history, coding-session state, and local metadata.
4. Runtime adapters launch or discover Claude Code, Codex, or OpenCode sessions.
5. Session events flow back into Jarvis so the UI can show progress, blocked states, and replayable history.

What to configure first

Jarvis itself can start with only the local backend configuration. To use coding sessions, you also need at least one runtime CLI installed and authenticated on the same machine.

How this documentation is organized

Use the docs by task, not by source tree:

• Start: local setup, first-run flow, and first coding session
• Concepts: Session OS behavior, runtime models, and context management
• Guides: workflows such as managing sessions or troubleshooting startup
• Reference: API contracts, configuration details, and protocol-level behavior

Recommended reading order

1. Quickstart to get a local instance running
2. First coding session to launch a runtime from the UI
3. Concept pages once you want to understand why the product behaves the way it does