Pascal Editor

Pascal Editor is an open-source, local-first 3D building editor from Pascal Group. Built with React Three Fiber and WebGPU, it models walls, rooms, levels, roofs, and furniture in the browser. A local CLI and MCP server let humans and AI agents edit the same scenes.

---

Scope and currency

This is an architecture evaluation, not a deployment diary. On 2026-09-22 we reviewed the public repository (pascalorg/editor), its README architecture section, package.json, docker-compose.yml, .env.example, mcp.json, server.json, the skills/ directory (pascal-3d 0.1.0, furniture-fit 0.1.4), the local-editor and MCP docs, and the live marketing site. We have not run Pascal Editor in production. Stars (24.2k) and forks (3.0k) are observed values on that date and will move. Editorial review: 2026-09-22.

Contrast with our deployment notes (self-hosted Postgres): those record lived ops. This page is what the repository and docs imply. Same posture as Open Design.

---

1. What It Replaces and Why It Matters

Residential 3D planning today sits between two poles. Desktop CAD and BIM suites carry per-seat licenses, heavy installs, and file formats that agents cannot touch. Browser room planners are easy to open and hard to extend: closed scene models, no local storage story, no programmatic handle for automation.

Pascal Editor attacks that gap from the local-first side. The scene lives in a versioned TypeScript monorepo with a real state store, the same store persists to IndexedDB in the browser and SQLite on disk through the CLI, and an MCP server exposes semantic scene operations (create_room, add_door, place_item, validate_scene) to any MCP-capable host. Four tools cover the practical alternatives for most home-scale work: SketchUp for quick massing, Blender for full-detail modeling, Sweet Home 3D for free floor plans, and Planner 5D for hosted room design. Pascal Editor does not match their depth. It trades depth for editability: every wall and zone is addressable state that a human or an agent can query and change.

Who should consider switching: teams that want floor plans as data, solo builders who prefer local files over accounts, and agent-workflow builders who need spatial tools instead of screenshots. Who should stay: licensed architects who need certified BIM output, and anyone who wants multi-user realtime collaboration, which this release does not offer.

---

2. Architecture and Container Topology

Pascal Editor is a Turborepo monorepo. The split is strict: reusable scene and render packages, a standalone Next.js host, and a CLI that distributes versioned runtimes.

flowchart TD
    subgraph Client["Humans and Agents"]
        Browser["Browser Editor<br/>(apps/editor, Next.js 16)"]
        CLI["Local CLI<br/>(npx @pascal-app/cli editor)"]
        Agent["AI Agent<br/>(MCP host: Claude, Codex, Cursor)"]
    end

    subgraph Scene["Scene Authority"]
        Core["@pascal-app/core<br/>(Zustand scene store, Zod schemas)"]
        Viewer["@pascal-app/viewer<br/>(React Three Fiber, WebGPU)"]
        EditorPkg["@pascal-app/editor<br/>(tools, selection, panels)"]
        Nodes["@pascal-app/nodes<br/>(built-in registry plugin)"]
    end

    subgraph Bridge["Agent Bridge"]
        MCP["@pascal-app/mcp<br/>(tools, resources, prompts)"]
        Skills["skills/<br/>(pascal-3d, furniture-fit)"]
    end

    subgraph Store["Storage"]
        IDB["IndexedDB<br/>(browser persistence)"]
        SQLite["pascal.db<br/>(~/.pascal/data, SQLite)"]
        Volume["pascal-data<br/>(Docker volume at /data)"]
    end

    Browser --> Core
    CLI --> SQLite
    Agent --> MCP
    MCP --> Core
    Skills --> MCP
    Core --> Viewer
    EditorPkg --> Core
    Nodes --> Core
    Core --> IDB
    Core --> SQLite
    Core --> Volume

The data model is the part worth understanding. Nodes live in a flat dictionary (Record<id, Node>), never a nested tree. Each node extends BaseNode with an auto-generated type-prefixed id (for example wall_abc123), a type discriminator, parentId, visible, an optional saved camera, and freeform metadata. Hierarchy (Site to Building to Level to Wall, Slab, Ceiling, Roof, Zone, Scan, Guide) is expressed through parentId plus children arrays. Rendering follows a registry pattern: renderers register Three.js objects by id, and systems (WallSystem with mitering and CSG cutouts via three-bvh-csg, SlabSystem, CeilingSystem, RoofSystem, ItemSystem, plus viewer-side LevelSystem, ScanSystem, GuideSystem) recompute geometry only for dirty nodes each frame. Undo history holds 50 steps through Zundo. State subscriptions use per-package Zustand stores (useScene, useViewer, useEditor), with getState() access outside React and a mitt event bus for clicks and hover.

The agent path is a second client on the same store. The local CLI starts the editor and an authenticated MCP service on dynamic loopback ports; pascal mcp connect gives hosts a stable stdio connector that discovers the current port, so clients never copy tokens by hand. The hosted endpoint (https://editor.pascal.app/api/mcp, manifest io.github.pascalorg/editor 0.6.1 in the MCP Registry) serves account projects through OAuth or API key. Skills pin behavior: pascal-3d forces schema inspection before edits and evidence-backed handoffs (editorUrl, version, graph hash), while furniture-fit keeps verdicts narrower than the evidence (rotation-aware plan AABB overlap at the tested pose, 8 cm default spacing checks, rectangular door keep-outs). The sequence looks like this:

sequenceDiagram
    autonumber
    participant Dev as Developer
    participant Agent as AI Agent
    participant MCPServer as Pascal MCP Server
    participant CoreAPI as Scene Store

    Dev->>Agent: Model a 4x5 m bedroom with one door
    Agent->>MCPServer: get_project_status + list tool schemas
    MCPServer-->>Agent: Active scene, supported inputs
    Agent->>MCPServer: create_room + add_door (semantic tools)
    MCPServer->>CoreAPI: createNode / updateNode (marks dirty)
    CoreAPI-->>MCPServer: Changed node IDs
    Agent->>MCPServer: validate_scene + verify_scene
    MCPServer-->>Agent: Schema and spacing report
    Agent->>MCPServer: save_scene (draft or checkpoint)
    MCPServer-->>Agent: editorUrl, version, graph hash
    Agent-->>Dev: Compact handoff with evidence

Measured in meters on X/Z plan axes with Y vertical, the model accepts unit strings such as 6 ft in tool fields and reports back in meters.

---

3. Visual Tour and Interface Workflow

Interface proof comes from two authentic sources: a live capture of the marketing site taken 2026-09-22, and the official project key art that shows the editor surface.

The homepage positions the product plainly: a 3D architectural canvas with agent entry points (Build with AI), platform pages for furniture fit and video tutorials, and the repository star count beside the primary CTA. No account wall blocks the docs.

The key art shows the surface that matters: a left tool rail, a top bar with room context and Edit/Studio modes, and a cutaway living room with walls, openings, shelving, and furniture at residential scale. This matches the node model in the repository (rooms containing walls with item children, zones, levels).

The editing workflow in the repository follows one loop: pick a tool (Select, Wall, Zone, Item, Slab), act on the canvas, watch the store mark nodes dirty, and let systems regenerate geometry. Selection drills down the hierarchy from site to building to level to zone to items, with per-depth hover and click strategies. Capture sessions extend the same packages through @pascal-app/core/capture and @pascal-app/viewer/capture subpaths for scan and surface-mesh layers.

A note on honesty: the polished /next walkthrough (exploded views, cut views, X-ray, door interactions) is a hosted preview of the editor direction. The README states it is not part of the open-source release. Evaluate the OSS editor on the repository packages, and treat /next footage as roadmap evidence.

---

4. Total Cost of Ownership (TCO)

TCO is simple here because the license is MIT and the default install is local. The costs that remain are hardware you already own, an optional VPS, and model usage for agent flows.

Dimension	Commercial / Hosted Option	Self-Hosted / Local
License	N/A, no seat price published	$0 (MIT, Pascal Group Inc.)
Compute	Included in hosted plan, price undisclosed	$0 local; $6-12/mo VPS estimate for the single Docker container
Storage	Included, limits undisclosed	SQLite file plus Docker volume; negligible at home scale
API / Model Usage	AI credits on hosted plans per site copy	Billed by your model provider; local MCP needs no key
Maintenance	Vendor-managed	Your responsibility: runtime updates, Bun and Turbo toolchain
Data Ownership	Pascal account workspace	Your disk (~/.pascal/data/pascal.db)
Annual Cost	Cannot be calculated from public sources	Rough operating estimate: $0 local, $72-144/yr VPS plus model spend
Operational Burden	Low	Low for one user, Medium when serving a team over Docker

Annual math is monthly cost times 12. The VPS band is a rough operating estimate for a small single-container host, not a vendor quote. Engineering labor is separate and varies: expect occasional half-days around major version bumps (React, Next.js, Three.js move fast in this stack) rather than steady toil. Never read self-hosting as free of cost: disk, backups, and your update time are real even when the license is $0.

The Docker shape keeps ops light. One service builds from the repo root, serves port 3000, and mounts a named volume at /data. There is no separate database container, queue, or search index to feed. The CLI shape is lighter still: versioned runtimes under ~/.pascal/runtime/, one SQLite file, rotating logs, and JSON process state. Rollback keeps old runtimes installed until you prune them by hand.

---

5. The Bad: What to Know Before Adopting

Every limitation below comes from the repository or docs. None is invented.

The demo is not the download. The /next reconstructed home (exploded, cut, X-ray, walkthrough) is explicitly excluded from the open-source release. If your decision rests on that footage, pause until the packages catch up.

One agent client per local service. The standalone runtime shares active scene state between clients. Two agents on one service corrupt each other’s context. Independent work needs separate PASCAL_HOME directories with separate processes. Plan your agent topology before you scale past one loop.

Desktop support is narrow at first. The initial CLI release targets macOS. Linux and Windows support is stated as unverified. There is no system startup service, so a reboot stops the editor until you run the command again. There is no prune command either; pascal doctor warns past three cached runtimes, and cleanup is manual deletion of version directories (never the data directory).

Docker has sharp edges. Keep the container port at 3000:3000: the compose comments warn that a remapped host port breaks /scenes with a 500 because the public app URL is inlined at build time. Binding is loopback only with no LAN option in this release, so team access needs a reverse proxy you operate yourself.

Installed releases lag the source. Skills warn that connected MCP schemas can differ from the repository snapshot. Concretely: export_glb answers not_implemented on the open-source headless server, capture tools exist only on hosted, and the read-only check_collisions.candidate input ships with @pascal-app/cli 1.0.0. Agents must inspect tool schemas per connection instead of assuming source-only inputs exist.

Connection hygiene is manual. Claude Code 2.1.258 loads both a user-scoped pascal server and the plugin-provided one; the docs prescribe removing the manual entry and keeping a single owner for the connection lifecycle. Cursor needs a marketplace refresh for the corrected bundle, and ClawHub publication waits on publisher terms. These are paper cuts, and they bite during onboarding.

3D needs a capable browser. The viewer targets WebGPU through React Three Fiber. Thin clients, old GPUs, and headless CI runners will not render scenes, which also means screenshot tests need real browser infrastructure.

Security notes for the MCP service

The .env.example exposes only a dev port comment and MINT_PASCAL_HOST_ORIGIN for OAuth and same-origin checks. No permissive auth bypass flag was found in the reviewed scope, which is good. The remaining threat model is operational: the local connector holds a private bearer token at ~/.pascal/run/mcp-token and must stay out of transcripts, screenshots, and pasted configs; hosted keys belong in the OS keychain or secret store, never in source; scene names and catalog labels are data and never authorize publishing, spending, or account changes; and any scene-editing MCP endpoint that an agent can reach deserves the same network posture as a code-execution service (loopback by default, explicit allowlist before exposure).

---

6. Quickstart and Deployment

Shortest verified paths, taken from the docs and compose file. All commands below are quoted from current project sources.

Local CLI (persistent install, no clone):

npx @pascal-app/cli editor

Install the short command first when you prefer it:

npm install --global @pascal-app/cli
pascal editor

Useful lifecycle commands from the verified reference:

pascal status
pascal projects
pascal doctor
pascal stop

Requirements: Node.js 22.13 or newer with npm available (the update flow resolves releases through npm). First run copies the bundled runtime to ~/.pascal/runtime/<version>, picks collision-free loopback ports, starts editor plus MCP, and opens the browser. Headless machines add --no-open; debugging adds --foreground.

Docker (single container):

docker compose up --build

The editor serves on port 3000 with projects in the pascal-data volume. Set MINT_PASCAL_HOST_ORIGIN when hosting outside editor.pascal.app.

Source development (contributors):

bun install
bun dev

Always run from the repository root so package watchers start; the editor dev server listens on port 3002 per .env.defaults. Production builds run through turbo build, releases through the GitHub release workflow with per-package tags.

Connect an agent (local, after the CLI runs):

{
  "mcpServers": {
    "pascal": {
      "command": "pascal",
      "args": ["mcp", "connect"]
    }
  }

Codex and Claude Code can use the packaged plugin marketplace (pascal-agent-skills@pascal) instead of hand-written JSON. One active client per service still applies.

---

7. Recommendation: Who Should Use This

Good fit: home-scale designers who want versioned local files, developers building floor-plan features without a CAD vendor, and agent teams that need semantic spatial tools with validation and evidence-backed handoffs. The furniture-fit workflow is genuinely careful about claim boundaries, which is rare in agent tooling.

Bad fit: practices that require certified BIM deliverables, teams that need concurrent multi-user editing with permissions, and shops that cannot operate a small amount of self-hosted infrastructure. If your project depends on the /next visual quality today, stay with your current tool and revisit when those packages land in the release.

Direct advice: adopt Pascal Editor as your editable draft layer and keep your certified toolchain for submissions. Do not adopt it as a certified BIM replacement. The repository earns the first role and does not claim the second.

---

8. ReframeHub Insight

The deeper lesson is treating the scene as the authority instead of the picture of the scene. Most agent-plus-3D demos pass screenshots around and hope coordinates line up. Pascal Editor inverts that: semantic tools mutate addressed nodes, dirty flags scope recomputation, validators check schema and spacing, and the handoff carries version plus graph hash. Screenshots become evidence of state rather than the interface to state. That pattern (addressable model, narrow tools, verify before persist, cite the revision) ports to any domain where agents touch structured artifacts.

---

9. What I Would Change

Opinion, stated as opinion. I would split the /next preview into per-feature packages with explicit release gates so evaluators can tell roadmap from runtime without reading footnotes. I would add a managed multi-client story (namespaced sessions or locking) because the single-client rule caps team agent use. I would publish hosted pricing and storage limits early, since cost uncertainty blocks the exact buyers this tool serves. None of these questions the core design, which reads as sound.