Every feature, shown for real — screen captures of the actual desktop app, one to four minutes each. Subtitles are available on every video.
Everything ForkScape does, and how to drive it.
ForkScape is a non-linear, node-based AI workspace: instead of one long chat that decays as it grows, you work on a branching canvas where every idea forks cleanly and a live meter proves how much context that saves. This guide walks every panel, screen, and setting — with real screenshots from the app, not mockups.
Video tutorials
Getting started
What ForkScape is
The one idea worth understanding before anything else.
Every AI chat tool works the same way underneath: one growing transcript, re-sent in full on every message. The longer it gets, the more you pay for the same context over and over, and the more the model's attention gets diluted across old, irrelevant turns — long linear chats measurably lose quality as they grow.
ForkScape replaces the transcript with a canvas. Every message is a node; every reply can fork into siblings that each carry only the context they actually need. A sibling exploring "the budget version" of your trip plan never re-pays for the tokens spent exploring "the food-focused version." The top bar's LINEAR BRANCH / CTX SAVED meter measures this live, per canvas, from real calls — not a marketing estimate.
Everything else in ForkScape — Design Studio, automations, the Memory Palace, multi-agent builds — sits on top of this one structural idea. If branching clicks, the rest of the app reads as consequences of it.
Install & first launch
From download to a workspace you can type into.
ForkScape ships as a desktop app (Windows/macOS/Linux via Tauri) and runs entirely on your machine — no account, no server round-trip for your canvases. First launch shows a two-panel welcome screen: the branching pitch on the left, and Start using ForkScape → on the right.
Click through and you land on provider setup — the only required step before you can type anything.
Try it in the browser
The web playground: the real canvas, zero install, honest limits.
The playground at try.forkscape.com is the same app running in your browser. Chatting, branching, Research Mode, templates, dashboards, and multi-agent orchestration all work — and a free capped model is pre-configured (30 requests per visitor per day), so your first fork is one click away with no key and no account. Hit the daily allowance and you can keep going instantly with your own API key, or download the desktop app.
Anything that has to touch your machine — building real files, running your app, MCP servers, CLI agents, code editors, the Obsidian vault, offline dictation — shows a short "needs the desktop app" note with a download button instead of failing silently. That's not an upsell tier: the desktop app is free; the browser simply can't reach your disk or run programs.
The playground model has a small daily allowance per visitor. Paste your own API key in Settings → AI Provider and the browser talks to your provider directly — no allowance, and nothing routes through ForkScape's servers.
Choosing a provider
Three genuinely different ways to run the models — pick the one that matches what you already pay for.
ForkScape does not lock you into one AI vendor. The onboarding screen groups your options into three rows:
- API providers — Anthropic, OpenAI, Gemini, Grok, OpenRouter (multi-model), Auto Router, or any OpenAI-compatible custom endpoint. You paste a key once.
- Local CLI — no API key, uses your CLI's sign-in. If you already have Claude Code, the Antigravity CLI, or Codex CLI installed and signed in, ForkScape drives them directly — no separate key, no extra cost. This is the "layer on the agents you already pay for" path.
- On-device — offline, needs a strong GPU. Ollama (local or
:cloud) or llama.cpp. Free, private, no internet required once a model is pulled.
Picking Ollama reveals a Local/Cloud toggle, a Base URL field (defaults to http://localhost:11434), and live detection — a red dot and "Install / start Ollama" link appear the moment ForkScape can't reach it, with the exact fix command underneath.
You can add more providers later and switch per-node — this first choice only sets your default. See Providers & models for the full reference.
Running it for free
Every provider row has a $0 path. Which one fits depends on whether you care more about privacy, speed, or not installing anything.
ForkScape itself is free and takes no cut of your usage — the cost, if any, is whatever the model behind it charges. Three ways to make that nothing:
- Fully local — Ollama or llama.cpp. No key, no account, no internet once a model is pulled, and nothing leaves the machine. Needs a reasonable GPU.
- A CLI you already pay for — Claude Code, Antigravity, or Codex CLI. ForkScape drives your existing sign-in, so there is no second bill.
- A provider's free API tier — a key, no card, capped per day.
Providers with a standing free tier that does not ask for a card. Limits move around, so check each one's own page rather than trusting a number here:
- Google AI Studio — Gemini keys, generous daily request cap, long context.
- Groq — the fastest free option; tokens-per-minute is the ceiling that bites, not requests.
- Cerebras — very high throughput, a daily token allowance.
- OpenRouter — dozens of community models priced at $0, all behind one key.
- Mistral — free developer tier.
Any of these goes in Settings → AI Provider. Gemini and OpenRouter have their own rows; the rest work through Custom (OpenAI-compatible) — paste the base URL and key.
Pooling several free tiers behind one endpoint
Because ForkScape talks to any OpenAI-compatible endpoint, you can put a local gateway in front of several providers and let it fail over between them as each allowance runs out. OmniRoute (MIT) is the most complete one we have looked at: you sign in to whichever free tiers you want, it runs on your own machine, and it exposes one endpoint at http://localhost:20128. Point ForkScape's Custom provider at that and every branch on the canvas routes through it.
We do not bundle or resell any of this — the accounts are yours, the keys stay on your machine, and ForkScape never sees them. It is the same Custom-endpoint field that has always been there, pointed somewhere useful.
What "free" is buying. Most no-card tiers are funded by your prompts — the provider may train on what you send. If the work is confidential, use a local model or a paid key with training disabled, not a free tier. Terms also differ per provider, and a few restrict proxying or non-personal use, so skim them before you route serious volume through one.
Free tiers cap tokens, so ForkScape's branching helps twice over: a branch only re-sends the context it actually needs, which stretches an allowance much further than a linear chat would. Watch it on the savings dashboard.
Your first canvas
Type into the box, or start from a template.
Once a provider is connected, you land on an empty canvas with a System node (the AI's standing instructions) and a Thread panel on the right. Two ways to begin:
- Type a task into "Give the agent a task…" at the bottom of the Thread panel and press Enter — an agent node appears on the canvas and starts working.
- Click 📋 Templates in the top bar and drop in a ready-made multi-node setup (see Templates gallery).
Either way, the result lands on the canvas as connected nodes you can branch, edit, and re-run — never as a scrollback you lose track of.
The canvas
Anatomy of a node
Every node on the canvas follows the same shape.
Reading left to right on the header row: a checkbox (select for bulk actions), a color dot (its branch color), a role badge (SYSTEM / USER / AGENT / ASSISTANT), and an editable title. The orange circle on the top-right corner is the Run button.
The dropdown row underneath controls how that specific node executes:
- Auto — best vs a pinned model — override routing per node without touching global settings.
- Agent role dropdown — what kind of worker this node is (plain agent, Project Manager, a named skill like
/software-engineer). - No role — an optional persona/skill preset.
Below that: Enhance (asks the model to tighten your prompt wording before running), then a row of icon actions — attach file, 🎤 dictate, preview, copy, duplicate, branch (fork), and delete. The body is your prompt or the model's reply; token count for that node sits quietly under the header.
🎤 Dictation: click the mic, speak, click again — the transcript is appended to the prompt (never replacing what you typed). On desktop it transcribes locally and offline via whisper.cpp; install it once from Settings → Plugins → whisper.cpp → Install for me. Nothing you say leaves your machine.
Branching, not scrolling
The behavior that makes the rest of the app make sense.
Click the branch icon (the git-fork glyph) on any node to fork a sibling from that exact point. The new node gets its own color and its own path back to the root — it inherits everything upstream, but exploring it never adds tokens to any other sibling's bill. Ask one branch for "the food-focused version" of a trip and another for "the budget version," and neither pays for the other's exploration.
Reopen the tour any time from Help → Welcome Tour — it's a real canvas you can run and branch, not a slideshow.
Practical rule of thumb: branch whenever a question splits into two genuinely different directions. Don't branch for small edits to the same direction — that's what re-running a node in place is for.
The Branches panel (left rail) lists every branch on the current canvas by name and node count — useful for jumping to a specific fork on a canvas that's grown large.
The savings badge
Proof, not a promise — metered on every real call.
Once a session has a few real calls behind it, the top bar shows a LINEAR / FORKSCAPE bar pair with a % tokens saved figure. This is the metered number — the exact same figure the Full Analytics dashboard headlines: every real LLM call this session made (agent loops, PM workers, research fan-outs, prompt enhancement — nothing excluded) versus what one linear chat re-sending its whole history would have needed for the same work.
It's a conservative floor: unmeasurable savings simply aren't counted, and the badge stays hidden until there are enough measured calls (three or more) to make an honest claim. The larger-but-narrower canvas-architecture comparison — context shrink on node conversations only, blind to agent traffic — is shown inside the dashboard as an explanatory "Where it comes from" card, never as the headline. Share cards post the same metered number.
Model context windows
Different models read different amounts — ForkScape tracks each one's limit.
Every model has a context window — how many tokens it can read in one call. They differ wildly: Claude models read ~200k tokens, GPT-4.1 and Gemini around a million, while a local qwen3:8b tops out at ~32k and older 8B models at 8k. Because any node can pin its own model, one branch can mix them — and a chain built under a big-window model can be longer than a smaller model further down can read.
ForkScape handles this in three places:
- Thread View meter — the fill bar at the top of the Thread panel measures your chain against the window of the model that would actually read it (your thread model pick, else the selected node's pinned model, else the canvas default). Hover it to see the token count, the window, and the model name.
- Pre-flight check — running a node whose chain exceeds its model's window asks first: compress the older history into a summary node (the same one-click ✂ Compress on the node menu), or send as-is. Without the check, providers fail silently — Ollama drops the oldest messages (the branch root that carries your task) and cloud APIs return an error.
- Agents and research panels — an agent whose starting chain is over its model's window warns before the loop begins, and a multi-model research run names exactly which panel members can't fit the shared chain.
Two practical notes: local models can be capped even lower than their native window by Ollama's num_ctx setting (4,096 by default — raise it in your Ollama config for long chains), and the ✂ Compress History action is the universal fix — it summarizes a deep chain into one node and re-roots the branch, shrinking any over-window chain to a fraction of its size.
The flip side — more context than the model has. Because every call sends only its own branch, a canvas can hold far more total working context than the model's window: eight 8k-token research branches on a 32k model is ~64k tokens of live, organized context — 2× the window — and no single call ever comes near the limit. When your active canvas genuinely crosses that line (and the deepest branch still fits), the dashboard shows it as a "🪟 N× the model's context window" card. A linear chat physically cannot do this: it must fit everything in one window or start forgetting.
Templates gallery
Ready-made multi-node setups, organized by what they're for.
Click 📋 Templates in the top bar to open a searchable gallery: All / Development / Web Design / Social Media / Automation / Writing / Research / Data / Prompt Engineering. Each card shows a one-line pitch and the node count it drops onto your canvas — from a 2-node Code Review Agent to a 7-node A/B/C Prompt Comparison that runs the same prompt through three phrasings side by side.
Clicking a card creates a new canvas from the template (your current canvas is untouched) with its own System node carrying the template's standing instructions, and its nodes laid out top-down — same parent-above-children convention as everywhere else in the app, computed automatically rather than hand-positioned. Edit the placeholder text, then run.
Save your own: Canvas → 📌 Save as Template… snapshots the current canvas into the gallery under a My Templates category — the System node's instructions travel with it, and loading it later opens a fresh canvas exactly like a built-in template. Hover a saved card and click its ✕ to delete it.
Copy nodes between canvases: select nodes and press Ctrl+C (or Canvas → ⧉ Copy Selection), switch to any other canvas, and press Ctrl+V — the nodes arrive with their layout and the links between copied nodes intact, as fresh independent copies. Handy for lifting a good sub-tree out of one exploration into another without saving a whole template.
Multi-agent orchestration
One goal, several specialized agents, one canvas.
The Multi-Agent Orchestrator template is the clearest example of a pattern used throughout ForkScape: a top-level CEO Agent (or a Project Manager role) decomposes a task, then spawns dedicated child nodes — a Researcher, a Coder, a Reviewer — each with their own model, their own branch color, and their own clean context. A final Assistant node synthesizes their outputs.
You don't have to build this by hand: giving a Project Manager node a real goal ("build a habit tracker with reminders and stats") makes it plan and spawn the tree itself. This is the same engine behind Create App.
The Project Manager panel (left rail) tracks the task list a PM node is working through — click + Task to add one manually, or give any canvas agent the /pm skill to auto-plan a multi-step project from a single instruction.
Building apps
Create App & plan review
Describe the app; approve the plan; watch it get built.
Click ✨ Create App in the top bar and describe what you want in plain language. ForkScape's planner breaks it into a short task list and — by default — pauses for your review before spending a single token on the build.
Each line is Title — what to do; delete a line you don't need, add one you do, or rewrite the wording entirely — the plan is plain text, not a locked structure. Fewer tasks means a faster, cheaper build. You can also pick a Design system right here (see Design Studio) or leave it as "None (agent's choice)."
This pause is a deliberate gate — you control scope and token cost before the build starts. It's on by default for interactive use and automatically skipped for headless runs (Telegram, scheduled automations), where nobody is at the modal to click it.
Click ✓ Approve & build and the plan becomes a Project Manager node that spawns and runs each task, same as multi-agent orchestration — visible on the canvas the whole time, not a black box.
Design Studio
Design your app's UI separately from its logic, then hand it to the build.
Open 🎨 Design from the top bar for a dedicated UI workspace: describe a page ("a dashboard with a sidebar, KPI cards, a chart, and a recent-activity list") and get a live, styled preview — Desktop / Tablet / Mobile — that you can refine in plain language or hand-annotate.
Pick a starting point from the left rail:
- Design system presets — Claude (warm, human), Linear (dark, exacting), Minimal, Playful, Corporate, Glass/Aurora, Terminal — or "Let AI decide."
- Color palette — pick a swatch or paste a
coolors.colink. - Reference design — attach an image; ForkScape copies its visual language only, never the literal content.
- Import HTML design… — bring in an existing page and keep editing it with the same tools.
Multiple pages live as tabs along the top. When it looks right, 🚀 Build this app drops every page into references/ and lets the Project Manager build the real app to match — design and implementation stay genuinely separate until you say go.
Running & previewing your app
One button, a real dev server, no manual port juggling.
▶ Run app in the top bar starts your project's dev server (auto-detected: Vite, Next, a static server, whatever the build produced) and opens an in-app preview pane. ForkScape probes upward from a base port for a free one, so a second project never collides with the first, and a stale server from a previous run is stopped before a new one launches — the preview never silently points at old content.
When Auto-Plan finishes a build, three Preferences toggles (on by default) chain automatically: run the app, verify it actually rendered (not just started), and take a screenshot for a vision model to sanity-check the render — see Preferences tab.
Git & GitHub
Turn a project folder into a repo without leaving the canvas.
The Project Files panel's Git setup flow covers three starting points: init a fresh local repo, publish a new one straight to GitHub, or connect an already-existing remote. Once connected, commits, the remote URL, and an Open on GitHub shortcut are all one click away — and agents can be told to commit as part of a build.
Publishing needs a GitHub token with the repo scope, added once in Settings. If an investor or collaborator needs to review source without full repo access, prefer time-boxed read-only collaborator access over emailing a zip — access can be revoked; a zip can't.
Automation
The Automate panel
Describe a goal; an AI agent does it, on a trigger you choose.
Click the ⚡ Automate icon in the left rail. Unlike node-wiring tools, you don't connect boxes — you set WHEN it runs and WHAT the agent should do, in plain English.
Inside the panel:
- ✨ Templates — ready-made automations by category (a daily standup digest, weekly content ideas, a news digest, a site health check…) — click + to add one pre-filled, then tune it.
- New automation — name it, choose when it fires, write what the agent should do.
- + Add automation — it appears under Your automations with ▶ (run now, to test), ⏸ (pause), and ✕ (remove).
Every run spawns a real agent node on the canvas — you can always open it afterward and see exactly what happened, same as any manual run.
Schedules new
Every N minutes, or at an exact clock time — daily, weekly, or monthly.
The When dropdown offers four trigger types:
| Trigger | Fires | Typical use |
|---|---|---|
| Manual | Only when you press ▶ | One-off jobs, testing a new automation |
| Every N minutes | On an interval, while ForkScape is open | Frequent polling (site health, inbox triage) |
| At a specific time | Daily / Weekly (pick a weekday) / Monthly (pick a day 1–31) at an exact HH:MM | "Every morning at 7am," "every Friday at 6:30pm" |
| When a node finishes / When a file changes | Event-driven | Chain a follow-up step; auto-fix on save (desktop only) |
Monthly schedules clamp sensibly to short months — "day 31" fires on Feb 28 instead of silently skipping. Run on launch (a checkbox under the schedule) catches a run that came due while ForkScape was closed, firing it once the next time you open the app, so a daily job never silently skips a day.
True closed-app runs: expand ⏰ Run while closed (OS schedule) to generate a one-time schtasks (Windows) or cron (macOS/Linux) command. Your OS then opens ForkScape with --autorun at the time you set, it runs every due automation to completion, then quits — true scheduling even when you never open the app.
Approval gates new
Agents draft; you decide. Every automation can require a yes before anything goes out.
The Approval dropdown on every automation has three settings:
- No approval — fully autonomous. Use only for actions with no outward effect (research, drafting to a file).
- ✋ Ask in app before acting. The run pauses on a popup showing the exact content, with Approve/Reject buttons.
- ✋ Ask on Telegram before acting. The draft is sent to your connected bot; you approve from your phone from anywhere.
Under the hood: before posting, publishing, sending an email, or doing anything irreversible, the agent must show you the exact final content and wait. On Telegram, reply with a number (mapping to the shown options) or type the option text; no reply within 30 minutes counts as not approved, and the content is saved as a draft file instead of being lost.
Secrets are never requested over Telegram — only the in-app modal ever asks for API keys or tokens, even mid-automation.
Task queues
Run an agent once per row of a spreadsheet.
The Automate panel's second tab, Task queue, processes any tabular source — a local CSV, a URL (CSV/JSON, so any REST API), Airtable, or pasted rows — running an agent prompt per row with {'{{Column}}'} placeholders (e.g. "Research {'{{Company}}'} and draft an intro email"). Concurrency and a status column are configurable, so a long list processes several rows at once and marks each done as it finishes.
Telegram remote control
Drive ForkScape from your phone, from anywhere.
Settings → Preferences → Telegram gateway: create a bot with @BotFather, paste its token, enable the gateway. The first chat to message the bot becomes its owner — after that, the bot ignores everyone else, so a leaked token can't be driven by strangers.
Once bound, message the bot an app idea and it builds it, sending a screenshot when done — the same engine as automations, just triggered by a message instead of a clock. It's also how Telegram approval gates deliver drafts and collect your yes/no.
Memory & knowledge
Memory Palace & skills
Durable preferences and reusable personas that outlive a single canvas.
The Memory Palace panel (left rail) holds durable memories — facts ForkScape should just know without you re-explaining them every session — and the Vault (below). A ❓ How Memory Palace works card at the top of the panel recaps everything at a glance — click it to collapse once you know your way around, and look for the small ? icon beside section headings throughout the app: hovering it explains that feature without a wall of text.
Skills (named system prompts you invoke by /command, like /software-engineer) are managed in Settings → Plugins: 43 ship installed by default; add your own with a name and prompt template, or import one from a raw GitHub URL.
Reuse skills already installed for Claude Code or Codex
Claude Code, Codex, and the vendor-neutral npx skills CLI all use the same open Agent Skills format underneath: a folder per skill containing a SKILL.md file. Click 🔎 Scan for local skills in Settings → Plugins and ForkScape reads that format straight off disk — ~/.claude/skills and ~/.codex/skills (global), plus .claude/skills and .agents/skills inside the current project folder — no re-typing a prompt you've already written for another tool. Each result shows where it came from; Import adds it as a normal ForkScape skill (editable, removable, invocable by /command like any other), and Import all brings in everything the scan found in one click. Desktop app only — the filesystem access this needs isn't available in a browser tab.
The Vault
Your memory, as plain markdown files you actually own.
The Vault is an Obsidian-compatible folder of plain markdown: every canvas (a readable transcript plus a block ForkScape can recreate it from), plus anything you explicitly save. ForkScape writes it directly — Obsidian itself is entirely optional, only useful if you want to browse the files there.
Create new Vault… sets one up fresh; Use existing folder… connects your own Obsidian vault safely — ForkScape writes only inside a nested ForkScape/ subfolder, never mixing into your personal notes.
The Vault is why re-opening old work is cheap: reading an archived markdown file costs a fraction of what re-explaining "what did we build last week" to a fresh agent would.
Knowledge Base
Retrieval-augmented answers grounded in your own documents.
Point this panel at a folder of reference material (docs, specs, past reports) and agents can query it by meaning, not just exact text — useful for grounding a build in a real spec instead of the model's memory of similar projects.
Importing old AI chats
Bring your ChatGPT or Claude history with you — as real canvases.
From the Memory Palace, 📤 Import AI Conversations… accepts every common export shape: a ChatGPT or Claude data export (conversations.json, including {"conversations": […]} wrappers and multimodal turns), OpenAI-style {"messages": […]} documents and API logs, and .jsonl files of any flavor — Claude Code / Codex CLI session transcripts, one-message-per-line files, or one-conversation-per-line fine-tune logs. ChatGPT's edit/regenerate branches are preserved as actual forks — not flattened into one long thread — and CLI transcripts are rebuilt as an optimized branching tree with the tool-call noise folded away.
The Conversations panel. The left rail's 💬 Conversations panel lists every canvas like a chat sidebar — searchable, newest first, with node counts — plus one-click + New, 📥 Import…, and 🗂 Browse…. The 🧠 toggle beside the search box switches to semantic search — find conversations by what they're about, not just title words (needs an embedding model, set in Settings → Preferences → ⚡ Tokens). Its 🧠 Organize this canvas by relevance button runs the organizer agent on the OPEN canvas at any time: a canvas with many branches gets them regrouped under department/topic headers, and a LINEAR imported chat (Claude/ChatGPT/Gemini trunks have no branches) gets split into topical branches — trunk to tree, with no cap on branch count (an isolated one-off question gets its own small branch). Inside a topic, distinct sub-threads — an A/B comparison, or separate aspects of the same theme — fork as sibling sub-branches from the point where they diverge. Every untitled node also gets a short content-based title in the same pass, so the tree reads at a glance. Lossless and undoable with Ctrl+Z.
The import organizer agent. When you import many sessions at once, a dedicated agent reads a lightweight digest of each and groups them into relevance clusters on one canvas — each topic a colored branch, each session a labeled subtree. When you import one long chat, the same agent splits it into topical branches (pricing here, design there) instead of one endless chain. It never loses anything: sessions the agent can't place land in an "Other sessions" branch, real forks are never re-arranged, and if no model is connected the import falls back to instant deterministic grouping by project folder.
Providers & models
API, CLI, and local providers
The full reference for what you can connect and why you'd pick each.
| Type | Examples | Cost model | Best for |
|---|---|---|---|
| API key | Anthropic, OpenAI, Gemini, Grok, OpenRouter, Custom | Pay per token, your own key | Highest-capability frontier models |
| CLI (bring your own) | Claude Code, Codex CLI, Antigravity CLI | Whatever subscription you already have | Zero extra cost if you already pay for the CLI |
| On-device | Ollama, llama.cpp | Free after download | Privacy, offline, no per-token cost |
Settings → Provider lets you set the Base URL, API key, default Model, and a system-prompt toggle (apply ForkScape's default assistant guidelines to all models). Per-node dropdowns can always override the global default for one specific task.
Model routing
Who decides which model handles each task.
Three radio options set the routing philosophy for the whole app:
- Smart auto-pick (recommended) — ForkScape routes each task to a suitable model automatically and skips broken ones.
- My routing map — you assign a specific model per task type; ForkScape follows it exactly.
- Single model — everything runs on your one default model.
This is a global default only — any individual node's Auto — best dropdown can still be pinned to a specific model for that one call.
Fallback models
What happens when your primary model is down.
Settings → Provider → Fallback Model is used automatically when the primary errors — a local model down, a rate limit, a dead endpoint. Leave it blank to disable; set it to another provider entirely (not just another model on the same one) for real resilience.
Labs opt-in
Secondary panels that stay out of a new user's way until you flip Enable Labs in Settings → Preferences. The core rail stays short by default; Labs adds a few more icons.
Social Media publishing
Connect accounts once; let post_social publish directly.
Add credentials for Twitter/X, LinkedIn, Instagram, TikTok, YouTube, or a generic webhook, then an agent's post_social tool call can publish text, an image, or a video directly — text posts on Twitter/LinkedIn, media-URL posts on Instagram/TikTok, local-file uploads on YouTube, or arbitrary JSON to a webhook.
Combine this with an approval gate for anything automated — drafts should always pass through a human before anything public goes out.
Collaboration (Enterprise) — on your own server
Multiple people, one canvas — nothing leaves your network.
Team features run against a server your team hosts yourself: the open-source Supabase stack, stood up with one docker compose up on your own VPS, on-prem box, or private cloud. There is no ForkScape cloud in the loop — your prompts, canvases, and presence data stay entirely inside your infrastructure. Setup takes about 15 minutes: see docs/self-hosted-team-server.md in the repo (server + schema + accounts), then paste your server's URL and anon key into the Collaboration panel, Connect team server, and sign in.
Live today: presence (teammates on the same canvas appear in the Team tab) and canvas cloud sync against your server. The shared task queue and commit feed show sample data until their write paths ship — the panel labels this honestly. Note this is coordination, not Google-Docs co-editing: simultaneous edits to one node are last-write-wins.
Git needs no server at all — the app drives your own git, so any remote works (GitHub, self-hosted GitLab, Gitea). GitHub Enterprise Server users can point repo creation at their instance via the githubApiBase setting (API root, e.g. https://github.corp.com/api/v3).
Collaboration requires an Enterprise license; on Free/Pro the panel shows what it does and how to get it.
Tracking & savings
Session Stats
The quick numbers, without leaving the canvas.
This left-rail panel is the lightweight version of the full Dashboard: LLM calls, tokens in/out, and the metered % saved figure — the same all-calls-counted number the Dashboard headlines — plus a list of every canvas you've touched this session with per-canvas totals. Click 📊 Open full dashboard for the complete picture. (The top-bar meter is different: it shows context shrink from branching only, which is why its percentage usually reads higher.)
Full Analytics dashboard
Every number the savings claim is built on, with sources shown.
Five tabs across the top:
- Overview — the headline is the metered savings figure: every real LLM call this session made (agent loops, PM workers, research fan-outs, prompt enhancement — nothing excluded) vs. what one linear session would have needed for the same work, with a comparison bar and the dollar figure beneath it. Below it, a smaller "Where it comes from" card shows the canvas-architecture comparison — usually a larger percentage, but it only sees node conversations, which is exactly why it isn't the headline.
- Quality — see Quality scoring below.
- Breakdown — real per-model usage, recorded automatically: every model that answered a call gets a row with its calls, fresh tokens in/out, cache re-reads, and cost. Run three models on one canvas and you'll see exactly how the work split between them.
- History — saved snapshots: point-in-time records of a canvas's branch-vs-linear saving with editable quality notes. The live meters never need them — snapshots are receipts, for tracking savings across projects or exporting a report. A one-click Save a snapshot button lives right in the tab.
- Cost — metered dollars first (spent vs. what a cache-using linear chat would have cost), then snapshot-based projections once you've saved snapshots. Local and CLI-subscription models cost $0 per call, so they add tokens but no dollars here.
The model filter (top-right) fills itself from every model that has actually answered a call, and narrows the Breakdown, History, and Quality tabs. A scope toggle switches every figure between this canvas and all canvases; the × closes the panel.
Quality scoring
Not just cheaper — verifiably as good, or better.
After a run finishes, a separate judge model scores the deliverable 1–4 against a rubric. A low score triggers exactly one bounded revision round — never an open-ended veto loop. Revision lift is the score gained by that single pass (e.g. 2→4/4); the per-model table lets you see, honestly, whether your cheaper model is actually holding up.
Verify pass is on by default — the one extra judge call per top-level run buys a real quality floor. Turn it off in Preferences if you'd rather skip that call.
Share cards
The savings number, as a postable image.
Click Share card from Session Stats or the Dashboard to render this card with your canvas's actual numbers baked in — the ForkScape mark, a big tokens saved percentage, the linear-chat token count, and ForkScape's real count. 𝕏 Post it is the one-click version for X specifically. Because it's a genuine per-canvas measurement rather than a fixed graphic, no two share cards say quite the same thing.
Settings reference
Open Settings from the gear icon at the bottom of the left rail. Three tabs: Provider, Preferences, Plugins.
Provider tab
Where your AI actually connects.
Covered in full under Providers & models — Base URL, API key, Model, Detect Models, Fallback Model, and the model-routing radios all live here.
Preferences tab
Theme, canvas behavior, agent limits, and the Telegram gateway.
The tab is organized into six category chips — click one to show just its group:
- 🎨 Appearance — 13 theme presets (GitHub Dark/Light, Claude, Blender, Dracula, Nord, Solarized Dark, Monokai, One Dark Pro, Tokyo Night, Cyberpunk, Linear Dark, Vercel Dark, Rosewood), plus the Labs toggle.
- 🗺 Canvas — snap to grid, straight vs. curved connection lines, grid size.
- 🤖 Agents & Builds — agent limits (spawn depth, token budgets, parallel PM tasks), orchestration mode, auto-compaction, plan review, app preview auto-run/verify, and the self-improvement toggles.
- ⚡ Tokens — the optimization checkboxes, the Token Saving level slider, and the semantic-search embedding model.
- 🔐 Security — the permissions bypass, trusted folders, and secrets vault.
- 🔌 Integrations — the Telegram gateway and preferred desktop editor.
The two most-visited groups:
- App preview (under Agents & Builds) — auto-run after Auto-Plan, verify the render, use a vision model on a screenshot (see Running & previewing).
- Telegram gateway (under Integrations) — bot token, enable switch, and the exact BotFather steps (see Telegram remote control).
- Permissions & Trusted folders (under Security) — "Agents bypass all permissions" for fully unattended runs, and the folder trust list (see Workspace Trust).
Plugins tab
Optional CLI tools that give agents extra capabilities — all fail gracefully when absent.
| Tool | Unlocks |
|---|---|
| web_reach (Agent-Reach) | Live reads of YouTube transcripts, tweets/X search, Reddit, GitHub, RSS — no paid search API |
| graphify | A live code knowledge graph — one query instead of reading 5–15 files to answer an architecture question |
| agent-browser | Real browser automation for agents — navigate, click, screenshot JS-rendered pages |
| docling | PDF/DOCX/PPTX/XLSX → clean markdown |
| probe | AST-aware semantic code search |
| pwcpp (whisper.cpp) | Free, offline local speech-to-text |
| flyctl | Deploy straight to Fly.io |
Install for me runs the tool's own installer (pip/npm/etc.) without opening a terminal; Re-check re-probes if you installed something manually. The first-run Token-efficiency playbook surfaces the same list with concrete before/after token numbers per tool.
Plan tab — Free, Pro & Enterprise
What each tier includes, and how licenses work without an account.
Free is real, forever: the full branching canvas, every AI provider (your own keys, local Ollama, CLI sign-ins), templates, agent builds, the dashboard — capped at 5 canvases, 1 level of sub-agents, 2 Research Mode models, and 1 MCP server. Pro ($12/month) removes the caps and unlocks Automations, the Telegram remote gateway, and the voice/avatar generation tools. Enterprise adds team collaboration on your own self-hosted server (presence, shared queue, canvas sync — entirely inside your network), deeper orchestration (5 sub-agent levels), volume licensing and priority support.
Licenses are plain signed keys (FSK1.…) verified offline — no account, no phone-home, and your work never leaves your machine on any plan. Paste the key from your purchase email into Settings → Plan → Activate. Removing a license just returns you to Free; nothing is deleted. If a run bumps into a Free-plan cap, you get a toast pointing here — never a broken half-result (Research Mode, for example, simply trims to the first 2 picked models).
Workspace Trust
Opening someone else's folder shouldn't mean silently running their instructions.
A freshly opened folder is Restricted by default: agents can browse and read, but cannot write files, run shell commands, or have that folder's own FORKSCAPE.md/.cursorrules instructions injected into their context — because a downloaded repo's rule file is attacker-controlled text, not something to trust blindly. Open in restricted mode lets you look around safely first; Yes, I trust this folder grants full write/shell access and applies its own instructions to every agent working there.
The project file renamed
How ForkScape remembers a canvas alongside your code.
Every project folder gets one file — <project-name>_fc.json — that mirrors its canvas. It's easy to spot in a file explorer and names the project it belongs to. Opening that folder again auto-resumes exactly where you left off.
- Older projects with a plain
flowcode.json(the pre-rebrand name) still resume correctly, and get migrated to the new name automatically on the next save. - Renaming the project folder doesn't orphan the file — ForkScape falls back to any
*_fc.jsonit finds and renames it to match on the next save. - If a folder's project file exists but can't be read as a canvas (corrupted, hand-edited, or from another tool), ForkScape asks before doing anything — never silently overwrites it. Decline, and that file is protected from autosave for the rest of the session.
Agents are explicitly instructed never to read or edit this file — it's ForkScape's own bookkeeping, not source code.
Tutorials
Tutorial: build an app automatically
One description in, a running app out — the fully-orchestrated path.
- Click ✨ Create App in the top bar and describe what you want in plain words — "a habit tracker with streaks and a weekly chart". The Enhance button tightens a rough description for you.
Step 1 — Create App opens a short wizard: describe the app, pick where it runs - Pick a folder. The native dialog both selects and creates folders; ForkScape asks you to trust it (that's Workspace Trust — agents can only write inside trusted folders). If files are already there, it builds into the existing project; if empty, it scaffolds fresh.
Step 2 — the Workspace Trust question: agents only write inside folders you trust - Review the plan. The Project Manager decomposes your description into concrete tasks and shows them for approval — this is where you control scope (and cost). Remove anything you don't want built, then approve.
Step 3 — the plan-approval gate: edit or remove tasks, then approve - Watch the build. The PM fans out into worker agents on the canvas — each takes one task with only the context it needs. Live logs stream into the Terminal (Ctrl+J). If a worker needs something only you have (an API key, a decision), the run pauses and asks — secrets go straight into
.env, never into the transcript.Step 4 — the PM fans out into worker agents, each building one task - It launches itself. After typecheck + tests pass, the app starts and the App Viewer opens on the live URL. Use Run in the viewer any time after; annotate elements in the preview to request changes.
Every build step lands as nodes you can re-run individually. Fix one task by re-running its node — lineage replay means unchanged steps come from cache and cost ~0 tokens.
Tutorial: build an app manually (canvas-driven)
Same power, your pacing — you place every agent yourself.
- Open a project folder first: Files → Open folder… (Ctrl+E), and trust it.
Step 1 — the Project panel with a folder open - Double-click an empty spot on the canvas to create a node. Type a focused task — "set up a Vite + Svelte project with a router".
Step 2 — a fresh agent node with a focused task typed in - On the node, pick how it runs: ▶ runs it as a single agent with tools; the ⚡ Auto split-button routes it through the planner first (plan → your approval → build). For a big goal, type it into one node and choose the /pm skill — it will spawn its own workers.
Step 3 — the node’s controls: run modes, model routing, and the toolbar - Branch instead of piling on: want to try two approaches? Create two child nodes off the same parent — each carries only its own context, and the savings meter shows what that avoids re-sending.
Step 4 — two branches off one parent, each carrying only its own context - Iterate tightly: 🧩 Open in VS Code from the Project panel to hand-edit, then re-run just the node that needs redoing. Use the GIT tab to init/commit/publish when it's worth keeping.
Manual mode is the best way to learn what the automatic path does — it's the same agents, minus the orchestration layer deciding for you.
Tutorial: Design Studio, idea → screens → build
Design the whole UI before a single line of app code exists.
- Open 🎨 Design Studio. Describe the app once in the whole-app prompt — it plans the screens and generates every page in parallel, each as a real, rendered HTML mockup.
Step 1 — Design Studio: one whole-app prompt plans and generates every screen - Refine per page: switch pages with the tabs, generate variations, and use annotate to click any element and say what to change — "make this header sticky", "warmer color here".
Step 2 — pages as tabs, v1/v2 variation chips, Annotate, and per-page Refine - Lock the look: import a color palette, or attach a reference design image — ForkScape copies its design language (spacing, tone, type), not the pixels. You can also import existing HTML files as pages.
- Keep it: 💾 Save page / Save all pages writes
design/*.htmlinto your project (in the browser playground the same buttons download the files). - Make it real: 🚀 Build this app hands every page + the design system to the Project Manager as references — the built app matches what you approved on screen.
Tutorial: run a research panel
Ask once, hear from every model you have — then get one honest synthesis.
- Create a node with your question — the kind with no single right answer: "What pricing model fits a prosumer AI tool?"
- Open the node's run-mode menu and pick 🔬 Research. Tick the models to include — the roster spans every provider you've connected (API, local Ollama, CLIs). Two models on Free; unlimited on Pro.
Step 2 — Research mode on: tick the models, optionally Web research grounding - Optionally enable Web research — a shared web search+fetch pass grounds every model with the same fresh sources, which makes even small local models useful on current topics.
- Run it. Each model answers in its own branch, in parallel — then a debate round has them critique each other, and a synthesis node merges the strongest points with disagreements kept visible.
Step 4 — each model answers in its own branch, side by side - Export: any research result can become a polished HTML or PDF report from the node's export buttons.
Tutorial: set up an automation
An agent that runs on a schedule — with you in the approval loop. (Pro)
- Open ⚡ Automate in the left rail. Start from a template (they encode working prompts) or click New automation.
Step 1 — the ⚡ Automate icon in the left rail - Write the prompt as a complete standing instruction — "every morning, summarize yesterday's commits and draft a standup note". Pick the trigger: manual, interval, daily schedule, or file-watch.
Step 2 — the New automation form: name, weekly schedule, and the standing prompt - If it touches an external service, store the token once in Secrets and reference it as
{{NAME}}— the agent can use it but never sees it. - Choose the approval mode: anything that posts or sends shows you the exact content first — approve in-app, or from your phone via the Telegram gateway (reply 1 to approve, 2 to reject; silence = rejected, saved as draft).
Step 4 — the approval gate: see the exact content before anything posts - Test with ▶ before scheduling — each run lands as a node on the canvas, so the full history of what your automation actually did is always inspectable.
Step 5 — armed: green dot means live; ▶ test-fires it right now
Tutorial: memory that compounds
Make month three smarter than week one — three layers, all inspectable.
- Memory Palace (left rail) is cross-session memory. Agents save durable facts with remember and retrieve them with recall; with auto-memory on, the important ones are distilled for you. Prune it like a garden — memory you didn't write is memory you should read.
The Memory Palace — cross-session memories, searchable and prunable - Project knowledge lives in
FORKSCAPE.mdin each project — standing instructions plus a maintained block of what the project is and how it's built. Agents read it on every run; corrections you make become rules that are enforced, not just remembered.Project knowledge — standing instructions agents read on every run - The Vault mirrors everything to plain markdown — Memory Palace, every canvas as a readable transcript — at
Documents/ForkScape Vault, Obsidian-compatible. Already use Obsidian? Connect your own vault; ForkScape keeps to aForkScape/subfolder and never touches your notes.
Import old Claude Code / Codex CLI sessions (Session Browser) and their knowledge joins the same pool — your history, restructured into branches.
Tutorial: dictation & your AI voice clone
Talk instead of type — and let agents speak in your voice. (Voice tools: Pro)
- Dictate into any node: click the 🎤 on the node toolbar, talk, click again to stop. On desktop this is whisper.cpp running locally — install once via Settings → Plugins → whisper.cpp → Install for me; audio never leaves your machine. Dictation appends, never overwrites.
The node toolbar — the 🎤 between attach and preview starts dictation - Clone your voice (once, at ElevenLabs): create an account → Voices → Instant Voice Clone → read the sample prompts. Copy your voice id and an API key.
- Wire it into ForkScape: store both as secrets —
ELEVENLABS_API_KEYandELEVENLABS_VOICE_ID. Done: any agent can now use the generate_voice tool. - Use it: ask an agent "read this summary as audio" or chain it in an automation ("draft my daily brief and voice it"). MP3s land in the project's
output/folder and on the canvas.
Tutorial: an AI avatar persona for videos
A talking-head video of your persona, from a script — no camera. (Pro)
- Create the persona (once, at HeyGen): make an avatar from your footage or pick a stock one; note the avatar id and a HeyGen voice id (pair it with your ElevenLabs clone for full consistency).
- Store the secrets:
HEYGEN_API_KEY,HEYGEN_AVATAR_ID,HEYGEN_VOICE_ID. If anything's missing at run time the agent pauses and asks — it will never invent ids. - Generate: ask an agent — "make a 30-second launch announcement video of my avatar reading this script". Rendering takes a few minutes; the MP4 lands in
output/and on the canvas. Need b-roll? The generate_video tool (Veo, needs a Gemini key) creates short scene clips from text. - Assemble: ForkScape generates the pieces — script, voiceover, avatar clip, b-roll — and the agent can cut them together too: see Cut a finished video for the full assembly workflow.
Pipeline idea: one automation that drafts the day's post → voices it → renders the avatar clip → sends everything to your phone via Telegram for approval. Every asset in that chain comes from tools in this tutorial.
Tutorial: cut a finished video (agent-driven edit)
From a pile of generated clips to one publishable MP4 — the agent does the cutting. (Desktop)
- Generate the pieces first. Follow the voice and avatar tutorials: your voiceover MP3, the avatar clip, and any Veo b-roll all land in the project's
output/folder. That folder is your edit bin. - Plan the cut with the built-in video skills. On the node's skill dropdown, pick 🎞 Hyperframes for a frame-by-frame storyboard — every keyframe timestamped with shot type, composition, transitions, and on-screen text/SFX cues (this is also your motion-graphics planner) — or just ask plainly: "Write the edit plan for my 30-second launch video: avatar intro, two b-roll cuts, captions, end card." Either way you get a cut list you can read, tweak, and approve before anything renders.
Step 2 — the edit plan as a node: timings, clips, captions — edit it like any text before assembly - Install ffmpeg once — the agent's cutting tool. Windows:
winget install ffmpeg· Mac:brew install ffmpeg. (Desktop app only: the agent runs it through the shell on your machine.) - Assemble with 📼 Video Use. Pick the Video Use skill on the node and say "assemble it" — it probes every clip with ffprobe first (duration, codecs, fps), runs ffmpeg per the plan — concatenating clips, laying the voiceover under the b-roll, burning in the captions — and always writes to
output/so your originals are never overwritten. For creative direction (pacing, transitions, sound design), the 🎬 Video Editor skill puts the agent in a pro editor's role for the whole task. Iterate in plain words: "tighten cut two to six seconds", "captions bigger". - Prefer hands-on? Import
output/into CapCut, Resolve, or Premiere and follow the same plan manually — ForkScape's plan is editor-agnostic. Either way, publish straight from the canvas with the social tools, behind the usual approval gate.Step 5 — publish from ForkScape: the approval gate shows the exact post before anything goes live
Honest scope: this is programmatic cutting — concat, audio, captions, trims. It's perfect for short-form and announcement videos; a music video with beat-matched cuts still wants a human in a timeline editor.
Tutorial: drive Blender (3D) with an agent — MVP
Describe a scene in words, watch it build itself in Blender's viewport. (Desktop · Blender is free)
- One-time setup in Blender: install Blender, then the community blender-mcp addon (github.com/ahujasid/blender-mcp — download the addon file, Blender → Edit → Preferences → Add-ons → Install). In Blender's 3D view press N to open the sidebar, find the BlenderMCP tab, and click Connect. Leave Blender open — that's the live end of the wire.
- One-time setup in ForkScape: Settings → Plugins → MCP Servers → add a server — name it
Blender, commanduvx, argumentblender-mcp(needs the freeuvtool:winget install astral-sh.uv/brew install uv). Click connect: the Blender tools join every agent's toolbox automatically.Step 2 — MCP Servers in Settings → Plugins: the Blender server added as uvx blender-mcp; Reconnect once Blender's addon is listening - Build your first scene. On the canvas, give an agent a concrete, bounded ask: "In Blender, create a low-poly desk scene: desk, laptop, mug, warm key light from the left, camera at eye level." Watch the objects appear in Blender's viewport as each tool call lands — if the viewport looks frozen, click inside it once (Blender redraws on focus).
- Iterate in plain words. "Make the mug red." "Lower the camera and aim at the laptop." "Add a soft rim light." Each request is a new node — branch to try two lighting setups side by side, exactly like any other ForkScape work.
- Render the result: "Render a 1080p still and save it to output/desk.png." The render lands in your project folder; from there it's a Design Studio reference, a social post (approval-gated), or b-roll for the video tutorial's edit bin.
MVP scope, honestly: object creation, materials, lights, camera, and renders work well through tool calls. Sculpting, rigging, and animation curves are still hands-in-Blender territory — the agent is your scene assembler, not a character animator. Free plan includes 1 MCP server, so Blender fits without upgrading.
Tutorial: settings & preferences tour
Five minutes through the four tabs — the handful of switches that actually change your day.
- Provider tab — who does the thinking. Your default provider/model live here, but the useful part is the rest: per-provider API keys (switch providers without retyping), a fallback model that takes over automatically when your primary errors, and the Auto Router if you want per-task model picking. Change the default any time — existing nodes keep the model they ran with.
Provider — default model, per-provider keys, and the fallback that saves a failed run - Preferences tab — how the canvas behaves. The ones worth knowing: theme presets, snap-to-grid and edge style (taste), the token-saver level and prompt-cache toggles (cost), auto-compact for long branches, and the agent knobs — max sub-agent depth, token budget, and the plan-review gate that makes builds ask before spending. If a run ever surprises you, the explanation is usually a toggle here.
Preferences — canvas feel on top, token-saver and agent budgets below - Plugins tab — superpowers, all optional. Top: MCP servers (Blender, GitHub, anything speaking MCP — name + command is all it takes). Middle: one-click CLI toolkits — whisper.cpp for offline dictation, Graphify's code graph, agent-browser, Docling, Probe — each with an Install for me button and honest availability detection. Bottom: the 40+ built-in skills your nodes can adopt. Everything here fails gracefully when absent.
Plugins — MCP servers, one-click toolkits, and the skill catalog - Plan tab — what's unlocked. Shows your tier, the full Free/Pro/Enterprise comparison, and the license-key box. Activation is offline — paste the key from your purchase email, no account, no phone-home. Removing a key just drops you back to Free; nothing is deleted.
Plan — your tier, the honest comparison table, and offline key activation - Two settings that live elsewhere: Workspace Trust (which folders agents may write to) is asked per folder and managed under Preferences → Trusted folders; Secrets (API tokens automations reference as
{{NAME}}) live in the ⚡ Automate panel. Both are covered in their own articles above.
Defaults are deliberately sane: if you never open Settings after onboarding, everything works. Come here when you want cheaper runs (saver level), bigger builds (agent budgets), or new capabilities (Plugins).
Troubleshooting
"Ollama not detected at this address"
- 1Confirm Ollama is actually running:
ollama servein a terminal (it's usually already running as a background service — this just confirms it). - 2Pull at least one model:
ollama pull llama3.2. - 3Check the Base URL in Settings → Provider matches where it's actually listening — default is
http://localhost:11434. - 4Click Detect Models to re-probe once it's up.
Stuck in restricted mode / agents can't write files
This is Workspace Trust doing its job on a folder you haven't trusted yet. Open Settings → Preferences → Trusted folders and add it, or re-trigger the trust prompt by reopening the folder and choosing Yes, I trust this folder. Only do this for folders whose contents you actually understand.
Token usage looks higher than expected
- 1Open the full Dashboard → Breakdown to see which node type or model is driving the total.
- 2Check Preferences → Agent limits — a high parallel PM tasks or spawn depth setting on a big build fans out further than expected.
- 3Long-running agents auto-compact their own transcript once it passes a threshold, summarizing older history so it doesn't keep resending in full — this is automatic and shows as a "🗜 Compacted context" log line. Compaction itself costs one extra call, so it's tuned to trigger only well above ordinary working-set size — expect to see it on long, complex builds, not short tasks.
- 4Install the Plugins-tab tools (Graphify especially) — they replace expensive multi-file reads with single, cheap queries.
An automation didn't fire
- 1Scheduled and event automations only run while ForkScape is open — check the automation row isn't paused (⏸ vs the green dot), and that the app was actually running at the scheduled time.
- 2For guaranteed runs regardless of whether the app is open, set up the OS-level schedule (
--autorun) instead of relying on ForkScape staying open. - 3If it's gated on Telegram approval, confirm the gateway shows listening in Settings, not error — a dead bot token falls back to the in-app popup, which needs someone actually at the screen.
- 4Check Recent runs in the Automate panel — an error there (⚠️) usually names the exact failure (missing secret, unreachable API).