Get up and
running.

$ npm install -g @openbaker/cli
$ baker --version
  0.5.0

$ baker

  No instance connected.

  ? What do you want to do?
    › New instance
      Connect to existing

  ? What type of instance?
    › Hosted     app.openbaker.org
      Self-hosted Docker, local or remote

  Hosted: paste your invite token.
  Self-hosted: baker handles Docker setup.

✓ Connected to app.openbaker.org

$ baker chat
✓ claude-opus-4 / workspace: default
baker › _

Config file

Baker stores its config at ~/.baker/config.json. You can edit it directly or use baker config set <key> <value>.

{
  "instance": "https://app.openbaker.org",
  "profile": "default",
  "workspace": "default",
  "model": "gpt-4o",
  "apiKey": "sk-...",
  "telemetry": false,
  "theme": "dark"
}

instance	URL of the connected OpenBaker instance.
profile	Active named profile. Allows multiple instance configs.
workspace	Default workspace name used when none is specified.
model	Default model ID. Overridable per-command with --model.
apiKey	Your AI provider API key. Stored locally, never sent to Baker servers.
telemetry	Boolean. Anonymous CLI usage telemetry. Default: false.
theme	CLI output theme. dark or light. Default: dark.

Environment variables

All config values can be overridden with env vars. Useful for CI or Docker setups. Env vars always take precedence over config file values.

BAKER_INSTANCE	Instance URL. Overrides config.instance.
BAKER_KEY	AI provider API key. Overrides config.apiKey.
BAKER_MODEL	Model ID. Overrides config.model.
BAKER_WORKSPACE	Workspace name. Overrides config.workspace.
BAKER_PROFILE	Config profile. Overrides config.profile.
BAKER_TELEMETRY	0 or 1. Overrides config.telemetry.

Example

# run a one-off chat without changing config
$ BAKER_WORKSPACE=research BAKER_MODEL=claude-opus-4 baker chat

Workspaces

A workspace is an isolated context container. It holds chat history, tasks, schedules, and model config independently from other workspaces. Think of it like a project folder.

What's isolated per workspace

• Chat session history and context
• Tasks list (open + completed)
• Schedules and automations
• Model override (optional)
• Usage history and stats

What's shared across workspaces

• Your AI provider API key
• Instance connection and auth
• CLI config and theme

Typical usage

# one workspace per project
$ baker workspace create api-project
$ baker workspace create research
$ baker workspace use api-project
$ baker chat
✓ Workspace: api-project · 0 sessions

Auth & API

The Baker CLI authenticates to the instance using a session token stored in ~/.baker/config.json. The instance exposes a REST API — same API the CLI uses.

CLI auth flow

Baker uses a token issued by the instance. For the hosted instance, you receive the token with your invite. For self-hosted, generate one from the admin panel or via baker admin token create.

# baker connect stores token locally:
~/.baker/config.json → { "token": "...", "instance": "..." }

# every CLI request sends:
Authorization: Bearer <token>

API key handling

Your AI provider key (OpenAI, Anthropic, etc.) is configured on the instance — not stored on your local machine. Keys are stored encrypted on the instance and used server-side when the CLI sends a chat request. They are never logged or transmitted outside the instance.

Planned features

These are features in active consideration or early design — not shipped yet, but close enough to document the intent. They may ship differently than described here.

Guided clarification mode (#3)

When Baker receives an ambiguous request, it currently attempts to infer intent and proceed. The planned clarification mode changes that: Baker identifies the ambiguity, asks one specific question, waits for the answer, then continues.

Design constraints being considered:

• One question per clarification pass — not a multi-step interview
• Configurable via baker config set clarify on|off|auto
• auto (default) triggers only when confidence is below a threshold
• Inline in the terminal — no mode switch, no separate prompt

Goal: fewer wrong assumptions, especially in automations that run unattended.

GitHub co-author attribution (#2)

When Baker helps write code and the result ends up in a commit, there's no current mechanism to attribute that. The planned co-author feature adds a Co-Authored-By trailer to commits when Baker was involved in writing the diff.

Design constraints being considered:

• Opt-in — not automatic by default
• Configurable baker identity: Baker <baker@openbaker.org>
• Applies only when Baker wrote or substantially modified the staged content
• Works with baker commit and baker task — not with raw git commit

This is as much about honesty as tooling. If Baker built it, the commit should say so.

Weekly update digest (#6)

A low-volume email list: one update per week, one question per week. No marketing. No announcements about the announcement. The format is fixed — update + question — and will not change based on engagement pressure.

Delivery will happen when there's something worth sending. If a week produces nothing notable, nothing sends. Sign-up will be on the feed page when it's live.