The entire “server” is about 80 lines of Rust, compiled to wasm. Gzipped, the binary is 145 KB. It handles everything my Apache .htaccess used to do: the canonical-host 301 redirect, six security headers on every response, DirectoryIndex resolution, trailing-slash redirects, and the 404 page. The images and CSS never touch the wasm at all — Cloudflare’s static assets binding serves them straight from the CDN, free and unlimited.

I went in expecting a fun toy. I came out convinced this is how I want to deploy a whole class of services. Five reasons.

1. The artifact is absurdly small

The deployable unit is 145 KB gzipped — smaller than most header images on this blog. A Docker image shipping the same routing logic drags along a base image, a distro, and a web server: tens to hundreds of megabytes that aren’t your code. A wasm module is just compiled logic against a standard runtime interface; the runtime is the platform’s problem.

2. You test the exact artifact you ship

wrangler dev runs the same workerd runtime locally that Cloudflare runs at the edge — same wasm binary, same bindings, up in milliseconds. My acceptance script (twelve curl checks: header parity, byte-identical HTML, redirect status codes) runs unchanged against localhost and the deployed URL. No image build, no registry round-trip, no environment drift.

3. The CDN does the heavy lifting — for free

The 10 MB worker limit forces the right architecture anyway: logic in the binary, bytes on the CDN. This blog’s ~74 MB of images, CSS, and fonts are served by Cloudflare’s static assets binding — edge-cached, zero egress fees, not counted against the worker’s request quota. The wasm only wakes up for redirects, headers, and 404s.

4. The economics are embarrassing

$0 per month: 100,000 worker requests/day free, static assets unlimited, no bandwidth charges; $5/month past that. And because wasm instantiates in milliseconds, scale-to-zero has no cold-start penalty — the problem you engineer around with containers doesn’t exist here.

5. It’s real server logic, not a static-hosting hack

The worker does what Apache did via mod_rewrite and mod_headers — canonical 301s, security headers, 404s — in 80 lines of typed, testable Rust instead of .htaccess regex. The same shape carries a real backend: routing, auth, database and upstream calls in one small binary. And with WASI it isn’t vendor-locked — the same module runs on wasmtime, Fastly, or Spin.

The honest caveats

It wasn’t friction-free, and I’d rather you hit these in this paragraph than at midnight:

• Toolchain sharp edges. worker-build silently requires a recent worker crate version; enabling LTO in the release profile broke wasm-bindgen with a cryptic “externref table” error. Both fixable in minutes once diagnosed, both annoying to diagnose.
• Platform defaults fight parity. Cloudflare’s default URL handling 307-redirects .html URLs to extensionless ones — nice for a new site, wrong when you need byte-parity with an existing Apache setup. One config line (html_handling = "none") and a few lines of Rust fixed it.
• The 10 MB limit is real. Wasm-on-Workers is for logic, not payloads. If your service is mostly moving large files, this isn’t your architecture.

Takeaway

A container ships a machine; a wasm module ships a function. For services whose job is logic rather than bulk data — redirects today, APIs tomorrow — the wasm version is orders of magnitude smaller, tests as the identical artifact you deploy, starts in milliseconds, and rides a free CDN for everything heavy.

The blog was the toy problem. Over the next weeks I want to push actual backend logic through this pipeline — a real service with state and upstream calls — and see where the model bends. If it holds, I struggle to justify a Dockerfile for small services again.

Then I installed Hallmark as a Claude Code skill and told it to redesign my blog and homepage. What came out was so much better it made the old version look embarrassing.

Here’s how it actually went.

It asked before it assumed

The first thing Hallmark did wasn’t generate anything. It asked about scope: just the blog, or everything? That one question already put it ahead of the usual “here’s 12 layouts, pick one” slot-machine approach. It wanted to know what it was working on before it started working.

Then it went quiet and analyzed. Not for show—when it came back, it came back with four distinct design directions. Not four variations of the same idea. Four genuinely different takes, each with a rationale.

I picked a direction, then it offered variations

Once I chose a direction, it didn’t just run. It surfaced a second round of decisions—variations within that direction, including whether I wanted dark mode. Small thing, but it’s the difference between a tool that designs for you and one that designs with you. I got to steer twice: once on the big direction, once on the details.

Then it worked. For 40+ minutes.

This is the part that sold me.

Hallmark didn’t spit out HTML and call it done. It drove a headless browser, took screenshots, and checked its own work—desktop and mobile, because I’d asked for both. It iterated. Rendered, looked, adjusted, rendered again. For over forty minutes it did the loop that I always skip when I’m rushing: actually looking at the thing on a real screen at real breakpoints and fixing what’s off.

That’s not prompt-and-pray design generation. That’s the workflow a careful front-end engineer follows—verify against the running page, not the mental model of it.

The result

Here’s the honest comparison. First, the old design—hand-wired from Google Stitch and Claude Design:

And here’s what Hallmark produced:

Compare the two—there’s no contest. Hallmark’s version is tighter, more coherent, and it just feels considered in a way the old one never did.

Takeaway

If you’re building a web page or want a redesign, go look at the Hallmark skills. The magic isn’t that it generates designs—everything generates designs now. It’s that it interrogates scope first, gives you real choices instead of noise, and then verifies its own work in a real browser until it’s right.

For someone who isn’t a designer, that’s the whole game. It doesn’t just hand me pixels. It does the part I’d skip.

That sounded great. Pi isn’t a sealed product — if you need a command, a tool, a provider, a workflow, or a UI tweak, you just ask Pi to build it, and it customizes itself on the fly. It ships powerful defaults but deliberately skips things like sub-agents and plan mode, on the theory that you’ll add them if you actually want them. Customizations bundle as Pi packages and ship over npm or git.

The catch: I wasn’t sure I was ready to build up all that judgment myself, skill by skill. A blank harness is only as good as what you teach it. Then I remembered agent-skills — the 77k-star pack of engineering process from Addy Osmani, a senior engineering leader at Google — that I’d already been testing inside Claude Code. Someone had ported it to Pi. So the test wrote itself: take the bare harness, drop in those skills, point it at a model, and see how far it gets.

The setup

Three moving parts.

The harness: Pi, out of the box, minimal.

The brain: @chankov/agent-skills, a Pi port of Addy Osmani’s agent-skills. The original bills itself as “production-grade engineering skills for AI coding agents,” and it’s cleared 77k stars on GitHub — Osmani is a senior engineering leader on Google Chrome, so this isn’t hobby advice. The skills are organized by phase: idea → spec → plan → implement → test → review → ship. Each one encodes the process a good engineer actually follows instead of just “write the code.”

install pi.dev/packages/@chankov/agent-skills

The model: I connected Pi to my OpenCode Go subscription and ran everything on kimi-k2.7-code at medium effort.

The test: spec, then build

My prompt was specific: a playable snake game in the terminal, styled to look like The Matrix — green digital rain falling behind the board. Not “write snake” — I let the skills drive. It ran the spec skill first, asked me a few clarifying questions the way Claude Code does, and only then started writing code. That ordering matters. The spec-first workflow is exactly what stops a model from confidently building the wrong thing.

The output was clean Python: a pure game-logic core with no curses imports, a separate renderer for terminal I/O, an input handler, and the Matrix rain effect cascading behind the play area. The interesting part was what happened when I asked it to grade its own work.

Running /review

I ran the installed /review skill on the finished game. What came back wasn’t a rubber stamp — a genuine five-axis review (correctness, readability, architecture, security, performance) that caught the things a good reviewer would: a spot where the renderer was quietly mutating game state, a bloated main() worth splitting, an unhandled edge case nobody asked about, and a correct nothing critical on security instead of invented risk.

That’s the tell. A weak reviewer pads the list. This one separated what’s good from what to fix, ranked it, and knew when to stop. Reading it back, I couldn’t tell it apart from a review I’d get out of Claude Code or any of the other agent harnesses I run day to day.

One note: it just runs

The skills asked me clarifying questions like Claude Code — but they never stopped to ask permission before acting. Pi read files, wrote code, and ran the review on its own. Honestly, I liked it: no clicking “yes” on every step, it just moved.

The clean way to get that speed is to run Pi in a container. Sandbox the workspace, let it go, and autonomy stops being something to worry about — a mistake can’t reach anything outside the box.

Takeaway

A minimalist harness plus a best-practice skills package added up to something that specced deliberately, built cleanly, and produced code and reviews I couldn’t distinguish from what Claude Code or any other harness I already use hands me. The harness stayed out of the way; the skills supplied the judgment.

If you’ve been curious about Pi, this is the fast way in: install @chankov/agent-skills, point it at a model, and ask it to review something you wrote. Then decide who the senior engineer in the room actually is.

So I decided to fix it in one sitting—and I used Fable 5 running inside Claude Code to do the heavy lifting, pointed at the specification checklist over at https://specification.website. Here’s the exact workflow, and why I did it now instead of later.

The setup: point an agent at a spec

There’s a site at https://specification.website—”What a good website does.” It’s a checklist of what a well-built site should ship: Foundations, SEO, Accessibility, Security, Well-Known URIs, Agent Readiness, Performance, Privacy, Resilience, Internationalisation. Each topic is tagged Required or Recommended, from the boring-but-essential (<!doctype html>, <meta charset>, a real <title>) to the modern stuff (canonical URLs, theme-color, agent-readable metadata).

My instruction to the agent was deliberately simple:

Analyze my website against https://specification.website. Find everything I’m missing—required and recommended. Make a plan. Then fix it all.

That’s it. No hand-holding. I wanted to see how far an agent could get when the “spec” is an external source of truth instead of a vague “make my site better.”

It planned first, then let me decide

It didn’t just start editing files. It checked my pages against the spec and came back with a plan—a grouped list of what was missing across Foundations, SEO, Agent Readiness, Performance, and the rest. Standard agent behaviour; you’ve seen it.

The part that mattered was what came next.

I made a few decisions, then let it run

An agent shouldn’t get to decide everything. A handful of items needed a human call—things like which canonical form to standardize on, what to put in the metadata that’s genuinely mine, and how far to go on the recommended-but-optional items.

So I answered those few questions, and then it did the work: updated the files, wired in the missing pieces, and—this is the part people skip—tested it. It didn’t just claim the fixes were done. It verified the build and checked the changes held together before calling it finished.

Plan → decide → fix → verify. That loop is the whole game.

Why I did this now

Here’s the honest reason for the timing: this is a fantastic use of Fable 5 while it’s still cheap.

Right now, having an agent audit a whole site and ship the fixes fits inside a normal Claude subscription. That won’t last—these capabilities get more expensive as they get more valuable.

So do the one-off, high-leverage cleanup while it’s cheap. You only do it once per site, and the payoff lasts every time a crawler, search engine, or AI agent reads the site correctly from now on.

Takeaway

You don’t need to be an expert on any spec to hold your app or blog to one. Point a capable agent at a good external standard, make it plan before it edits, keep the few decisions that are actually yours, and demand it verify its own work. It applies to any codebase, not just an old one.

I did it in one sitting. And I did it now, on purpose—because getting an agent to bring something up to a standard is cheap today, and that’s exactly when you should spend it.

That split is the whole opportunity. The reasoning is where you want a strong model. The grunt work is where you want fast and cheap. There’s no rule that says both have to come from the same vendor — or from Anthropic at all.

So I put a LiteLLM proxy in the middle. The planning tier routes to a fast GLM 5.2 on Baseten. The coding, background, and subagent tiers route to cheap budget models on OpenCode Go. Claude Code stays completely stock — it thinks it’s talking to Anthropic, sends normal Anthropic requests, and LiteLLM translates each one to whatever backend I mapped that tier to.

This is a writeup of an actual setup — real config shape and ports, placeholder secrets. Substitute your own keys and model ids; provider catalogs change often, so don’t copy the model strings blind.

Why this shape

• One proxy, many backends. Claude Code only knows how to talk to a single Anthropic-shaped endpoint. LiteLLM fronts that endpoint and fans out per tier.
• Cheapest capable model per tier. Heavy turns go to GLM 5.2. Background and quick turns go to a cheap, fast model. You pay for thinking where you need it and almost nothing where you don’t.
• Claude Code stays stock. No patches, no forks, no flags. Point two env vars at the proxy and you’re done.

1. Install LiteLLM

Use a venv so the proxy is isolated. uv is fast; plain python -m venv works too.

uv venv .venv
uv pip install --python .venv 'litellm[proxy]'

The [proxy] extra pulls in the proxy server (the litellm --config … mode). Without it you only get the Python library.

Security — pin your version. LiteLLM’s PyPI releases 1.82.7 and 1.82.8 shipped credential-stealing malware. Pin away from those two. This setup uses 1.90.0. Do not downgrade into the bad pair.

2. Drop your keys in .env

The launcher sources .env, so provider keys live there:

BASETEN_API_KEY=baseten-XXXXXXXX
OPENCODE_API_KEY=opencode-XXXXXXXX      # works for both Zen and Go plans
LITELLM_MASTER_KEY=sk-litellm-local     # the proxy's OWN auth (not a provider key)

# Critical for OpenCode Go — see the gotchas section.
LITELLM_USE_CHAT_COMPLETIONS_URL_FOR_ANTHROPIC_MESSAGES=True

LITELLM_MASTER_KEY is how the proxy authenticates you. Claude Code sends it as ANTHROPIC_AUTH_TOKEN, and the two values have to match (default sk-litellm-local). That last env var isn’t optional if you use OpenCode Go — skip ahead to the gotchas if you want to know why before you trust it.

3. Write the routing config — this is the whole idea

litellm.config.yaml is a list of model_name → backend mappings. The model_name is the tier Claude Code asks for; litellm_params.model is the real backend, prefixed with the provider so LiteLLM knows how to talk to it (baseten/… for Baseten, openai/… for any OpenAI-compatible endpoint).

This is where the brain/hands split lives:

model_list:
  # THINKING TIER → fast GLM 5.2 on Baseten. This is the model that plans.
  - model_name: claude-opus-4-8
    litellm_params:
      model: baseten/zai-org/GLM-5.2
      api_key: os.environ/BASETEN_API_KEY

  # MID TIER → OpenCode Zen (OpenAI-compatible)
  - model_name: claude-sonnet-4-6
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://opencode.ai/zen/v1
      api_key: os.environ/OPENCODE_API_KEY

  # FAST / BACKGROUND TIER → OpenCode Go (OpenAI-compatible, cheap)
  - model_name: claude-haiku-4-5
    litellm_params:
      model: openai/kimi-k2.7-code
      api_base: https://opencode.ai/zen/go/v1
      api_key: os.environ/OPENCODE_API_KEY

  # SUBAGENTS (Claude Code's Task tool) → cheap model on Go.
  # Claude Code sends CLAUDE_CODE_SUBAGENT_MODEL's value as `model`; map it here.
  - model_name: subagent
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://opencode.ai/zen/go/v1
      api_key: os.environ/OPENCODE_API_KEY

litellm_settings:
  drop_params: true   # silently drop Anthropic params the OpenAI backends reject

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

A few things that bite people:

• drop_params: true matters because Claude Code sends Anthropic-only params the OpenAI backends will reject. This strips them silently.
• The openai/ / baseten/ prefix on model: is not optional. LiteLLM reads the provider from that prefix. Leave it off and you get LLM Provider NOT provided at startup — and the deployment is silently skipped, so every later request for that tier 404s with “no healthy deployments.”
• The separate subagent entry exists because Claude Code’s Task tool sends CLAUDE_CODE_SUBAGENT_MODEL’s value verbatim as the model field. Point that env var at the literal string subagent (step 5) and the proxy routes every subagent wherever you want — here, a cheap model on Go.

Want it even cheaper? Make a second config — litellm.config.go.yaml — where every tier goes through OpenCode Go (no Baseten, no Zen), using Go-catalog model ids. Run it on a different port (e.g. 30181) so it sits alongside the main proxy. Now you can flip between “GLM 5.2 brain” and “all-cheap” with a single alias.

4. Start the proxy

A tiny launcher that loads keys and runs the proxy:

#!/usr/bin/env bash
set -euo pipefail
cd "$(dirname "$0")"
set -a; source .env; set +a
exec .venv/bin/litellm --config litellm.config.yaml --port 30180

Save it as start-proxy.sh, chmod +x, run it, leave it running:

./start-proxy.sh   # listens on http://localhost:30180

The set -a; source .env; set +a dance exports every var from .env so the proxy actually sees the keys, then flips export back off to keep your shell clean.

Startup prints register_model: … not in built-in cost map warnings for your custom model strings. Harmless — LiteLLM just has no pricing table for them, so its cost tracking shows 0.

5. Point Claude Code at the proxy

Two ways in. The first is file-driven and tied to the repo dir; the second works from anywhere.

Settings file — .claude/settings.json, read once at startup:

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:30180",
    "ANTHROPIC_AUTH_TOKEN": "sk-litellm-local",
    "ANTHROPIC_MODEL": "claude-opus-4-8",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "claude-haiku-4-5",
    "CLAUDE_CODE_SUBAGENT_MODEL": "subagent"
  }
}

Then cd into the repo and run claude. Restart Claude after editing this file. Those ANTHROPIC_DEFAULT_* vars pin each Claude Code tier to a model_name the proxy actually knows, so the /model picker always lands on something routable. Skip them and you risk sending an id the proxy can’t map.

Inline env — works from any directory, overrides settings.json for that one run:

ANTHROPIC_BASE_URL=http://localhost:30180 \
ANTHROPIC_AUTH_TOKEN=sk-litellm-local \
ANTHROPIC_MODEL=claude-opus-4-8 \
ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6 \
ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5 \
CLAUDE_CODE_SUBAGENT_MODEL=subagent \
claude

For something repeatable, alias it in ~/.zshrc:

alias ccgo='ANTHROPIC_BASE_URL=http://localhost:30181 ANTHROPIC_AUTH_TOKEN=sk-litellm-local ANTHROPIC_MODEL=claude-opus-4-8 ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6 ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5 CLAUDE_CODE_SUBAGENT_MODEL=subagent claude'

(Swap the port to 30180 for the Zen/Baseten proxy, 30181 for the all-Go one.)

6. Verify it works

With the proxy running, hit it directly with an Anthropic-shaped request:

.venv/bin/python - <<'PY'
import json, urllib.request
body = json.dumps({"model": "claude-opus-4-8", "max_tokens": 16,
    "messages": [{"role": "user", "content": "reply with OK"}]}).encode()
req = urllib.request.Request("http://localhost:30180/v1/messages", data=body,
    headers={"x-api-key": "sk-litellm-local", "anthropic-version": "2023-06-01",
             "content-type": "application/json"})
print(urllib.request.urlopen(req, timeout=30).read().decode())
PY

Expect a 200 with an Anthropic-shaped content block. Swap the model for claude-sonnet-4-6, claude-haiku-4-5, or subagent to prove each tier independently.

Using the split in practice

Once it’s wired up, the brain/hands split isn’t just a config diagram — it changes how a session feels.

The heavy reasoning rides on GLM 5.2. That’s the Opus tier, which is what Claude Code leans on when it’s actually thinking — working through Plan mode, holding the shape of a change in its head, deciding what to do. The cheap models carry the volume: the Haiku tier’s background chores and every subagent your Task tool fans out. You’re paying for a strong reasoner on the turns that need one and pennies on the turns that don’t.

If you want to be deliberate about it, lean into the tiers: draft the approach in Plan mode on the Opus/GLM tier, then /model down to a cheaper tier to grind out the execution. Plan with the smart model, code with the cheap one. That’s the whole pitch, and now it’s a config file instead of a vendor lock-in.

Gotchas (the painful ones)

OpenCode Go 404s on /v1/responses. Every request to a Go-backed tier logs Client error '404 Not Found' for url 'https://opencode.ai/zen/go/v1/responses', then cascades into 429 No deployments available as the failing deployment goes into cooldown. The cause: LiteLLM’s Anthropic pass-through converts /v1/messages into an OpenAI Responses API call (/v1/responses). Zen implements that endpoint; Go does not — only chat/completions and messages. The fix is the env var from step 2:

LITELLM_USE_CHAT_COMPLETIONS_URL_FOR_ANTHROPIC_MESSAGES=True

It’s global but only touches the Anthropic→OpenAI path, so Zen and Baseten keep working. The tell: when you see a 404 … /v1/<endpoint> against a provider, you’re calling an API surface that provider doesn’t implement — reach for the chat-completions toggle before anything else.

Catalog drift. You’ll hit ModelError: Model <x> is not supported or There are no healthy deployments for this model because provider catalogs change often and they are not symmetric between plans. OpenCode Zen’s model list is different from Go’s, and an id that looks plausibly newer can still be the wrong plan. Check the live catalog and copy the exact id:

# Zen
curl -s https://opencode.ai/zen/v1/models -H "Authorization: Bearer $OPENCODE_API_KEY"
# Go
curl -s https://opencode.ai/zen/go/v1/models -H "Authorization: Bearer $OPENCODE_API_KEY"

Match the id field exactly in your model: line (after the openai/ prefix, or baseten/… for Baseten). A 403 instead of a model error means a backend key is wrong, not the model string.

TL;DR

uv venv .venv && uv pip install --python .venv 'litellm[proxy]'   # 1. install (avoid 1.82.7/1.82.8)
# 2. put BASETEN_API_KEY / OPENCODE_API_KEY / LITELLM_MASTER_KEY +
#    LITELLM_USE_CHAT_COMPLETIONS_URL_FOR_ANTHROPIC_MESSAGES=True in .env
# 3. write litellm.config.yaml: thinking tier → baseten/zai-org/GLM-5.2, rest → openai/… on OpenCode
./start-proxy.sh                                                   # 4. start it (port 30180)
ANTHROPIC_BASE_URL=http://localhost:30180 ANTHROPIC_AUTH_TOKEN=sk-litellm-local claude   # 5. use it

Claude Code never knows the difference. You just stopped paying Opus prices for grunt work.

There are two ways to do that. The first takes thirty seconds and works with a subset of the models. The second installs a small proxy and unlocks the whole catalog with stable per-model routing. Here’s both.

Way 1: Environment variables only

Claude Code speaks the Anthropic Messages API. OpenCode Go exposes some of its models through an Anthropic-compatible endpoint, so for those models you don’t need anything in the middle — you just tell Claude Code’s Anthropic client to call OpenCode Go instead of Anthropic. That’s a handful of environment variables:

export ANTHROPIC_DEFAULT_OPUS_MODEL=minimax-m3
export ANTHROPIC_DEFAULT_SONNET_MODEL=minimax-m3
export ANTHROPIC_DEFAULT_HAIKU_MODEL=minimax-m3
export CLAUDE_CODE_SUBAGENT_MODEL=minimax-m3
export ANTHROPIC_BASE_URL="https://opencode.ai/zen/go/"
export ANTHROPIC_AUTH_TOKEN=""
export ANTHROPIC_API_KEY="$OPENCODE_API_KEY"

Set those, start claude, and every Opus/Sonnet/Haiku slot — plus subagents — resolves to the OpenCode Go model you named.

The one limitation: this only works with models that ship an Anthropic-compatible interface. On OpenCode Go’s model list those are the ones with @ai-sdk/anthropic in the AI SDK column — at the moment, the MiniMax and Qwen families (minimax-m3, qwen-3.7-plus, qwen-3.7-max). Anything else needs a translation layer, which is exactly what the second method gives you. (Credit to kkovacs.eu for documenting this approach.)

Way 2: The ocgo proxy (all models, with mapping)

ocgo is a small Go CLI that runs a local compatibility proxy. It translates Claude Code’s Anthropic Messages API requests into OpenAI-style chat completions on the way out, so any OpenCode Go model works — not just the Anthropic-compatible ones — and it remembers a per-model mapping so you don’t reconfigure every session.

Install it and save your key:

brew install emanuelcasco/tap/ocgo
ocgo setup   # paste your OpenCode Go API key when prompted

Now map each Claude model name to the OpenCode Go model you actually want behind it. Three commands — one per tier:

ocgo mapping claude set claude-opus-4-8 glm-5.2
ocgo mapping claude set claude-sonnet-4-6 deepseek-v4-flash
ocgo mapping claude set claude-haiku-4-5 kimi-k2.7-code

Then launch Claude Code through the proxy:

ocgo launch claude

Under the hood, ocgo launch claude exports ANTHROPIC_BASE_URL=http://127.0.0.1:3456 and ANTHROPIC_AUTH_TOKEN=unused, then routes each Claude model name to its mapped OpenCode Go model — Opus requests go to GLM, Sonnet to DeepSeek, Haiku to Kimi — while the proxy injects your real OpenCode Go key upstream. Unmapped names pass through unchanged.

The proof is in the model picker. Ask the running session what it is and it tells you straight:

Model: kimi-k2.7-code. Claude Code session, but not running a Claude model.

That’s the Claude Code harness, your $10 subscription, and a Kimi model answering the prompt.

Which one to use

Way 1 is zero-install but limited to the Anthropic-compatible models. Way 2 is one brew install and a proxy process, but it opens the entire OpenCode Go catalog and lets you pin a different model to each tier and keep it there. Either way, you keep the harness you like and swap out the expensive backend for a ten-dollar one.

And honestly — if you can get good work done on the cheap models, you’ll have no trouble at all when you do reach for the expensive ones.

The obvious fix is to bind the dashboard to 0.0.0.0 and open the port. Don’t. That puts your agent control panel on the public internet. The better move is to keep the dashboard bound to 127.0.0.1 on the server and tunnel that port to your laptop over SSH. Your browser hits localhost, SSH carries the traffic, and nothing is ever exposed.

Three steps.

1. Open an SSH tunnel

From your local machine, connect to the server with a local port forward:

ssh -L 9119:127.0.0.1:9119 root@your-server.example.com

The -L 9119:127.0.0.1:9119 part is the whole trick. It says: take local port 9119 on my laptop and forward it to 127.0.0.1:9119 on the remote side. Anything I send to localhost:9119 here comes out as a connection to 127.0.0.1:9119 there.

Leave this SSH session open. The tunnel only lives as long as the connection does.

2. Start the dashboard on the remote

Inside that same SSH session, on the server, run:

hermes dashboard --host 127.0.0.1 --port 9119 --no-open

Two flags matter here:

• --host 127.0.0.1 keeps the dashboard private to the box. It’s not listening on any public interface — only the loopback address that our tunnel targets.
• --no-open stops Hermes from trying to launch a browser on the server. There isn’t one, and without this flag it’ll complain.

3. Open it in your local browser

Back on your laptop, go to:

http://localhost:9119

The request travels down the tunnel and lands on the dashboard running remotely. You get the full Kanban view — boards, channels, gateway status, sessions — exactly as if it were running locally.

Takeaway

Keep the dashboard bound to 127.0.0.1 on the server and let SSH do the reaching. One -L flag, no open ports, no reverse proxy, no auth layer to bolt on. Close the SSH session when you’re done and the tunnel disappears with it.

Hermes Agent is what I switched to when I wanted the same general promise, but less setup drama and fewer updates that turned into an afternoon.

Setup should not be a side quest

This was the first difference. Hermes was easier to get running and easier to keep running.

That sounds like a small thing until you use these tools every day. Then it is the thing.

Hermes feels agent-first

A lot of tools bolt agent behavior onto a chat wrapper. Hermes feels built around the agent loop itself: tools, memory, skills, cron jobs, delegation, real workflows.

That matters. I do not want a demo. I want a system.

The learning loop is the real feature

The killer feature for me is that Hermes can turn solved work into reusable skills.

Do something once, save the workflow, load it next time. The system gets better because I used it, not because I waited for a product update and hoped nothing else broke. Strange concept, I know.

Memory that does useful work

Another thing Hermes gets right is memory.

It automatically keeps track of useful context, organizes it, and makes it available later when I need it. That sounds obvious until you use tools that forget everything the moment the session ends.

It means less re-explaining, less copy-pasting, and a better shot at building on previous work instead of recreating it from scratch.

Stability wins

OpenClaw updates kept breaking enough things that I stopped trusting the ground under my feet.

Hermes has felt more stable, more composable, and generally better thought through from a security and operations point of view. Not perfect. Just less brittle, which is the adult version of exciting.

Why I stayed

I switched for easier setup.

I stayed because Hermes helps me build a repeatable system around AI work instead of starting fresh every session.

That is the difference between a fun tool and infrastructure.

Links:

• Hermes Agent: hermes-agent.nousresearch.com

What it shows

One terminal window, every running agent at a glance. For each Claude Code and Codex CLI session it tracks:

1. Tokens used and context window fill % — per-session bars with warnings when one is getting close to full. This is the headline feature for me.
2. Rate limit status — your quota in real-time, so you stop guessing whether you’ve been throttled.
3. Child processes and open ports — if an agent spawned a dev server and forgot to kill it, you’ll see the orphan port and can clean it up with one key.

It also catches subagents, git status, and the current task each session is on. All read-only — no API keys, no auth.

Why this matters

The dumb thing about running multiple agents is that you can’t actually see them. Each one lives in its own terminal pane, you have to switch around to check status, and there’s no system-level view of who’s burning tokens or about to compact. abtop is the missing system view. One screen, every session, live.

Installing it

macOS or Linux, one line:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/graykode/abtop/releases/latest/download/abtop-installer.sh | sh

Or via Cargo if you have Rust set up:

cargo install abtop

Then just run abtop. Recommended terminal size is 120x40 or larger.

Windows users — it needs Unix tools (ps, lsof), so run it inside WSL.

Bonus: tmux integration

If you already work in tmux, this gets better. abtop discovers sessions across panes, and pressing Enter on a row jumps you straight to the terminal running that agent. So the flow is: scan abtop → see the one at 87% context → Enter → you’re there, ready to wrap up or compact.

That’s it. Tiny tool, dead-simple install, and once it’s in your stack you’ll wonder how you managed running parallel agents without it.

Links:

• Repo: github.com/graykode/abtop

With Conductor, it’s closer to ten.

What it is

A Mac app that runs Claude Code agents in parallel. Not a new model, not a new IDE — a harness. It reuses my existing ~/.claude setup verbatim: skills, hooks, MCP servers, RTK, CLAUDE.md. No re-onboarding.

One overview, many agents, many projects

Every workspace across every project, one window, status at a glance.

Right now: one agent writing this post, one on a Jekyll deploy script, one on a flaky test in another repo, one drafting a PR. Three projects. I know who’s blocked on me without clicking in.

The loop: plan → implement → review → PR → merge → archive

Every task moves through the same six steps. My job is two of them — approving the plan, reviewing the diff. The rest is the agent.

Worktrees + setup/run scripts

Every task gets its own git worktree. Own branch, own checkout. Three versions of the same site can run side by side with no collisions. Each workspace runs my project’s setup script (deps, env) and run script (dev server) on demand. Testing a branch is one click.

Staying out of the IDE

The unexpected win. When the editor is in front of me I twitch — rename things, fix a semicolon, lose an hour. Conductor keeps me one step back, on intent and review.

When I actually need code, the diff viewer is right there. “Open in IDE” and “open terminal in this worktree” are one click each. No access lost — just no default pull.

GitHub issues in, PRs out

Point Conductor at an issue. It opens a workspace with that context, plans, executes, opens a linked PR. Backlog turns into throughput.

So is it smarter than Claude?

No. That’s the point. Conductor isn’t a better model — it’s the safety rails (worktrees, PRs, structured review, archive) that let me run a lot of Claude at once without it turning into chaos.

If your bottleneck moved from “the AI is too slow” to “I can only supervise one of these at a time,” try it.