Get Started

Bring Your Own Infrastructure

Use all of Theazo, or just the parts you need. Plug your own compute provider, your own model API key, or run your existing agent framework inside Theazo sandboxes — paying only for the orchestration layer you actually use.

The 2x2 matrix

Theazo decomposes into two independent layers: compute (where agents run) and orchestration (how agents think and act). You control each axis independently. AgentCo configures two knobs: computeMode (managed or BYOI) and primitivesEnabled (true or false).

Compute →

Orchestration ↓

Managed compute

Theazo provisions sandboxes (E2B, Fly, Daytona)

Managed orchestration

Theazo runs the model loop + all primitives

Full Platform

Theazo handles everything. Zero provider accounts needed. Compute + model tokens + primitives all billed through Theazo. Highest operational simplicity.

Your orchestration

LangGraph, CrewAI, AutoGen, or your own loop

Infra-only

Your agent code runs inside Theazo sandboxes via agent.exec(). Theazo bills compute time only. Best early entry point — most urgent pain, simplest sale.

Compute →

Orchestration ↓

BYOI compute

Your E2B / Fly account, or your own infra via webhook

Managed orchestration

Theazo runs the model loop + all primitives

Primitives-only (BYOI)

Theazo orchestrates agents on your compute. You pay your provider directly. Theazo charges orchestration fees only. Best margin profile — ~90% software margin.

Your orchestration

LangGraph, CrewAI, AutoGen, or your own loop

Not a customer

If you own both layers, Theazo adds no value. Use E2B and LangGraph directly.

The Terraform analogy: Terraform doesn't care if you use AWS, GCP, or Azure — you bring your credentials, Terraform provides the orchestration. Theazo does the same for agent compute. Bring your E2B key, your Fly token, or let Theazo manage it. Either way, sessions, billing, limits, and observability work identically.

Compute provider buckets

Theazo routes compute through a ComputeProvider interface. All providers implement the same interface — create(), exec(), readFile(), writeFile(), destroy(). Three buckets determine which adapter is used.

Bucket 1 — API-based providers

Theazo builds and maintains the adapter. These providers have well-documented HTTP APIs. Currently available: E2B (done). Fly.io and Daytona are planned post-launch.

Each API-based provider has two sub-modes: Managed (Theazo's key, Theazo bills compute) and Direct BYOI (your key, you pay the provider directly, Theazo bills orchestration only). Same adapter code — only the credential source changes.

bucket1-e2b.ts
import { Theazo } from 'theazo'

// Managed — Theazo uses its own E2B account (zero config)
const theazo = new Theazo({ apiKey: 'th_live_...' })

// Direct BYOI — Theazo calls E2B using your key
// credentialRef points to a secret stored in the Theazo secrets vault
const theazo = new Theazo({
  apiKey: 'th_live_...',
  compute: {
    provider: 'e2b',
    credentialRef: 'e2b_key',  // PUT /v1/secrets/e2b_key first
  },
})

// Agents now provision on your E2B account, at your E2B rates
const session = await theazo.sessions.forUser('user_123')
const result  = await session.run('researcher', 'analyze competitor pricing')

Bucket 2 — Self-hosted orchestrators (webhook adapter)

For Kubernetes, Docker Swarm, ECS/Fargate, Nomad, or any self-managed cluster. Theazo cannot build a universal adapter — every K8s setup has different auth, networking, and ingress. Instead, Theazo provides a webhook adapter contract: you wrap your infra behind HTTP endpoints, Theazo calls those endpoints. Sessions, billing, limits, and observability all work identically regardless of what's behind the URL.

bucket2-webhook.ts
import { Theazo } from 'theazo'

const theazo = new Theazo({
  apiKey: 'th_live_...',
  compute: {
    provider: 'custom',
    endpoint: 'https://compute.agentco.com/sandbox',
    credentialRef: 'compute_token',  // PUT /v1/secrets/compute_token first
  },
})

Bucket 3 — Custom / proprietary

Same webhook adapter contract as Bucket 2. This covers bare metal SSH, custom VM APIs, niche providers, or any infra that doesn't fit elsewhere. This is the escape hatch — no matter what compute exists today or gets invented tomorrow, you can plug it in without Theazo shipping a new adapter.

Webhook compute contract

To use Bucket 2 or 3, expose these HTTP endpoints from your infrastructure. Theazo calls them as if they were a provider SDK. You handle the actual compute provisioning behind the contract.

Required endpoints

POST /create{ sandboxId, metadata }Provision a new sandbox. Receives { runtime, timeout, envVars }. Return a stable ID for subsequent calls.
POST /:id/exec{ stdout, stderr, exitCode }Execute a command in the sandbox identified by :id. Receives { command }. Block until complete.
GET /:id/files/:path{ content }Download a file from the sandbox filesystem. Content is base64-encoded.
DELETE /:id{ ok }Destroy the sandbox and release all resources. Called when the agent is destroyed or the session ends.

Optional endpoints

If an optional endpoint is not implemented, return 501 Not Implemented. Theazo detects this on first call and disables that capability for your provider — it won't call it again.

PUT /:id/files/:path{ ok }Upload a file to the sandbox. Content is base64-encoded in the request body.
GET /:id/files?dir=/{ entries[] }List files in a directory. Each entry: { name, size, isDir }.
POST /:id/ports/:port{ url }Expose a port and return a public URL. Used for browser and HTTP agents.
POST /:id/pause{ snapshotId }Snapshot and pause the sandbox. Called by agent.pause().
POST /:id/resume{ sandboxId }Restore from a snapshot. Receives { snapshotId }.
GET /:id/metrics{ cpuPercent, memoryMb, diskMb }Current resource usage. Surfaced in the Theazo observability dashboard.
GET /:id/logsSSE streamServer-Sent Events stream of log entries. Used for live log tailing.

Request authentication

Every request Theazo sends to your webhook endpoint includes three headers. Verify the signature before processing — reject requests with invalid signatures or timestamps older than 5 minutes to prevent replay attacks.

webhook-headers.txt
// Headers sent on every request from Theazo to your endpoint:
Authorization: Bearer {token}           // the credential from your secrets vault
X-Theazo-Signature: sha256={hmac}       // HMAC-SHA256 of request body with shared secret
X-Theazo-Timestamp: {unix_ms}           // for replay protection — reject if > 5min old
webhook-provider.ts
// Express.js — example webhook endpoint implementation
import express from 'express'
import crypto from 'crypto'

const app = express()
app.use(express.json())

const SHARED_SECRET = process.env.THEAZO_WEBHOOK_SECRET!

function verifySignature(body: string, sig: string, timestamp: string): boolean {
  const now = Date.now()
  const ts = parseInt(timestamp, 10)
  if (Math.abs(now - ts) > 5 * 60 * 1000) return false   // replay protection

  const expected = 'sha256=' + crypto
    .createHmac('sha256', SHARED_SECRET)
    .update(body)
    .digest('hex')

  return crypto.timingSafeEqual(Buffer.from(sig), Buffer.from(expected))
}

// POST /create — provision a new sandbox
app.post('/sandbox/create', async (req, res) => {
  const rawBody = JSON.stringify(req.body)
  const sig = req.headers['x-theazo-signature'] as string
  const ts  = req.headers['x-theazo-timestamp'] as string

  if (!verifySignature(rawBody, sig, ts)) {
    return res.status(401).json({ error: 'invalid_signature' })
  }

  const { runtime, timeout, envVars } = req.body

  // Your infra provisioning logic here:
  const sandboxId = await provisionContainer({ runtime, timeout, envVars })

  res.json({ sandboxId, metadata: { runtime } })
})

// POST /:id/exec — run a command
app.post('/sandbox/:id/exec', async (req, res) => {
  // ... verify signature, then:
  const { command } = req.body
  const result = await runInContainer(req.params.id, command)

  res.json({
    stdout:   result.stdout,
    stderr:   result.stderr,
    exitCode: result.exitCode,
  })
})

// DELETE /:id — destroy
app.delete('/sandbox/:id', async (req, res) => {
  await destroyContainer(req.params.id)
  res.json({ ok: true })
})
Store your shared secret in the Theazo secrets vault (PUT /v1/secrets/webhook_secret), then reference it via credentialRef: 'webhook_secret' in your SDK config. Theazo never logs request bodies to your webhook endpoint.

BYOI models

Theazo always makes the model call — guardrails, observability, and token attribution run in every mode. What changes is whose API key and which endpoint. Three modes:

Mode 1 — Managed (default)

Theazo calls Anthropic or OpenAI using Theazo's own API keys. Model tokens are billed to your Theazo account as pass-through + 10% markup. No provider account needed.

model-managed.ts
// No model config — Theazo uses its own Anthropic/OpenAI account
const theazo = new Theazo({ apiKey: 'th_live_...' })

const session = await theazo.sessions.forUser('user_123')
const result  = await session.run('researcher', 'summarize this report')
// result.cost includes compute + model tokens (billed to your Theazo account)

Mode 2 — Direct BYOI (your Anthropic / OpenAI key)

Theazo calls Anthropic or OpenAI using your API key. Token costs hit your provider account directly. Theazo records token counts for observability and attribution, but does not add a markup. Your Theazo bill shows $0 for model tokens.

model-direct-byoi.ts
import { Theazo } from 'theazo'

// Store your key in the secrets vault first:
// PUT /v1/secrets/anthropic_key  { value: 'sk-ant-...' }

const theazo = new Theazo({
  apiKey: 'th_live_...',
  models: {
    provider:      'anthropic',
    credentialRef: 'anthropic_key',   // references secrets vault entry
  },
})

// Per-session override — useful for multi-tenant setups where each customer
// has their own Anthropic account:
const session = await theazo.sessions.forUser('user_123', {
  models: {
    provider:      'openai',
    credentialRef: 'user_123_openai_key',
  },
})

Mode 3 — Gateway BYOI (any OpenAI-compatible endpoint)

Point Theazo at any URL that speaks the OpenAI /v1/chat/completions format. This covers OpenRouter (200+ models, one key), LiteLLM (self-hosted proxy), Azure OpenAI, vLLM or Ollama (self-hosted open-source), or any custom model gateway. Theazo treats it as an OpenAI-compatible endpoint — no model cost on your Theazo bill.

model-gateway-byoi.ts
import { Theazo } from 'theazo'

// OpenRouter — 200+ models behind one key
const theazo = new Theazo({
  apiKey: 'th_live_...',
  models: {
    provider:      'openai-compatible',
    endpoint:      'https://openrouter.ai/api/v1',
    credentialRef: 'openrouter_key',
    model:         'anthropic/claude-sonnet-4-5',
  },
})

// Azure OpenAI
const theazo = new Theazo({
  apiKey: 'th_live_...',
  models: {
    provider:      'openai-compatible',
    endpoint:      'https://my-org.openai.azure.com/openai/deployments/gpt-4o',
    credentialRef: 'azure_openai_key',
    model:         'gpt-4o',
  },
})

// Self-hosted vLLM or Ollama
const theazo = new Theazo({
  apiKey: 'th_live_...',
  models: {
    provider:      'openai-compatible',
    endpoint:      'http://my-gpu-server:8000/v1',
    credentialRef: 'vllm_key',   // or omit if no auth required
    model:         'meta-llama/Llama-3.1-70B-Instruct',
  },
})

Per-agent model override

Override the model on a per-agent or per-session basis. Useful when different agent roles need different models, or when you want to route specific workloads to cheaper or faster models.

per-agent-model.ts
// Per-agent override at creation time
const agent = await session.agents.create({
  definition: 'researcher',
  model: 'openai/gpt-4o',           // override the platform-level model config
})

// Or per-session — all agents in this session use this model
const session = await theazo.sessions.forUser('user_123', {
  models: {
    provider:      'openai-compatible',
    endpoint:      'https://openrouter.ai/api/v1',
    credentialRef: 'openrouter_key',
    model:         'google/gemini-flash-1.5',
  },
})

The credentialRef pattern

Credentials are never passed inline in SDK config or API requests — they live in the Theazo secrets vault (AES-256-GCM, per-platform HKDF key derivation). You store a secret once and reference it by name everywhere. Rotating a credential means updating one vault entry, not touching your code.

credential-ref.sh
# 1. Store the credential in the vault
curl https://api.theazo.com/v1/secrets/e2b_key \
  -X PUT \
  -H "Authorization: Bearer th_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "value": "e2b_sk_..." }'

# 2. Reference it by name in your SDK config (never the raw value)
# compute: { provider: 'e2b', credentialRef: 'e2b_key' }

# 3. To rotate: update the vault entry — no code changes required
curl https://api.theazo.com/v1/secrets/e2b_key \
  -X PUT \
  -H "Authorization: Bearer th_live_..." \
  -d '{ "value": "e2b_sk_new_..." }'

Provider config API

BYOI compute credentials can also be configured via the dashboard (Settings → Providers) or directly via the API. This is useful for onboarding flows where you want to collect a customer's provider credentials and register them programmatically.

provider-api.sh
# Register an E2B BYOI credential
curl https://api.theazo.com/v1/providers/e2b \
  -X PUT \
  -H "Authorization: Bearer th_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "credentialRef": "e2b_key",
    "mode": "byoi"
  }'

# Register a custom webhook provider
curl https://api.theazo.com/v1/providers/custom \
  -X PUT \
  -H "Authorization: Bearer th_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "endpoint":       "https://compute.agentco.com/sandbox",
    "credentialRef":  "compute_token",
    "mode":           "byoi"
  }'

Infra-only mode

You have an existing agent framework — LangGraph, CrewAI, AutoGen, or your own loop — and you want isolated, observable, multi-tenant compute without rewriting your orchestration. Use agent.exec() to run your code inside a Theazo sandbox. The sandbox is isolated and metered; your model calls go through your own provider directly.

infra-only.ts
import { Theazo } from 'theazo'

const theazo = new Theazo({ apiKey: 'th_live_...' })
const session = await theazo.sessions.forUser('user_123')
const agent   = await session.agents.create({ browser: false })

// Run your LangGraph agent code inside the isolated sandbox
const result = await agent.exec({
  lang: 'python',
  code: `
from langgraph.graph import StateGraph
from theazo_sandbox import log, span, complete

def researcher(state):
    log("Searching for information...")
    with span("fetch"):
        data = fetch_data(state["task"])
    return { "result": data }

graph = StateGraph(dict)
graph.add_node("researcher", researcher)
graph.set_entry_point("researcher")

app = graph.compile()
output = app.invoke({ "task": "analyze competitor pricing" })
complete(output["result"])
  `,
})

console.log(result.stdout)
console.log(result.cost)  // { amount: 8, currency: 'usd' } — compute time only
In infra-only mode (managedLoop: false), Theazo does not run the model loop. Your code calls your model API directly inside the sandbox. Theazo bills compute minutes only — no model token charges on your Theazo bill. Primitives (workflows, fleets, teams) are not available in this mode.

theazo-sandbox inside exec()

Install theazo-sandbox inside your agent's Python or TypeScript runtime to emit structured logs, progress updates, and trace spans back to the Theazo observability pipeline.

sandbox-sdk.py
# Install inside your exec() environment
pip install theazo-sandbox

from theazo_sandbox import log, span, progress, complete

log("Starting analysis", level="info")

with span("fetch_data"):
    data = fetch_competitor_pages()

progress(50, "Data fetched, now analyzing...")

with span("analyze"):
    result = analyze(data)

complete(result)   # signals successful completion to Theazo
log(msg, level?)voidEmit a structured log line. Appears in the Theazo Logs dashboard.
span(name)ContextManagerOpen a trace span. Use as a context manager.
progress(pct, label?)voidEmit a progress update (0–100). Surfaced in the agent status view.
complete(output)voidSignal successful completion and provide the final output to the caller.

Pricing impact by mode

What Theazo charges versus what your provider charges depends on your configuration. All cost objects in the SDK use integer cents — never strings.

Full Platform — managed compute + managed models

ComputeTheazo billPer-minute rate for sandbox uptime. Billed to your Theazo account at ~$0.05–0.15/hr per sandbox.
Model tokensTheazo billToken costs routed through Theazo's provider account. Pass-through + 10% markup.
PrimitivesTheazo billFlat orchestration fee per workflow run, fleet dispatch, approval cycle, scheduled execution.
StorageTheazo billPer-GB/month for snapshot and artifact storage.

BYOI compute + managed models

ComputeProvider billPaid directly to E2B / Fly / your infra at their rates. Theazo takes no compute cut.
Model tokensTheazo billSame as Full Platform — Theazo's provider account, pass-through + 10%.
PrimitivesTheazo billSame flat orchestration fee.
OrchestrationTheazo billSmall per-agent fee for session management, billing tracking, and observability.

BYOI compute + BYOI models (fully BYOI)

ComputeProvider billPaid directly to your compute provider.
Model tokensModel billPaid directly to Anthropic / OpenAI / gateway. Theazo records counts for attribution only.
PrimitivesTheazo billSame flat orchestration fee per primitive run.
OrchestrationTheazo billPer-agent orchestration fee — sessions, observability, limits enforcement.

Infra-only — managed compute, your orchestration

ComputeTheazo billPer-minute rate for sandbox uptime. Same rate as Full Platform.
Model tokensYour billYour orchestration calls your model API directly. Theazo is not in the model path.
PrimitivesN/APrimitives are not available in infra-only mode (managedLoop=false).
Regardless of mode, result.cost always reflects only what Theazo charged — not what your provider charged separately. Build your per-user billing by summing result.cost plus your provider invoices, allocated by session using the usage export API.

Why not use E2B directly?

If you use E2B (or any provider) directly, you own the full operational burden of multi-tenancy. Theazo adds the control plane on top.

CapabilityE2B aloneTheazo BYOI E2B
Isolated sandboxesYesYes
Per-user session isolationBuild itBuilt-in
Per-user cost trackingBuild itBuilt-in
Cost limits & auto-pauseBuild itBuilt-in
Structured observabilityBuild itBuilt-in
Webhooks on lifecycle eventsBuild itBuilt-in
Workflows & fleetsBuild itBuilt-in
Approvals / HITLBuild itBuilt-in
Multi-provider fallbackBuild itBuilt-in
Billing export (Stripe/CSV)Build itBuilt-in
Was this page helpful?
Ask anything...⌘I