. | .
\|/
.--- O ---.
/ /|\ \
' / | \ '
. | .
AI Cockpit · One IDE. Every AI.A multi-agent orchestration interface for Claude, Gemini, Ollama, LocalAI (or both at once via Dual mode), online LLM providers (Workers), and local CLI tools (Tools).
Built by Dario Ruggi · cockpit.ruggi.site
The installer adds Cockpit to your applications menu under an “AI” category, and as terminal commands:
cockpit-start
(the full V2 edition).cockpit-v1-start (the Stand-alone edition, if you installed
both).Launching shows a splash while the agent sessions start, then opens
Cockpit in a clean app window. Stop with cockpit-stop /
cockpit-v1-stop; add --force to restart the
sessions.
One edition at a time: V1 and V2 use the same machine’s agents, so only one runs at once. Launching the other while one is open asks whether to switch (stopping the first) or cancel.
Terms and integrity. On an account’s first use
Cockpit shows its Terms of Use and licence — Apache-2.0 with attribution
and trademark conditions (also at logo → Terms and at
cockpit.ruggi.site/license.php) and checks the install against the
manifest shipped with its build. Logo → Integrity repeats the check at
any time: a changed or missing file is listed, and the bundle the
installer kept can put the shipped files back (Restore) without touching
your configuration or data. A modified copy keeps working locally; the
Cockpit account services are provided to official builds only. The
installer also makes the shipped files root-owned and read-only (editing
them takes sudo — a deliberate act) and starts
cockpit-guard, a small service that logs any change to
a shipped file, flags it in the app at once and puts the file back from
the kept bundle (cockpit_data/guard.log;
sudo systemctl status cockpit-guard).
Hints, First Use and the Tour. Hover over anything — a card, a button, a panel title — for a hint; leave the mouse there a moment longer and the hint expands with a summary from this guide (F1 opens the full topic). Hints are drawn by Cockpit itself, so they are never cut off at a screen edge. The First use toggle (top right, beside Help) shows the expanded form at once for everything. Tour (next to it) walks the whole screen step by step — every card, strip, sidebar and button — with Next / Back, Esc to leave, F1 for the matching help topic on any step.
The cockpit window has four regions:
┌──────────────────────────────────────────────────────────────────┐
│ TOPBAR — 5 supplier cards · Start/Stop/Restart · Theme · Rules │
│ Project / Chat / Path · Jobs · Accumulator · Help │
├──────────┬──────────────────────────────────────┬────────────────┤
│ LEFT │ CONSOLE (chat scroll) │ RIGHT │
│ SIDEBAR │ │ SIDEBAR │
│ │ user: ... │ │
│ Chats │ CLAUDE: ... │ Preview │
│ Projects │ GEMINI: ... │ Code │
│ Files │ OLLAMA: ... │ Library │
│ │ │ Snippets │
│ │ ┌──────────────────────────────┐ │ Sources │
│ │ │ PROMPT · Execute/Clear │ │ Config │
│ │ │ Attach · Save · Voice │ │ Search │
│ │ └──────────────────────────────┘ │ Capabilities │
│ │ Mode: Single·Pipeline·Broadcast·Plan│ Plans │
│ │ Style: Chat·Build·Debug·Research·… │ Attachments │
│ │ Toolbar: Translate·Summarize·Skills… │ Usage │
├──────────┴──────────────────────────────────────┴────────────────┤
│ FOOTER — Font size · Typography · Caveman · Model selector │
└──────────────────────────────────────────────────────────────────┘To do anything:
For multi-agent flows, switch the mode strip below the prompt to Pipeline, Broadcast, or Plan before pressing Execute.
Five cards run across the top of the cockpit. Each represents one provider class. Only the active card is expanded; the others show just an icon, the selected model name, and a thin progress bar.
| Card | Color | What it is |
|---|---|---|
| CLAUDE | amber | Anthropic Claude — best at reasoning, refactoring, architecture |
| GEMINI | blue | Google Gemini — fast iteration, broad knowledge, summaries |
| OLLAMA / LOCALAI / DUAL | orange | Local models running on your GPU — fully offline. Card 3's label follows whichever backend is assigned (Ollama, LocalAI, or Dual for both at once) |
| WORKERS | purple | Online LLM APIs — Groq, HuggingFace, OpenRouter, etc. |
| TOOLS | teal | Local CLI binaries — ffmpeg, whisper, pandoc, etc. |
Click any inactive card to make it active. The previous active card collapses to its icon-only state. The console border-color and Execute-button color follow the active agent so you always know what’s loaded.
Inactive — icon + selected model name + 3px progress bar.
Active — icon + agent name + AGENT button label, model dropdown, settings or open-tmux button, and a full usage line below.
The progress bar reflects different things per agent:
While the agent is responding, you’ll see a small ⏳ placeholder for that message which gets replaced as tokens stream in.
Click the Stop button next to Execute. The stream is aborted on both the frontend and the backend (the agent’s tmux process is signaled). The partial response stays in the chat for context.
The Up arrow key in the empty textarea brings up your previous prompt for quick edit-and-resend.
Click the Attach button (next to the prompt) or drag files onto the chat to attach. Text/code files are inlined as agent context; images go to vision-capable models. Manage attached files in the Attachments tab (right sidebar).
You can also attach reference material from the Library, Snippets, and Sources tabs — click any item’s attach icon to insert it into your next prompt as quoted context.
| Button | Action |
|---|---|
| EXECUTE | Send prompt (same as Ctrl+Enter) |
| CLEAR | Empty the prompt text area |
| SAVE | Save prompt text to Snippets or Library |
| Attach | Open file picker to attach files |
| Voice Rec | ord and transcribe locally (whisper.cpp) |
Below the prompt textarea is the mode strip:
┌─────────────────────────────────────────────────────────┐
│ ◉ Single ○ Pipeline ○ Broadcast ○ Plan │
└─────────────────────────────────────────────────────────┘Prompt goes to the active agent only. Standard chat behavior.
Prompt goes to agent A; A’s response becomes the prompt for agent B; B’s response becomes the prompt for agent C; etc. Useful for refinement chains:
Claude analyzes the spec → Gemini drafts code → Ollama runs the test suite
To configure pipeline order, the Multi-agent panel above the mode strip lets you select which agents to include and in what order.
Same prompt sent to every selected agent in parallel. Responses appear side-by-side. Useful for getting different perspectives on a question or comparing model output quality.
Treats the prompt as a goal and triggers the Orchestrator. All 3 main agents draft a plan in parallel; a synthesizer merges the votes; the result is saved to the Plans right-sidebar tab where you can review, edit, and execute it step-by-step. See The Orchestrator + Planner.
Pipeline and Broadcast normally run in the page: the browser drives each step, and closing the tab or losing power throws the run away. For a long chain of agents that is the wrong place to keep the work.
With Pipeline or Broadcast selected, the mode strip shows a link Durable button. Press it instead of Enter and the same selection — your prompt, the agents you ticked, each one’s current model — is turned into a checkpointed chain on the server and run through AutoCognition. Every step is a file with a status, so an interrupted run resumes at the step that died instead of starting over. It appears in Hive → Chains like any other chain.
Enter is unchanged. It always runs the mode in the page, exactly as before. Durable is something you press, never a setting that quietly changes what your keyboard does — the older Cruise checkbox worked that way and was removed for exactly that reason.
When to use which:
Two other routes reach the same engine, and it is worth knowing why they are not the same thing: flight PLAN lets the planner model decide the steps from your goal, and a Power Combo’s link runs a recipe someone else wrote. Only this button makes the selection you just built resumable.
(Durable chains are a Basic-tier feature; parallel ones need Pro.)
The style strip (below modes) prepends an instruction to every prompt, steering how the agent responds:
| Style | Behavior |
|---|---|
| Chat | Conversational — answers in prose, no code unless asked |
| Outline | Plan first, then implement |
| Research | Explore and explain with sources and reasoning |
| Build | Default builder mode — writes working code directly |
| Debug | Focus on finding and fixing bugs |
| Analyze | Deep analysis of code, data, or architecture |
| Report | Structured output — formal report with sections and conclusions |
In Plan mode, the style prefix is NOT prepended to the orchestrator goal — it only applies to direct agent prompts.
The cockpit organizes work into projects (folders on disk) containing chats (separate conversation threads).
Projects live under:
~/Software/Programing/LocalAIProjs/Each project is a directory; each chat is a
chat_<name>.json file inside that directory.
The new project becomes the active one. The path appears in the topbar’s info bar.
The chat is created inside the active project. The textbox in the topbar shows the active chat name.
Each chat has independent history, attachments, and proposals.
Click any project name → that project becomes active. Click any chat name → that chat becomes active.
The info bar (Project: foo · Chat: bar · /path/...)
always reflects the current context.
If no project is selected, the cockpit operates in
_standalone mode — chats live in
~/scripts/cockpit_data/_standalone/. Useful for quick
one-off questions.
The left sidebar has three tabs:
| Tab | Purpose |
|---|---|
| Chats | List of chats in the current project. Create, rename, import/export, detach, delete. |
| Projects | All projects. Create, switch, edit COCKPIT.md rules, delete. |
| Files | Project directory file tree. Click to preview/edit. Map button generates a Pascal/PHP unit map. |
The right sidebar has 11 vertical icon tabs:
| Tab | Purpose |
|---|---|
| Preview | Live preview of HTML/Markdown files. Updates when you select a file from the file tree. |
| Code | Inline code editor with syntax highlighting, find/replace, line numbers, word wrap. |
| Library | Saved references — URLs, file paths, notes. Scopeable to project or global. |
| Snippets | Reusable code fragments with language tags. Save from chat (F2) or add manually. |
| Sources | Source code files used as context or reference material for agents. |
| Config | Configuration — storage paths, attachment routes, import/export settings. |
| Search | Web search (Brave/DDG). Results can be fetched and injected into prompt context. |
| Capabilities | MCP servers and tool-shims. Toggle ON/OFF per capability. |
| Plans | Orchestrator plans — view steps, run/sequence/schedule, inspect votes. |
| Attachments | Files attached to the current chat. Upload, manage, and reference in prompts. |
| Usage | Token usage, quota tracking, and paid API spend for all suppliers and workers. |
Click any tab to open its panel. Only one panel is visible at a time. Tab state persists across page loads.
Below the tabs, the Pending Proposals section shows agent suggestions (file edits, commands) awaiting your approval. Approve or reject individually or in batch. Always visible regardless of which tab is open.
The Capabilities tab unifies three layers underneath:
SKILL.md folders)You declare a capability once with up to three implementations; the cockpit routes correctly per agent.
| ID | What | Claude | Gemini | Ollama |
|---|---|---|---|---|
filesystem |
Read/write project files | MCP | MCP | shim |
git |
Inspect/modify git repo | MCP | MCP | shim |
web-search |
Brave/DDG search | MCP | — | shim |
web-fetch |
Fetch URL → text | MCP | MCP | shim |
ssh |
Run commands on remote hosts | — | — | shim |
Click + New in the Capabilities toolbar. Provide:
This scaffolds an empty CAP.json at:
~/scripts/cockpit_data/capabilities/<id>/CAP.jsonEdit the file to wire up implementations. See
CAPABILITIES_README.md for the full schema.
Browse the registry suggestions via the cloud_download button in the Capabilities toolbar. Suggested options include GitHub, Slack, GDrive, SQLite, and Memory. Currently you copy the package name into a custom capability manifest (auto-install is a future feature).
The Plan mode treats your prompt as a goal and breaks it into executable steps using all three agents collaboratively.
USER GOAL
│
├──→ Claude ─┐
├──→ Gemini ─┼──→ 3 draft plans
└──→ Ollama ─┘
│
▼
SYNTHESIZER (default: Claude)
│
▼
MERGED PLAN — saved to Plans tabIf only one voter produces valid JSON, the synthesizer is skipped — that voter’s plan IS the plan. If the synthesizer fails, the longest valid voter plan is used as fallback.
| Button | What it does |
|---|---|
| Run Ex | ecute all remaining steps honoring auto-run mode |
| Pause St | op auto-progression after current step |
| Votes Sh | ow all 3 original voter plans side-by-side |
| Delete Re | move the plan from disk |
| (per step) Ru | n just that step now |
| ⏭ (per step) | Mark step skipped |
| (per step) Ed | it the step’s description |
Click the tune icon in the Plans toolbar to cycle through:
| Mode | Behavior |
|---|---|
auto |
Run all steps to completion, no prompts |
approve_destructive |
Pause before any step marked destructive (default) |
approve_each |
Pause before every step (browser confirm dialog) |
manual_only |
Don’t auto-progress; click Run on each step manually |
A step is marked destructive when it writes files, modifies git, runs network commands beyond GET, or uses ssh.
Click the edit pencil next to any pending step to rewrite its description. Already-running and done steps can’t be edited (re-run them with the per-step play_arrow button if needed). Edits persist on disk.
Everything above is the manual toolkit — you pick a mode and drive. Autopilot Cruise lets Cockpit fly the whole task instead: type a goal in the main prompt box, press flight PLAN in the Hive section of the left sidebar, and the answer lands back in your chat. You clear the one critical moment; the busywork runs itself.
Pressing Enter always does the same thing it has always done — classic dispatch to the agent you picked. Planning happens only when you ask for it by pressing PLAN. There is no mode to remember and nothing hidden that changes what your keyboard does.
In one line: one goal, broken into steps, run in order — and it survives being killed.
A small local model writes a plan. By default
qwen2.5:7b, running on your own machine — free, nothing
leaves the box. If that plan comes back malformed (nothing parsed, a
single step, an unrecognised tag) Cockpit automatically re-plans with a
larger model, qwen2.5:14b, so you pay the slower model’s
time only when the fast one actually failed. It is told to break your
goal into 2–5 ordered steps, each with one concrete instruction and a
tag for the kind of thinking it needs (text,
code, reasoning, web,
vision).
The plan is shown before the work happens. Which of two things follows depends on where you started it. Pressing flight PLAN prints the plan and runs it straight through — the fastest path. If you would rather read the steps before anything executes, open Chains in the Hive section and press link Draft a plan from the prompt box: that creates the chain in a building state as a Proposal that sits in Task Chains until you press Run. Use it when the goal is expensive or destructive. Both read the same main prompt box — there is only one place to type a goal.
Either way you see the steps, because the planner is a small local model and small models get things wrong. In testing it once planned “edit the file” → “check the live site” with no deploy step in between — structurally perfect, and it would have verified a page that never changed.
Steps run in order, each handed the previous one's
output. Step 2's prompt literally begins with a
%PREV% marker that is replaced by whatever step 1 produced.
That is the "chain".
Every step is a file on disk with its own status
— pending → running → done — and
its output saved beside it.
The final answer returns to your chat.
A fast-path skips planning for trivial one-line messages (they run as a single routed step). The classic modes stay as manual entry points that build the same underlying chains.
Changed in this release. Cruise used to be a checkbox in the hive panel that silently changed what the Enter key did, and it defaulted to on — the same prompt could dispatch or plan depending on a setting you could not see from the chat. That toggle is gone, along with the Manual Override label. If you had set a preference, it is cleared automatically on first load. Enter dispatches; PLAN plans.
Because each step is a file with a status, closing the laptop,
crashing, or hitting Ctrl-C does not throw the run away. Finished steps
stay done with their outputs intact; the interrupted step
flips back to pending; Resume re-runs only that one
step. You never redo completed work — which is exactly what
most one-shot agent tools lose.
It also degrades instead of dying: if the planner model is missing or returns nonsense, Cruise falls back to a single step containing your goal verbatim, behaving like an ordinary prompt.
The pattern worth noticing: Cruise pays off most when one step is slow or expensive and the steps after it are fiddly.
(Autopilot Cruise is a Basic-tier feature.)
AutoCognition is the brain underneath Cruise: a local multi-agent bus your agents share, opened from the Hive section of the left sidebar. (It used to be a floating hive button in the corner; that button is gone — it overlapped the sidebar that replaced it.) Where Cruise is the autopilot, AutoCognition is the crew and the intercom — several separate AI tools that can see each other, pass notes, and vote, with you as the gatekeeper.
AI agents are not servers. Claude Code, aider, goose, a Gemini CLI — each exists only while its process is alive, and an idle agent is polling nothing. So AutoCognition is a mailbox, not a phone call: a message waits in a folder until its recipient next wakes up. Everything else follows from that one fact.
info (FYI),
ask (a question expecting an answer), call
(please run this), wake (please start up).auto
asks "who can do this right now?" — live agents are ranked, and
local is preferred over cloud, so free beats paid by
default.A call never runs by itself. It is
surfaced to you as a proposal, with a highlighted banner saying what it
wants to do, and waits for your keypress. Anything arriving on the bus
is treated as data, never orders — the sender field is
not trusted, because anything on the machine could write one. Your
consent is the actual protection. Without that rule, a design like
this would be a worm rather than an assistant.
ask, which is answered when that agent next wakes. Neither
has to be running at the same time.code routes to a live local agent instead of
spending paid cloud tokens — automatically, because the router prefers
local.Everything runs locally, on your own machine and models. (AutoCognition is a Pro-tier feature; both it and Autopilot Cruise are open free during beta.)
Cruise builds the chain. AutoCognition decides who runs each step, can run some of them in parallel, and can put a step to a vote. That is also where the tier line falls: planning plus sequential execution is Cruise (Basic); routing, quorum, parallel groups and the message bus are AutoCognition (Pro).
One honest caveat: small local models sometimes ignore instructions even when the text is right in front of them. Since the Cruise planner defaults to a 7b model, that is precisely why the plan arrives as a Proposal you approve rather than something that simply runs. Point it at a larger planner model and the plans get noticeably better.
Workers are online LLM providers used for tasks the main agents can’t do (image generation, audio, niche translations) or as fallback when the main providers are exhausted.
| Provider | Free? | Specialty |
|---|---|---|
| Groq | Yes (generous) | Ultra-fast text inference |
| HuggingFace | Yes (hourly) | Text + image-gen + audio + translate |
| OpenRouter | Has free tier | Universal LLM gateway |
| Together AI | $1 free | Open-weight models, image gen |
| DeepInfra | Pay-per-use | Cheap inference |
<provider>:<model> pairsKeys are encrypted with AES-256-GCM at rest. The
encryption key is derived from your machine’s
/etc/machine-id plus a fixed cockpit salt, which means:
This is not military-grade — anyone with shell
access on your machine can decrypt. Same security level as your
~/.ssh/ keys.
The cockpit dispatches via HTTP, captures the response, and renders it inline:
<img><audio controls>When enabled for a project, all main agents (Claude/Gemini/Ollama) get a system-prompt addition advising them about the marker:
%%WORKER:provider:task:prompt%%crud_executor.sh dispatches the markers and surfaces
results inline. To enable, POST to
workers.php?action=set_auto_route with
{"project":"myproject","enabled":true}.
The WORKERS card’s bar shows aggregate tokens used; the settings modal shows per-provider call counts, error counts, tokens in/out, and last-call timestamp. Right-click the card’s usage area to reset all counters.
Tools are local CLI binaries for file → file transformations. No internet, no API keys, no usage tracking.
| Tool | Presets | What it does |
|---|---|---|
| ffmpeg | 9 | Audio/video conversion, extraction, resize, frames |
| whisper | 7 | Speech-to-text (auto/EN/ES/HE), SRT, translate-to-EN |
| pandoc | 8 | Document conversion (md ↔︎ pdf/docx/html/epub) |
$PATH
for binariessudo nala install ffmpeg whisper pandoc)<tool>:<preset> pairsIf the tool’s program is not installed on the machine, the modal says so before Run, with the exact install line for your package manager (copy it, run it in a terminal — Cockpit never installs software itself), or set the binary override in Tools settings.
While it runs, the bubble shows the elapsed time and the last lines
of the tool’s log. The output appears inline as a clickable file path
with size, runtime, and embedded preview if it’s an image/audio/video.
Every run — finished, failed or stopped — is recorded in the chat as a
TOOLS turn with the input and output paths, so it survives
a reload and the agents can find it later (“the file we converted
earlier”).
The Stop button stops everything the page started: the running tool, a worker call, a CLI agent’s generation. If the server still reports something running afterwards, Cockpit says which and offers to kill again.
Anything that runs longer than two minutes (or the tool’s own timeout, if shorter) raises a Still running question — Stop it or Keep waiting — and asks again every five minutes. Tool runs also have a hard timeout (five minutes by default, per preset). Closing the page stops your tool runs.
Default resolution order:
~/scripts/cockpit_data/tools_outputs/<tool>/<timestamp>/Same pattern as Workers. When enabled per-project, agents emit:
%%TOOL:tool:preset:input_path%%
# or with extra args:
%%TOOL:tool:preset:input_path|extra_args%%Three right-sidebar tabs hold reference material:
Long-form reference texts — design docs, specs, project briefs, AI persona descriptions. Stored as markdown files at:
~/scripts/cockpit_data/library/To add: paste content into the chat with a %%LIB:title%%
marker, or use the agent’s “Save as Library entry” suggestion that
follows substantive responses.
To use: click the attach_file attach icon to insert the entry as quoted context in your next prompt.
Short, reusable code snippets — boilerplate, regex patterns, useful one-liners. Same workflow as Library entries.
URLs, file paths, or other external references the agent should be aware of. Linked rather than copied — the agent fetches the content fresh each time the source is referenced.
The Search right-sidebar tab provides web search via Brave Search (primary) → DuckDuckGo lite → DuckDuckGo HTML (fallback chain).
Two extra buttons:
Search results have a fetch button that retrieves the page’s text content and adds it to the chat as quoted context.
| Shortcut | Action |
|---|---|
| Ctrl+Enter | Send prompt to active agent |
| Esc | Cancel current request / close any modal |
| Ctrl+F | Search in chat console (or find/replace in editor) |
| ↑ / ↓ | Cycle prompt history (in empty prompt box) |
| F1 | Context help for element under cursor |
| ? | Open full help guide |
| F2 | Save selected text to Snippets |
| F3 | Save selected text to Library |
| F8 | Open Ollama Model Manager |
| Double-click chat | Rename chat |
| Tab (in editor) | Insert 2 spaces |
| Right-click (chat) | Copy, Select All, Save to Snippets/Library |
| Right-click (prompt) | Cut, Copy, Paste, Select All, Save |
open_in_new) on the agent’s
cardcockpit_start.sh reports an error, check
~/scripts/cockpit.logCaused by:
Click Stop to abort, then re-send. The token cleanup runs every poll so stale state is cleared.
Capabilities take effect on the next agent session start. Click Restart in the topbar to reload all sessions with the new capability configuration.
API key is missing, expired, or invalid. Open Workers settings and re-paste the key.
Rate limited — you’ve hit the provider’s per-minute or per-hour cap. Wait or switch to a different provider/model.
Either:
sudo nala install <name>After installing, click Detect in Tools settings to refresh.
Check the auto-run mode in Plans toolbar’s tune
button. If it’s approve_destructive and a step is marked
destructive, the orchestrator pauses for confirmation. Click play_arrow on the next
pending step to continue.
The cockpit’s runtime configuration is split across these files:
/var/www/html/cockpit/ ← Web root (PHP backend + frontend)
├─ index.html ← UI
├─ bridge.php ← Stream/poll/cleanup
├─ files.php, status.php, ... ← Other backends
├─ capabilities.php, orchestrator.php, ...
├─ paths.json ← Where cockpit_data lives
├─ workers_providers.json ← Worker provider catalog (seed)
└─ tools_builtins/*.json ← Tool definitions (seed)
~/scripts/ ← Scripts run by Apache user
├─ cockpit_start.sh, cockpit_stop.sh
├─ agent_loop.sh ← Per-agent dispatch
├─ crud_executor.sh ← %%CRUD%% / %%TOOL:%% / %%WORKER:%%
└─ cockpit_data/ ← Per-user state
├─ library/, snippets/, sources/
├─ capabilities/_builtin/
├─ workers_state.json
├─ workers_keys.enc ← Encrypted API keys
├─ workers_usage.json
├─ tools/, tools_outputs/
└─ tools_state.json
~/Software/Programing/LocalAIProjs/ ← Projects root
├─ <project>/
│ ├─ chat_<name>.json
│ ├─ capabilities.json ← Per-project enabled caps
│ ├─ orchestrator.json ← Per-project plan settings
│ └─ plans/plan_<id>.jsonMost files are JSON; edit them directly with xed if
needed. The cockpit re-reads configuration on each request, so changes
take effect immediately (except agent capabilities, which require a
session restart).
This section covers features added after the original guide. Everything here is local-first and offline unless noted.
Global standing rules that are prepended to every supplier’s context at dispatch — Claude, Gemini, Ollama, and text Workers alike. Write once; they apply everywhere.
COCKPIT.md and layer on top.cockpit_data/directives_global.md (+
_compact.md, _config.json).The mic Voice button records your microphone and transcribes it locally with whisper.cpp — audio never leaves the machine.
HE to force
Hebrew (otherwise it can be mistaken for Arabic);
Auto/EN/ES for the rest.Auto uses the largest). The button
tooltip shows the active model.Each supplier card’s dropdowns are driven by a JSON file, so options can be changed without touching code.
claude --effort <level> flag:
low, medium, high, xhigh (Extra), max.cockpit_data/claude_controls.json /
gemini_controls.json) in the editor. Add an option to the
options array, Save, and it appears in the dropdown.Snippet/source/file editing now uses a draggable, resizable floating editor with:
Capability enablement is a single global on/off per capability — it
applies to all projects, free chats, and every supplier
the capability declares (the CLAUDE/GEMINI/OLLAMA badges are
informational, set by the capability’s CAP.json).
CAP.json in the editor) and delete.time capability (uvx
mcp-server-time).In Workers settings, Discover probes each provider’s
/models endpoint and shows the full list. Click
+ next to a model to make it
selectable (it’s added to that provider, text kind). A
filter box narrows long lists.
See Comprehensive help system below for the full, current description.
A scheduled job left “running” for more than 15 minutes (its worker died) is now auto-marked failed, so the Jobs badge no longer shows stale “running” counts.
The same provider can be reached two ways: as a supplier (CLI subscription, via tmux — Claude, Gemini, Ollama) and as a worker (HTTP API, BYOK). Alongside the free-tier workers (Groq, OpenRouter, …) you can now add three paid API workers: OpenAI (ChatGPT), Claude (Anthropic API), and Gemini (Google API). The CLI supplier roles are untouched — this is purely additive.
Because these cost real money per call, they sit behind a deliberate safety stack (all enforced server-side, so no UI state can bypass it):
Why bother: a free/alternate API key can pick up when your paid CLI subscription hits a limit, and a Broadcast can fan out across mixed-cost providers at once.
Pricing is editable per model (via the provider’s controls); until provider cards carry pricing, edit the input/output rates in the worker config.
Cockpit replaces all native browser right-click menus with themed, app-native context menus that follow the active theme.
Input fields (text inputs, textareas, dropdowns) retain the native browser menu for paste and spell-check.
All confirm() and prompt() browser dialogs
have been replaced with Cockpit-native modals that follow the active
theme.
true/false.null.All modals use CSS variables (--bg-base,
--border-mid, --text-base,
--accent-*) — they adapt to every theme automatically,
including dark, light, and custom themes.
Completed, halted, or failed plans now show a Re-Run button in the plan toolbar. Clicking it resets all steps to "pending" and restarts execution from step 1. Previous step results are cleared. Confirmation is required before re-running.
When paid API spend reaches 80% of any configured cap (global or per-model), a system message warns you in the chat. Warnings are checked after every paid API call and include the current percentage and cap value.
The Model Manager (F8) now includes a runtime knobs panel at the bottom:
| Knob | Default | What it controls |
|---|---|---|
keep_alive |
5m | How long models stay loaded in memory after last use |
num_ctx |
4096 | Context window size in tokens (higher = more VRAM) |
num_parallel |
1 | Concurrent requests per loaded model |
max_loaded |
1 | Maximum models loaded simultaneously |
Click Save knobs to persist to
cockpit_data/ollama_config.json. Values are read by
agent_loop.sh on session start via environment variables
(OLLAMA_KEEP_ALIVE, etc.). Restart agent sessions for
changes to take effect.
Generate media locally using your GPU — no internet, no cost.
| Type | Engine | Time | Output |
|---|---|---|---|
| Image | stable-diffusion.cpp (SD 1.5) | ~20 sec | PNG with presets: Logo, Icon, FavIcon, Background, Image |
| Sound | Piper TTS | ~5 sec | WAV spoken audio from text |
| Video | sd.cpp + ffmpeg | ~2-3 min | Animated GIF from varying-seed frames |
Results appear inline in the chat with Save/Download/Delete buttons.
All files go to cockpit_data/generated/.
Translation uses local LibreTranslate — no data leaves your machine.
The Track button starts/stops a timer for the current project.
Three toolbar buttons provide embedded panels without leaving Cockpit:
Extracts reusable knowledge from PDFs and documents using a local pipeline:
Panel tabs: Queue (pending files), Results (processed documents), Health (pipeline checks). Click Run to process. Progress is shown live.
Skills are reusable prompt templates with auto-trigger capability.
SKILL.md
files in cockpit_data/skills/<name>/ directories with
YAML frontmatter.The Summarize button generates a summary of the current chat session using the active agent. The summary appears as a new message. Useful for creating a recap before switching tasks or sharing context.
The Caveman toggle (bottom-right of prompt area) controls token compression for online suppliers (Claude, Gemini, Workers). Ollama (local) is never affected.
| Level | Effect | Savings |
|---|---|---|
| Off | Normal prompts and responses | — |
| Strip | Removes filler words, articles, pleasantries from your prompt before sending | ~30% |
| Strip+AI | Strip mode + asks the agent to respond in terse caveman style | ~60-75% |
The help system has been expanded to cover every Cockpit feature:
data-help attributes
across the UI (an ancestor's attribute covers all its children, so most
panels are wired via one attribute on the panel itself).Multi-model recipes — several small local models run
together on one task and merge into a single answer,
instead of one model answering alone. Works with Ollama models,
LocalAI models, or a mix of both (see "Dual-mode" below).
705 combos across 8 categories — 150 free (50 per
backend: Ollama, LocalAI, Dual) plus 555 more (185 per backend), free
with a (free) Starter account. Full per-combo descriptions live in
cockpit_data/ Cockpit_AllCombos_Reference.md (quick lookup
table) and Cockpit_AllCombos_Explained.md (detailed
rationale per combo) — too long to usefully inline here.
| Pattern | What happens |
|---|---|
| Parallel | Several models answer the same prompt independently; results shown side by side (or merged). |
| Sequential | Models run in a chain — each sees the previous step's output. |
| Judge | Parallel candidates, then a judge model picks/synthesizes the best answer. |
The Ollama and LocalAI dropdowns each have their own combo catalog
and identical layout — a master row (total count, filter box, "+ new",
⊟/⊞ collapse-all), a categorized Combos section (star favorites +
one group per category, same 8 categories either side), a Needs
both backends section for combos whose steps mix both servers
(merged — a dual combo shows up in both dropdowns regardless of
which catalog it's actually saved in), then the model list. Ollama's
catalog is combos_ollama.json; LocalAI's is
combos_localai.json; Dual's is
combos_dual.json (merged into both single-backend views
too) — same schema, same editor, kept separate since a "combo" is really
"a recipe of model names," and the backends don't share model names.
Both Ollama and LocalAI run at the same time — installing AI Cockpit sets up both, no separate choice needed. A combo can mix steps from both: each step in a combo carries a small O/L tag showing which server it runs on, and steps tagged for different servers genuinely run in parallel (not switched back and forth) when the combo's pattern allows it. Before a combo runs, a quick pre-flight check confirms every server it needs is actually reachable — if one isn't running, you get a clear "X not reachable" message instead of a partial, confusing failure partway through.
The same idea works outside Power Combos too. Card 3's model list shows every Ollama model and every LocalAI model together — pick one of each and both stay loaded at once, VRAM permitting. Picking a third model while both slots are full triggers a real fit-check: if the two wouldn't fit together in your detected VRAM, the other slot is freed automatically instead of silently over-committing.
With only one model picked (either backend), chat works exactly as before — nothing changes unless you actually fill both slots. With both filled, sending a prompt first asks each model to rate its own confidence (a quick 1–10, not a full answer) — you'll see both scores, then choose: use one model's answer, or run both together as parallel / sequential / judge, the same patterns Combos use.
Known limit: LocalAI has no confirmed reliable "unload model" API, so clearing its slot updates the app's own tracked state honestly but can't guarantee the model actually leaves memory yet — the UI says so right next to the LocalAI chip.
The 150 free combos ship plaintext across
combos_ollama.json, combos_localai.json, and
combos_dual.json — no account needed, works on any machine.
The other 555 (and any future curated packs) are encrypted at
rest in combos_store.enc, the key derived from
this machine's ID + your account's license key — a copied file is inert
on someone else's install. This stops casual
copying/redistribution; it doesn't and can't stop a determined person
reverse-engineering a combo's idea by watching it run — that's an
accepted, honest limit shared by every local-execution product, not a
Cockpit-specific weakness.
If a protected pack exists on disk but fails to decrypt (wrong machine, expired/missing license), Tier-0 shows an amber warning instead of silently returning fewer combos.
Click ＋ new in either panel's master row to build your own — id, name, pattern, category (pick one or type a brand-new one, which creates that group on the fly), description, and steps. Each step has its own model dropdown (populated from your actually-installed Ollama and LocalAI models — not free-text, so you can't accidentally reference a model you don't have) and its own backend picker (Default / Ollama / LocalAI) — set different steps to different backends and you've built a dual combo, which then shows up under Needs both backends in both panels. Add a judge model + instructions for judge-pattern combos, same dropdown-driven picker. Saved instantly as plain JSON, never encrypted — it's already yours, nothing to protect you from. Edit (edit) or delete (delete) anything tagged · mine — the edit icon works even when the combo is currently missing a model, since that's exactly when you'd want to open it and fix the model pick.
Publish to the Marketplace (Account panel → Marketplace → ⊕ Publish → kind My Combo, pick one of yours) to let others download it — requires a (free) Starter account, same as publishing a Skill or Tool. Unlike the admin-curated 185, your published combos are not admin-gated — publishing your own combos is open to any registered user.
Downloading someone else's combo merges it into your own Tier-0 (tagged · by <name>). Before it downloads, Cockpit checks each of its models against your actually-installed Ollama and LocalAI models (each model checked against the specific backend it actually runs on, for a mixed-backend combo) and shows which you're missing, so you can back out instead of downloading something you can't run yet — the same missing-model check already applies after download too (a combo needing an unpulled model just shows greyed-out, hover for which model is missing from which backend — whether it's built-in, protected, or user-authored). Published something by mistake? The languageclose icon on your own published combos pulls it from the Marketplace; your local copy stays.
Standing rules that automatically hand off matching tasks to a different supplier/model/combo before the normally-selected agent continues — the delegated result gets folded into your prompt as context, then the original dispatch proceeds. Works identically no matter which mode (Single/Pipeline/Broadcast/Plan/Combos) is active, since every prompt funnels through one shared dispatch point.
Not the same as the Rules (Directives) button — Directives inject static context into every prompt for every supplier; Delegate routes specific tasks to a different supplier.
Worker (REST API provider), Power Combo, or a specific Ollama model. Tool-kind targets are file-in/file-out (ffmpeg/whisper/etc.) and aren't supported for automatic prompt delegation — that needs a file attached first, a different flow.
Toolbar → Delegate → + New Delegation Rule → name it, list keywords/phrases (comma-separated), pick what it delegates to. Toggle rules on/off or delete them from the same panel.
One Cockpit install can serve several people (family, work profiles) with fully separate data — not just a login screen, genuinely separate tools/skills/combos/chat history/Cockpit Account subscriptions per person.
Account card (top-right of the supplier strip) → Users button opens the User Manager: add a new local login (username + password + role), see who's registered, remove one. Each local user gets their own data folder automatically on first login — nothing to configure.
Sign out (account card) and the next person logs in with their own credentials. Switching users tears down any running agent sessions in the background — the incoming user starts clean and clicks Start themselves; live agent sessions (the tmux processes) are still machine-wide, not per-user, so this avoids landing mid-conversation in someone else's chat.
Same account card → Pass button — changes the local login password (not your Cockpit Account/SaaS password, which is separate — see below).
Your online AI Cockpit account — separate from the local login above. Click the license status text (top-left) or the account chip (top-right of the supplier strip) to sign in, register, or manage it.
Full edition (V2): yes, once. On first run Cockpit shows an account panel with no close button and waits. A free account is enough — there is no card and no paid step — but the install has to be registered before you reach the app. The server, not the app, decides this: it checks whether this machine is registered to an account, so editing local files does not get around it.
Stand-alone edition (V1): no, ever. V1 makes no network calls at all and has no account layer. If you want Cockpit with no registration, this is the edition to install — it is the same download, you just choose Stand-alone when the installer asks.
Once past that, the account layer itself is still only about the online/shared-content side: marketplace, subscriptions, credits. Your local features — agents, models, tools, media, projects — neither check it nor report to it.
If the account panel appears on an install that was signed in, it means the server could not confirm this machine. Sign in again; if the network is simply down, a previously validated licence keeps working offline.
Free / Starter / Basic / Pro / Ultimate — shown as a chip next to your account name. Starter (free, with an account) unlocks the community Marketplace; Basic adds Autopilot Cruise; Pro adds AutoCognition; a Starter account also unlocks all 705 Power Combos; Everywhere (an add-on, included in Ultimate) unlocks remote-control relay to this machine from another device.
Browse and download community skills/tools/themes/prompts/worker cards/pipelines, and Power Combos. Downloads install straight into the matching local panel — no manual file placement. ＋ Publish lets you share something you made (combo publishing is admin-curated, not open upload).
Profile, registered machines (deregister old ones), and your subscription/renewal choice — all in one Account portal.
Change user (account modal) switches between several registered Cockpit Accounts on this machine without re-entering credentials — a roster, separate from the local-login "Users" feature above (you can have several local logins AND several SaaS accounts; they're independent systems).
Your subscription tier lives on the Cockpit server, tied to this
machine. If you reinstall your OS (or move to a new machine), the local
license is gone and Cockpit would otherwise drop to Free. To get back
in, use your recovery token — a one-time secret
(CRT-XXXX-XXXX-XXXX-XXXX-XXXX) shown once, right after you
first created the account. Save it in a password manager.
To recover: open the account modal and start creating an account with the same username and email — Cockpit detects the existing account and switches to the recovery form — or click "Reinstalled or new machine? Recover an existing account" on the sign-up screen. Enter username, email, and the recovery token; your real tier and license are restored and this machine is bound. Lost the token? An admin can reset it (issuing a new one) — the old token can never be retrieved, only replaced.
Card 1 ("Claude") and Card 2 ("Codex") aren't hardwired — each slot can be reassigned to a different paid CLI supplier (e.g. Qwen Code) or a free agent (Aider, Goose, opencode) on your local models, or, for Card 2, a free REST fallback (Gemini's free-tier key, Groq, etc.).
Gear/tune icon on the supplier card, or the Slots
button on the account card. Pick a different supplier from the catalog
(cli_suppliers.json, user-editable) — the card's displayed
name, its model dropdown, the status pill, and the "Open CLI in
terminal" button all follow the assigned supplier automatically.
A REST-only fallback (no local binary) hides the CLI-launch button automatically; a genuine CLI alias (has a binary) keeps it, retitled.
Card 3's slot works the same way, with its own option list: Ollama, LocalAI, or Dual — Ollama + LocalAI. Picking plain Ollama or plain LocalAI gives you that one backend only, same as before this option existed. Picking Dual is what turns on everything described above under "Dual-mode" and "Dual-model regular chat" — the merged model list, the O/L chips, and mixed-backend combos. Switching away from Dual hides all of that again and restores the single-backend picker.
Long-running autonomous goals that keep working while you do something else — set a goal, Cockpit keeps making progress on it in the background instead of blocking the console for one prompt at a time.
Cron-driven recurring tasks (e.g. "summarize new files every night at 2am") — separate from the Orchestrator's own one-off "Schedule" option inside Plan mode, which is for scheduling a single plan, not a repeating job.
Batch audio/video → text extraction (local whisper.cpp), beyond the quick mic-dictation button in the prompt bar. Analyze a file, compile the transcript, download it, or export as HTML.
↑
↓