What an Outgate agent is

A real coding agent, running in its own cloud sandbox, reachable from chat or the API.

An Outgate agent is not a thin chat wrapper around a model. Each agent is a full agentic CLI — Claude Code or Codex — running inside an isolated sandbox container in an Outgate region. It has a shell, a persistent filesystem, git, and the same tool access it would have on a developer machine.

You talk to it the way you would talk to a colleague: send a message, watch it work, review the result. Chat at chat.outgate.ai is the built-in interface, and everything chat can do is also available programmatically through the Agents API — chat itself is built on the same public endpoints.

you (chat or API)
      |
      v
  Outgate control plane ──── thread registry, auth, events
      |
      v
  region ─── sandbox container
              ├─ Claude Code or Codex
              ├─ /workspace (persistent volume)
              └─ model traffic via the gateway
                  └─ guardrails apply on the way out

Model traffic from the sandbox flows through the same gateway as any other Outgate traffic, so routing, guardrails, and observability apply to agent work exactly as they do to direct API calls.

Threads

A thread is one agent: a conversation, a sandbox, and a durable event history.

The unit of work is a thread. A thread bundles three things: the conversation with the agent, the sandbox container the agent runs in, and a durable, ordered event history of everything that happened — messages, tool calls, lifecycle changes.

Threads are long-lived. The sandbox can go to sleep and wake up again, but the thread keeps its identity, its history, and its workspace the whole time. You can close your laptop mid-task and pick the conversation up days later.

• Every thread has a stable ID and belongs to your organization.
• The full event history is queryable — nothing about the run is a black box.
• Threads created in chat and threads created through the API are the same object and can be inspected the same way.

Sandbox lifecycle

Sandboxes start, run, sleep when idle, and wake on demand; threads are long-lived by default.

create                    message / resume
   |                              |
   v                              v
starting ────────> live <──────────────── idle
   |                 |    idle timeout       |
   |                 └──────────────────────>┘
   v
spawn_failed                 thread TTL reached
                                   |
                                   v
                                 ended

Agent types, models, and effort

Choose Claude Code or Codex, pick any model your account can access, and set reasoning effort.

Each thread runs one agent type: claude (Claude Code) or codex (Codex CLI). The agent type is fixed per thread; the model and effort level are not.

The model picker shows the live catalog for your actual account — the models your provider subscription really offers, not a hardcoded list. You can switch the model mid-thread; the sandbox restarts with the new model and the conversation continues.

Effort maps to the native reasoning controls of each agent — Claude Code effort levels for claude threads, model reasoning effort for codex threads. Set it per thread in chat from the composer menu, or per request through the API.

Signing in to model providers

Agents authenticate to Anthropic or OpenAI with your own subscription, or run against gateway providers.

There are two ways an agent gets model access. The simplest is signing in with your own provider subscription: chat shows Connect Claude and Connect ChatGPT buttons that walk through the provider sign-in flow. You open a URL, approve on the provider side, and the sandbox completes the login — the same flow the CLIs use on a laptop, adapted for a headless container.

Alternatively, a thread can run against a provider configured in your Outgate gateway — including non-Anthropic and non-OpenAI upstreams behind compatible APIs. In that mode the sandbox receives scoped credentials automatically and no interactive sign-in is needed.

• Sign-in state survives idle and wake — you do not re-authenticate every session.
• Auth status is visible in chat and queryable through the API, so you always know whether a thread is signed in before sending work.
• Sign out any time; the thread stays, only the provider session is cleared.

Permission modes

Decide whether the agent asks before running tools, or runs autonomously.

Every thread has a permission mode. In ask mode, the agent pauses before consequential tool runs and raises a permission request — chat shows an approval card, and API consumers receive a permission_request event they can answer programmatically. In skip mode, the agent proceeds autonomously without asking.

Ask is the safer default for exploratory work; skip suits automation where a human is not watching. The mode can be changed on a running thread.

Workspace and volumes

/workspace is a persistent volume that survives sleep, wake, and model switches.

Each sandbox mounts a workspace volume at /workspace — the working directory where the agent clones repositories, writes files, and builds output. The volume is real persistent storage: it survives idle sleep, waking, model and effort changes, and sandbox restarts.

In chat, threads are organized into projects, and threads in the same project share one workspace volume. That is deliberate: a follow-up thread in the same project sees the files the previous thread left behind, so multi-session work on one codebase does not start from zero.

For one-off jobs you can create an ephemeral thread instead: no volume is attached, the agent gets scratch space that disappears when the sandbox stops. Ephemeral threads are the right choice for stateless automation where persistence would only accumulate clutter.

• Upload files to a thread from chat (drag and drop, up to 500 files per message) or through the files API.
• Browse workspace contents from the Files tab in chat or list them through the API.
• Workspace size is measurable per volume, so you can keep an eye on growth.

Git and GitHub

Agents work with real repositories; the GitHub App grants short-lived, scoped access.

Sandboxes ship with git, and agents use it natively — clone, branch, commit, push. Chat has a Git tab that shows repository status, and the API exposes git operations directly.

For private GitHub repositories, install the Outgate GitHub App on your organization or selected repositories. When a thread touches a repo the app covers, Outgate mints a short-lived installation token (valid for about an hour) and hands it to git inside the sandbox through a credential helper.

Repositories on other hosts work too: any git remote that accepts token authentication can be used by passing a token with the git operation — it is used for that operation and not stored.

Thread naming

Agents name their own threads, so your thread list stays readable.

New threads start with a placeholder name. Once the agent understands what it is working on, it names the thread itself using a built-in tool — a thread that starts as an untitled session becomes "Fix flaky auth tests" without you doing anything.

You can always rename a thread manually in chat, and API consumers can set the title with a thread.title event.

Where to go next

Drive agents programmatically, or let them build scheduled apps.

• Agents API — create and drive threads from your own code: REST endpoints, streaming events, and webhooks.
• Apps — let an agent package recurring work as a scheduled, publishable app that keeps running after the conversation ends.