Features

Persistent session infrastructure, not another chat window

OpenDray is for developers evaluating how AI coding sessions behave when they become long-running server processes with memory, channels, and APIs around them.

OpenDray infrastructure map visual
PTY sessions

Real processes that outlive the laptop

OpenDray runs Claude Code, Codex, Gemini, and shell as PTY-backed processes on infrastructure you control. Scrollback survives. Waiting prompts survive. The active process does not need a browser tab to stay alive.

  • Reconnect without losing output or session position
  • Let sessions wait safely for review, approval, or clarification
  • Keep the workflow closer to operator tooling than disposable chat
pty/session 
$ opendray attach web-refactor
restored scrollback: 817 lines
cwd: /workspace/opendray
state: waiting_for_reply
channel: telegram
OpenDray memory and routing visual
Memory and routing

Context stays local and replies find the right session

Memory is organized across user, project, and session scopes. Embeddings can run through ONNX, Ollama, or LM Studio, while Postgres + pgvector handles retrieval. Channel replies are routed back into the correct live session instead of becoming detached messages.

  • User scope for durable preferences and working style
  • Project scope for engineering conventions and deploy rules
  • Session scope for temporary decisions and task-specific context
OpenDray API surface visual
API surface

A gateway other tools can build on

REST endpoints and WebSocket streams make OpenDray usable beyond its own UI. Teams can build approval flows, dashboards, monitoring surfaces, and automation around the same session model.

Comparison

What changes compared with a normal CLI workflow

Concern Normal local CLI OpenDray
Session lifetime Bound to laptop and terminal Runs as a server-side PTY session
Reply path Return to the same machine Reply from browser or message channels
Memory Usually implicit or provider-owned User, project, and session scopes stay local-first
Integrations Manual scripting around terminal state REST, WebSocket, scoped keys, and audit trail
Deployment tradeoff

Why no Docker?

OpenDray is host-resident by design. It spawns real PTY subprocesses and depends on practical host state such as project files, SSH agent access, provider credentials, and long-running operator workflows.

A container boundary sounds cleaner than it behaves for this product. Systemd or launchd fit the operational model better because OpenDray is meant to supervise real developer tools on the host, not hide from them.

operator notes 
- host-resident PTY sessions
- shared project files and CLI auth
- direct access to SSH agent and provider credentials
- simpler service management
- fewer artificial workflow boundaries