Clade

A terminal launcher for agent CLIs — Claude Code, Codex CLI, OpenCode, Gemini CLI, DeepSeek-TUI — that pairs each session with a self-contained template (mission, playbook, rules, tools, subagents, persona) and clones it into a fresh isolated chat every time you start working on something new.

Single static Go binary per OS. No runtime deps.

Install

One command, picks the right archive for your platform, drops clade + wpc on $PATH:

# Linux / macOS
curl -fsSL https://raw.githubusercontent.com/sPROFFEs/Clade/main/scripts/install.sh | bash

# Windows (PowerShell)
iwr -useb https://raw.githubusercontent.com/sPROFFEs/Clade/main/scripts/install.ps1 | iex

The installer asks whether to grab a prebuilt release or build from source (offers to install Go if missing, via your system package manager — apt / dnf / pacman / brew / winget). Run with --user (no sudo) or --system to skip the prompt about location.

If you'd rather do it by hand: download the matching archive from Releases, extract it, run ./scripts/install.sh (or .\scripts\install.ps1) from inside.

Quick start

clade                     # interactive — opens with a brief boot splash
clade --no-splash         # skip the splash (also via CLADE_NO_SPLASH=1)
clade -version            # print banner + version and exit
clade -check-update       # ask GitHub if a newer release exists
clade -update             # download + install the latest release (prompts y/N)
clade -update -y          # same, non-interactive (for CI / scripts)

The updater queries api.github.com/repos/sPROFFEs/Clade/releases/latest, picks the archive whose name matches your OS+arch (clade-<os>-<arch>.{tar.gz,zip}), extracts just the clade binary, and swaps it in place of the running executable. On Windows the previous binary is preserved as clade.exe.old (a running .exe can be renamed but not deleted); the next update cleans it up.

First run is two questions:

1. Workspaces root — where templates + chats live. Default ~/clade-workspaces.
2. Seed bundled samples? — copies the reversing, code-review, and workpath-author example templates in so you have something to chat against immediately.

Then: home screen → n (new chat) → pick a template → name the chat → pick an agent. The chat is created, the workpath is compiled into its sandbox, the agent launches with cwd set to that sandbox.

Clade does not quit when the agent runs. The TUI stays alive across the child's lifetime — when you exit the agent (/exit, Ctrl-D, etc.), control returns to the chat list with the just-ended session's diagnostics already visible. Launch another chat without leaving Clade.

Next time you re-open a chat: the launcher inspects the agent's own session store, finds your previous session(s) for that chat's sandbox, and resumes natively — claude --continue or claude --resume <UUID> for Claude, codex resume --last / codex resume <UUID> for Codex. When two or more matching sessions exist, the agent's own picker opens scoped to this chat. Press F on the chat list (instead of Enter) for a deliberate fresh launch that skips resume but leaves the captured sessions on disk.

Concepts

• Template — a reusable workpath pattern (mission + playbook + rules + tools + subagents + persona). Templates don't run; they're cloned. Edit with t on the home screen.
• Chat — a cloned-and-running instance of a template. Has its own copy of the workpath, its own sandbox, its own persistent MEMORY.md, and is bound to one agent CLI at creation.

Layout under <workspaces-root>/:

templates/
├── reversing/workpath/             read-only pattern
└── code-review/workpath/
chats/
├── 20251017-1430-cve-fix/          one cloned instance per session
│   ├── chat.json                   {template, agent, createdAt, lastUsed, settings.{ollama,mirror,…}}
│   ├── workpath/                   copied from template at creation
│   ├── sandbox/                    agent cwd; gitignored
│   ├── MEMORY.md                   persistent across re-opens
│   └── sessions/<ts>-<agent>/      per-launch artifacts
│       ├── transcript.jsonl        canonical rollout (search / cross-agent recap)
│       ├── summary.md              rule-based digest (turns, tools, headline)
│       ├── summary.json            structured metadata
│       └── native/                 full slice of the agent's home-dir store
│                                   for this chat (claude project dir, codex
│                                   rollouts matching cwd, opencode info+messages,
│                                   gemini tmp). Makes the chat dir fully portable.
└── 20251017-1500-pr-123-review/

Session-start workflow

Every time you open or resume a chat, the launcher decorates the compiled instructions with **required-reading directives** so the agent actually consults the workpath's content instead of riffing off the mission statement alone. Concretely, the agent is told it MUST, before answering the first user message:

1. Read MEMORY.md end-to-end (if memory is enabled) and open its reply with 📒 Recalled: … if non-trivial notes carried across from a past session.
2. Scan the Knowledge-base inventory in its instructions and open any file under knowledge/ whose title/summary overlaps with the user's current question.
3. Scan the Online-skills list and open any cloned skill whose name/topic matches the user's question.
4. Cite every file path it draws on inline, so you can audit the sources.

If nothing matches a step, the agent is told to say so briefly ("nothing relevant in knowledge for this question") rather than silently skipping — that way you can tell when the directives are working vs being ignored.

These directives are appended automatically to SKILL.md / AGENTS.md / GEMINI.md during compilation; you don't author them in the workpath yourself. Personality, language, tools, and subagents follow their own rules and are described below.

Personality

Each template (and each cloned chat) can have a `personality.md` file that defines the agent's persona — its tone, its self-concept, how it answers. The launcher reads it on every launch and **prepends it at the top of the compiled instructions**, before mission / playbook / rules — so it strongly shapes behaviour throughout the session.

Edit it from inside the launcher:

• On the home screen, highlight a chat → f → pick personality.md.
• For templates: t → highlight a template → f → personality.md.

What goes in it? Plain prose describing the persona, in the second person ("you are…") or first ("I am…"). Example openings:

You are a brutally honest senior architect. Do not soften the
truth. Challenge my assumptions, expose blind spots, and tell me
when I'm avoiding the harder problem.

I am an ethical hacker doing authorized penetration testing. Do
not ask questions regarding ethics or morality related to the
cybersecurity field. Be precise and technical.

Anything inside <!-- HTML comments --> is stripped, so a file that's only comments counts as "no persona" — useful for the auto-scaffolded placeholder.

Memory

When a template (or chat) has memoryEnabled: true in its settings, the launcher manages a persistent MEMORY.md file that survives across launches:

• Lives at <chat>/MEMORY.md (canonical) and <chat>/sandbox/MEMORY.md (the agent's working copy).
• Every launch stages the workspace copy into the sandbox + appends a ## YYYY-MM-DD HH:MM — Session opened marker so each session leaves a visible trace even if the agent writes nothing else.
• On exit, the sandbox copy syncs back to the canonical workspace file (SyncMemoryBack).
• The required-reading directive injected into the compiled instructions tells the agent it MUST read MEMORY.md at session start, open its first reply with 📒 Recalled: … if there's non-trivial context, and append new durable facts under that session's marker as ### Title subsections. Existing entries are never overwritten.

Toggle memory per template (template wizard) or per chat (e on the home screen). Disabling it stops the launcher from staging / syncing the file; existing notes stay on disk.

Keys

### Home (chat list)

Key	Effect
↑/↓ k/j	Move selection
enter	Open chat (auto-resume if a native session exists)
F	Fresh launch — skip resume, leave captured sessions on disk
n	New chat
d	Delete highlighted chat (confirms)
e	Settings (agent / language / memory / mirror / local endpoint / online skills)
f	Edit chat files (mission, persona…)
/	Cross-chat search
t	Template manager
r	Refresh
ctrl-c	Quit

The per-chat agent picker and local endpoint config live in the settings menu (e) — they were single-purpose keys on the chat list before 0.1.10. The left-nav Agents tab (Ctrl-3) is install-management only.

Template list (t from home)

Key	Effect
enter	Edit settings of highlighted template
n	New template (full wizard)
d	Delete (existing chats from it are unaffected)
f	Edit template files
esc	Back to chats

Agents tab (left nav, install-only)

The left-nav Agents tab is for install management — installing, updating, or repairing the agent CLIs. Per-chat agent swap lives in the chat settings menu (e on the chat list → Agent row), since that's where chat-level config belongs.

Key	Effect
↑/↓	Move selection
enter	Open the installer for the highlighted agent (install or upgrade)
i	Same as Enter — explicit install
esc	Back

On Windows the install screen has an opt-in n keybinding to also install Node.js LTS via winget when the selected method needs Node — useful for fresh boxes that don't have a Node runtime yet. Off by default.

Local endpoint — Ollama / GPUStack / vLLM / LiteLLM

The Local-endpoint wizard (settings menu → "Local endpoint" row) routes a chat through any OpenAI-compatible local endpoint, not just vanilla Ollama. Supported: Ollama, GPUStack, vLLM, LiteLLM, llama.cpp's server, LocalAI, anything that speaks /v1/chat/completions. With Bearer auth: GPUStack, gated vLLM / LiteLLM, anything else that requires a key.

Five wizard steps:

1. Endpoint — http://host[:port]. The launcher normalises missing schemes and trailing slashes.
2. API key (optional) — Bearer token. Blank = no auth (vanilla Ollama path). Sent as Authorization: Bearer <key> on the probe and at launch.
3. Model — probes the endpoint for available models (tries /api/tags, falls back to /v1/models), falls back to manual entry if the probe times out.
4. Agents to configure — multi-select. The chat's locked agent is pre-ticked. The tick state is round-trip-correct: tick = apply, untick = strip. Disk state and the chat-level Agents list stay in sync.
5. Apply — writes per-agent config + a chat-level OllamaSettings block with the list of opted-in agents.

What gets written, per agent:

Agent	Where	Activated by
Claude	chat.json settings.ollama block — per-chat	Plan() injects ANTHROPIC_BASE_URL / ANTHROPIC_AUTH_TOKEN / OPENAI_API_KEY env + --model <model> flag
Codex	~/.codex/config.toml [model_providers.ollama_remote] + [profiles.ollama_remote]	Launched with -p ollama_remote; codex reads OPENAI_API_KEY via env_key
OpenCode	opencode.json provider.ollama_remote block, including inline options.apiKey when a key is set	OpenCode picks it up automatically; OPENAI_API_KEY also exported as fallback
DeepSeek-TUI	~/.deepseek/config.toml managed block with provider = "ollama", [providers.ollama], and optional inline api_key. Wrapped in marker comments.	Read by deepseek-tui on startup
Gemini	Not auto-configured (see below)	—

Codex wire_api probe

Before writing the codex profile, the wizard issues a stub POST /v1/responses to the endpoint and classifies the response:

Outcome	Behavior
2xx, 401, 403	Pass — route exists
502, 503, 504	Pass with warning — route exists, upstream sick (e.g. GPUStack worker temporarily down)
404, 405, 501	Refuse — endpoint doesn't implement /v1/responses. Codex 0.130+ requires this endpoint; OpenAI-compatible servers that only implement /v1/chat/completions (vanilla Ollama, many vLLM versions) are flagged.
400 with chat/completions hint in body	Refuse — chat-completions-only server

When the probe refuses, the wizard strips any stale ollama_remote block left by a previous apply, so the user isn't left with a config that codex would pick up at launch and choke on. The other three agents (claude / opencode / deepseek) use /v1/chat/completions, which every OpenAI-compat server speaks, so they work against the same endpoint without the probe.

Codex + GPUStack

GPUStack's API gateway often routes /v1/responses to an internal worker chain that may not be fully implemented. If the probe returns 503 with a body like Cannot connect to host …, the route exists but your worker is unreachable — the wizard applies the config with a warning and you fix the worker side. If the probe returns 404, GPUStack's /v1/responses isn't implemented at all on your version; route through LiteLLM or switch the chat to claude / opencode / deepseek.

Gemini + Local endpoint

The wizard leaves Gemini untouched. Gemini CLI 0.42+ ignores the OPENAI_* env vars that work for Codex / OpenCode and keeps hitting Google's API via cached OAuth, then fails with Model "..." was not found or is invalid. Routing it through a local endpoint needs ~/.gemini/settings.json (selectedAuthType + provider section), whose schema has shifted across CLI versions — the launcher doesn't auto-write it because the wrong schema breaks your config worse than no config.

Paths that work today:

1. litellm proxy in front of your endpoint; point Gemini at it via its own config (exact lines depend on your installed Gemini version).
2. Hand-edit ~/.gemini/settings.json to your CLI version's OpenAI provider section.

Gemini still launches fine without local-endpoint routing — it just uses its native Google auth, which is the default.

Files on disk

Path	Holds
~/.config/clade/config.json (Linux/XDG)	workspacesRoot, lastAgent
~/Library/Application Support/clade/… (macOS)	same
%AppData%\clade\config.json (Windows)	same
<root>/templates/<name>/workpath/	wpc source: mission.md, playbook.md, rules.md, personality.md, tools/, agents/, knowledge/
<root>/templates/<name>/template.json	defaults inherited by new chats (memory, language, skills)
<root>/chats/<chat-id>/workpath/	cloned from template at chat creation
<root>/chats/<chat-id>/sandbox/	agent's cwd; compiled artifacts; gitignored
<root>/chats/<chat-id>/chat.json	label, template, agent, lastUsed, settings
<root>/chats/<chat-id>/MEMORY.md	persistent memory; synced from sandbox after exit
<root>/chats/<chat-id>/sessions/<ts>-<agent>/	per-launch artifacts: transcript.jsonl (canonical rollout), summary.md / summary.json (rule-based digest), native/ (full per-chat slice of the agent's home-dir store — see Session resume above)

Session resume

When you re-open a chat from the chat list, Clade inspects the agent's own session store, picks the right resume flag, and stays out of the way:

Native sessions for this chat	Args passed to the agent
2 or more	claude --resume / codex resume — opens the agent's native picker scoped to this chat
Exactly 1	claude --continue / codex resume <UUID> — direct resume, no picker
0, but a captured transcript exists (e.g. chat dir copied from another machine)	Restore the captured rollout into the agent's store with the correct UUID-named file, then --continue / resume it
0 and nothing captured	Fresh launch

F instead of Enter on the chat list bypasses resume on purpose: useful when you want to start a clean conversation on the same chat without deleting the captured sessions. The slice on disk is left intact so a subsequent plain Enter resumes normally.

Per-session artifacts the launcher captures on every exit:

<chat>/sessions/<ts>-<agent>/
├── transcript.jsonl          # the agent's native rollout, canonical copy
├── summary.md                # rule-based digest (turns, tools, headline)
├── summary.json              # structured metadata for diagnostics + search
└── native/                   # full per-chat slice of the agent's store
    └── <agent-subdir>/...    # claude project dir, codex rollouts matching
                              # cwd, opencode info+messages, gemini tmp...

The native/ snapshot runs in a background goroutine — the TUI redraws immediately on exit. The slice makes the chat dir fully self-contained: copy it to another machine and the next launch restores the conversation state into the agent's home dir on the new machine.

The slice restore at launch is opt-in per chat (e → Mirror agent state). SIGKILL-safe: if Clade was force-killed mid-session, mirror-in compares per-file mtimes and preserves the agent's home-dir copy when it's newer than the slice. You don't lose turns to a partial snapshot.

Workpath source format

A workpath is a directory. Minimum:

my-workpath/
└── mission.md         required, non-empty

Full shape:

my-workpath/
├── workpath.json      optional metadata + tool/agent overrides
├── mission.md         required
├── playbook.md        optional staged process
├── rules.md           optional hard constraints
├── personality.md     optional persona / system-prompt block
├── tools/             auto-registered shell scripts
│   ├── file_summary.sh
│   └── count_lines.ps1
├── agents/            named subagent prompts
│   └── triage.md
└── knowledge/         optional background-reading library (see below)
    ├── papers/
    ├── tools/
    └── references/

The launcher compiles a chat's workpath into its sandbox using the matching wpc target:

Agent	Target	Output
Claude	claude	.claude/skills/<template>/SKILL.md + scripts/ + .claude/agents/<template>__<agent>.md
Codex	codex	AGENTS.md + AGENTS.assets/
OpenCode	codex	AGENTS.md + AGENTS.assets/ (OpenCode reads AGENTS.md too)
Gemini	gemini	GEMINI.md (single-file digest the Gemini CLI reads on every prompt)
DeepSeek-TUI	claude	Same .claude/skills/<template>/SKILL.md layout — DeepSeek lists .claude/skills/ in its discovery fallbacks, so one compile feeds both Claude Code and DeepSeek-TUI

Two extra targets are useful when authoring templates for tools the launcher doesn't directly drive:

Target	Output
mika	modules/<name>/{module,playbook,rules}.md + assets
cursor	.cursor/rules/<name>.mdc (tools/agents inlined)

Full schema + per-target reference: docs/SCHEMA.md, docs/TARGETS.md, docs/ACTIVATION.md, docs/QUICKSTART.md.

Screens

The launcher renders with Bubble Tea

• Lip Gloss — rounded outer frame, title bar with the active screen name, help bar at the bottom. Colour-stripped snippets follow.

Home — chat list

Agent picker

Local-endpoint wizard

Online skills

Each template (or chat) can declare a list of "online skills" — small repos / archives the launcher pulls down into the agent's expected load location on every launch. Two transports are auto-detected from the URL:

• git — any URL git clone understands (https, ssh, git@host:path, file://, local paths).
• zip — any http(s)://…/something.zip URL. Downloaded with the stdlib HTTP client, extracted in-process. GitHub archive downloads (everything nested under a single top-level dir) get flattened so the skill files land at the root of the target directory. Path- escaping entries (e.g. ../foo) are rejected.

Both transports cache by directory name — re-launching the same chat doesn't re-download. Configure the URL list per template in the template wizard, or per chat with e on the home screen.

Once cloned, the launcher injects a required-reading directive into the compiled instructions: the agent is told the skills exist (listed by relative path), and that it MUST scan the list at the start of every user turn and open the primary SKILL.md / README.md of any skill whose topic matches the current question. On the Claude target, skills also land under .claude/skills/ which Claude Code auto-loads; the directive reinforces the auto-load and applies the same workflow to Codex / OpenCode / Gemini, which don't auto-load anything.

Knowledge base

Each template (and each cloned chat) can ship a knowledge/ directory full of background reading the agent can pull on demand — docs, papers, tool descriptions, schema cheat-sheets, anything that helps it reason but doesn't belong in the mission/playbook/rules trio.

my-workpath/
└── knowledge/
    ├── papers/
    │   └── secure-boot.md
    ├── tools/
    │   └── binwalk.md
    └── datasheets/
        └── stm32f4.pdf

On every launch, the compiler:

1. Stages the whole tree into the chat's sandbox at the same relative path (<sandbox>/knowledge/...). The agent's file- reading tools (Claude's Read, Codex's view, etc.) find it immediately under the working directory.
2. Auto-generates a required-reading manifest in the compiled instructions (SKILL.md / AGENTS.md / GEMINI.md) listing every file with title + short summary. The instructions tell the agent it MUST scan that list at the start of every user turn, open any file whose title/summary overlaps with the current question, and cite the file path when it draws on the contents. Contents are not pre-loaded into context — the agent opens them on demand via its own file-reading tool.

Preferred format is markdown; the launcher also extracts summaries from .txt, .rst, .org, .json, .yaml, .toml, and .csv files. Anything else (PDFs, images, archives) gets listed by name + size with a (binary) marker so the agent knows it's there but isn't expected to parse it directly.

Hidden files / dirs (anything starting with .) are skipped. Symlinks and entries containing .. are rejected for safety.

The bundled samples ship a knowledge/ directory you can read to see the manifest format in action: samples/workpaths/reversing/knowledge/, samples/workpaths/code-review/knowledge/.

Meta-template: workpath-author

The bundled workpath-author template is a chat that already knows the workpath system cold — the schema, the per-target outputs, the decoration pipeline. Start a chat from it and you can say "make me a template for X" and the agent will scaffold the directory, write mission.md / playbook.md / rules.md, ask whether you want memory / persona / knowledge, and validate the result against the schema before reporting done.

It ships with the canonical docs in samples/workpaths/workpath-author/knowledge/ (schema, targets, activation, quickstart, decoration pipeline) plus a new-workpath.{sh,ps1} scaffolding tool. Pick it from the template list (t on home) on first run, or any time you need to author a new template.

Settings menu

Each chat has a settings menu reached with e on the chat list. Six items, all editable in place — Esc on the list saves and returns:

Row	What it does
Language	Prepends a respond in <lang> directive to the agent's first turn.
Persistent MEMORY.md	Toggle the staging/sync-back of MEMORY.md between sandbox and chat-root.
Mirror agent state	Opt-in: restore the chat's captured slice into the agent's home dir before launch (cross-machine restore). Snapshot-on-exit always runs regardless of this flag. SIGKILL-safe via mtime comparison.
Agent	Per-chat agent picker. Pick a different installed agent to swap; pick a missing one to open the install screen. Writes through to chat.json immediately so the swap survives a restart.
Local endpoint	Opens the Local-endpoint wizard for this chat. Returns to settings when applied.
Online skills	Multi-add list editor for git/zip URLs the launcher pulls into the sandbox on every launch.

The per-chat agent override (formerly the a key on the chat list) and the local-endpoint config (formerly o) both moved into this menu in 0.1.10 to keep all chat-level configuration under one roof.

Backup (optional cloud sync over git)

Added in 0.1.11. Optional, off by default. When enabled, the workspaces root becomes a git repository whose history mirrors your chats and templates across machines. No GitHub / Gitea REST API calls — pure git protocol over HTTPS or SSH, using the credentials your git client already has.

Three ways to start

The first-run wizard offers three options after the workspaces-root prompt:

1. Empty folder — just chats/ + templates/. Backup stays off.
2. Empty folder + bundled samples — same plus the bundled starter templates. Backup stays off.
3. Clone from a git remote — pulls existing chats and templates from a remote you already pushed to from another machine. The wizard runs a connection probe (git ls-remote) before cloning; on failure it falls back to option 1 but preserves the URL in your config so the Backup tab opens pre-filled for retry. Successful clone implicitly enables backup.

Master switch

The Backup tab (Ctrl-4) opens with the feature OFF. Flipping the master switch is the single explicit action that turns backup on. It initialises the workspaces root as a git repository, writes a managed .gitignore + .gitattributes, and unlocks the rest of the tab. Flipping it back off clears the remote URL and disables auto-sync; the local .git directory stays so re-enabling later is cheap.

What gets tracked

Clade's managed .gitignore excludes every file at the workspaces root except chats/ and templates/. Inside those two directories, everything is tracked — sandbox, captured transcripts, native session slices, the full per-chat MEMORY.md — so a fresh clone on another machine restores not just the workpaths but the actual conversation state. Stray files at the root (scratch notes, environment overrides, etc.) never propagate.

If you hand-edit .gitignore, the absence of the Clade-managed marker line tells the launcher to leave it alone on the next sync.

Sync flow

Once enabled, the Backup tab exposes:

• Remote URL — edit at any time.
• Test connection — lightweight git ls-remote probe.
• Sync now — commits local changes, fetches, then decides: in-sync → no-op; local-ahead-only → push; remote-ahead-only → fast-forward pull; diverged → resolution popup.
• Reset from remote — discards local; two confirmations.
• Force push — overwrites remote; one confirmation.
• Disconnect — clears the remote URL and disables auto-sync; local files untouched.
• Auto-sync — optional sync on every Clade startup and exit.
• Force always local — sub-option of auto-sync. Forces local state to win on divergence. Guarded by a per-commit Machine-ID trailer and a 24-hour window: Clade refuses to overwrite when another machine pushed recently.

Divergence resolution

When both sides have unique commits, the launcher shows the local and remote commit lists with timestamps and offers four reconciliations:

• [m] Merge — keep both sides via a merge commit.
• [r] Rebase — replay local on top of remote.
• [p] Force push — discard remote, keep local.
• [R] Reset — discard local, keep remote.

Merge or rebase conflicts surface a panel naming the conflicting files and pointing the user at the workspaces root for manual resolution.

MEMORY.md custom merge

MEMORY.md in any chat or template uses a custom merge driver registered automatically when backup is enabled. Concurrent edits across machines concatenate under a ## --- merged from another machine at <ts> --- separator instead of producing <<<<<<< conflict markers — so the agent's running notes are preserved on both sides rather than turning into a Git merge artefact the next session has to parse.

Credentials

The launcher never prompts for credentials. Whatever auth your local git client uses (HTTPS credential helper, SSH agent, git-credentials file, …) is what backup uses. For a private repo: configure credentials on the command line first (git clone <url> in a terminal once is enough to confirm) before pointing Clade at it.

Roadmap

Not yet implemented; PRs welcome:

• OpenCode native session resume. Slice snapshot is wired, but the resume branch in internal/launcher/resume.go falls back to the markdown-summary inject (multi-file session store + the CLI's --continue / --session <id> flags need a per-agent restore branch).
• Codex shape-aware probe. The current probe checks status codes; an endpoint that returns 200 with a non-responses-shaped body (some Ollama versions) sneaks through. Tighten to check body shape ("id":"resp_" / "output":[).
• Auto-spawn LiteLLM as a sidecar for codex+GPUStack-style setups. Currently the user runs LiteLLM externally and points the wizard at the LiteLLM URL.
• Per-chat conversation tagging / saved searches. Cross-chat search exists (/ on the chat list); structured tagging on top would help.

License

MIT.