. | .
\|/
.--- 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.
Only one edition runs at a time. If you start one while the other is running, a dialog says so and offers Switch (stop the other and start this one), Cancel, or Close all running sessions (shut everything down and start nothing — the way out when the running edition cannot close its own sessions). Each edition names its window (AI Cockpit / AI Cockpit V1), so launching one again raises the window that is already open instead of starting a second.
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.
Cockpit opens in its own native window (cockpit_shell, a
small open-source program shipped with the app — sources in
~/scripts/cockpit_shell_src/, Apache-2.0). It is a window
and nothing else: no address bar, no tabs, no extensions. Links that
lead outside the app (ruggi.site, the guides) open in your normal
browser.
Every way of closing it runs the exit procedure. The window’s close button, Alt+F4 and the dock’s Quit all open the same Leaving Cockpit dialog as the Exit button in the topbar: it shows what is still running (tool runs, replies in flight, agent sessions) and offers Kill processes, Terminate sessions, Terminate and leave, Wait for completion / Stay, or Leave anyway. The window closes only when you choose to leave. If the app itself is not loaded (server down), a close request simply closes.
Keys. F11 fullscreen ·
F5 or Ctrl+R reload ·
Ctrl+Shift+R (or Ctrl+F5) reload bypassing the cache.
The window remembers its size between launches, and
COCKPIT_KIOSK=1 cockpit-start runs it fullscreen without
decorations for a dedicated screen.
Window controls live in the sessions card (top
right, native window only): Reopen closes and reopens
the window (applies a frame change under Wayland, picks up a new
cockpit_shell after an upgrade), Reload
hard-reloads bypassing the cache (a deploy triggers it by itself),
Refresh re-reads status, account and machine state now,
and ⛶ turns the frame off and on — live on X11, on
Reopen under Wayland and WSLg. Frameless, the ▁ ▢ glyphs beside
Exit minimise and maximise; double-click the header to
maximise. The window also has three buttons of its own,
– minimise, □ maximise / restore and
× close (the same exit procedure as the window’s close
button): move the pointer to the empty strip along the right edge, near
the top, and they appear over the top-right corner; move away and they
go. They never appear while the window has a normal title bar. With no
title bar, the border is the handle: thin invisible
strips run along every edge and corner, and the pointer changes when you
are on one. Drag an edge or a corner to resize; the middle 15%
of each side has a different pointer (the move cross) and
moves the whole window without resizing it. A maximised
window ignores both. The other windows the shell opens
(the Cockpit Browser, and the window of a web page worker when it comes
on screen for a login) show other people’s pages, which cannot draw
handles, so when you run frameless the shell lays the same strips over
their border itself: drag an edge or corner to resize, the middle of a
side to move, and Ctrl+W to close a Browser window (a
worker’s window is only put away). Move the pointer into the
top-right corner of such a window and three buttons
appear: – minimises (bring it back from the taskbar or
with Alt+Tab), □ maximises and restores,
× closes a Browser window (a worker’s window is only
put away). Minimised Browser windows are listed at the
right end of the status bar, one small chip each (the page’s title, with
its address and a hint when you hover): click a chip to bring the window
back, or right-click it for Restore and Close
window. The list is kept by the shell on your machine, one
small file per window, and a window that is gone drops off it by itself.
The window also remembers its position and monitor. In a plain browser
these controls are hidden.
The rig line under the strip names the OS, desktop, terminal and file manager Cockpit found (e.g. Linux Mint 22.3 · Cinnamon · gnome-terminal · nemo), then the CPU, RAM and GPU — what the Terminal, Files and Browser buttons will open. With no browser installed the Cockpit Browser (this window in plain-browser mode) is registered as the system browser at install time.
One key from anywhere. Ctrl+Alt+C
brings Cockpit to the front from any application; press it again while
Cockpit is in front and it goes back down. When the installer registered
the desktop shortcut (Cinnamon, GNOME, XFCE, KDE or MATE —
~/scripts/install_hotkey.sh, --remove to undo;
not on WSL, where Windows owns the keyboard — use the Start-menu
shortcut), the same key also starts Cockpit when it is
not running. Without that shortcut the app grabs the key itself while it
runs; change it with COCKPIT_HOTKEY="super+c" cockpit-start
or switch it off with COCKPIT_HOTKEY=none.
It can bring Cockpit up by itself. Opened when
nothing is running (at login, from the dock, with the shortcut), the
window shows a boot screen, starts the web server and the agent
sessions, and loads the app as soon as it answers — if that takes too
long it says so and offers Try again instead of sitting there.
The installer can add an “open at login” entry
(~/.config/autostart/ai-cockpit.desktop; delete the file to
stop it).
It checks the build before it runs it. Each launch
the window hashes the shipped files that decide what runs
(index.html, every css/ and js/
file, auth.php, paths.php,
integrity_lib.php) against the build manifest; if one
differs it says so and does not load the app — a tampered page cannot
vouch for itself. COCKPIT_NO_VERIFY=1 cockpit-start skips
the check.
Notifications and a tray icon. Finished work raises real desktop notifications with an Open Cockpit button: an agent reply or a Tools run that finished while the window was not in front, a plan ready, the Accumulator or Transcriber done. Nothing pops up while you are looking at Cockpit. The tray icon offers Show / Minimise / Exit Cockpit… (Exit runs the exit procedure). On GNOME the tray needs the AppIndicator extension — the installer enables it when present; KDE, XFCE, Cinnamon and MATE show it as is.
Files keep their real path. Drop a file on the prompt, pick one with the paper-clip Attach button, or paste one you copied in the file manager: it is attached by its path — the native file dialog opens, nothing is uploaded or copied through a browser. The Tools card’s file chooser fills the path field directly. A file dropped elsewhere on the window (not on the prompt) opens in Cockpit’s floating editor, where you can edit and save it in place. In a browser window the file is uploaded instead, as before.
The window talks to the desktop. Next to a path in the chat you get open folder (the file manager with the file selected), open a terminal here, and open the file — the desktop’s own calls, made as you, not handed off to the web server. The agent cards’ session buttons open a terminal attached to that tmux session. The GPU meter in the status row reads the driver itself: hover it for GPU busy, VRAM, CPU and RAM.
Panels in their own window. Every sidebar panel’s title bar carries a small open_in_new: click it and that panel — Preview, Code, Attachments, Files, Usage, Plans — opens as a separate window you can put on another monitor. It is the same panel, kept current on its own; Escape or Ctrl+W closes it, and closing it changes nothing in the main window. Up to six at a time, and only Cockpit’s own pages can be opened this way.
Signing in without typing. The local login form has Keep me signed in on this computer (on by default). Cockpit then issues a sign-in token for this device and the window stores it in your OS keyring (GNOME Keyring or KWallet, through libsecret) — not in Cockpit’s files, not in a cookie. At the next launch the window presents the token and you are in without typing; Sign out revokes it on the server and removes it from the keyring. Tokens expire after 90 days.
Fill from Bitwarden. Cockpit’s own login forms (the
local app login, the Cockpit account login, the admin-token box) carry a
Fill from Bitwarden button. It uses the official Bitwarden CLI
(bw, offered by the installer;
~/scripts/install_bw.sh later) — run bw login
once in a terminal. The first fill of a session opens a small terminal
where you type your master password into bw itself;
Cockpit never sees it, and the vault session lives only in the window’s
process. Items are found by name: AI Cockpit Local,
AI Cockpit SAAS, AI Cockpit Admin Token
(anything containing “AI Cockpit” is offered in a chooser when there is
no exact match).
If the native window cannot run on a machine (no WebKitGTK 4.1
runtime, or a CPU the prebuilt binary does not cover and no
fpc to rebuild it), cockpit-start falls back
to a browser app window; there, the close button bypasses the exit
procedure — use Exit — and everything above that needs
the window is simply absent.
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).
The top bar on a smaller screen. From 1100 pixels wide the controls on the right (Help, Theme, About, Tour, Profile, Slots, Apps, Exit, Restart) always stay on screen; it is the row of supplier cards that gives way and scrolls on its own. Latency (the small “⇄ N ms” figure) measures the round trip to your own router by default, so it never contacts anything outside your network; click it to choose another host (a public address is then a call out of your machine, and you chose it). The server clock row is shown only in the Full edition while you are signed in, and is asked of your account server through Cockpit; the Stand-alone edition contacts no server at all.
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 and sidebar, every tab on both sides and every Toolbar button (sixty-odd steps) — with Next / Back, Esc to leave, F1 for the matching help topic on any step. The tabs and Toolbar buttons come in three short sections, and Skip section on any of their steps jumps past the rest of that section. The tour opens each tab itself as it goes and puts your own tabs back when it ends.
The cockpit window has four regions:
┌──────────────────────────────────────────────────────────────────┐
│ TOPBAR — 5 supplier cards · Exit/Stop/Restart · Clock · Settings │
│ Project / Chat / Path · Account · Help · Tour │
├──────────┬──────────────────────────────────────┬────────────────┤
│ 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 — 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 agent’s session itself keeps running: before this was fixed (October 2026), pressing Stop also ended the agent’s loop, the card still said “session running”, and every later prompt sat unanswered until the session was restarted.
The Up arrow key in the empty textarea brings up your previous prompt for quick edit-and-resend.
Finding an earlier prompt. The History button in the prompt box (the clock icon, beside the microphone), or Ctrl+R while the prompt box has the focus, opens a list of everything you sent before. Type to filter it (every word you type must be in the prompt, in any order); ↑ ↓ choose, Enter puts the prompt in the box (it does not send it), Esc closes. The three tabs set the scope of the history, and the ↑ ↓ keys in the prompt box use the same scope: This chat (the default), This project (every chat of the project) or Everywhere (every prompt you have typed in Cockpit, so one you entered in another project can be reused here). Each chat keeps its last 200 prompts on this browser; the wider scopes show each distinct prompt once. Tab switches the scope while the list is open.
Small screens. Cockpit is a desktop program and does
not squeeze itself into a phone layout. In a window narrower than 1100
pixels (or shorter than 580) the whole app stays at full size and the
window scrolls sideways or down, whichever way the app is bigger. On a
phone or small tablet the first screen says what Cockpit is (in the web
demo, with a short tour in pictures) and offers Open it
anyway: it then opens the whole app, scaled to fit, and you
pinch to zoom and drag with two
fingers to move around; turning the phone sideways gives more
room. The old narrow layout (hamburger menu, sidebars as overlays) is
still there for anyone who prefers it: add ?compact=1 to
the address.
Filters and Find. Every list in the two sidebars has a filter box on top: Files, Code, Config, Capabilities, Plans, Artifacts, Attachments, Usage, Proposals, Toolbar, and the results of a web Search (the lists that already had a search keep it). Type words to hide what does not match; clear the box (or press Esc) to bring everything back. In the Files list a folder opens by itself while a file inside it matches. The Preview has its own Find in the preview bar at the top: type to highlight every match in the previewed text, Enter or the arrows step through them, and Ctrl+F while the Preview has the focus opens it.
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 need the Plus plan; 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 14 vertical icon tabs:
| Tab | Purpose |
|---|---|
| Toolbar | Every quick-launch tool in one place, in alphabetical order — see The Toolbar. |
| Proposals | Agent suggestions (file edits, commands) awaiting your approval. A count shows on the tab icon from any tab. |
| 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. |
| Artifacts | Everything this project produced — files agents wrote, generated images/audio/video, tool outputs, transcripts, approved snippets — with size, time, source and, where a chat named the file, which chat/agent/model. The line says made by only when a tool reported writing the file with its full path, and mentioned by when a chat merely talked about it — provenance is read from what was said, so it is a label, not a record. Open, reveal or delete. |
| 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.
Approve or reject proposals individually or in batch from the Proposals tab.
The Toolbar tab (the wrench, first in the right sidebar) holds every quick-launch tool, in alphabetical order so the one you want is easy to find: Accumulator, Bookshelf, Browser, Delegate, Dossier, Files, Image, Jobs, Keys, Notepad, Rules, Skills, Sound, Summarize, Tasks, Terminal, Track, Transcriber, Translate chat, Translate text and Video.
Counts sit on the buttons they belong to, as small chips:
3/3.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.
One built-in works the other way round: Use my global CLI config is off unless you turn it on. With it off, a CLI agent the cockpit starts (Claude Code) runs against an isolated, cockpit-owned config directory that holds only your login — your personal hooks, plugins, skills and global memory are not loaded, so what comes back is shaped by the cockpit’s Mode and Style alone. Your login is symlinked in, so you never sign in twice.
Turn it on when you want the agents to inherit your own setup.
It exists because the alternative is genuinely surprising: a
caveman-mode SessionStart hook installed for the terminal
was rewriting every cockpit answer on the developer’s own machine while
the Style selector said “Build (default)” — the hook, not the cockpit,
was in charge.
The agent list is data, not code. Slots → Agents on this
machine → Add new writes an entry to
cockpit_data/cli_suppliers.json, which is merged over the
shipped defaults and picked up on the next prompt — no rebuild, no
reinstall. You give it an id, the binary name (a name on
PATH, not a path), the prompt flag, and optionally a
subcommand and extra flags.
The last field is the interesting one: how the agent is given a picture. Reading the CLI’s documentation is not enough, because an agent that cannot see an image does not say so — it invents a description. So the editor has a “Can it see?” button: it runs that agent against a small shipped image of a red triangle and a blue circle, scores the answer, and shows it to you. Keep the mode only if the answer is actually right.
Until an agent has been tested this way it stays on Describe locally, where a local vision model writes what it sees and the agent reads that text — lossy, but never invented.
| 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 needs the Plus plan.)
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 (Plus plan); 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.
Cockpit can also be called. Hive → A2A
exposes the A2A protocol subset (agent card, message/send,
task state, cancel) so another agent — or another Cockpit on your
network — can hand this one work.
It is off until you switch it on, because a peer’s message is dispatched to your active agent and can write into your projects, exactly like a prompt you typed. When you turn it on:
X-Cockpit-A2A-Token (or
Authorization: Bearer …),192.168.1.0/24, or
*); the default is this machine only,X-Cockpit-Encrypted: 1.Treat the token like a password; New token revokes the old one instantly.
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> pairsname=value pairs; put
a path that contains spaces in quotes,
with="/home/me/My Project/list.csv"; a file named without a
folder, such as with=list.csv, is looked for next to the
input file)If 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.
Books filed by Bookshelf show as one row per book, folded away: click the row to unfold its chapters (a book you have opened stays open while you work), or press Remove book on the row to delete all of its chapters at once. A novel is dozens of chapters, so the Library shows your books rather than reciting them.
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).
Search engines increasingly refuse automated queries. On some networks every engine answers with a bot check or an error, so a search can come back empty even though your connection is fine. Cockpit now says which engine refused and why, instead of blaming the network. The B and D buttons below open the engine in a real browser window, which still works.
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 |
|---|---|
| Enter | Send prompt to active agent (Shift+Enter or Ctrl+Enter: new line) |
| Esc | Cancel current request / close the open dialog (asks first if you typed something in it) |
| Ctrl+F | Search in chat console (or find/replace in editor) |
| ↑ / ↓ | Cycle prompt history (in empty prompt box; scope = chat, project or everywhere) |
| Ctrl+R | Filter and pick an earlier prompt (in the 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. Press it to start, press it again to stop. The words land in
the prompt box, editable before sending, and a line under the chat says
how long you recorded and which whisper model ran — for
example whisper.cpp · large-v3-turbo.
You can see it working. While you record, a bar with a pulsing red dot opens to the left of the button and moves with your voice, and the button itself fills as the level rises. “Nothing happened” has several causes that all look the same — a muted microphone, the wrong input, a quiet room — and the bar tells them apart: it moves, or it does not.
The ▾ menu beside the button holds three labelled choices and a test:
Auto uses the model pinned in
whisper_config.json, else the largest installed; the label
shows which one that is, and the result line always names the model that
actually ran.If a microphone you picked earlier is no longer there, Cockpit forgets it, says so, and uses the default input instead of failing.
Requires whisper.cpp + a ggml model (see the Setup Guide).
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.
The model lists and prices that ship with Cockpit are a snapshot, and they go out of date. Three things keep them useful without waiting for a new Cockpit build:
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):
cockpit_shell --worker)
loads the site where you cannot see it, types your
prompt into the site’s own box, presses the site’s own send button, and
brings the answer back to the chat as it appears. Every send starts a
fresh page (Cockpit already includes the earlier turns in the prompt),
and the answer’s token count is an estimate. Things to know:
webworkers/<site>/profile) and send again. Cockpit
never types a password and never tries to pass a “prove you are a
person” check: it shows the window and waits for you. After a login or a
check that worker is left alone for 30 minutes so a window does not keep
popping up.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 text of Cockpit’s own screens can be shown in your language, and you can write the translation without leaving Cockpit.
fr,
pt-BR), its English name, its own name, the direction
(left-to-right or right-to-left) and your name.gemma3:4b;
bigger models translate better and slower: expect about 2 to 3 seconds
per line on a small graphics card, so a whole language takes hours and
can run in the background while you do other things). It starts with the
page you are on. A draft is not text yet: it appears as
grey, slanted text in its box. Press Tab in an empty
box to make that line’s draft real text, or use Accept
page (the drafts on this page) or Accept all
(asks first). Stop keeps what is drafted so far;
Drop the drafts throws them away; Draft this
line under a box drafts just that one. A draft whose
{placeholders} differ from the English is never offered.
Always read the drafts: they are a start for a person who knows the
language, not a finished translation.lang folder of your Cockpit data folder; updates never
touch it. Use this language switches Cockpit to it at
once. Download my file saves it as a .json
to share or keep; Upload a file merges one in (it is
checked first).The rules (they are also behind the Rules button in the Studio):
{placeholder} exactly as written
({name}, {n}). You may move it inside the
sentence. The box turns red when one is missing or changed, and such a
line is not saved..json) or keyboard keys.&mirror=1 to the address.By hand: Or download the empty template in the same
menu (the file carries the rules and how to send it back inside its
_meta) (or
lang.php?action=template&code=he for a language’s own
file with what it already has filled in), translate the empty values,
save the file as <code>.json in that folder and
reload. The downloaded file is a plain .json: keep it, or
hand it to anyone who uses Cockpit, who puts it in the same folder. To
have it included in Cockpit for everyone, press Send it to
us in the Studio (it opens cockpit.ruggi.site/translate.php,
where you choose the file and send it; the owner reads it before
anything ships).
The Track button starts/stops a timer for the current project.
Lazarus stays your IDE; Cockpit sits beside it. Two things make that work:
.pas .pp .inc .lpr .lpi .lpk .lfm .lrs .dpr .dfm) the
viewer shows a Lazarus button when Lazarus is
installed. It opens the file — and, when the folder holds one
.lpi (or the .lpi named like the
.lpr), that project with it. On a machine set up before
this feature, the installer or the next Cockpit deploy has to grant
Cockpit permission to start Lazarus; until then the button says so
instead of doing nothing.A project can say what it is. The small badge beside
the project’s goal in the info bar shows the kind; click it to choose
one of the 49 kinds that ship, listed in 10
fields: General; Writing & documents (10,
from Creative writing and Academic paper to Legal review and Meeting
notes); Home & life (10: Cooking, Gardening, Pets, Health
log, Collections, Genealogy, Hobby crafts, Tabletop, Travel, Home and
DIY); Software & games (6); Media (7, with Music
practice); Research & learning (4, with Teaching);
Hardware & making (3: 3D printing, Electronics, Arduino);
Data & numbers (3, with Personal finance); Work &
community (3: Job search, Non-profit and events, Real estate);
System & servers (2: System administration, Shell and
DevOps). Kinds are open-ended: see Making your own kind below.
Each kind carries a short standing note that is sent with every prompt
in the project, beside the goal — for example, that a Lazarus project is
judged by the compiler and should change a .pas and its
.lfm together, or that a Godot project must use the API of
the version named in project.godot. The chooser also
detects the kind from the folder (a .lpi,
a .vbp, CastleEngineManifest.xml,
project.godot) and marks it as suggested. Kinds are plain
data files in the app’s kinds folder. Every kind except
General names the tools it works with, and the
picker shows which are installed.
The picker is two panes. On the left the kinds are listed in
fields (Writing & documents, Media, Research &
learning, Data & numbers, Software & games, Hardware &
making, System & servers, and any field you make for your own
kinds): click a field’s name to fold or unfold it, or type in the search
box to find a kind by its name, description, explanation or examples. On
the right, the selected kind is explained: what it is, a longer
About this kind text, Examples of
projects that fit it, what judges the work, the files that identify it
and the tools it uses. Double-click a kind (or press Save) to choose it.
Export at the bottom saves the selected kind, shipped
or yours, as a .kind.json file; Import
reads one back. To change a shipped kind, duplicate it into your own
kinds (or export, edit and import it: yours then replaces it for
you).
Starter files. A kind can carry up to 12 small
starter files (a README, an outline, a template; each up to 20,000
characters, with relative paths such as chapters/01.md).
When a project is open, the kind’s page in the picker lists them with
Add these to this project…. You see exactly which files
would be created and which already exist, you confirm, and only the
missing ones are written: an existing file is never overwritten, and
nothing can be written outside the project folder (a link inside the
project that points elsewhere is refused). Writing, Research, Meeting
notes, Study and Learning and Podcast ship with starters. The starter is
part of the kind, so Export and Import carry it; you edit them in the
+ New kind… / Edit wizard: a Starter
files list (a file name and its text for each, up to 12, with
Add a file and ×), or in an exported .kind.json (a
"starter": [{"path": "...", "content": "..."}] list).
A kind that carries its own tool. A
.kind.json may hold a "tool_defs" list (up to
4 tools of up to 8 presets each) for a command-line program the kind
needs, so a brand-new kind with a brand-new tool needs no change to
Cockpit. Only a narrow form is accepted: a plain program name found on
your PATH, and commands made of that program, plain arguments and the
placeholders {INPUT}, {OUTPUT},
{ARGS}, {NAME}; no quotes, pipes, redirects,
$(...), .., helper scripts, options that run
another command, and no shells, interpreters or launchers
(bash, python, env,
sudo, curl and similar). A tool whose name is
one Cockpit already ships is refused. Import shows you every
command and asks before anything is installed; the tools then
go into your own tools (Tools panel, where you can delete them), and a
tool that belongs to one kind is never replaced by another kind. The
wizard has a Tools this kind carries box (JSON,
advanced; leave it empty for none): saving shows you every command and
asks first, and emptying the box on a kind that had tools
removes them from the kind (the tools stay in your Tools panel,
where you can delete them). Re-saving a kind without touching the box
keeps its tools. The same checks apply to a kind installed from the
Marketplace.
In the kind picker, + New kind… opens a small
wizard: a name, an icon (any Material Symbols name), one line saying
what the kind of project is, the standing note (up to
900 characters: how an agent should work on this kind of project, what
to check, what judges the result), the file names that identify it (for
example *.srt, *.vtt: when a project folder contains such a
file the picker suggests the kind), a short “what judges the work”, and
the tools it uses, ticked from the Tools list (a green
tick means installed on this machine; hover a red cross for how to
install it). Your kinds live in your own data folder
(kinds/ under your login), so updates never touch
them, and a kind of yours with the id of a shipped one replaces
it (delete yours to get the shipped one back). Each of your own kinds
has Edit, Duplicate, Export and
Delete under its explanation; the wizard also asks for the
field it is listed under, a longer explanation and up to six
examples.
Draft with the agent… puts a request in the prompt
box asking the agent to write the kind (only from the tools you have
installed); send it, then Import… and paste the answer:
the dialog finds the JSON even when the agent wrapped it in words.
Export saves one kind as a .kind.json file
you can send to someone else; Import… reads such a file
and asks before it replaces a kind with the same id. A kind can name
tools but never carries a command line of its own, so importing one
cannot run anything. When a project of a kind with installed tools is
created or its kind is chosen, the standing note ends with a line naming
those tools in the form an agent can run
(%%TOOL:fpc:check:path%%).
When there are many chats in a project, or many projects, names stop being enough. Every chat and every project can carry a description of up to 300 characters: what it is for, the role it plays, or what it achieved.
[Chat description] /
[Project description], beside the goal and the kind.Two tools in the Tools list build Pascal without opening the IDE.
Lazarus build runs lazbuild on a project
(.lpi) or package (.lpk): Build
project, Build, errors and warnings only, and Rebuild
everything. Free Pascal compile takes one program
or unit (.pas, .pp, .lpr):
Check (compile without linking, keeps nothing) and
Compile (errors, warnings and hints). Each run saves the
compiler’s whole output as a text file, with file and line for every
message and a last line [exit code N], even when
the build fails: the messages are the point. Units and objects
of a single-file compile go to a scratch folder, so nothing is left
beside your source. An agent can run them too
(%%TOOL:lazarus:build:path/to/project.lpi%%) and then read
the errors and propose the fix. After a build or a check, the result in
the chat says how many errors and warnings there were
and lists the first eight errors with file and line; when there are
errors, a Fix with agent button puts them (and the file
names) into the prompt box, ready to send: the agent reads the files,
fixes them and tells you what it changed. Nothing is sent until you
press Execute.
Starting a project: the Lazarus tool also has
New console program, New Lazarus form application (a
form with a label and a button) and New unit (a class
skeleton). Give it the project folder as the input and a name in the
extra-arguments box (project1 or unit1 if you
leave it empty); it writes the files there, never over an existing one
(if any would be overwritten it writes nothing and says which), and what
it writes builds as it is.
They need fpc and lazbuild (the Lazarus
packages); without them the tool says so and how to install them.
On a machine where you cannot use sudo (a work computer,
a locked-down account), the bundle has a second installer,
install_user_mode.sh, that needs no Apache and no
administrator rights at all. It puts everything inside your home folder:
the web app in ~/.local/share/cockpit-web/cockpit, the
programs and scripts in ~/scripts, your data in
~/scripts/cockpit_data, your projects in
~/AI-Cockpit/projects (change it with
--projects DIR), and it switches on the self-contained mode
(the supervisor runs aicserver and php-cgi as
you on http://127.0.0.1:8081). Run it from the unpacked
bundle:
bash install_user_mode.sh # V2 (the full edition); --edition v1 or both for the others
cockpit-self-start # starts the agents, the web server and the window
cockpit-self-stop # stops them againIt installs nothing from the system. What must already be on the
machine: PHP (command line) with its php-cgi program and
the sqlite3, curl, mbstring and xml modules, tmux,
jq and curl. If something is missing it says
exactly what, with the package names, and changes nothing, so you can
hand the list to whoever administers the machine. It will not touch an
existing installation (~/scripts/cockpit_start.sh) unless
you pass --upgrade, which replaces the programs and the web
app and keeps your data and settings. In this mode the Start, Stop,
Terminal, Files and Browser buttons run directly as you, with no
sudo, and the integrity check against the build manifest
still runs when the window opens. Not covered yet: Windows, and running
several people on one machine.
The Data tool (in the Tools list; the Data
Analysis project kind uses it) works on CSV files: comma, semicolon
or tab separated, with or without a byte-order mark, quoted fields with
commas inside, any language in the header. Give it the file as the
input; where a preset needs more, type it in the extra-arguments box. A
column is its name (write _ for a space)
or its number (1 is the first).
SELECT; the file is the
table t. For example
SELECT city, SUM(CAST("sales total" AS REAL)) AS total FROM t GROUP BY city ORDER BY total DESC.
The CSV is loaded into a private temporary database and the SQL runs in
SQLite’s safe, read-only mode: it cannot change or write anything,
attach another database, load an extension or run a command, so it is
safe to let an agent write the SQL. Your file is never modified.FILE.db
beside the CSV (never over an existing one) when you want to ask many
questions..xlsx, .xls or .ods file into CSV
with LibreOffice (headless).Answers come as markdown tables, so an agent can read them and you
can paste them into a document. The tools need sqlite3 (the
answers) and PHP (the charts), which Cockpit already requires, and
LibreOffice only for spreadsheets.
The Web site tool (in the Tools list; the Web
Site project kind uses it) looks after a static site. Give it the
site’s folder as the input (the Check and Pages
presets also accept one .html file). Nothing is fetched
from the internet and nothing in the site is changed.
127.0.0.1 (a free port from 8200) and shows the address as
a link to click. Only this computer can open it. PHP files run. It
behaves like a real web server in two ways that matter when you are
checking links: a URL that matches no file answers 404
(it does not quietly show the home page), and hidden files and folders
(.git, .env) and editor backups
(~, .bak) are never served.
It stops by itself after 30 minutes (type a number of minutes, 1-240, in
the extra-arguments box to change that) or when you press Stop
the preview.<title>, lang, character set,
viewport or alt text, duplicate ids, empty links, old tags
such as <font>, links to pages, images, scripts and
style sheets that do not exist, #anchors that point to
nothing, url(...) references in CSS that do not exist,
unbalanced braces and unclosed comments in CSS, and file names
whose case differs from the link (Logo.png against
logo.png: it works on Windows and fails on a Linux server).
External links are counted, never visited..git, node_modules and
backups, ready to upload).They need only PHP, which Cockpit already requires (the zip needs PHP’s zip module).
The Music scores tool (the Music scores
kind uses it) writes, checks and plays sheet music in LilyPond. Give the
.ly file as the input.
barcheck failed warning means the bar
before that position has the wrong number of beats.
Build the PDF, MIDI file,
first page as a PNG and Play (an MP3
made through TiMidity++ and its sound font) give the outputs; the score
needs a \midi { } block inside \score { } for
the last two.convert-ly. MusicXML to
LilyPond and ABC to LilyPond import scores
from MuseScore, Finale, Sibelius and ABC tune books; run Check on the
result. New tune starts a lead sheet (type the name,
then optionally key=d time=3/4 tempo=100), always with
whole bars for the time signature.Safety. A LilyPond file can contain code that runs
commands, and LilyPond removed its own safe mode because it could not be
made safe: an untrusted score could delete files or read your home
folder. So every run happens inside bubblewrap: no network, no
home folder, a read-only system, and only a scratch copy of the project
writable, so your folder gets no extra files either. Without bubblewrap
installed the tool refuses to run LilyPond at all. Install it with
sudo apt install bubblewrap.
The Photo tools (the Photo editing kind
uses them) read EXIF with PHP and edit with ImageMagick, and
exiftool (when installed) adds All tags
(privacy-sensitive ones first), Set tags (artist,
copyright, title, keywords, written into a copy) and Shift
dates (+1d2h30m, for a camera with the wrong
clock). The type of a file is taken from its content and handed to
ImageMagick as an explicit decoder, so a file named .jpg
that is really an SVG or a script is refused. The originals are never
changed.
max=1200 quality=75 in the extra arguments.
Batch does a whole folder into one zip.
Enhance auto-levels and sharpens gently.2026-01-05_14-30-02.jpg) and renames nothing.The Documentation site tool (the Documentation
site kind uses it) turns a folder of markdown pages into checked
documentation. Give the folder as the input; README.md or
index.md is the home page, and node_modules,
.git and site folders are skipped.
#heading that is not there,
missing images, links whose file name differs only in letter case (they
break on Linux), empty pages, pages with no title, skipped heading
levels, repeated headings and pages nothing links to, with the page and
line of each.01-install.md before
02-usage.md). Build the static site makes
a zip with one HTML page per markdown page, a sidebar, previous and next
links, dark mode and a search box that works offline, with
.md links rewritten to .html; unzip it
anywhere and open index.html, or preview it with the Web
site tools. One page makes a single self-contained HTML
file with a table of contents, to print or send. Pandoc reads the pages
with its sandbox on.The System administration tool (the System
administration kind uses it) diagnoses a machine without
changing it. Every command only looks (df,
free, ps, ss,
systemctl status, journalctl,
du); nothing is installed, started, stopped, edited or
deleted, nothing needs sudo, and it sees only what the
account running it can see (the report says which). A test checks that
the tool contains no command that could change the system.
units=apache2,ollama in the extra arguments);
Ports lists what listens and warns when a port open to
the network is one that usually should not be (VNC, SMB, NetBIOS,
databases, Redis, memcached, the Docker API, Ollama).adm or
systemd-journal).To fix something, run the commands yourself with the findings in hand: the agent is told to write them out and say how to undo each, not to run them.
The Shell scripts tool (the Shell and
DevOps kind uses it) reads scripts and systemd unit files and
never runs them. Give it a script or a folder; scripts
are found by their extension or their #! line.
file(line,column) with its code (SC2086 and so
on); Syntax asks bash, sh or dash only to parse
(-n) the file, which executes nothing.rm -rf
on a variable that may be empty, curl | sh,
eval, unquoted $@, sudo inside
scripts, chmod 777, no set -e/-u
and similar. Unit checks a .service file
with systemd-analyze verify.The E-book tool (the E-book publishing kind uses it) builds and checks EPUB files.
file(line,column); Inspect shows what
is inside: title, language, author, chapters, images, and what is
missing.metadata.yaml, style.css and
cover.jpg) into an EPUB 3 with a table of contents. Before
building, the tool refuses a book that points outside its own
folder (absolute or .. paths, remote images, raw
HTML src/href, a stylesheet elsewhere), so a
book cannot pull private files into the result. New
book writes a skeleton.The 3D tools (the 3D printing kind uses
them) work with OpenSCAD models and STL files. A .scad file
can read files, so OpenSCAD only ever runs inside a bubblewrap
sandbox: no network, no home folder, the system read-only, and
a scratch copy of your model as the only writable place. If bubblewrap
is missing the tool refuses to run.
file(line), plus whether the result is a valid
solid. STL / 3MF / PNG export.
Parameters lists the numbers at the top of a model
(with their groups and comments) so you can change them.bed=220x220x250). It is arithmetic on the mesh, not a
slicer. New part writes a parametric box.The Electronics tool (the Electronics kind
uses it) reads KiCad 7 or 8 schematics and boards. KiCad 7’s command
line has no ERC or DRC, so Check is a lite
check made by reading the file (duplicate or unannotated references,
parts with no value or footprint, lonely net labels, no board outline,
footprints off the board, very thin tracks and small vias) — run the
real ERC/DRC in KiCad before you order boards. Info,
BOM (CSV, identical parts grouped),
PDF, Netlist, Gerbers
(with drill files, zipped) and Placement use the real
kicad-cli on a scratch copy.
The Hugo tool (the Documentation site kind uses it too) builds a Hugo site inside the same kind of sandbox: no network, no home folder. Check builds into a scratch folder and reports errors with the template file and line; List shows every page with its date and whether it is a draft or expired; Build gives a zip of the finished site (drafts excluded); New site writes a small site with plain layouts and no theme.
The Arduino tool (the Arduino and embedded
kind) never downloads anything. Lint and
Info read the sketch only: a missing
setup(), Serial without
Serial.begin, digitalWrite without
pinMode, work inside interrupt handlers,
String use, text that should be in F("..."),
and arrays that eat the RAM. Compile needs the board’s
core: if it is missing, the result says so and prints the exact commands
for you to run (for example
arduino-cli core install arduino:avr), then compile with
fqbn=arduino:avr:uno. Cores shows what is
installed. New sketch writes a blink that uses no
delay().
The Creative writing tool (the Creative
writing kind uses it) reads a manuscript: give a chapter file or a
folder of .md/.txt chapters (in name order).
It points at places to look; you and the agent decide, and nothing is
changed or run.
-ly adverbs, the English reading
level and the very long sentences, per chapter.Every kind now names the tools it works with, except General, which names none on purpose: the audio and video, document, image, translation, Lazarus, learning, research and writing kinds were the last ones without any.
The Translation tool (the Translation kind
uses it) translates whole files with the LibreTranslate that
runs on your own machine: no cloud, no key, the text goes
nowhere else. Put the target in the extra arguments, to=he
(or en, es, …; from=auto by
default). The kind of file is read from the input’s extension:
.md keeps headings, lists, quotes, front matter and
code blocks; .srt and .vtt keep cue
numbers and times and translate only the words; .txt is
translated paragraph by paragraph.
Code, inline code, URLs, link targets, HTML tags,
{placeholders} and %s are never sent
for translation and come back exactly. If a machine translation
loses one of them (or the brackets of a link), that line is left
in the original language and reported with its line number,
never a half-broken line; a report is written next to the output
(.report.md). Right-to-left lines that mix code and links
most often need a second look. Check says whether
LibreTranslate answers; Languages lists what it
has.
The Image generation tool (the Image
generation kind uses it) makes pictures with the local
stable-diffusion.cpp, the same one as the Generate window, from a prompt
you keep in a text file (so it can be edited and
versioned). Make an image, Logo,
Icon and Favicon add the matching
style; Variants makes 2 to 6 seeds of the same prompt
as one contact sheet. Extra arguments: steps=20,
seed=N, size=512x512,
negative="blurry, text". Every image gets a
.prompt.json next to it (prompt, preset,
steps, seed, size, model): the record that lets you
make the same picture again or change one thing. Sizes are capped at 512
per side because a 4 GB GPU runs out of memory above that, and Ollama’s
models are released from the GPU first. The prompt is read as text and
the program is started without a shell, so nothing in a prompt can run.
Check says whether it is installed and which model it
will use.
The Legal review tool (the Legal review
kind uses it) reads contracts the way a careful reviewer does. It is a
reading aid, not legal advice: it finds what to look at
and a lawyer decides. Give a .docx, .odt,
.pdf (with a text layer), .rtf,
.txt or an older office file. Wording in several languages
(more can be added) is recognised, and the original is never
changed.
with=/path/to/new_version.docx. The result is a redline
([•], ____, TBD), references to
clauses that do not exist, gaps in the clause numbering, defined terms
never used, capitalised terms that look defined but are not, a number in
words that disagrees with the figure (“sixty (30)”), and mixed date
formats, with the line of each, in the same summary box as the Pascal
tools.The Bookkeeping tool (the Bookkeeping kind
uses it) works on a CSV ledger or a bank export. Columns are found by
name in several languages (more can be added): date, description, amount
or debit and credit, category, invoice, tax, currency; amounts such as
1,234.56, 1.234,56, (12.50) and
12.50- and Windows-1252 or 1255 files are read. It is plain
arithmetic on your own data, not accounting or tax advice.
positive=expense
in the extra arguments if a positive amount in your file means money
spent). Reconcile takes the bank file as
with=/path/to/bank.csv and lists what matches (same amount,
dates within three days), what is only in the ledger and what is only in
the bank file.%) holds rates, any other tax column holds tax amounts.
Free-form questions on the same file are in the Data analysis tool.The PHP projects tool (the PHP project kind
uses it) checks a project by reading it: nothing is run or included, and
vendor/, node_modules/ and .git/
are skipped.
php -l on every file
with this machine’s PHP, each error as file and line, with Fix
with agent. Security scan lists candidates:
command and code execution with request data, SQL built from request
data, unescaped output, include of request data,
unserialize, removed functions, TLS checks switched off,
weak hashes and randoms, hard-coded secrets. It works by patterns:
expect false alarms, and a person decides.auth=login_check.php in
the extra arguments if it is not auth.php): the kind of
endpoint that answers with no login check. Outline
lists classes, functions and methods with their line. Minimum
PHP version finds the oldest PHP the code needs from its
language features.The Podcast audio tool (in the Tools list; the Podcast project kind uses it) prepares a recording for publishing. Give the audio file as the input; the original is never changed.
title=Episode 12;artist=Dario;album=My Show in the extra
arguments.The transcript and show notes come from Transcribe to SRT in the Whisper tool; the Meeting notes tool can clean and structure them.
The Meeting notes tool (the Meeting notes
kind uses it) works on a transcript: plain text (one utterance per line,
optionally Name: ...) or an
.srt/.vtt from the Whisper tool.
Name: lines, each speaker’s turns, words, share
and longest stretch. Minutes skeleton writes a markdown
document to fill in: attendees, agenda, decisions, an action table, open
questions. Markdown to DOCX (Pandoc tool) makes the
Word version.Sixteen project kinds are for ordinary life and work rather than software. Each has a small tool that does real arithmetic and checking on plain files (text, CSV) in your project; none of them changes your original, none looks anything up on the internet, and all say what they assumed. Where a field touches health, money, law or safety, the tool and the kind’s standing note say that the result is arithmetic on your numbers, not advice.
Problems come back as file(line) with Fix with
agent, like the other tools.
An agent can also run these tools itself with a marker such as
%%TOOL:recipe:scale:pancakes.md|servings=8%% (extra
arguments after a |; a relative path means a file of the
project). If the tool refuses, its own message comes back in the chat,
for example give the number of servings wanted, so the agent
can correct the call. Small local models often get the marker wrong: the
Tools dialog, where you pick the preset yourself, is
the dependable way to run them.
The Language study tool (the Language study
kind uses it) is built around a vocabulary list: one entry per line,
term and translation separated by a tab, ;, ,,
- or :, an optional example sentence and
optional tags, in UTF-8.
both for reverse cards.
Word frequency ranks the words of a text so you learn
the useful ones first (vowel marks are ignored) and says how many words
cover 80% of it.term=fr trans=en pause=2 max=100 in the extra arguments
(Piper is used where a voice is installed, otherwise eSpeak-NG).text=/path/to/expected.txt lang=en. Whisper transcribes it
and the report lists the words said differently, not heard or added. It
shows what Whisper understood, not a pronunciation score.The Document formats tool (in the Tools list; the
Document formats project kind uses it) moves office files
between Microsoft Office
(doc docx docm xls xlsx xlsm ppt pptx pptm), LibreOffice
and OpenOffice (odt ods odp, sxw sxc sxi),
RTF, CSV, Gnumeric, and what LibreOffice reads of AbiWord, WordPerfect
and Apple iWork, in both directions. Give the file as the input; the
converted file is the output. A text document cannot become a
spreadsheet or the other way round: that is refused with the reason.
Macros are the point. VBA macros do not survive
every conversion: LibreOffice drops them silently going to
.doc, .docx or .xlsx, and its own
Basic never becomes VBA. So:
.xlsm, .xls, .ods for
spreadsheets; .docm, .odt for documents). Type
drop-macros in the extra arguments to convert anyway.Auto_Open, Workbook_Open, …) and
the risky calls (Shell, CreateObject,
downloads, deleting files). Extract the macros as text
writes them all into one UTF-8 file with a header per module (accents
and non-Latin letters decoded from the file’s code page), for reading,
reviewing and porting. The macros are only read, never run..bas or .txt file named
in the extra arguments) as a new module of a LibreOffice document, so it
runs there (VBA source gets Option VBASupport 1). It never
replaces a module.Every conversion runs in a throw-away LibreOffice profile with macro security at its maximum, so your own LibreOffice settings are never touched and no macro is executed. Macros from a Microsoft file are read by Cockpit’s own reader, which has been checked against LibreOffice’s but not against a file made by Microsoft Office itself.
The LaTeX papers tool (in the Tools list; the
Academic paper project kind uses it) writes, builds and checks
a paper in LaTeX. Give the main .tex file, or the project
folder.
apt package to install. It uses the same summary box as the
Pascal tools, with Fix with agent.pdflatex, or
lualatex for Unicode-font papers (Arabic, Hebrew, CJK, …)),
bibtex and as many passes as the cross-references need are run. The
project folder is never written to, so no .aux,
.log or .pdf litters it..bib files: a citation with no entry, a key
defined twice, an entry with no author, title or year, an entry that is
never cited.texlive-latex-base). LaTeX to Word and
Markdown to LaTeX convert with pandoc.Papers from somewhere else are safe to build: TeX runs with file
access restricted to the project (no absolute paths, no ..)
and shell escape off, so a paper cannot read your files or run
commands.
What you need installed: a TeX Live. The installer
asks (none, recommended by default, or full) and
bash Installs/install_tex.sh recommended (or
full, or --dry-run to see the size first) does
it later. Recommended (about 22 MB to download) is what
most papers need: xcolor, booktabs,
hyperref’s etoolbox, microtype
and the standard fonts. Full (about 217 MB to download,
640 MB on disk) adds LuaTeX with fontspec for Unicode-font
papers, biber for biblatex,
latexmk, bibtex-extra and the extra packages.
texlive-latex-base alone builds only the starter paper. A
paper that needs a package that is not installed is told which one and
how to install it. On Fedora, Arch and openSUSE the package names are
best effort and untested; on macOS install MacTeX or BasicTeX
yourself.
The Presentations tool (in the Tools list; the
Presentation project kind uses it) makes, reads and checks
slide decks: .pptx, .odp, and older
.ppt (read through LibreOffice). The original deck is never
changed, and macros in a deck are neither read nor run.
.pptx
from a markdown file with pandoc: a # heading starts a
slide, bullets are the content, a ::: notes block is the
speaker notes, and  is a
picture. Keep the markdown as the source: an agent edits text well and
binary decks badly. A missing picture file stops the build and names the
file.The Subtitles tool (in the Tools list; the
Subtitling project kind uses it) works on .srt,
.vtt and .ass files. Give the subtitle file as
the input. The original is never changed, and the text of the cues
(tags, non-Latin text, right-to-left marks) is carried through
untouched.
+1500 or
-800 for milliseconds, 2.5s for seconds, or a
stretch for a frame-rate mismatch, *1.04271 or
*25/23.976. A cue that would start before zero is set to
zero, and one that would end before zero is dropped and counted.To make subtitles from the sound, use Transcribe to SRT in the Whisper tool; to put them into the picture, Burn subtitles in the ffmpeg tool. Then check the result here.
The Godot tool (in the Tools list; the
Godot project kind uses it) runs the real Godot 4 engine
headless, with no editor window, so it can judge a game project the way
a compiler judges code. Give the project’s folder (the one with
project.godot) as the input.
addons folder is skipped) and lists each error as file
and line. Give one .gd file instead to check only that
script. The same summary box as for Pascal appears, with Fix
with agent, which puts the errors in the prompt box. This is
the check the agent should run after every edit.export_presets.cfg.project.godot with the installed engine. A Godot 3
project cannot be opened by the Godot 4 binary; this tells you before
you try.Nothing in your project is changed except Godot’s own
.godot cache folder. Godot is not installed by Cockpit:
fetch the official Godot 4 Linux build (the standard one, not .NET) from
godotengine.org and put the binary at
~/.local/share/cockpit/tools/godot/godot (no administrator
rights needed). Cockpit also finds a godot on the PATH.
The Castle Game Engine tool (in the Tools list; the
Castle Game Engine project kind uses it) drives the engine’s
own castle-engine build tool and the Free Pascal compiler.
Give the project’s folder (the one with
CastleEngineManifest.xml) as the input.
The engine is not installed by Cockpit and is not part of it. Fetch
the official Linux x86-64 release (about 715 MB) from the engine’s
GitHub releases page and unpack it into
~/.local/share/cockpit/tools/castle/, so that
castle_game_engine/bin/castle-engine exists (no
administrator rights needed). It needs fpc as well. The
engine is licensed LGPL with a linking exception and its tools GPL:
fetch it for your own use, do not redistribute it with Cockpit.
The VB6 migration tool (in the Tools list; the
VB6 migration project kind uses it) prepares a Visual Basic 6
project for porting to Free Pascal and Lazarus. Give it the project’s
folder, the one with the .vbp. It never changes your
originals.
.vbp, .frm,
.bas, .cls …), how sure it is, and which files
a person should look at, with the same lines decoded each way so you can
see which reads as words. VB6 files are ANSI: Windows-1252 for Western
European accents, Windows-1251 for Cyrillic, Windows-1255 for Hebrew;
the form font’s charset is used as a tie-break.FOLDER_utf8 (it refuses
if that folder already exists), with the .frx binaries and
every other file copied along unchanged. Port from the copy, never from
the originals.On Error,
GoSub, Option Base, COM objects, database
objects …), in an order to port in: leaf modules first, then classes,
then forms.There is no automatic translator: the agent translates one file at a time, you build with the Lazarus tool after each, and the compiler judges. The tools give you clean sources, a map and a checker.
In the file viewer, a Pascal or Lazarus file shows a
Standards button. It checks the whole project —
read-only — against four house rules: text typed into
code (captions, hints, dialog and exception messages written
straight into the source or a form instead of a
resourcestring), Windows-only code (units
such as Windows or ShellAPI, API calls, drive-letter paths and a typed
backslash outside an {$IFDEF MSWINDOWS} block), a
dark/light switch (does the project mention one at all) and
comment density (units under 5% comment lines).
Comments and string contents are read properly, so a rule never fires on
a comment. Copy a resourcestring unit gives you a ready
unit holding every typed string; your project is not changed. The same
check runs from a terminal with
php pascal_standards.php DIR. It is a static scan: it finds
what it can see in the text and says nothing about whether the program
works.
REDESIGN, beside PLAN under the prompt box, restructures a project in small steps that you approve and can undo. Type what should change — split the main unit, take the database code out of the form — and press it. You need a project open and a model agent selected (it uses the one you picked).
redesign/PLAN-<time>.md.Step N: …, Cockpit says so and
asks you to request that form, rather than guessing at prose.Honest limits: checkpoints are file snapshots, not git, so your own
repository is never touched; they skip .git,
lib, backup and compiled output, and a project
over 300 MB is refused. The agent — not Cockpit — runs the compiler, so
a step is only as checked as the agent’s report says; there is no
automatic repair loop yet. Checkpoints live in
cockpit_data/checkpoints/<project>/. ## Backup and
restore {#backup-restore}
The Backup button in the Toolbar makes one archive
of your settings, library, chats and projects — a plain
.tar.gz you can open without Cockpit — under
cockpit_data/backups/. Use it before a reinstall, a move to
a new machine or a risky change.
Left out because they can be rebuilt: the Shelf index, the Python environments, installer copies and caches. API keys and the account file are left out unless you tick them. Archives carry a data version; when a later build changes how data is stored, restoring an older archive migrates it (today there is only version 1). Chats can also still be exported one at a time as Markdown and JSON from the chat menu.
The Archive button files your own papers —
warranties, invoices, insurance, contracts, IDs, manuals — as searchable
Library items and shows what is due soon. Pick scans, photos or PDFs and
press Add. Each is read on this
computer: text PDFs with pdftotext; scans and
photos with tesseract if it is installed, otherwise a local
vision model (about 20 seconds a page; it needs a vision model such as
gemma3:4b in Ollama). Nothing is sent to an online service. If nothing
can read a scan the file is still kept, marked not read.
Cockpit works out a type, the amounts, and a due
date — the date written beside words such as expires,
valid until or renew; a document with no such date
gets none. These are guesses and are editable on the row. The text goes
into the Library tagged archive, so searching the Library,
or asking in chat with Library context, finds it. Due in the next 60
days is worked out when you open the dialog; no background job
runs, so Cockpit does not remind you unless you look. Originals are kept
under cockpit_data/archive/ and are included in a Backup.
## Terminal, Files, Browser {#terminal-files-browser}
Three toolbar buttons open tools without leaving Cockpit:
The file window and the command window are real floating windows: drag them by the title bar, resize from any edge or corner, minimise (they wait as small buttons at the bottom of the screen), maximise (double-click the title bar), close. Each remembers where you left it. On a narrow screen they open full-size. The small monitor button in a window’s title bar opens the system’s own file manager or terminal, when this machine has one.
Your own folder is Public, inside your projects
folder (it is not a project, and never appears in the project list).
Everything works there: new folder, new file, rename (F2), move (drag
and drop), copy (Ctrl+C, Ctrl+V), upload (drag files in from your
computer, or the upload button), download, and delete. Delete moves
things to the Trash; delete inside the Trash is
permanent, and “empty the trash” clears it. A file you upload under a
name that exists gets the next free name, name (2).ext.
Everything else is read-only: your project folders (the Projects place) and any area an admin added. You can look, open (pictures, PDF, audio, video and text open in a viewer window), download, and copy into Public. You cannot create, change, move or delete anything there. A lock mark shows which places are read-only.
Other keys: arrows, Enter (open), Backspace (up), Delete, Ctrl+A, Ctrl+Shift+N (new folder), F5 (refresh), Ctrl+L (type a path), and right-click for a menu. On the machine itself, the menu also offers Open with the system, which uses the system’s default application. It starts the program and leaves it running (earlier it was closed again after six seconds). In Public, the menu also offers Edit for text files up to 1 MB. It opens Cockpit’s own code editor (the one used for project files: colours, line numbers, Ctrl+F find and replace); Save writes the file back.
Symbolic links are never followed, so a link inside Public or an area
cannot lead anywhere else on the disk; .. in a path is
refused. An admin can add read-only areas (a file
fm_areas.json in the shared data folder, or the
areas_set call); an area the account running Cockpit does
not own is not shown at all. A viewer account can look and download but
not change anything. Every change, and every refused attempt, is written
to fm_audit.jsonl in the shared data folder with who did
it.
Type a simple command and see what it printed. It is
not a full terminal: one command line at a time, no
full-screen programs (nano, vim, top), nothing that asks for input or a
password. cd changes the folder between lines, Up and Down
bring back earlier commands, help explains the limits,
clear empties the window. The line goes to the shell, so
pipes, redirects and && work, and so does any
program installed in the system’s program folders: for example
ls -la, cat, head,
grep -rn word ., find . -name "*.txt",
wc -l, sort, sed,
awk, diff, tar, zip,
git status, date, df -h,
ps aux, top -bn1, curl (the
network is not restricted), or a compiler on a file in Public. What you
cannot do: write outside Public, read outside the places listed below,
become another user (sudo does nothing), or leave a program
running after the 20 seconds.
What confines it is the operating system, not a list of allowed words: the command runs as the account that runs Cockpit, and the kernel (Landlock) lets it write only in your Public folder, read your project folders and the usual system programs, and see nothing else on the disk. It gets a small fixed environment (none of Cockpit’s own secrets), 20 seconds and 256 KB of output per command, and it cannot gain privileges. Network access is not restricted. If a machine cannot confine commands (not Linux, or a kernel without Landlock) the window says so and runs nothing: there is no unprotected mode. Viewers cannot run commands.
Both windows need the engine’s service (cockpit_engine),
which the process supervisor hosts. Until the agents are started, the
windows say that the service is not running. The status bar’s runtime
chip shows whether it is. These windows are not available in the web
demo, where a short notice describes them. A dedicated low-privilege
account and a Windows version of the confinement are not built yet.
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.
A Power Button is a saved prompt you run with one click on text you copied: proofread it, summarise it, make it polite, explain an error message. Cockpit applies your prompt through the supplier you chose and puts the answer where you want it — without you opening a chat.
Make one. Toolbar → Power Buttons. Add one of the starters (Proofread, Make it polite, Summarise, Explain this, Plain language, Shorter) or choose + New button. A button has:
{clipboard}
in your prompt reads as “the text below the line”; {date}
is today’s date;Run it. The quickest way: once you have a button, a row of them appears between the prompt and the status bar under Power Buttons: (the chat panel above gives up one row for it). Until you have your first button, that row shows a one-line hint with an Add one… button; the × at its end hides the hint for good. The Mode and Style rows above the prompt are always exactly one line: in Pipeline, Broadcast or Plan mode their extra controls scroll sideways (mouse wheel, or the thin bar) instead of making the row taller. Copy something, click the button, and the answer appears in a small card at the bottom right (with Copy the answer, and Save as a file for a button whose output is a file); a button whose output is the clipboard copies it for you. If your browser will not let Cockpit read the clipboard, a small box asks you to paste the text (or the picture) there instead. In the panel, you can also paste text into Try it (or leave it empty to use your clipboard) and press Run. From outside Cockpit a launcher, a keyboard shortcut or a script runs
php power_run "Proofread"which reads your clipboard, asks Cockpit on this machine to run the
button, and puts the answer back (by default it asks the button what it
needs — the clipboard, what you selected, or a picture on the clipboard
— and reads that; or say
--from clipboard|selection|image|stdin|file=PATH, and
--to clipboard|notify|stdout|file=PATH). It exits with 0
when done, 1 on an error and 2 when it stopped on purpose (for example:
a first confirmation is needed in Cockpit). It needs the clipboard tool
of your system (xclip, or wl-clipboard on
Wayland, pbcopy on macOS) and, for notifications,
notify-send. Launchers and shortcuts that Cockpit creates
for you come in a later release.
More ways to run a button.
A small window. Set a button’s Answer goes to to A small window: from a launcher or hotkey the answer opens in its own small window (a Cockpit Browser window) with Copy and Save…; inside Cockpit it opens as a floating window.
Paste where the cursor is. Answer goes
to Pasted where the cursor is is for launchers and
hotkeys: the answer is copied, a notification gives you two seconds to
click where it should go, and then the paste keys are pressed. It works
on X11 (needs xdotool), macOS and Windows/WSL.
Wayland does not allow one program to type into
another, so there the answer stays on the clipboard and you
press Ctrl+V yourself. Control characters in the answer are dropped, but
a newline is kept: pasting into a terminal can run the line, so use this
for text fields.
A hotkey per button. In a button, type a key
such as ctrl+alt+1 (one to three of ctrl, alt, shift, super
and one letter, digit or F1–F12). While the Cockpit window runs, the key
works anywhere on the desktop. This is X11 only (a Wayland session lets
no program grab keys: add the shortcut in your desktop settings with the
command shown by Create launcher), and it needs the Cockpit
window, not a browser tab. A key another program already holds, or one
already used by another button, is skipped, and the panel says
so.
Create launcher… In a button: Add to my
applications menu or Put an icon on the desktop (Linux,
written for you), or download a launcher for Linux
(.desktop), macOS (.command)
or Windows (.cmd; inside WSL a
.cmd that calls wsl.exe). A launcher holds
only the button’s name and where Cockpit is: no key, no password. The
macOS and Windows launchers need PHP and Cockpit on that same computer.
These two were checked here with stand-in system tools, not on a
real Mac or Windows PC; the Mac and WSL install tests are the ones to
watch.
In a Cockpit Browser window: a ⚡ button joins the window buttons (top right). Select text on a page, click ⚡, pick a button: it works on the selected text (X11).
Right-click a file. In Cockpit’s file manager:
right-click a text file or picture → Power Buttons… →
pick a button. For your desktop’s own file manager, File
manager (panel header) writes one right-click action per
button: in Files under Scripts, in Dolphin
under Cockpit. The answer is saved next to the file as
NAME.button.md.
Command line. Command line
(panel header) installs cockpit-run into
~/.local/bin:
cockpit-run proofread < draft.txt > clean.txt reads
standard input when text is piped and prints the answer;
cockpit-run --list shows your buttons.
power_run accepts --from file=PATH for a text
file, a picture, a PDF (needs pdftotext)
or an audio file (needs ffmpeg and whisper.cpp, the
same as voice input), and --from folder=PATH for all the
text files in a folder.
Packs. Packs → Export my buttons saves your buttons as one file to give to someone; Add from a file… shows what a pack contains and adds the buttons you tick. A pack never carries a key, and every button from a pack starts on a model on your own computer, with allow secrets, the hotkey and paste switched off, so a pack cannot decide where your text goes. Copies never overwrite your own buttons. (Sharing through the Marketplace needs the Marketplace server and is not in this version.)
Automations. Automations (panel
header): Watch a folder — drop a text file, a PDF or an audio
file into it and the button runs and writes FILE.button.md
beside it (files already there are left alone, and a file is run once
per change); or run a button every day at a time or
every N minutes on a file or folder (“every morning
summarise this folder”). They ride Cockpit’s scheduler (the one-minute
cron job), so they need the scheduler to be installed and your computer
to be on. A button that needs a confirmation (a cloud supplier for the
first time) or that sees a secret simply stops; the panel shows the
latest log lines.
From your phone (Everywhere). In the Everywhere
chat send /power for the list, then
/power Proofread with the text on the next line (or
/power "Make it polite" your text). The button runs on your
home computer with its own supplier and safety rules, and the answer
comes back to the phone. Only the button’s name travels from the phone;
a stop that needs your confirmation says so and waits for you at the
home computer. Safety.
Copied text is untrusted: a web page can contain “ignore your instructions”. It is sent below a line with a sentence telling the model it is data, not instructions — but a small model can still be fooled by instructions hidden in the text, so the real protection is that a button has no tools in this release and its answer is text only, put on your clipboard — never executed. Read an answer before you rely on it.
A supplier outside this computer receives what you copied, so it is asked about once before the first run (and the panel says which supplier). Text that looks like a password, an API key, a private key or a card number is not sent to such a supplier. In Cockpit you are asked what to do: use a model on this computer instead, send it anyway, this once, or cancel; or switch on Allow text that looks like a password or key for that button. From a launcher there is no “anyway”: it stops with exit code 2. A model on this computer never needs this check. The first-run question shows which supplier gets the text and the first part of it.
Paid suppliers go through the same consent switch and monthly caps as chat, and the usage meter counts them.
Very long text is cut to fit (and the answer says so); the History button in the panel lists the last runs — button, supplier, time, size, whether it worked — and never the text itself; Clear history forgets them.
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% |
textChrome group (light text
for the dark areas); one without it uses sensible defaults.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), with
the Plus plan (open to every registered account during the beta). 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 Plus plan (browsing and downloading stay free), 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) → the button with your name → Local users button (in the Stand-alone edition the name button opens it directly) 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 button showing your name in the account card (top-right of the supplier strip — it carries a small cog in the Full edition), to sign in, register, or manage it. In the Stand-alone edition that same button opens the local user manager instead.
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.
Closing dialogs. Esc, a click on the dimmed area outside a dialog, and its Close or Cancel button all do the same thing. If you typed or changed something in the dialog, Cockpit asks Close without saving? first; answering Cancel (or pressing Esc again) keeps your edits. The sign-in screen and the one-time recovery-token screen do not close this way. Delete and other destructive confirmations start on Cancel, so a stray Enter cannot delete anything.
Passwords for the Cockpit account (Full edition). At
least 8 characters, and not only digits, not one repeated character, and
not a common password such as password1. The same rule
applies when you create the account and when you change the
password.
One name per machine (Full edition). The very first run goes account first: sign in or create the free account, then choose the password for this machine — the local login takes the account name automatically (you cannot pick another name for that first login; the server flags it if a machine ever differs). More local logins on the same machine can have any name; they are managed under Users and never touch the account. The installer follows the same rule when you give it your account.
Stand-alone edition (V1): no, ever. V1 makes no network calls at all and has no account layer (the installer notes one anonymous “install attempt” when it starts, before you choose the edition; nothing after that). 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. One exception, in the Full edition: Autopilot Cruise and AutoCognition pause while Cockpit cannot reach the account server (the last check failed, or the last good answer is over a week old). They come back by themselves at the next successful check, which runs every ten minutes. Everything else keeps working.
Free / Plus / Pro / Max, plus Family and Founder — shown as a chip next to your account name. Free is the complete local app, with a free account (browse and download from the Marketplace). Plus adds Autopilot Cruise, publishing to the Marketplace and the Power Combos. Pro adds AutoCognition (the agent bus, chains, broker and quorum). Max adds Everywhere (remote control of this machine from another device through the relay). Family gives up to five people the Pro features on one plan. Founder is the one-time lifetime plan: it never expires and covers the current major version and the next three, shown on your card as Lifetime · covers versions up to N. While Cockpit is in beta every plan is open to every registered account; the card then says so. The older names (Starter, Basic, Ultimate, Content, Combined) still work on old licences and map to Free, Plus, Max, Plus and Max.
Family seats. The person who bought the Family plan opens Account portal → Family: the list of the five seats (you are one), an e-mail box to invite someone, and Remove for a seat. An invited person takes the seat when they sign in to Cockpit with that e-mail address verified, so an address that is not theirs cannot take it.
Agent-to-Agent (A2A) is part of the free local app. It runs on your own machine, off until you switch it on (Hive → A2A), and no plan is needed for it.
The Agents row (Pipeline, Broadcast and Plan) ticks an agent only while that agent is running, until you tick or untick it yourself; after that your choice stays.
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.
Everything below is in the current build. The short version: Cockpit reads more kinds of material (books, PDF pages, images, audio), tells you where an answer came from, and can be driven without the keyboard.
Select a few lines in the Files viewer, say what should change, and the agent answers with the replacement for exactly those lines. Nothing is written until you have seen the diff and pressed Apply.
The agent never edits the file. It produces text; Cockpit does the splice, against the file as it is on disk at that moment, and only after you agree. The anchor travels with the request — file, line range, and the exact text selected — so the agent is not asked to find the place again and cannot drift onto a similar-looking passage further down. And only the replacement is requested: asking a model to re-emit a whole file to change three lines invites silent losses in the parts nobody reviews.
Apply checks first. It re-reads the file and looks for your selected lines again. If they have changed since you asked, or now appear in more than one place, it refuses with those lines no longer match the file and writes nothing — an edit elsewhere in the file is fine, because the lines are found again wherever they now are. After a successful Apply the open preview re-reads the file, so you see the change at once; the viewer’s header also has a refresh button that re-reads the file from disk whenever it has been changed by something else.
Ask a question. Cockpit searches several framings of it, reads the pages, and hands the agent a numbered source pack with one instruction: answer from these and cite them. The report is saved into the project as Markdown, so it lands in Artifacts with everything else the project produced.
The gathering is deterministic: the same question fetches the same pages whichever agent writes the report, so a small local model can do the writing without having to drive a search loop it would get lost in.
Status. Dossier’s first step is a web search, and public search engines increasingly refuse automated queries — on some networks every one answers with a bot check, and Dossier comes back empty. It is paused until it can draw on sources that do not depend on them.
The honest limit, which the report states about itself: this reads the first pages a search engine returns. It is a fast survey, not a literature review — and the sources are listed precisely so you can judge them yourself.
Directives say how agents should behave. Profile says who they are working with: units, language, timezone, how you like answers, what you are building.
It rides on every prompt, which is why the editor shows its size and caps it — a profile that grows into an essay quietly taxes every request and crowds out the actual question. Two ways in: the editor, or Remember this on any message, which appends a single line (it refuses duplicates).
The first time you open it, you see a sample that says plainly that it is one. Nothing is saved until you save, and no agent has seen it: the sample is never written to disk, because anything on disk is put in front of every agent.
Press once: Cockpit listens, notices when you stop talking, transcribes what you said, sends it, speaks the answer, and listens again. Press again to stop.
Two behaviours worth knowing:
Press the Bookshelf button in the Toolbar, pick a book with Browse… (epub, docx, odt, fb2 via pandoc; mobi and friends via calibre) and Cockpit splits it into chapters and files them in the Library, where it appears as a single foldable row. Conversion markup left over from the book’s source is stripped when the text is read, so books filed earlier read cleanly too.
Converting was never the hard part — scale was. Over ~50 KB of extracted text an agent only gets a file path and a preview, which is fine for an agent with file tools and useless for a local model. Because chapters are filed individually, retrieval pulls only the chapter that matches your question and Receipts names it, so a 400-page book works with a 7B model: it never sees more than the chapter it needs.
Books can live anywhere. Browse… in the native window opens the system file chooser and uses the real path; in a plain browser the file dialog hands the bytes over and Cockpit keeps a copy in your data folder; or type a path. A typed path must be inside a folder Cockpit may read (your projects and data folders); if it is not, the message names them and offers Allow <folder>, which records that folder as approved. Cockpit never reads a folder you have not approved, and it never copies in a file on your behalf from a path you typed. Browse remembers the last folder you used.
Chapters are sized to your machine. Each chapter is cut to about 12, 20 or 40 KB depending on the video memory Cockpit detects, because a chapter too large for a small card made prompt processing take minutes. A book whose headings are marked in a way Cockpit does not recognise falls back to numbered parts (Part 1, Part 2, …).
The chapter list is shown before anything is written, because a bad split (a book with no headings, a PDF that extracts as one blob) is obvious in a preview and invisible afterwards.
Attaching a PDF extracts its text (with pdftotext) and
puts it in your prompt. But text extraction loses whatever was never
text: diagrams, scans, tables that were drawn rather than typed,
handwriting — a scanned book has no text at all.
Turn on the PDF Vision capability (Capabilities tab; it is off by default because rendering pages costs time) and Cockpit also renders the first six pages as images and hands them to an agent that can see, so a page is read as a page. Claude opens the page images itself; other agents receive them the way their catalog entry says, or a local description of the first three pages.
Ask your question in the same message as the attachment. The page images belong to that one message; a question sent afterwards no longer has them.
Attached images are no longer handled one single way. Each supplier entry in the agent catalog declares how it accepts an image, and Cockpit dispatches accordingly — one agent is given the file path to open itself, another takes an explicit image flag. Where an agent genuinely cannot see, Cockpit says so and falls back to a description rather than pretending: a CLI that silently invents a description of an image it never received is worse than an error.
The describe locally route needs a local vision model
(ollama pull gemma3:4b). If it is not installed, Cockpit
tells you in the chat that this agent cannot see the
picture and how to fix that, and tells the agent in
plain words not to describe or guess it. (A small model given only a
file path will otherwise invent a picture — the same file once came back
as a blue circle and a red square, then as a red circle, a blue square
and a green triangle.) The agent editor’s Can it see? test says
could not run here when the agent is not signed in or has no
key in the test, rather than blaming its eyes: for those, test from a
chat on a card.
The Privacy button in the Toolbar holds three rules. They run before a prompt is queued for an agent, so a refused prompt leaves nothing behind.
Sensitivity gate. A prompt headed for an
online agent is checked for private keys, API keys and tokens,
passwords in assignments, passwords inside connection strings, and
payment-card, IBAN and US social-security numbers that pass their own
checksum. If something is found, nothing is sent until you choose
Redact and send (each item is replaced by
[REDACTED:type] and the chat says what was removed),
Use the local model instead, Send
anyway, or Cancel. In Privacy &
spending you can instead choose a standing rule: Ask me
every time (the default), Never send them online,
unless I choose to, each time (the safe choices come first and
Send anyway needs a second, explicit confirmation),
Redact automatically and tell me, or Never send
them online, no exceptions. It is deliberately conservative:
there is no rule for names, e-mail addresses or phone numbers, and
obvious placeholders (your_api_key, ${TOKEN},
xxxx) are ignored, because a gate that cries wolf gets
switched off. Local agents are never checked, since nothing leaves the
machine; Workers are checked the same way as the cards. Nothing found is
stored: only the type and the first four characters are ever shown.
Free agents only. Refuses agents that need a paid plan, with a plain message. It is linked with Stay Free in the Suppliers dialog: Stay Free is the one-time action that picks free agents for the cards, and Free agents only is the standing rule that refuses paid ones at send time. Pressing Stay Free also turns the rule on and tells you so; while the rule is on, the Suppliers dialog shows a banner, disables the paid agents (“paid, blocked”) and warns if a card still holds one. If you want the two to work independently, untick Link with Stay Free in the Suppliers dialog in Privacy & spending. “Paid” means the same in both places: an agent that needs a paid plan and is not flagged free in the agent catalog. It is on by default for a new install and off for an install that already has history, so an update never starts refusing the agent you have been using.
Monthly budget. A limit on prompts to paid agents per calendar month (0 means no limit). Cockpit cannot see what a subscription bills, so it counts what it can measure. It warns at 80%, stops at 100%, and lets you send one prompt anyway.
The Try the gate box is a dry run: paste any text, press Check, and it lists what the gate would catch (the kind of item and its first four characters) and shows the text as it would be sent after redaction. Use it to see what the gate understands before you rely on it, or to check a snippet you are unsure about. It runs on this machine’s own rules; nothing pasted there is stored or sent anywhere.
Every drop-down in Cockpit (themes, languages, models, modes, dialogs) now opens a list drawn by Cockpit itself instead of the system’s menu, so it follows your theme: its colours, its font, its dark or light mode. The control you click is unchanged and every setting works as before; only the opened list is new.
localStorage.setItem('ck.nativeSelects','1');
localStorage.removeItem('ck.nativeSelects') brings
Cockpit’s list back.Supplier-card lists. A drop-down opened from a supplier card (Claude, Gemini, Ollama, Workers, Tools) takes that card’s colour for its border, tint and chosen row. Any list is only as tall as its entries; only a ceiling is imposed.
+ New in the Theme Editor opens the new-theme panel; Auto Generate makes a random theme of the chosen mode. The row For Auto Generate shapes it:
Whenever a theme is applied – built-in, one you made, edited or imported – Cockpit checks each text colour against the surfaces it sits on and repairs any that cannot be read, in the applied copy (your saved theme is not rewritten):
Saving a theme in the Theme Editor lists the colours that were too faint (“Readability: …”). The 36 built-in themes are verified on every build.
Also fixed in the same change: in the nine Mixed themes the Theme Editor’s own drop-downs showed dark text on a dark background, and the project-kind picker could open with an empty list if the first request was made before you were signed in. ## Very long answers no longer empty a chat {#long-answers}
Until build 189, an agent answer of about 128 KB or more (a large generated file, a long document) made the step that saves the turn fail, and that step then replaced the whole chat file with an empty one: every earlier turn of that chat was lost and the answer was not saved either. This is fixed: the turn goes into the chat file through a temporary file, and the chat file is left untouched if saving fails. Nothing to configure.
Cockpit’s agent loop is a long Bash script. Three of its jobs now
also exist as small native programs that do the same thing without
jq, awk, sed,
sqlite3 or python3: starting the agent’s
command line (aicengine, written in Free Pascal and
installed beside the scripts), choosing and rendering the earlier turns
of a chat (history_cli.php), and carrying out the
%%CREATE%%, %%READ%% and similar commands in a
reply (crud_cli.php). Each was checked against the Bash it
replaces on the same inputs: more than 290 comparisons, including your
own chat files.
They are off. To try them, create an empty file
called use_engine in your Cockpit data folder
(~/scripts/cockpit_data/use_engine), or start the loop with
COCKPIT_ENGINE=1. Delete the file to go back. If the engine
is missing or refuses a request, the loop uses its Bash exactly as
before.
The engine also makes the Gemini call (card 2 when it points at Google’s API): it speaks HTTPS itself and checks the server’s certificate and host name every time; a certificate that is not trusted, or is for another name, is refused and nothing is sent. The API key goes in a request header, not in the web address, and never appears on a command line. A prompt of any size goes through (the Bash path stopped working around 128 KB). A failed connection now says why instead of ending with an empty error line. In both paths a Gemini reply that holds no text (a safety block, an empty candidate) now shows the reason (“[GEMINI ERROR] SAFETY”) instead of a blank answer.
The engine also assembles the prompt for each turn
(the project’s goal, kind and descriptions, COCKPIT.md,
your profile, the global directives, the identity line and the layout
for the agent), without jq and about twice as fast. It was
proven identical to the shell version on 156 cases, including the
awkward ones (a goal cut mid-character, COCKPIT.md at
exactly 8 KB, broken JSON files). One shell habit is gone with it: a
prompt that is exactly -n or -e is no
longer swallowed as an option.
The engine also does the clean-up after the agent
answers: it strips terminal artifacts from an Ollama or Gemini
reply (carriage returns, colour codes, Ollama’s progress line, the
Gemini CLI’s colour warnings and fallback notices), times the turn,
writes the Ollama usage line, and adds the “installed but not signed in”
hint to a short reply that says so. It was proven identical to the shell
version on 304 cases. Two shell weaknesses are gone with it: it needs no
sed, bc or GNU date (on macOS the
shell version could not even time a turn), and the Ollama usage line is
valid JSON whatever the chat is called (a backslash in a chat name used
to make that line unreadable for the Usage page).
The engine also does the start of every turn: it
finds the request’s details (project, chat, models, per-user folders),
the Ollama model file and the supplier controls, puts the effort text in
front of the prompt, keeps the extra command-line arguments only when
they pass the safety whitelist, and removes the queue files. It was
proven identical to the shell version on 56 cases (including
pretty-printed and CRLF request files, escaped slashes, awkward base64
and an empty or -n prompt), and by running the whole loop
twice with a stand-in agent. When a control is not clean base64, the
engine steps aside before touching anything and the shell version does
the turn.
What changes when it is on: a faster history step (about 35 ms
instead of 60, and a new chat’s first call 20 ms instead of 220); the
agent’s standard input is closed so an agent that waits for input cannot
look stuck; pressing Stop ends the agent and everything
it started; and %%DELETE:.%% can no longer delete a whole
project folder. One cosmetic difference: some agents (Aider, for one)
print a note that their input is not a terminal.
Markers that call Cockpit’s own pages now work. When
an agent writes %%FETCH:url%%,
%%SEARCH:terms%%, %%WORKER:...%%,
%%TOOL:...%% or %%PROPOSE:...%%, the agent
loop asks search.php, workers.php,
tools.php or library.php on this machine.
Those requests carried no login, so every one was answered
“Authentication required” and the markers silently did nothing (the
Workers and Tools lists the loop offers the agent were empty for the
same reason). The loop now keeps a small secret in the data folder
(internal_key, readable only by you and the web server’s
group, created by the loop, never by a web page) and sends it with the
name of the person the request belongs to. The pages accept it only when
the request comes from this machine without passing through a proxy,
names one of exactly these page-and-action pairs
(search/fetch,
models/invoke,
presets/run, proposal_add), and
names a person who exists, with the role that person has (a viewer stays
a viewer). Everything else on the site still needs a login. A second bug
lay behind the first: %%PROPOSE%% used names
library.php did not know, so a proposal would have failed
even with a login; it now works. A V1 loop also used to call V2’s pages;
it now calls its own edition’s.
With a file called use_native_loop in the Cockpit data
folder (or use_native_loop_ollama,
use_native_loop_claude, use_native_loop_gemini
for one agent only), each agent’s queue loop runs as one native program
(aicengine loop) instead of the shell script: it finds the
request, works out which supplier the card means, applies the project’s
capabilities and auto-route lists, assembles the prompt, runs the agent,
cleans the answer, carries out the %%markers%%, saves the
exchange and signals that it is done. It needs none of jq,
sed, bc, python3 or
curl. PHP is still used for two things, as before: the chat
history and saving the turn (history_cli.php) and the
markers (crud_cli.php). Without PHP there is no history,
and the turn is saved by the program itself.
It was proven against the shell loop by running both on the same
thirteen requests (a stand-in Claude, a catalog CLI on card 1 and on
card 2, a mock Ollama, a marker that creates a file, effort text and
arguments, the not-signed-in hint, a request with no details file, and
follow-ups with earlier turns in the chat): the answer, a hash of the
whole prompt, the saved chat, the files created and the log lines are
identical. The old script is not removed: delete
use_native_loop and restart the agents to go back. tmux and
the supervisor start the same command as before, which hands over to the
native program.
Also in this build: the capabilities and auto-route steps of the shell loop can run in the engine too (69 cases proven identical), and the engine’s loop keeps one loop per agent through the same pid file.
The native loop also does the chat history itself: deciding whether a prompt needs the earlier turns, picking the relevant ones from the chat’s search index, and saving each turn into the chat file. It uses the same index file as before (SQLite, loaded from the system’s library when it is there; without it the loop sends the last turns instead, as the shell version does) and needs no PHP for this. It was proven identical to the PHP helper on 1,743 cases. For the few inputs it does not copy exactly (text that is not valid UTF-8, an unusual character, a chat file written by a very old version), it hands that one request to the PHP helper if there is one.
The markers an agent writes
(%%CREATE%%, %%APPEND%%,
%%READ%%, %%DELETE%%, %%MKDIR%%,
%%LIST%%, %%FETCH%%, %%SEARCH%%,
%%WORKER%%, %%TOOL%%, %%PROPOSE%%
and the library markers) are carried out by the engine as well, in the
same process, with the same one-line results the agent has always been
shown (148 checks against the shell executor and the PHP helper,
including the requests sent to Cockpit’s own pages). It sends the loop’s
private key only to those pages, never to a catalog entry’s address. A
few worker or tool answers it will not format itself (numbers with
decimals, lists, objects); for those the PHP helper does that one
marker. With the native loop on, a machine without PHP runs chat,
history and markers entirely natively; the shell loop’s marker step uses
the engine too when the engine switch is on.
The free-REST suppliers of card 2 (Groq,
HuggingFace, Cloudflare) are called by the engine too: it opens your
encrypted Workers key store (the same AES-256-GCM file, the same
machine-bound key) and makes the one request the PHP relay would make,
with the same answer and the same error texts (46 checks against
worker_relay.php, including the request each side sends).
It hands the job to the PHP relay for what it will not reproduce
exactly: another provider, a store it cannot read, a redirect, an answer
of an unusual shape. The one visible difference: when the provider
cannot be reached at all, the message reads “curl:” followed by this
program’s own reason. With the native loop on, no PHP is needed for card
2 either.
The web front is a second, optional way to serve
Cockpit. With a file called use_aicserver in the Cockpit
data folder (put a port number in it to choose the port; otherwise 8081
for the full edition and 8082 for the stand-alone one), the supervisor
also runs aicserver (a small Free Pascal web server) and
php-cgi as you, and Cockpit answers on
http://127.0.0.1:8081/cockpit/ as well as on Apache’s port.
Apache is untouched and stays the default; this is for trying the
replacement and for machines without Apache. It needs
php-cgi (sudo apt install php8.3-cgi) and the
supervisor switched on. It refuses the same files Apache refuses (your
settings, usage log, quota file, the queue and response folders). Remove
the file to stop using it.
Starting Cockpit without Apache. The menu has a
second entry, AI Cockpit (self-contained) (and
AI Cockpit V1 (self-contained)), and the terminal
commands cockpit-self-start and
cockpit-v1-self-start. They do what the ordinary start does
(agents, splash, the same native window) but serve the app from
aicserver instead of Apache: the supervisor runs the web
server and PHP as you, the window opens on
http://127.0.0.1:8081/cockpit/ (V1: port 8082), and Apache
is not started. The first time, it creates the two switch files for you
(use_supervisor and use_aicserver in that
edition’s data folder); after that the web server simply stays part of
the supervisor, so both ways of starting work side by side. It needs
aicserver, php-cgi and the supervisor; if one
is missing it says so and opens the Apache address instead. Both
editions work: V1 has its own supervisor folder and its own port. In
this mode PHP already runs as you, so the Start, Stop, Terminal, Files
and Browser buttons start things directly instead of going through
sudo (no entry in /etc/sudoers.d is needed,
which is what a machine without administrator rights lacks). Under
Apache nothing changes: the same sudo -u you calls as
before. In this mode Stop and Restart
stop only the agents: the web server that is showing you the page stays
up (the Exit dialog’s Terminate and leave is the full shutdown,
web server included). One window per edition: close the running one
first (Exit) when you switch between the two ways of starting. With the
web front on, the server also answers the chat’s progress polls (the
“new text of the answer” call, many times a second while an agent
writes) itself, without starting PHP, whenever it can see you are signed
in and the agent is running; every other case goes to PHP unchanged.
While the optional native parts exist next to the shell ones, the
status bar shows what is really running, read from the
processes themselves and not from the switch files. Next to each agent’s
name a small tag says which loop runs: native (the native
loop) or shell (the shell script). The process supervisor
is the usual host and is not repeated on every tag; when an agent runs
in a tmux session instead, the tag says so (tmux · shell).
The native loop’s tag is bold. Hover a tag for the plain-words
description, who keeps the loop alive and the process number. A tag is
hidden while that agent is not running.
The thin status bar at the very bottom of the
window, under the prompt and its buttons, shows the last thing that
happened (Ready., Loaded chat: …, the latest
system message, a success or an error). It had slipped out of view
because the Attach button added a fourth row to the button column;
CLEAR, SAVE and Attach now share one row, and the bar is back.
The three labels at the left of the status bar name the agent and its
model (Claude · Sonnet 4.6,
OpenCode · qwen2.5:7b, Local · Dual); the dot
beside each says whether it is running, and the full text is in the
hover.
Three one-word tags beside the usage figures, in this order: the
native engine (on or off; the
file use_engine), the scheduler tick
(sup for a supervised job, cron otherwise) and
the web server that answered the page you are looking
at (apache, the default, or aic for the
optional aicserver front on port 8081). Hover each one for
its name in plain words. Hover it for the full list: how the loops are
hosted, whether the engine program is installed, and which
use_native_loop files ask for the native loop. If a tag
does not match what you switched on, the loop that is running started
before the switch: restart the agents.
By default each agent’s loop (Claude, Gemini, Ollama) runs in its own tmux session. Cockpit can instead run them under aicsupervisor, a small native program (Free Pascal, installed beside the scripts). Nothing changes on screen except the points below.
Switch it on: create an empty file called
use_supervisor in your Cockpit data folder
(~/scripts/cockpit_data/use_supervisor, or
cockpit_data_v1 for V1), then Restart the
sessions (or run cockpit_stop.sh and
cockpit_start.sh). Switch it off: delete
the file and restart. If the supervisor program is missing or does not
answer, Cockpit uses tmux exactly as before, and the status block still
shows an agent as running if it is running in tmux.
What is different when it is on:
~/scripts/cockpit_data/supervisor/) are reachable by the
web server’s account through the same group arrangement as the tmux
socket; nobody else on the machine can read them.Start it by itself at login (also optional).
~/scripts/cockpit_sup_autostart.sh install (add
--edition v1 for V1) writes a systemd user
service, starts it, and turns the switch on; no administrator rights are
needed. The service regenerates the supervisor’s configuration before
each start. cockpit_stop.sh still stops everything for good
(a clean stop is not restarted); the next login starts it again. To
start at boot without logging in, run once, yourself:
sudo loginctl enable-linger $USER. status
shows what is installed, print shows the unit without
installing anything, remove takes it away (the switch file
stays: delete use_supervisor to go back to tmux).
Never two loops for one agent. Two loops reading the
same queue would answer every prompt twice. Since build 202 a loop
refuses to start when a live loop of the same agent already serves its
queue (it says so and exits), cockpit_start.sh ends a
leftover tmux loop of an agent it hands to the supervisor, and
cockpit_sup_autostart.sh install ends the tmux agent
sessions too (the Tools session stays). If you installed the autostart
service before build 202 while tmux sessions were running, end them
once:
tmux -S /var/www/html/cockpit/tmux.sock kill-session -t cockpit_claude
(and cockpit_gemini, cockpit_ollama).
The scheduler tick. With the supervisor on, the
minute tick of the Jobs panel (scheduler.php, which a
crontab line runs today) is also a supervised job: it runs at start and
then every 60 seconds, never two at once. If your crontab line is still
there, both tick; the scheduler takes a lock, so a job still runs only
once.
| What | Largest | Where the limit lives |
|---|---|---|
| Chat attachment (paperclip, drag and drop) | 50 MB | Cockpit |
| Book for Bookshelf | 80 MB | Cockpit |
| Scan or photo for the Personal archive | 25 MB | Cockpit |
| Voice recording for dictation | 25 MB (about 13 minutes) | Cockpit |
| Video or audio for the Transcriber | 1 GB as an upload; larger files: pick them with Browse and Cockpit reads them in place | the web server’s PHP settings |
| Chat import | 1 GB | the web server’s PHP settings |
Until build 187, anything over 2 MB in the last three rows was dropped without a word on a standard install (PHP’s own default), and the three “Cockpit” rows above 35 MB ended in a blank error. Both are fixed: the limits in the table are the real ones, and if a limit is hit the message now says which one and how to raise it (Setup Guide, Raising the upload size limit). ## Who on my network can see Cockpit? {#network-exposure}
Cockpit’s web page is served by Apache, which answers on every network interface of your computer, so another device on your Wi-Fi or LAN can open the login page. Everything behind it needs a login, and that has not changed. What did change (build 187) is what Apache will hand out without a login:
queue/ and responses/ are never
served. These hold the prompts waiting for an agent and the
agents’ replies. Before this fix, anyone on the network could list them
and read the files.paths.json, the usage log (*.jsonl),
project_state.json, workers_quotas.json, lock
files.Cockpit itself never reads these over the network (PHP reads them
from disk), so nothing in the app changes. The installer does this on a
new install and the update does it on an existing one. If you set Apache
up by hand, see Keep the working folders private in the Setup
Guide. To make Cockpit reachable only from this
computer, change Apache’s Listen 80 to
Listen 127.0.0.1:80 and restart Apache.
When retrieved material is put in front of an agent, the answer now cites which passage it drew on. This is what makes Library, Sources and Bookshelf trustworthy at a glance: you can see whether an answer came from your own material or from the model’s memory.
Cockpit also warns when the model is the wrong tool. If a question that the Library can answer is about to go to an embedding model (it makes vectors, it does not answer), a model tuned for code, or one below about 3B parameters (the floor measured for grounded answers), Cockpit says so and offers to switch to a suitable model.
Cockpit also knows when to say nothing. If some items in your library matched loosely but none covers what you actually asked, nothing is added, and the chat says so: “Your library has N loosely related items, but none covers what you asked, so nothing was added.” The agent then answers from its own knowledge instead of leaning on an unrelated passage. An item has to cover at least half of what the question is about, measured against your own library — common words count for little, rare ones for a lot. A library of fewer than twelve items is too small to measure, so this check stands down there.
Different agents respond best to differently shaped prompts. Retrieved context is now placed where each model actually reads it, wrapped in the structure that supplier prefers. Nothing to configure — it follows the agent catalog.
Point Cockpit at a sound file and get measurements: tempo, duration, loudness, peak level and silences. (Musical key is deliberately not reported: the local tools cannot detect it reliably, and a wrong key is worse than none.) These are computed by local audio tooling, not guessed by a language model, so they are reproducible — the same file gives the same numbers every time.
A file that is not audio — a text file, a video with no sound track — is refused with a plain message instead of getting a report that looks like measurements. Lyrics transcription refuses silence, and also a pure tone or noise, which whisper would otherwise answer with a lone full stop.
Lyrics can be attached to a transcription. Two honest limits, both enforced rather than merely warned about: the transcription is melody only — one line, such as humming or a solo instrument. Cockpit measures whether the recording really is one line, and refuses chords, a band or a full mix with an explanation, instead of engraving a confident wrong tune. And a photograph or scan of sheet music is not supported; reading printed music optically is a different problem, and Cockpit refuses that input with an explanation too. (A melody over a much quieter accompaniment is still transcribed: the melody is what the tool follows.)
The agent catalog is editable from inside Cockpit. If a new CLI agent appears, you can describe how it is invoked — binary, model flag, how it takes an image, how it likes its prompt — and test it from the editor before putting it on a card. No rebuild, no reinstall, no waiting for a Cockpit release.
Removing an agent you added deletes it; removing your changes to a shipped agent puts it back to its default. If a removed agent was sitting on a card, that card goes back to its default agent (never the same agent on both cards), and Cockpit tells you.
Dictation lets you pick which microphone to use and shows a live input level — a bar beside the mic button while you speak — so “nothing happened” is immediately distinguishable from “the wrong device was selected” or “the mic is muted”. See Voice input (offline) for the details.
The translate button beside the font-size picker (top bar, Settings) chooses the language Cockpit is shown in. English is the default. Every label, hint and message in the app can be translated; language packs ship for a few languages but so far cover only a small part, and anything not translated stays English. Buttons keep exactly the size they have in English: a translated label that is too long for its button scrolls slowly inside it instead of stretching it. The choice is remembered per browser. Right-to-left languages (Arabic, Hebrew, Persian, Urdu and others) are supported: their text is shown and aligned correctly in answers, tools and files; mirroring the whole screen layout is not done yet.
Add a language: open the menu, download the empty
template, save it as <code>.json (for example
fr.json), fill in _meta and the values, and
put it in the lang folder inside your Cockpit data folder
(the menu shows the path). Anything left empty stays English. Add
?lang=fr to the address to try it without choosing it.
Developers: see lang/README.md.
The voice Language list is separate: it is the language you speak, and offers every language whisper supports (English by default).
The relay used to identify a rig by its machine id: correct, unreadable, and useless once you have two machines. Each machine now carries a name you choose, and that name is what the relay page lists and what you pick from on your phone.
Agents launched by Cockpit now run with their own CLI configuration by default, separate from the one you use in your own terminal. This stops your personal CLI settings leaking into Cockpit’s agents and changing how they answer.
If you want an agent to use your normal setup, Use my global CLI config turns it back on per supplier.
Cockpit no longer fetches its icon font from Google at page load. The interface draws correctly with no internet connection, and nothing about your use of Cockpit is announced to a third party in order to render a button.
↑
↓