- Jobs run through authenticated local CLI sessions.
- Outbound bridge polling; no inbound ports or tunnels.
- Claude, Codex, Cursor and Gemini backends behind one `/v1` API.
Problem
A Claude, Codex, Gemini or Cursor subscription is built for one thing: you, coding, in your editor or terminal. Put a model inside the product you are building and that subscription no longer applies. Application features have to talk to the metered API, billed per token. You end up paying twice for access to the same models.
Approach
Invert the connection. Rather than exposing the developer's machine to inbound traffic, a bridge daemon dials out to a relay and polls for work, so there are no ports to open and no tunnels to run. It shells out to the CLI the user has already authenticated, which means Relayent never stores or handles a credential. The economic reframe is the real insight: instead of one central API bill that grows with every user, each user brings their own subscription, which makes per-user job isolation the core design problem rather than an afterthought.
Solution
Three parts. A Go relay acts as a job broker behind a versioned HTTP API; a Go bridge runs on the user's machine and invokes claude -p, codex exec, cursor-agent or gemini -p headlessly; and an OpenAPI document is the only integration surface, with an optional Python client generated from it. Backend readiness is deliberately tri-state (installed, supported, ready) because a CLI merely being on PATH does not make a backend usable. Cursor jobs run in ask mode so a generation job can never edit files or run shell commands.
Impact
Relayent changes the cost model for AI features during development and internal tooling: the application can use the subscription already attached to a user's CLI instead of defaulting to a central metered API bill. It also changes the integration shape, because the app only talks to a versioned `/v1` API while the user's credentials stay local.