HighX
Reference

Status

What is built, what is measured, and what is deliberately not.

PhaseState
0 ContractsComplete
1 Runtime sliceComplete, and verified on a live Cloudflare deployment
2 Auth and tenant routingComplete, including JWT and custom adapters
3 Reactive engineComplete, with index-precise invalidation
4 Protocol and clientComplete; SSE and long-polling deferred
5 SSR and hydrationComplete, including D1 public routes
React bindingsuseQuery, useMutation, useDraft, useCollaborative, useConnectionStatus
CollaborationComplete: sequencer, five algebras, divergence recovery, rich text, remote carets
6 CompilerComplete; gates the real client build
7 Reliability and operationsComplete: structured logs, emitted metrics, measured limits
ToolingCLI, scaffolding, inference-driven configuration, stages, load testing
8 Agents and workflowsComplete: durable runs, interrupts, permissions, usage ledger
9 Agent skillsComplete: descriptors, phase restriction, versioned replay, highx eval
10 Linked projectsComplete for inline apps; isolated Workers deferred

What is proven

The reactive slice, collaboration, and the claims about latency and fan-out were measured on a live Cloudflare deployment: sign-in, sessions in KV, a tenant Durable Object per workspace, live subscriptions across browsers, presence, and several browsers editing one rich-text document with simultaneous edits converging byte-identically.

Durable runs are proven under workerd rather than on a deployment: an agent run suspending on its approval, resuming exactly once, the object's own alarm waking a sleeping run, spend recorded to tenant rows, and a linked app served inside the object — all against Durable Object SQLite and real alarms.

Known gaps

D1, R2, cross-authority sagas, and agent runs are not exercised on a deployment. Those paths are covered under workerd rather than by a running account, and the recorded load baseline predates the current example — record a new one before treating it as a gate.

Engine benchmarks are algorithmic, not platform measurements. → Limits

Hot-tenant behaviour under real contention is unmeasured. A single-threaded isolate under concurrent requests cannot be reproduced in process.

Retention is enforced but its limits are unmeasured in production. How often a real tenant needs sweeping, and how large an archive object becomes, are deployment questions.

Index pushdown into SQLite is not implemented. The Durable Object adapter materializes rows and runs the shared plan runner in JS. Semantics are identical to the test adapter by construction; performance is a later optimization.

Deliberate v1 non-goals

  • Live D1 or global tables
  • Atomic transactions across D1 and Durable Objects
  • Arbitrary route re-execution with server and client hooks
  • Complete static proof of JavaScript capabilities
  • Inline code sandboxing
  • Globally synchronous cache invalidation
  • Multiple deployment platforms

What runs on every change

bun run test runs the in-process suites and the workerd suite together; CI adds check-types, the client-bundle boundary check, and a generated-API drift check. The Cloudflare-semantics tests behind the isolation, hibernation, and resume claims gate every change rather than waiting to be run by hand.

Browser behaviour is checked by hand in two profiles: convergence, presence, what happens to an edit made while disconnected, and whether a reconnect resumes or resubscribes. Those are the claims only two real browsers can settle.

On this page