AHMAD:// Available for work — open to remote roles and contracts

← ~/work

xr

Live · active RUNTIME

A local-first AI agent runtime that cannot overspend its budget or hide its actions: BYOK, hard spend ceilings, approval-gated effects, and a hash-chained log you can verify offline.

built: 2026-06 → ongoing role: solo — architecture, implementation, review, release stack: TypeScript · Bun · SQLite · MCP · Playwright (optional) repo: 5★ · pushed yesterday

> attest xr

claims → status → evidence — every row opens something you can check yourself
claimstatusevidence
The agent loop cannot overrun a token or dollar ceiling — enforced in code and covered by tests TESTED test/cost.test.ts
Typed allow/deny decisions returned before every step SHIPPED src/cost/governor.ts
Dependency-injected Observe–Think–Act loop, provider-agnostic SHIPPED src/core/agent.ts
Publicly installable from npm as @rrrtx/xr PUBLISHED npmjs.com/package/@rrrtx/xr
Seven GitHub Actions workflows guard the repo (CI, cross-platform, nightly, provider canaries, supply-chain, release) GREEN .github/workflows
Browser dashboard live on Vercel LIVE xr-gules.vercel.app
Built with heavy AI-tool assist — disclosed, not hidden; see the repo's honest beta labeling and known-limitations register DISCLOSED github.com/ahmadrrrtx/xr

01What this is, in one paragraph

xr is an agentic runtime for people who are tired of agents that act like they own your credit card. You give it a task; it plans, calls tools, and changes real things on your machine — under a policy gate, your approval for risky actions, a hard budget ceiling, and a tamper-evident log of everything it did. BYOK and local-first: your keys, optionally a local model, no middleman account.

02The problem I actually built for

In 2026 every demo agent is a loop calling a model. The interesting engineering isn't the loop — it's what bounds the loop. Most agent frameworks treat spend, egress, and approval as afterthought "guardrails" bolted onto the prompt, where a persuasive model can negotiate around them. I wanted the opposite: bounds enforced in deterministic TypeScript that the model can see but not touch. That single design decision — the budget lives outside the brain — shaped every module in the repo.

03Architecture

The core loop (src/core/agent.ts) is dependency-injected: it takes providers, tools, state, and the governor as constructor arguments, which is exactly what makes the guarantees testable — tests hand it a greedy fake provider and assert the run stops. Twenty-seven modules sit under src/ (cost, security, mcp, memory, plugins, providers…) and the release/version surface is stamped from a single release.manifest.json — if any drift, CI fails. Boring on purpose.

04The load-bearing decisions

  • Enforce before generate. The governor's checkBeforeStep() runs every turn with an optimistic estimate of the next call — denial is proactive, not reactive bookkeeping.
  • Typed decisions, no booleans. GovernorDecision is a discriminated union: a denial must carry a reason and a snapshot; there's no silent false to ignore in the UI layer.
  • Egress allowlist, default deny. Network is an effect like any other; the agent doesn't get "helpful" outbound calls for free.
  • MCP as a platform, not a plugin bolt-on. Server and client support are first-class (the repo's plugin marketplace treats MCP tools like any other skill).
  • Deliberate non-decision: no LangGraph/CrewAI dependency. With the loop this small and this load-bearing, owning those ~400 lines beats inheriting someone else's abstraction.

05The exhibit: the ceiling that can't be negotiated

xr/test/cost.test.ts excerpt, trimmed — the second test is the whole thesis view on GitHub ↗
/**
 * XR — Cost Governor tests. The headline guarantee: the agent CANNOT
 * exceed the ceiling, enforced in deterministic code.
 */
test("governor blocks the next step before exceeding the token ceiling", () => {
  const g = new CostGovernor({ maxTokens: 1000 }, ...);
  g.record(400, 100); // 500 used
  expect(g.checkBeforeStep().allow).toBe(true);
  g.record(400, 100); // now 1000 used
  expect(g.checkBeforeStep().allow).toBe(false); // at ceiling
});

test("AGENT LOOP: a tiny token ceiling stops the run (the headline
guarantee)", async () => {
  // Provider that always wants to keep going…
  // …loop is asserted to stop. The budget wins over the model.
xr/src/cost/governor.ts excerpt, trimmed to the load-bearing lines view on GitHub ↗
export type GovernorDecision =
  | { allow: true; warning?: string }
  | { allow: false; reason: string; snapshot: CostSnapshot; suggestLocal?: boolean };

export interface Budget {
  /** Hard ceiling in USD for this task (0 or undefined = no $ cap). */
  maxUsd?: number;
  /** Hard ceiling in total tokens for this task. */
  maxTokens?: number;
}

Three things I like about it: the boundary semantics are decided and tested (at-ceiling is denied), the local-model path is priced at zero explicitly instead of special-cased downstream, and the integration test proves the loop halts — not just the component.

06How it's shipped, not just written

Sixty-five PRs merged through branches, seven CI workflows (unit, cross-platform, nightly, provider canaries, supply-chain, release), published to npm as @rrrtx/xr — currently v3.x — with install scripts for Linux/macOS/Windows/Termux and a documented beta feedback loop. The footer of this site shows the CI status of the latest run whatever it is; when it's broken, this sentence is the proof I'm not cherry-picking.

What's false about the pitch — and what's just early

  • I did not hand-write 721 commits at that pace and pretend otherwise. AI coding agents generate much of it; I designed the contracts, reviewed the diffs, and the tests are the arbiter. My skill here is orchestration with verification — that's disclosed, not hidden.
  • No external users yet. "Public beta" is the honest label the repo itself uses.
  • The audit chain is integrity tooling, not a security boundary: someone with host-key access can rebuild a consistent chain. Stated in the repo, restated here.
  • Single-user, local-first by design — the "OS" naming is about scope of control, not a claim to be a kernel.
  • 5 stars on GitHub. Reach and rigor are different axes and I don't confuse them.

07Lessons, kept

  • Guarantees belong in code the model cannot edit, above the prompt.
  • A passing integration test is worth more than a polished README paragraph.
  • Ship on a registry early: versioning forces honesty about what "done" means.
  • One source of truth (release manifest) deleted a whole category of drift bugs.
ahmad@xr:~% ask — grounded in this site · no LLM, no invented answers

try: