What happens when you save a card

A card has a Markdown description, comments, and eventually a pull request link and a preview URL. When you save one, kardboard waits a minute (so a quick second edit doesn't kick off a second session), then spins up a throwaway container. The container clones the repo onto a branch named after the card, then starts Claude Code or Codex with a workflow prompt and an MCP server. That MCP server lets the agent read every card, comment, and attachment on the board, and comment on, move, or create cards of its own.

The agent reads the request, does the work, runs the repo's acceptance command, pushes, and opens a pull request. Then it leaves one comment on the card and moves it to Review. If the request wasn't clear, it moves the card to Blocked and asks a question instead. That part turned out to be the most useful thing about it. A bad card gets a question back within a minute, before anyone spends twenty minutes on the wrong pull request.

When I hit Approve, kardboard squash-merges the PR, deletes the branch, and moves the card to Done. The agent also has a name and an avatar (Milo, by default). I thought that was a gimmick until I had more than one person on a board and needed to see at a glance who did what.

Guardrails

Agents can push branches, but they can never merge. Merging goes through a second GitHub app that only kardboard has, so even if a session goes completely off the rails, the worst it can do to the repo is open a pull request that a person still has to approve.

Approvals are tied to the exact commit on the pull request when you hit Approve. If anything gets pushed to the branch after you approve, the approval is thrown out and the card waits for you again.

The agent container never gets my provider credentials. An egress proxy adds my subscription token to requests on the way out. That gave me a bonus I didn't plan for: when my Claude subscription hits its usage limit, the proxy sees the rejection and the card gets picked back up on Codex. So the board keeps moving while I'm asleep.

Every session also has a CPU and memory limit, a time limit, and a repo token that expires after an hour. Each one gets its own network, too, and can't reach anything else on my LAN.

Previews and bigger requests

With preview mode on, kardboard builds the branch's Dockerfile and hosts it at the card's own hostname. So if a card is about a form in the footer, it comes back with a link where you can actually go click on that form. Only board members can open it, and it gets torn down once the card hits Done.

If a request is too big for one pull request, it gets split into child cards. Each child starts its own session without anyone touching it, and the parent waits in Blocked. Once the children are done, the parent wakes back up and gets told which ones were merged and which were closed without changes.

What's different now

I still describe work in plain English, same as I used to write prompts. The difference shows up months later. If I want to know why a feature was built a certain way, I just open the card. The description, the questions, and the pull request are all still there. With a chat thread, that would all be gone.

It's live at kardboard.cc, invite-only. kardboard itself is managed on a kardboard board, and most of its pull requests come from Milo.

It's still just pi

Pier doesn't reimplement any part of pi. Every open session is a real pi process running in RPC mode, and Pier just displays what it sends back. Your models, settings, extensions, and slash commands all work, because it's literally the same program. You can quit Pier, run pi -c in the terminal, and pick up right where you left off.

The only things Pier stores are its own preferences, in ~/.pi/gui/settings.json, and an error log next to it. Everything else stays in pi's config.

What you see

The transcript streams in as pi writes it: markdown, thinking (collapsed by default), tool calls with their output showing up live, and edit diffs inline. The input box supports pi's slash commands, @ file mentions, pasted images, and up-arrow history.

You can keep typing while a turn is running. Follow-up prompts go into a queue, and you can promote any of them to a steering message that interrupts the current turn. The header shows the git branch, and the model, thinking level, and a context meter sit under the input box.

Next to the transcript there's a read-only diff of the working tree against HEAD that updates as files change, plus a login shell in the project directory. Extension dialogs show up as sheets, and notifications show up as toasts.

Installing it

Download the DMG from the latest release and drag Pier to Applications. It's signed and notarized, so it opens like any other app, and it checks for updates on its own and installs them when you say so. You'll need a Mac with Apple silicon on macOS 13 or newer, and pi 0.85 or newer on your PATH.

What's running

• Model: Qwen3.8-27B, quantized to 4-bit (GPTQ INT4). The weights take about 18 GB, which leaves the rest of the card for context.
• Context: 131,072 tokens. The KV cache, which is the model's working memory for the conversation, is stored in FP8.
• Speculative decoding: the model's own draft head, also shrunk to INT4, guesses four tokens ahead, and the full model checks them.
• Engine: vLLM on Intel's XPU stack, one user at a time.

decode, thinking off

87tok/s

decode, thinking on

69tok/s

uncached 126K-token prompt

146s

the same prompt, cached

5.7s

With thinking on, which is how my agents actually use it, decode runs at about 69 tokens per second. The bigger number to watch is how long before the first token. A 126,000-token prompt the server hasn't seen before takes 146 seconds. That almost never happens in practice, because an agent resends the same growing conversation every turn and nearly all of it comes from the prefix cache. The same prompt a second time starts in under 6 seconds.

Why the obvious choice was wrong

The B70's matrix engines handle FP16, BF16, INT8, and INT4, but not FP8. On most cards, Qwen's official FP8 release would be the safe, low-loss pick. On this one, FP8 goes through a slower conversion path, and Intel's math library has an open bug about FP8 matrix math occasionally giving wrong results on these cards. So the weights are INT4.

Quality first, then context, then speed

That order decided most of the config. For coding, I'd rather have a 27B model at INT4 than a smaller model at higher precision. Agents fill the context with the repo, so 128K was a must. Speed came last.

Context was the hard part. With a 16-bit KV cache, the card tops out around 110,000 tokens, because the speculative decoding buffers and the model's recurrent state come out of the same memory. An FP8 cache holds almost twice as many tokens. The cost is prompt processing time: about 15 percent slower at 31K tokens and 20 percent slower at 90K. Cached requests lose a bit too, since the FP8 cache works in bigger blocks and more of each prompt gets reprocessed. I took the trade.

What helped, and what didn't

Two changes made a real difference. Shrinking the draft head to INT4 sped up decode by 26 to 31 percent, with no quality loss on my test tasks. Guessing four tokens ahead instead of three added another 6.6 percent on identical code requests.

The rest didn't:

• Doubling the prefill chunk size didn't speed anything up and cost 17,000 tokens of cache. Prefill on this card is limited by the work per token, not by how tokens are grouped.
• Pinning the process to one CPU core complex made no measurable difference.
• vLLM 0.29.0 passed every check but wasn't faster, needed four patches, and held 1,400 fewer tokens of cache. I stayed on the pinned image.
• llama.cpp's SYCL backend with a Q6_K build worked at 128K, but decoded at 34 tok/s with thinking on, about half of vLLM.

Why not just run it on the Mac

I ran the same base model on my M5 Pro MacBook with Inco's Splash and sent both machines identical requests. The B70 decoded at 91 tok/s to the Mac's 63. The bigger gap is prompt processing: an uncached 32K prompt took 21 seconds on the B70 and 102 on the Mac. The Mac was faster on cached prompts, 0.27 seconds vs 2.4, but under sustained load it got hot enough to slow down.

What broke

• The engine crashed at startup with opendir failed: could not open device directory until I bind-mounted /dev/dri into the container. Mapping it as a device isn't enough, even with one GPU.
• Level Zero rejects any single allocation over 4 GiB by default, and the KV cache is bigger than that. Setting UR_L0_ENABLE_RELAXED_ALLOCATION_LIMITS=1 fixes it.
• The usual GPU monitors don't work. intel_gpu_top and btop's Intel collector are both hard-coded to the old i915 driver. sudo gputop works with xe.
• Thinking comes back in message.reasoning, not message.reasoning_content. A client that only reads the older field shows no thinking at all.
• The GPU faults every so often, so a watchdog catches it, saves diagnostics, and restarts the engine. My first version had a regex bug that matched any log line, so it kept restarting a healthy server over unrelated network messages. The fixed version only reacts to real GPU faults. It passes its tests but hasn't caught a real one yet.

The client side

The repo also has the MacBook side: tested configs for Claude Code, Codex, OpenCode, and Hermes. Claude Code doesn't need a proxy, because vLLM serves Anthropic's Messages API directly. It needs three settings: the key sent as a bearer token, an effort of low, medium, or xhigh (plain "high" gets a 500), and the context limit set explicitly, or it assumes 200K. My pi config lives in its own repo.

Same core, new interface

Kino runs on the actual Stremio Core, the same library the official apps use. So add-ons, catalogs, your library, and watch progress all work the same as they do everywhere else. Everything you see on screen is new, though.

On macOS it's a native Qt app. The screens are built with web tech, but playback is handled by libmpv with VideoToolbox hardware decoding. Media keys and Now Playing work, and the screen only stays awake while a video is playing. Subtitles, whether they're embedded or come from an add-on, have controls for delay, size, and position.

On the TV it's a native Kotlin and Compose app running on an NVIDIA Shield, so moving around with the remote works the way it should. Near the end of an episode it shows Up Next, and it waits until your progress is saved before it loads sources for the next episode.

Keeping Core updates from breaking things

On the Mac, everything that comes out of the Core goes through a validating adapter before any screen sees it, so the screens only get navigation requests and playback fields. Those adapters are tested against a pinned version of the Core using committed fixtures, on every pull request. If a Core update changes the shape of the data, a test fails instead of a screen breaking.

Skip intro

This is the feature that started the whole thing. Kino finds intro markers, either embedded in the file or from the community, shows them on the timeline, and skips them when you press a button or automatically, with an undo. I'd wanted this in a Stremio client for years, and I couldn't add it to one that wasn't mine.

Development started on macOS, and the Android TV app came next. Windows and Linux are after that. For now, the macOS build is ad-hoc signed and only runs on Apple silicon with macOS 26.

Keeping my bank details out of git

The stuff that identifies me on an invoice, my ACH payment details, and the footer text are all set on a Settings page and stored in the database. None of it is in the repo. That way I can share the code and anyone can run it, and nobody's bank details end up in git history.

Running it

CI builds a new image on every green push to main, tagged with latest and the commit hash. All the data is in one SQLite database, so backing up means copying the data folder, and rolling back means pinning an older tag. For something that deals with money, I wanted both of those to be as boring as possible.

Boot config

The fork adds a boot.json file next to the WADs:

{ "iwad": "doom2.wad", "file": "brutal22test6.pk3", "warp": 1, "skill": 4 }

With that in place, going to the address loads Doom 2 with Brutal Doom and drops you right into MAP01 on Ultra-Violence, no menu. The first visit downloads the WADs and shows the progress. After that they're stored in the browser's IndexedDB, so the game starts right away. If you drop another file in the mounted folder, you can load it by name without registering it anywhere.

A URL that names an IWAD skips the file entirely, so a shared link like ?iwad=doom2.wad&file=brutal22test6.pk3&warp=7 still works on a kiosk setup. Every parameter gets checked against a strict pattern before it gets anywhere near the engine, and anything that doesn't match gets thrown out.

The bug I fixed

Upstream ships with Brutal Doom's damage overlays turned off, because they were covering the whole screen in almost solid red. The cause turned out to be a HUD message limit that was applied per font. Brutal Doom draws damage using about twenty different graphics over the same pixels, so even with a limit of four per font, you could still end up with around eighty translucent layers stacked on top of each other. Applying one limit across all of them fixed it, and the overlays are back on.

Two settings that will break it

WebAssembly threads need SharedArrayBuffer, and browsers only allow that on pages that are cross-origin isolated and served from a secure context. If either one is missing, the engine's threads never start.

• The bundled Caddy sets Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. If you put your own reverse proxy in front of it, make sure both headers reach the browser unchanged.
• It has to be served over HTTPS. A plain HTTP address on your LAN doesn't count as a secure context, so the engine won't start. Plain HTTP only works on localhost.

The fork also builds on Linux and macOS, while upstream's helper tools only came as Windows binaries. Other than Freedoom, WADs aren't included, so you'll need to bring your own.

WebRTC, with a fallback

The video comes in over WebRTC, which is the fastest option a browser has. If WebRTC can't connect, the player falls back to Media Source Extensions over the same port. That's fine for keeping an eye on a hallway, but you'll notice the delay on anything that moves.

Inside the container, go2rtc pulls the RTSP stream and can serve it either way. nginx sits in front so the page and the signaling socket can share one port:

Works with any camera

A lot of cameras send H.265 or some other format browsers won't play. camview transcodes those to H.264 on the fly with ffmpeg, so any camera works in any browser. If you set HWACCEL to vaapi or cuda and pass your GPU through, the transcoding runs on the GPU instead of the CPU. And if your camera already has an H.264 sub-stream, you can set TRANSCODE=off and just use that.

The setting that's easy to miss

When the container is on a bridge network, it can't figure out an address the browser can actually reach, so you have to tell it. Set WEBRTC_CANDIDATE to the server's LAN address and port. If you leave it blank, everything still works, but it quietly drops to the slower fallback. So if the feed seems about a second behind, check this first.

services:
  camview:
    image: ghcr.io/chriscorbell/camview:latest
    ports:
      - "3147:8080"
      - "8555:8555/tcp"
      - "8555:8555/udp"
    environment:
      CAMERA_RTSP_URL: ${CAMERA_RTSP_URL}
      WEBRTC_CANDIDATE: ${WEBRTC_CANDIDATE:-}
      TRANSCODE: ${TRANSCODE:-h264}
      HWACCEL: ${HWACCEL:-}

All I really wanted was a live view of my own cameras on my phone or laptop, without going through some vendor's app.

Everything runs in one process

The whole app is one Node process on one origin:

/               the page
/api/chat/*     chat, with a server-sent-events stream for live messages
/api/schedule   the schedule, normalized
/iptv/*         a reverse proxy to ErsatzTV

Honestly, that layout is most of why I built this. The player, schedule, chat, and stream proxy all fit in one container, so deploying it is a single compose service, and if you want to know how requests get routed, you can just read one file.

The schedule comes from ErsatzTV's guide, and the server cleans it up before sending it to the browser. If you give it a Jellyfin key, it adds release years and air dates too. The IPTV proxy rewrites the playlist as it passes through, so the stream still works behind any public hostname, as long as PUBLIC_APP_ORIGIN is set.

The chat doesn't stick around

Accounts are just a nickname and a password. Messages max out at 500 characters, and the server only keeps the last 100. That's intentional. TV doesn't have scrollback, so I didn't think the chat next to it should either. There's also a small admin side for warning people, deleting messages, and banning.

The frontend is React, TypeScript, Vite, and Tailwind. The backend is a small Express app with SQLite and its own tests. I use Bun for development and Node 24 in production. It's been running for months now, and people I know drop in when something good is on the schedule.

Day to day

Each service gets an icon, a name, a short description, and a category. You can upload a PNG or SVG for the icon, or paste a URL and Orbitdash will grab it. You can drag categories to reorder them in settings and click to collapse them, and your browser remembers which ones are collapsed. There's a search box for when the list gets long, and you can switch between a 3, 4, or 5 column grid depending on your screen.

The metrics panel shows the last 30 seconds as a chart, with tabs for CPU, RAM, and disk.

Running it

It's one container with one volume:

services:
  orbitdash:
    image: ghcr.io/chriscorbell/orbitdash:latest
    restart: unless-stopped
    ports:
      - "7770:3000"
    volumes:
      - ./orbitdash-data:/data

It runs as uid 1000, so if Docker creates the folder as root, run chown -R 1000:1000 ./orbitdash-data once.

The database and uploaded icons are all stored in that volume, so backing up is just stopping it and copying one folder. Images are built for x86_64 and aarch64. Every push to main gets its own tag alongside latest, and releases get version tags like v0.2.0, if you want to pin one.

It's built with TypeScript, React, Tailwind, shadcn/ui, Hono, Bun, and SQLite. My favorite part is that I haven't had to open a config file since.