A fast, tasteful, self-hostable AI console. Local-first, passkey auth, shareable live sessions.

a7t.chat is a self-hostable, multi-model chat console you actually want to live in. It streams fast, it looks good, and it runs entirely on your own machine by default: point it at any OpenAI-compatible model and nothing leaves the box. When you want more, it grows with you, with passkey accounts, bring-your-own frontier keys, file uploads, and live shareable sessions.

The design bet is simple: speed and taste first, then depth. Instead of racing to match every feature the big labs ship, a7t.chat focuses on being genuinely nicer to use, and on the one thing the giants do poorly, live no-login collaboration.

• Streaming multi-model chat. Rich markdown, model switching with /model, and generations that survive a client disconnect (they run on a server-side queue, not the HTTP request).
• Capabilities. Focused, in-chat tools rather than separate apps:
  • Maps for places and directions.
  • Recipes that format a dish as a shopping checklist plus timed steps, with self-contained countdown timers that chime when they finish.
  • Research, web search that fetches live, cited context before a turn so any model answers from fresh sources.
• Local-first. Talk to a local, OpenAI-compatible model through JANO_URL. In this mode nothing leaves your machine.
• Bring your own key (optional). Plug in your own frontier-provider API keys and run turns on your own key and cost. Keys are encrypted at rest and never leave the box except into a turn.
• File uploads. Per-account attachments delivered into the prompt, with per-file and per-account quotas.
• Shareable live sessions. Conversations are private by default. Opt in and mint an unguessable link that anyone can watch build in real time with no sign-up, or invite another account into a live collaborative session.
• Passkey auth. Passwordless, phishing-resistant WebAuthn sign-up and sign-in.

The full surface, by area. Anything marked optional stays dark until you configure it, and nothing here phones home.

The default posture is fully local: you run a local OpenAI-compatible model, the app talks to it, and nothing is sent to any third party. You need Bun and any OpenAI-compatible model endpoint (for example Jano, llama.cpp's llama-server, Ollama, or vLLM).

git clone https://github.com/a7t-ai/chat.git && cd chat
curl -fsSL https://bun.sh/install | bash   # if you don't have Bun
bun install
bun run setup

bun run setup detects your machine, recommends a local model it can actually run, downloads it from Hugging Face, serves it with llama.cpp, wires .env, and verifies a clean streaming turn. Everything persistent (the download, installing llama.cpp, a boot service, editing .env) is confirmed first and can be skipped, so you can just try it in the foreground or let it set up a service that survives reboots. macOS (Apple Silicon) is fully supported today; on Linux the wizard recommends and downloads a model and wires .env, then prints the llama.cpp and service commands to run. Non-interactive: bun run setup --yes --model qwen2.5-7b; preview only: bun run setup --dry-run.

Then create the database and start the app:

bun run db:migrate
(cd web && bun install && bun run build)
bun run start        # http://127.0.0.1:8787

1. Get the code: git clone https://github.com/a7t-ai/chat.git && cd chat
2. Install Bun (if you don't have it): curl -fsSL https://bun.sh/install | bash
3. Install dependencies: bun install
4. Create your env file: cp .env.example .env
5. Point at your model: set JANO_URL to your local OpenAI-compatible endpoint (default http://127.0.0.1:8082) and DEFAULT_MODEL to a model id that endpoint exposes via /v1/models.
6. Create the database: bun run db:migrate (migrations also auto-apply on boot).
7. Start the backend as the owner: DEV_ADMIN_LOGIN=you@example.com bun run dev (serves on http://127.0.0.1:8787). DEV_ADMIN_LOGIN makes you the owner locally, no account needed.
8. Start the frontend: cd web && bun install && bun run dev (on http://localhost:5173, proxying the API to 8787).

Open http://localhost:5173 and start chatting. That's the whole loop, entirely on your machine.

The app is a plain OpenAI-compatible client, so any endpoint works. For a single model, point JANO_URL straight at llama.cpp's llama-server (brew install llama.cpp; bun run setup does this for you). For several models on one machine that cannot all fit in memory at once, put Jano in front: it is a tiny router that greedy-batches requests by model so a burst of mixed calls costs one model swap instead of many, and the app inherits model switching and per-backend telemetry with one JANO_URL. A note on multimodal GGUFs: some MLX serving stacks intermittently leak a stray user role marker into streamed replies; llama.cpp uses the GGUF's own chat template and does not, which is why the wizard verifies with a streaming smoke test.

To let other people sign up with a passkey, set WEBAUTHN_RP_ID (the registrable domain the app is served from) and APP_URL to your real origin. Passkeys are dark until WEBAUTHN_RP_ID is set, so until then only the owner (via DEV_ADMIN_LOGIN, or a private network such as Tailscale) can reach the app.

Everything is configured through .env (see .env.example for the full, commented list). The essentials for a local self-host:

Optional features have their own blocks in .env.example:

• Research (web search): pick a provider (Tavily, Brave, or self-hosted SearXNG) and set its key or URL. The toggle stays hidden until a provider is configured.
• BYOK (bring your own key): set the BYOK encryption key to enable storing frontier-provider keys encrypted at rest. Left unset, the feature stays dark.
• File uploads: the storage directory and per-file / per-account quotas.

• Backend: Bun + Hono + bun:sqlite with Drizzle ORM. Entry point src/server.ts, which binds 127.0.0.1. The app is a client of your model endpoint, never a second router.
• Frontend: Vite + React + streamdown for streaming markdown, in web/.
• Capabilities are a clean seam (src/capabilities/, web/src/capabilities/): each is a small marker plus a server and client entry, so adding one touches only the two registries, never the core chat route. Maps and Research are the examples to copy.
• Auth is a two-tier gate (src/auth/): the owner (over a private network such as Tailscale, or DEV_ADMIN_LOGIN locally) and passkey accounts. Everyone else hits a friendly wall.
• Storage: SQLite via Drizzle, migrations auto-applied on boot. The db, model-client, and auth boundaries are deliberate swap seams.

See src/README.md for the module map.

Contributions are welcome. See CONTRIBUTING.md for the dev setup, the test and coverage bar, and the branch-to-PR flow, and CODE_OF_CONDUCT.md for the community expectations. To report a security issue, use GitHub's private security advisories.

MIT (c) Leo Cardoso