Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.arkor.ai/llms.txt

Use this file to discover all available pages before exploring further.

​
Studio

Studio is the local web UI you get when you run arkor dev. It is not a separate service to sign into; it boots on your machine, talks to the same Arkor CLI process, and goes away when you stop the dev server.

​
What Studio is for

Three jobs:
  1. Start a training run. A “Run training” button submits the job to the managed backend by spawning arkor start under the hood. arkor start runs the existing .arkor/build/index.mjs artifact (and only auto-builds it when missing); see the dev-loop note below for how Studio keeps that artifact fresh.
  2. See training happen. A jobs list with live status, a loss chart that updates as the run streams in, and a tail of training events. You can leave it open in a tab while you work on other things.
  3. Try a finished model. A Playground page lets you pick the base model or the final adapter from any completed job and chat with it. The Playground does not load intermediate checkpoints; for mid-run inference, use onCheckpoint callbacks in your trainer.
A note on the dev loop: Studio’s /api/manifest endpoint rebuilds and re-imports your trainer on every request (with a cache-bust query, see packages/arkor/src/studio/manifest.ts), but the UI only fetches it when the Run training page mounts. So if you edit src/arkor/ and stay on the same Run training page, the next click reuses the existing .arkor/build/index.mjs and runs your old code. Refresh the page (or run arkor build from the terminal) between edits and clicks to pick up the new code reliably.

​
Where Studio runs

When you start arkor dev, the CLI:
  1. Boots a Hono server on 127.0.0.1:4000 (use -p to change the port).
  2. Serves a Vite + React SPA from the same origin so the UI talks to the CLI through /api/* on loopback.
  3. Issues a per-launch CSRF token (saved to ~/.arkor/studio-token with mode 0600) and requires every request to present it.
The server only binds to loopback and rejects requests with a non-loopback Host header. There is no public URL, no inbound connection, and the token rotates every time you start arkor dev. You can run Studio safely on a shared dev machine without worrying about exposing your training data.

​
How Studio fits with the managed backend

Studio is just a viewer for what your CLI is doing. The CLI talks to the managed backend over authenticated HTTPS; Studio asks the CLI (over loopback) what to render. 
Studio (browser tab)
   │  /api/* on loopback, CSRF-token gated
   ▼
arkor CLI (your machine)
   │  authenticated HTTPS
   ▼
Arkor managed backend (training, inference)
That separation is why Studio works without you logging into anything in the browser: the CLI already has your credentials in ~/.arkor/credentials.json, and Studio inherits them by virtue of running locally.

​
What you actually see

The current views are intentionally small:
  • Jobs. Status, name, created time, and ID, polled every few seconds.
  • Job detail. Loss chart, log tail (most recent events), and live status. Streamed via Server-Sent Events so it stays current without manual refresh.
  • Playground. Adapter selector (base model or the final adapter from any completed job), a chat UI, and a streaming response. Calls flow through the CLI, then to the managed inference endpoint. The Playground only lists jobs that have finished. To run inference against an intermediate checkpoint while a run is still in flight, use onCheckpoint callbacks instead.
A walkthrough of each view with screenshots lives in the Studio section (coming next in the docs).

​
When not to use Studio

Studio is a development tool. It runs on your machine, only on loopback, and only while arkor dev is up. For production usage of a fine-tuned model you would call infer from your own application code (or wire it into whatever serving layer you ship), not point users at Studio.