Getting started

Getting started

How Apex fits together, and how she starts.

The shape of her — dashboard, bridge, model

Apex is three pieces on your own machine:

• The dashboard is this page, served by the bridge at http://localhost:8675.
• The bridge (bridge.py, in the install folder) does the real work: it serves the dashboard, runs shell commands, manages chips and workflows, holds the sudo root shell, and carries your words to the model.
• The model server is navi.llamafile, running ./navi.llamafile --server --v2 plus the flags from her hardware profile on port 8080 — at install, the installer profiled this machine (CPU, RAM, GPU) and chose the context size, threads, batch size, and GPU layers to fit it, so her settings come from your hardware, not the developer's; Settings shows what was detected and what was chosen, and the full log is hardware-profile.log; the model answers to the id navi, which the bridge reads from the server itself (/v1/models) rather than guessing.

Nothing leaves the machine on its own — the only network calls the bridge makes are to GitHub: when you open the chip or pack catalogs, check something for updates, or, once you have signed in and set it up, run a backup. The GitHub — issues & backups page in this wiki covers that whole side of her.

Two small details ride the frame: under the APEX wordmark sits her tagline — “Powered by Navi”, one static line; and at the top of the status column, her presence line starts at “Navi is here.” and cycles every few minutes through what she's up to — listening to the network breathe, arguing with a CAPTCHA, haunting Rockport's west end. The same state feeds her presence header at the top of the Chat window — her name, her dot, and what she is doing — covered in Chat & CLI mode.

The menu is grouped, and 196px wide when open. Chat sits pinned at the top on its own. Apex | Systems opens to Node, Mesh, and DHD. Apex | Navi gathers Chips, ChipDeck, and RAG. Vault stays flat below them, belonging to neither family. Apex | Utilities sits at the foot and opens upward, to Settings, Updater, GitHub, and Docs. Every launch opens with all three groups collapsed — which groups are open is not remembered, and a stale save is cleaned rather than honored — while the rail itself keeps its remembered open/closed state. A group opens with a height glide, a turning chevron, and children that arrive one after the other, and it all goes instant under reduced motion. Every transition in the app runs on one shared set of motion tokens — one set of durations and one curve — so the menu, the panes, the views, the cards, and the Docs topics all move the same way; Potato mode, in Settings → Appearance, collapses decorative animation app-wide. On a phone the groups expand in place, inside the menu.

The status column is a tabbed pane now: Status first, Chats second, with the chat count, and exactly one pane shows beneath the tabs. Status is the default, and what a phone's dock opens on. On desktop the column starts hidden, behind two toggles that share one state — the Status toggle in the menu chrome and the toggle at the top right of the chat header — and its width is given to the content until you open it. When something wants your eye — an update waiting, a stale bridge or page — the Status tab carries a small amber dot while you are in Chats. The VOICE stat reports state only now; there is no Call button on it — starting a call lives on the composer's Call button and the call panel in Settings → Voice.

Docs reads in a fixed frame: the docs menu scrolls in its own pane fixed to the UI height beside an independently scrolling article, the menu keeps its scroll position across page switches, and the popped-out Docs window has the same frame.

Starting her up

On Linux she lives in /opt/navi-apex. Launch her from the application menu or ./start.sh. Every launch is check-first: the launcher probes the model server, and if navi.llamafile is already running — from boot, an earlier launch, or started by hand — it leaves it alone and just runs the app; only when nothing answers does it start the server itself, with ./navi.llamafile --server --v2 and the hardware-profile flags from config/navi.config.json. The launcher starts the bridge, verifies the thing answering on port 8675 is really this build — naming whatever else it finds by its page title — and only then opens the dashboard. During install you chose when the model server starts: on app launch (the bridge starts navi.llamafile when you press Connect) or at system boot. Server output lands in navi.llamafile.log beside the app.