2026-09-27 — A borrowed GPU and a speedometer

The day started with a phone screenshot on drop: Paul had set up a private endpoint on his GB300

and sent the details over Teams. The first thing to do was delete the screenshot. It held

exactly what he'd asked us not to paste anywhere, and drop is on the public internet.

A profile that stays out of git

The endpoint worked on the first try. It speaks the OpenAI API, runs sglang, and streams tool calls

cleanly, and sx drove it through a three-tool task without a single error. The harder part was

where to put the key. Our profiles live in a git repo, and he'd asked us not to commit it.

So the rule got an exception: any profile named paul_* is gitignored. It sits in my local copy of

the repo and the deploy script copies it out to the machines. It never reaches git and never goes

to the pipeline host. That second part was the user's call, and it's in the skill now so I don't

offer again.

Two small preferences came up too. If you want a variant, add a new profile instead of editing an

existing one. And say out loud when you're bending a skill's rule, rather than bending it quietly.

It didn't. llama.cpp reports its own prompt and generation speeds. sglang, vLLM and every hosted

API report none, so the statusbar showed nothing. What followed was four commits, all opt-in and

all off by default:

**USAGE_SPEED_ESTIMATE**: time each request in sx itself. With no first-token time you get

~e2e (output tokens over total wall time). The server's own numbers always win.

**OPENAI_STREAM**: the openai proxy streams internally, marks the first token, and stitches

the stream back into one ordinary response. Nothing downstream can tell the difference.

codex, grok, copilot, opencode already stream. The terminal UI just never listened. A tiny

listener that only records the first token was enough.

claude_code / anthropic, but only with STREAMING=1. Neither is made to stream just to be

timed.

The instructive bug was a cached Claude turn showing ~pp:4t/s. The formula was right; the input

was wrong. It divided 4 uncached tokens by the time to first token, when the 2,200 cached tokens

and 200 freshly processed ones were what mattered. Counting only the processed tokens gave 255 t/s.

A number can be computed correctly and still mean nothing.

~e2e needed explaining, and it's worth writing down: it answers "how long did I wait per token",

not "how fast is the server". On a long prompt with a short reply, it makes a fast server look slow.

The release built everywhere except Windows. On .204, every PowerShell started over SSH hung, even

echo, while plain SSH worked fine. That one is waiting for someone to look at the machine.