HeraldLabs OpenClaw Beta: LiteLLM, Budgeted Keys, SOPS, and Public Handoff Threads

A beta program is mostly a wiring problem with people attached. The model is the easy part. The hard part is making sure testers get scoped access without you handing out raw provider keys, secrets never end up in a chat window, and the next operator to pick up the work can read the whole story in one place.

This is how HeraldLabs onboards OpenClaw beta testers, generalized. Tester names and specific key values are removed. The architecture is the point.

Four moving pieces

The stack is small on purpose.

1. A LiteLLM proxy as the single model gateway.
2. Per-tester budgeted virtual keys with hard spend caps.
3. SOPS-encrypted secrets checked into the repo, decrypted only at deploy.
4. Public handoff threads so testers and the team share one timeline of truth.

Each one exists because the others were not enough alone.

1. LiteLLM proxy on Railway

The proxy is the only public entry point for tester traffic. Behind it, the model routes and the keys live. The operator sees one URL. The provider sees one set of credentials.

Practical bits that matter.

• Lock the proxy to a fixed Railway region. Region changes break route assumptions.
• Pin the LiteLLM config version. A drift here is the kind of bug that ships as a billing surprise.
• Surface spend per virtual key in the proxy logs, not only in the model router. The proxy sees the bill.

2. Per-tester budgeted virtual keys

Every tester gets a virtual key issued by LiteLLM, not a raw provider key. The virtual key has a hard spend cap and a model allowlist.

• Spend cap: enforced at the proxy. If a tester burns through the cap, the proxy returns a clean error and the run stops.
• Model allowlist: scoped to the routes the tester actually needs. A tester doing retrieval work does not need image-gen routes.
• Key rotation: rotate on tester exit, not on tester entry. Tests are short.

Budgeting beats generosity. Generous budgets without caps are how beta programs become incidents.

3. SOPS in the repo, never the chat

Secrets live in the repo, encrypted with SOPS. The CI step decrypts at deploy, not at commit. The decrypted value never enters chat, never enters a run log, and never enters a screenshot.

• Encrypt with a key the CI runner can resolve.
• Commit only the encrypted form. Lint rule, not a norm.
• Decrypt once, inject as env, run.
• Audit the decrypted env hash into the deploy report, not the values.

If a secret ever appears in a chat window, the answer is to rotate it. Treat that as an outage, not a slip.

4. Public handoff threads

Testers and the team share one timeline. Public means a Discord thread, a Linear cycle, or a Notion page that anyone with access can read later. It is not Slack DMs. DMs are where bugs go to die.

The thread records:

• what shipped and when
• what broke and what was patched
• what each tester saw, in their own words
• the next decision and who owns it

When the program ends, the thread is the postmortem draft. You do not have to reconstruct the program after the fact. You read it in order.

The collector miss we caught

The first time the proxy went live, one tester’s session logged nothing. Every request looked successful, but the collector that aggregates the per-key spend and request metrics saw zero events from that key.

The cause was a misconfigured virtual key that bypassed the request logger. The key was technically valid, but the proxy never emitted the usual per-request event for it. Spend was still being enforced at the hard cap, so the tester did not run away with the budget. The audit gap was the real risk.

The fix was twofold:

• reject any virtual key whose logger hook is unbound at startup. The proxy should refuse to serve traffic until the hook is wired.
• daily audit: spot-check at least one tester key for a non-zero event count. A flat zero is a flag, not a quiet day.

That incident is the reason the receipt chain exists for the proxy too, not only for the crons.

What we generalized for other operators

• One public entry point, not many.
• Virtual keys with caps and allowlists, not raw provider keys.
• Secrets encrypted in the repo, decrypted at deploy, audited by hash.
• One timeline the team and testers actually use.
• Daily audit for any metric that should never read zero.

The work is unglamorous and it is the only reason a beta program ends with trust instead of an invoice.