pclshm/playground
↖ pclshm.dev
Menu

pclshm / playground · 0.1.0 · Windows · macOS · Linux · MIT

The daily AI workspace. Everything it does is a run you can read.

Local models, hosted APIs and the coding agents you already have, on one permanent base — with projects, tools, retrieval and generated assets beside them. Every unit of work, from a chat turn to a spoken sentence, keeps its typed input, a config snapshot, an event stream, outputs and metrics. Inspectable, replayable, forkable, comparable.

Every feature, described Availability

One person's tool, at 0.1.0. It is not released and no release is planned: there is nothing to download, and the source repository is private. It runs entirely on your machine and reaches a network only for a provider you configure, never at start.

Playground's front door: a wheel of every artifact in the centre, micro-apps, the calendar and connectors on the left, and the brain's questions and notes on the right
The front door — what can I run, what runs without me, what do I know, what did they make. screenshot · 0.1.0 · Windows
The Agent chat panel: a conversation composer with Agent or Just-the-model, a framework picker, Auto / Plan first / Ask, the loaded models and runtimes above, and the Runtimes panel beside it
Agent chat — one agent, on one framework, on the model you chose; the Runtimes panel says which answer and why not. screenshot · 0.1.0 · Windows
The Second Brain drawing this repository's 2,029 files as rings around its router file, with the folders — crates, apps, packages, docs, tools, sidecars, schemas — labelled, and the layout menu open
The Second Brain — this repository's 2,029 files, whole, on one canvas. screenshot · 0.1.0 · Linux · served to a browser
The front door served by a locked node to a browser: the calendar with the next three routines, the deck with one skill card, the routines board, and the wheel of the open project's files
A locked node's front door — the deck, the routines board and what's next, from pg brain serve --locked. screenshot · 0.1.0 · Linux · served to a browser

01 The idea

Three rules hold the whole thing together.

They are the same rules the repository is measured against, and the machine enforces two of them. The third is a habit the app refuses to break.

Everything is a run.

Any unit of work produces a run with typed input, a config snapshot, an event stream, outputs and metrics. Replay it from the same snapshot. Fork it with one parameter changed and the lineage kept. Compare runtimes, models or configurations on one task, side by side.

“A sentence heard wrong is a fork away from being said again.”

Fail visibly.

No silent fallback between providers, no swallowed error, no default that hides a missing choice. A fallback happens only when a configured rule matches, and it says what it fell back from, to, and why.

“An unavailable model is listed with the reason, never hidden. A model that vanishes from a picker is a bug report.”

Local-first, in the open.

A project is a folder you already have; the app's index is a cache and the folder is the truth. Keys live in the OS keychain, referenced by name. Nothing leaves the machine unless you point it at a provider, and every token that does lands in a ledger.

“Copy a project folder anywhere, attach it, and the library is back.”

02 What's inside

One base. A new capability is an extension, not a rewrite.

Nineteen areas, each a slice over the same headless core. Every panel here has a pg command that does the same thing from a terminal, because the window is a second, thin consumer of the same services — never the other way around. The long version, with every panel and command named →

Models and agents
  1. 01

    Local modelsModels · Library / Instances / Profiles / Chat · pg models, pg bench

    Point it at your GGUF folders. It scans, estimates whether a model fits in VRAM before you launch it, runs llama-server, shows live telemetry, benchmarks a profile matrix and lets you chat — reasoning streamed on its own channel.

    Read →
  2. 02

    The gatewayModels · Providers · pg gateway, pg providers, pg creds

    An alias goes in; a routed, budgeted, accounted, recorded turn comes out. Hosted providers are manifests, not code. An OpenAI-compatible endpoint anything can point at, with every request in the same spend ledger.

    Read →
  3. 03

    Coding agents as runtimesAgent chat · Agent grid · Runtimes · Sessions · pg agents, pg modes

    Claude Code, Codex, Gemini, Grok, opencode and Pi, plus LangGraph, CrewAI and Pydantic AI in containers — interchangeable runtimes on the models this app routes. A question an agent asks waits on a card until you answer it.

    Read →
  4. 04

    Plans, standing agents, the fleetthe plan card · Activity · Sessions · pg plan, pg sessions, pg fleet

    Scope a conversation into a plan, approve it once, and it runs itself out with nobody typing. Standing agents on heartbeats. Delegation authorized by the plan a person approved, checked in the tool.

    Read →
Tools and runs
  1. 05

    Tools, policy, approvals, auditMCP · Tools · Approvals · pg mcp, pg tools

    Any MCP server is configuration. One namespaced surface beside the app's own tools, a policy floor no user setting can lower, approvals that show the arguments, and an audit you can read afterwards.

    Read →
  2. 06

    Runs: inspect, replay, fork, compareRuns · Activity · Trace · Statistics · Run a task · pg run, pg runs

    A virtualized trace that still scrolls at 100k events, the tool trio of arguments, decision and result, gaps marked where a run went quiet, Replay and Fork on the trace, and a copy that pastes as text.

    Read →
Your work
  1. 07

    Projects, assets, lineageProjects · Library · Inspector · Lineage · pg projects, pg assets

    A project is a folder you already have, filed by area with saved views. Everything produced is a content-addressed asset with the run that made it, on a lineage graph that offers “regenerate” and “fork config”.

    Read →
  2. 08

    The workspaceFiles · pg files, pg format

    Ordinary files at ordinary paths that you and the agents hold at once, with a change journal that says who wrote what — your editor's edits included. Commands and dev servers saved with the folder.

    Read →
  3. 09

    The workshopthe scope switcher · the work board · pg repos, pg work propose

    Repositories attached or cloned, typed git verbs that never force, a worktree per run on a branch named after it, and a pull request treated as publishing — floored at a prompt.

    Read →
  4. 10

    The tracker and the vaultWork board · Specs · pg work, pg notes, pg spec

    An epic, a feature, a ticket — each a markdown document in the project. A claim protocol so a standing session picks up the next ready ticket. Only a person accepts finished work.

    Read →
Knowing and making
  1. 11

    Retrieval you can take apartCollections · Pipeline · Inspector · Eval · pg rag

    Eight stages, each a registered plugin with its own form. An inspector for every chunk and score. An eval loop across pipeline versions. Swap the vector store at zero embedding calls.

    Read →
  2. 12

    Generation and the DCC bridgesGenerate · Lineage · MCP · pg gen, pg mcp enable godot|blender|aseprite

    Images, video and meshes from hosted or local generators, every result a tracked asset. Bridges into Godot, Blender and Aseprite that ship off, scoped to nothing, and stop at an approval showing the arguments.

    Read →
  3. 13

    The brainthe front door · Second Brain · pg brain, pg map, pg signposts

    One full-screen surface over all of it: the wheel of everything your agents finished, the deck, the routines board, micro-apps, a memory map, and a map of every project's files that asks when it is not sure.

    Read →
Around the workbench
  1. 14

    The companion, the voice, the padCompanion · pg control

    A small window you pin in a corner and talk to from inside any other application. A spoken turn is a run. A macropad on your desk shows the fleet in light.

    Read →
  2. 15

    The dashboardDashboard · the pop-out window · Playground --hud

    Working, waiting, approvals, stuck. A picture of the app's own graph where traffic lights the pipes and fades over six seconds, so a stall is visible from across the room.

    Read →
  3. 16

    Skills, memory, themes, terminal, settingsSkill Library · Memory · Theme editor · Terminal · Settings

    Procedures an agent looks up mid-job, edited as data. An agent's notebook you can read. Themes with contrast repair that says what moved. A real shell wearing the theme. Every settings form generated from a schema.

    Read →
Beyond the desk
  1. 17

    Nodes, the locked profile, a VPS on demand newpg brain serve --locked · pg nodes · just vps

    The same build with no window, on a machine that stays up. Locked for a node nobody watches. On Hetzner, one command brings a node up and one takes it down; your desk manages it through a tunnel.

    Read →
  2. 18

    The central record newProjects · pg sync

    Enrol one project at a time, from a preview that names what it records and what it leaves out. Its runs and file changes reach the central record once — nothing duplicated, nothing lost, no secret ever.

    Read →
  3. 19

    Kit and Interface newpg kit, pg interface

    The family's own tool servers, installed on demand: pclshm-kit scaffolds a project on a stack; pclshm-interface serves your own data to your agents and to the front door's search.

    Read →

03 The agents you already have

Three kinds of connection. Never one “provider”.

A conversation always says which of the three it is running on, because they are not interchangeable: a CLI subscription does not grant API access, a hosted key is metered per token, and a local model has a different capability envelope. The badge is mandatory. The app never guesses which one you meant.

Installed CLI

Your coding agents, as runtimes

The agent CLIs installed on this machine, driven in their own non-interactive mode against a run-scoped gateway grant — so they run on whatever the alias routes to, a local GGUF included, and every token lands in the run's ledger. Or, as a chat target under your own subscription, with the cost honestly unknown.

  • Claude Code · this machine or a container
  • Codex · Grok CLI · opencode · Pi · Gemini CLI
  • LangGraph · CrewAI · Pydantic AI (containers)
  • the reference runtime · the orchestrator
Hosted API

Your key, billed per token

A provider is a JSON manifest naming an adapter family. The key goes to the OS keychain and is referenced by name. Budgets are enforced before the call; spend is recorded after it; a fallback happens only when a rule says so, and says so.

  • OpenAI · Anthropic · DeepSeek · xAI
  • any OpenAI-compatible endpoint: LM Studio, Ollama, a llama-server, a box on the LAN
  • families: openai-compat · anthropic-messages
Local model

On this machine, no key, no network

GGUF files in folders you name, served by llama.cpp in Docker or by the native llama-server you already have. A feasibility check before the launch, because an over-budget load on a consumer driver does not fail — it spills to system RAM and decode collapses.

  • scan · feasibility · launch · telemetry · bench
  • inference profiles from the generated schema
  • reasoning streamed on its own channel

04 From your desk to a VPS

The same app, with a window or without one.

It starts on your machine, and that is where the window, the approvals and your local models stay. When work should go on with the laptop shut, the same build runs as a node — no window, the scheduler's clock, the front door on loopback behind a token — and on a Hetzner VPS one command brings a locked node up. The whole path, step by step →

First, what is true today

  • The one-command VPS path runs from the source repository, which is private for now, and its first run against a live Hetzner project is still to come. Without it, a node is the same steps by hand on any Linux box with pg on it. What it does, and the path by hand →

Your desk

the window · pg

The app as you installed it. Everything a run does lands under the home you chose.

  • ModelsGGUF instances on your GPU; hosted keys in the OS keychain
  • Approvalsyou, at the window or at the terminal
  • Reaches outpg nodes, pg sync, a browser tab
SSH tunnel
127.0.0.1:7318 → node:7317
pg nodes · pg sync
token on every request
the front door
in your browser

A node on a VPS

locked

pg brain serve --locked as a service: the same build, on a machine that stays up.

  • Servesthe front door on 127.0.0.1:7317, never wider
  • AgentClaude Code, restricted, through the gateway
  • FirewallSSH in, nothing else
Provision
  1. just vps deploy · or Actions → VPS
  2. Terraform → Hetzner Cloud
  3. cloud-init
  4. install over SSH
  5. health check
  1. 01 · Your desk

    Install, choose a home, work

    Local models, hosted keys and the agent CLIs you have, every unit of work a run under one folder.

    $ pg setup --home D:\Playground
$ pg models up <model>
  2. 02 · A node

    The app without a window

    On a mini PC, a VM or a VPS. Locked when nobody watches: reads, workspace edits, its own coordination — everything else refused at once.

    $ pg brain serve --locked \
    --token-file <file>
  3. 03 · On demand

    A VPS in one command

    Terraform makes the server and an SSH-only firewall, installs the locked node and checks it answers. About €6 a month, billed by the hour.

    $ just vps deploy
$ just vps destroy --yes
  4. 04 · From your desk

    Reach it, manage it

    A tunnel to its loopback; the node in your list; a routine bound to it; your runs sent to its record.

    $ just vps tunnel
$ pg nodes fleet

05 From a terminal

Everything the app can do, from pg.

Every installer puts the pg command beside the app. It drives the same services the window drives, it is the surface the integration tests run against, and if something only works in the window, that is a bug. Serve the front door to a browser on loopback with pg brain serve, behind a token minted on demand and revocable while the server runs — the same command that runs the app as a node on a machine that stays up.

pg — the same app, from a terminalsh
$ pg setup --home D:\Playground
home pinned — every run lands under it
$ pg models scan
3 GGUF models · VRAM estimated · profiles ready
$ pg run chat:local --set seed=1
run 01J9…K4 · 41 tok/s · TTFT 180 ms
$ pg agents compare --message "What is a config snapshot for?"
4 runtimes · one task · diffed side by side
$ pg runs fork 01J9…K4 --set temperature=0.2
$ pg sessions do research "summarise what changed this week"
$ pg brain serve --locked --token-file <file>
serving the front door on http://127.0.0.1:7317 (loopback only, token on every call)
$ pg nodes probe          # from your desk, through the tunnel
playground-node  up  21 ms  project: playground

06 Availability

Not released, and no release is planned.

Playground is one person's tool. There is no installer to download, signed or unsigned, and the source repository is private. The packaging is set up — a Windows wizard, a macOS disk image, Linux packages, each with pg beside the app — but it builds only from a checkout of the source. The setup below is what that build installs.

07 The setup

It asks what matters, and nothing else.

The Windows wizard is drawn with the app's own palette and set in the system font. Beyond the usual — where the program goes, this user or every user — it has two pages of its own, and the uninstaller undoes exactly what they did.

  1. 01
    What the setup doesDesktop and Start Menu shortcuts, a second shortcut that opens straight onto the always-on-top dashboard, pg on PATH, start at sign-in. Nothing is created that is not ticked. A second run reads the machine and shows what is installed now.
  2. 02
    Where your data goesThe home: every run, project, setting and recorded request lands under it. Keep the default or point it at a data drive — never inside the install folder, which an update replaces. It writes the same pointer pg setup --home writes.
  3. 03
    Undo is symmetricalThe uninstaller removes what the setup added — the PATH entry, the sign-in entry, the shortcuts — and offers to delete the home, naming the folder it means.
  4. 04
    macOS and Linux, in kindA branded disk image with the drag-to-Applications layout; a full launcher entry, a Dashboard action and AppStream metadata for GNOME Software and Discover. And for a machine that is not a desktop: systemd, launchd and Task Scheduler templates for running pg brain serve as a node — from your desk to a VPS.