Configuration

Previously is configured exclusively through environment variables — six shipped vars, zero config files, one implicit backend switch that determines whether reads hit GitHub's API or your local filesystem.

Environment Variable Reference

Every variable the runtime actually reads, in one table:

Note on GITHUB_TOKEN: The code decides its backend with a single expression — const USE_GITHUB = !!process.env.GITHUB_TOKEN — declared independently in seven modules (chat route, flush route, episodic manager, user profile, profile writer, maintenance, and the identity/profile endpoint). There is no dedicated USE_GITHUB environment variable. Token present = GitHub API. Token absent = local filesystem. This is intentional: the simplest possible toggle, no config file, no extra surface area.

Backend Switch: GitHub API vs Local Filesystem

The storage backend is implicit by design. No env var, no config toggle — just the presence or absence of GITHUB_TOKEN:

const USE_GITHUB = !!process.env.GITHUB_TOKEN;

Both backends enforce the same security boundary:

• Path whitelist: only memory/, tasks/, and sessions/ are read-write; src/ is agent read-only
• Size cap: MAX_FILE_SIZE_BYTES = 1_000_000 (1 MB) on all file reads

The local-filesystem backend is what you use during development (pnpm dev). It reads and writes real files on disk — no GitHub, no network, no rate limits. The GitHub backend is what you deploy to Vercel. The code paths diverge at the route handlers, but the interface is identical.

DEMO_MODE Behavior

DEMO_MODE=true puts the entire memory layer into a read-only demonstration mode against a bundled persona dataset. Here is exactly what changes:

Path Redirection

Every memory/ read path is rewritten by resolveDemoPath (src/lib/demo/paths.ts):

memory/episodic/slices/...  ->  memory/demo/personal_14/episodic/slices/...
memory/nodes/some-node.md   ->  memory/demo/personal_14/nodes/some-node.md

The rewrite is guarded to fire only for paths starting with memory/ that do not already carry the memory/demo/personal_14/ prefix (idempotent). A companion unresolveDemoPath reverses the mapping so callers stay in the original namespace.

Writes: Accepted, Never Persisted

DEMO_MODE makes writes a no-op on both storage backends:

• Local-filesystem (src/lib/tools/local-fs.ts): returns { path, created: false } without writing to disk
• GitHub API (src/lib/tools/writeFile.ts): returns the same early-success response, never calls createOrUpdateFileContents

The agent sees a successful write. The data is silently discarded.

Demo Ref for GitHub Deployments

When deploying with DEMO_MODE=true and GITHUB_TOKEN set, you also need DEMO_REF. Without it, the GitHub API reads from the repository's default branch (main) — which is intentionally empty in the demo scenario. Set DEMO_REF to the branch, tag, or SHA where the demo dataset lives:

DEMO_MODE=true
DEMO_REF=demo-branch-name

The ref is applied at src/lib/tools/readFile.ts: ref: ref ?? demoRef(). The demoRef() helper returns process.env.DEMO_REF || undefined — only active when DEMO_MODE is true.

DEMO_REF is present in the code but not documented in .env.example — a documentation gap in v0.1.0.

UI Banner

The locale layout conditionally renders <DemoBanner /> when DEMO_MODE=true. Users see a visual indicator that the instance is running in demo mode.

Model Registry and DeepSeek Routing

Previously ships with a DeepSeek-only model registry. Two tiers, one model family:

Flash Is Hardcoded

The Flash pass runs before the response stream opens. It makes one generateText call to deepseek-chat (temperature 0.1, toolChoice: 'required') that performs three jobs in a single round-trip: intent classification, recall scanning, and metadata maintenance. There is no configuration for Flash — it always uses deepseek-chat.

Pro Model Selection

The Pro model is selected per-request from the client:

const model = (body.model as string) ?? 'deepseek-chat';

The client default is deepseek-chat as well (getClientSetting('PREVIOUSLY_MODEL', 'deepseek-chat')). The model registry defines exactly two models:

deepseek-reasoner exists in the registry and is available as a user-selectable option, but it is not the default and is not auto-selected by the thinking toggle. The shipped path stays on deepseek-chat.

Thinking Toggle

The thinking toggle is a request-level boolean (body.thinking, default true) that is not a model switch. When enabled, the server adds provider options to the deepseek-chat call:

providerOptions: {
  deepseek: {
    thinking: { type: 'enabled' },
    reasoningEffort: 'medium',
  },
}

When disabled, no providerOptions are sent. The thinking duration is measured server-side (wall-clock time between the first reasoning chunk and the first text chunk) and emitted as a data-reasoning event — not tracked client-side via timers.

Nuance: deepseek-reasoner exists in the registry but the thinking toggle does not switch to it. Both the route code and the client default are deepseek-chat. The toggle is a provider-level option on deepseek-chat, not a model swap.

Internationalization

i18n uses next-intl with exactly two locales:

Configuration lives in src/i18n/routing.ts:

defineRouting({
  locales: ['en', 'zh'],
  defaultLocale: 'en',
});

Translation files:

• messages/en.json
• messages/zh.json

Navigation must use utilities from @/i18n/navigation instead of next/navigation (enforced by project convention). The locale layout wraps content in NextIntlClientProvider.

The Omitted Vars

A few environment variables you might expect, and why they do not exist:

Related

• Deployment — deployment walkthrough with the full .env.local template
• Recall — how Flash and Pro use the configured models