Theopenagentruntime.
Embedit.Self-hostit.Ownit.
OpenGeni is a managed-agent service you run yourself. Durable sessions, sandboxed tool execution, replayable event history — and a public API your product talks to directly. Embed it inside your product, or stand one up for your whole org.
Built to be embedded. Built to be deployed.
OpenGeni isn't a developer CLI for one machine. It's a runtime — a tiny operating system for agents that lives wherever you put it.
Inside your product.
Bring real agents into your product. Your UI, your auth, our runtime. OpenGeni owns durable session state, event history, approvals, and final outputs — your customers never know it's there.
Across your org.
Stand up one OpenGeni for your whole company. Any cloud. Your sandboxes, your secrets, your audit trail. A scalable agentic OS that grows with the team — not a single-machine CLI.
A durable, observable, interruptible agent service — with the boring infrastructure already wired in.
Sessions live in Postgres. Live events stream over SSE with NATS fanout. Long work is coordinated by Temporal. Tool execution happens inside a sandbox you choose. Repos and documents plug in as first-class agent tools.
One API in front. Postgres as truth, Temporal as the metronome, a sandbox at the edge.
Public clients only ever talk to the Hono API. Postgres is the durable source of truth, NATS handles realtime fanout, and Temporal coordinates long-running work.
If an SSE client misses live events, the API backfills from the event log by sequence number. Sessions replay. Always.
Realtime fanout only. Loss-tolerant: durability is somebody else's job (Postgres'). Keeps the hot path cheap.
Model calls, tool execution, sandbox commands, repo ops — all inside non-retryable Temporal activities, because side-effects.
Your data, your model, your perimeter. Pick the brain. Keep the keys.
Agent intelligence is too important to outsource blindly. OpenGeni runs the agent harness on the OpenAI Agents SDK, so the model is a swap — not a lock-in. Route prompts to a frontier API, an enterprise Azure tenant, a regional Bedrock deployment, or a GPU sitting in your own DC. Keys, traffic, and inference all stay inside the boundary you control.
- OpenAIDirect Responses + Chat Completions, default path
- Azure OpenAIPin inference to your tenant, region, and compliance envelope
- Anthropic · Gemini · Bedrock · MistralRouted via the LiteLLM provider extension
- Ollama · vLLM · LM Studio · llama.cppSelf-hosted, OpenAI-compatible, never leaves your network
- Anything elseImplement a ModelProvider — air-gapped and bespoke endpoints welcome
Every model call goes through a ModelProvider running inside your worker. Default is OpenAI; flip OPENGENI_OPENAI_PROVIDER=azure to pin inference to your Azure tenant, or hand the SDK a LitellmProvider to fan out to Anthropic, Gemini, Bedrock, Mistral, Ollama, vLLM — anything LiteLLM speaks.
Need air-gapped, region-locked, or audited? Implement the ModelProvider interface against your own endpoint. The harness doesn't care where the tokens come from.
From POST /sessions to a healthy reply, in six durable steps.
Client opens a session
Your client posts to the Hono API. The request is validated, a session row lands in Postgres, and an id comes back. Nothing has run yet — but the session is already replayable.
{ "initialMessage": "diagnose drift in prod",
"resources": [...], "tools": [...] }Tool execution lives in a sandbox you choose, on a contract you can extend.
OpenGeni delegates execution to a SandboxClient — the same contract the OpenAI Agents SDK speaks. Repos and files mount in as real filesystem paths. Sandbox session state is part of the saved run state, so the next turn picks up exactly where the last one left off.
Bring your own runtime.
Anything that satisfies the OpenAI Agents SDK SandboxClient contract is a valid backend: create / resume / delete a session, deserialize state for durable resume, materialize a manifest of resources. Add yours next to the ones we ship.
- Surface
- createSandboxClient(settings)
- Resources
- Manifest with gitRepo + s3Mount entries
- State
- deserialize / serialize SandboxSessionState
Plus anything else that implements the SDK contract — wire it up in createSandboxClient and you have a new backend.
Secure by default. Nothing leaks in unless you say so.
Out of the box no host environment enters the sandbox. Opt into a preparation profile when you want one — an Azure profile that runs a built-in az login --service-principal hook, a GitHub profile that passes through a local token and git identity — or list extra variables explicitly via an allowlist. Model provider keys stay with the worker.
Tuned for infra work out of the box.
Ships with Terraform, Checkov, Azure CLI, GitHub CLI, git, jq, curl, shell utilities, and bundled Terraform / Checkov skills. Swap OPENGENI_DOCKER_IMAGE for your own when you outgrow it.
Tools are MCP servers. We ship a few. You plug in the rest.
Every tool the agent reaches for goes through the Model Context Protocol — including the ones we ship by default. Point OPENGENI_MCP_SERVERS at any compatible server and select it per session.
Plug in any MCP server.
A session attaches tools by id; the worker connects the matching MCP servers, prefixes their tool names, and hands them to the agent. Built-ins are convenient defaults — your enterprise search, your vector DB, your custom MCP server slot in the same way.
- ▸Streamable HTTP MCP transport
- ▸Per-server allowedTools allow-list
- ▸Tool names auto-namespaced (serverId__tool)
- ▸Connect in parallel, tool list cached
Every agent needs an inbox. We built one that doesn't lose messages.
Per-session FIFO. One workflow per session, one turn at a time. Postgres row-locking under the hood — FOR UPDATE SKIP LOCKED — so you never have to think about it.
One workflow per session. One turn at a time.
Plumbing, not a feature. You don't think about it. It's just here so your agent stops dropping turns the moment a user gets impatient and double-sends.
Three things you'd otherwise have to build.
- 01Idempotent submits
Duplicate turn requests collapse on a key. Double-clicks, retries, network blips — they don't multiply work.
- 02Live edits
Reorder, edit, or cancel queued turns before they run.
PATCH /turns/:id · POST /turns/reorder · DELETE /turns/:id - 03Backpressure
Long-running turns don't drop user messages. They queue. The workflow drains the head as it finishes each one.
Tasks. Let the agent run itself.
Like ChatGPT Tasks or Claude's scheduled prompts: a saved agent run that fires once, on an interval, or on a calendar. You can create them — or the agent can create and manage its own. Durable on Temporal Schedules, with overlap policies that won't trample the previous fire.
User: "keep an eye on our infra repos for drift."
Agent: created task — every weekday at 09:00, scan repos and post a summary to #ops.
Tasks are tools. The agent can create, edit, pause, and delete its own — or you can manage them by hand. Either way, fires durably and resumes if a worker dies mid-run.
runAt + tz"remind me at 4pm Friday"
everySeconds"every weekday at 09:00"
hour · minute · days"first of the month, 06:00 UTC"
allow_concurrentfire even if previous still runningskipdrop new fires while one is in flightbuffer_onekeep at most one queued behind the current run
new_session_per_runreusable_sessionOne contract. Real endpoints. No magic SDK required.
The Hono API is the public contract. Build with curl, fetch, or anything that speaks HTTP. The included React app is just one client.
Routes shown without the /v1 path prefix for clarity. The shipped API mounts everything except /healthz under /v1.
Boring choices, on purpose. Every box is the part that's already proven.
- 01BunWorkspace runtime
- 02HonoPublic API
- 03React + ViteReference web client
- 04TemporalDurable orchestration
- 05PostgresSource of truth
- 06DrizzleType-safe ORM
- 07pgvectorDocument embeddings
- 08NATS CoreRealtime fanout
- 09MinIO / S3Object storage
- 10OpenAI Agents SDKAgent harness
- 11MCPTool protocol
- 12LiteParseDoc parsing / OCR
One command brings the whole runtime up locally. Postgres, NATS, Temporal, MinIO, sandbox, API, worker, web.
bun run dev installs deps, brings up Docker infra, runs migrations, builds the local sandbox image, then starts the API, worker, and web app together. That's local dev today — a one-command production deploy to the cloud of your choice is coming next.
OPENGENI_DATABASE_URLpostgres://opengeni@localhost:5432/opengeniOPENGENI_NATS_URLnats://localhost:4222OPENGENI_TEMPORAL_HOST127.0.0.1:7233OPENGENI_OPENAI_PROVIDERopenai | azureOPENGENI_SANDBOX_BACKENDpluggable backend selectorOPENGENI_MCP_SERVERS[{ id, url, allowedTools }]OPENGENI_OBJECT_STORAGE_ENDPOINThttp://127.0.0.1:9000
Teach your coding agent OpenGeni. One install, in any repo.
A skill for skill-aware coding agents — install it in any repo and your agent knows how to integrate with OpenGeni and configure its sandboxes. It points at the source when it needs exact details.
$ npx skills add Cloudgeni-ai/opengeni --skill opengeni- ▸How to integrate OpenGeni from a client app
- ▸How to configure sandboxes and MCP servers
- ▸Where in the source to look for current details
- ▸Vocabulary, workflows, and architecture
Shipped, in flight, and on the horizon.
- ShippedOpen-source core — Apache-2.0, contribution + security guides✓ shipped
- NextOne-command deploy of the full stack — scalable, robust, on the cloud of your choice✓ in the works
- NextAuthentication, tenancy, API keys, scoped client permissions
- NextOutbound webhooks for event delivery
- NextFirst-class agents and environments API resources
- LaterClient SDK — streaming, timeline projection, approvals, interrupts
- LaterMore OpenAI Agents SDK-compatible sandbox backends
- LaterDeeper Temporal / OpenAI Agents SDK durability integration