Agent-native · API-first

An agent runtime your other agents can call.

Orbita is not a chat app for humans. It is a session-based HTTP API for AI orchestrators — structured turns, scoped memory, tools, trajectory, and scheduling without WhatsApp bridges or desktop GUIs.

Get started Live API health 
# Create session → send structured turn
curl -X POST $API/v1/sessions \
  -H "Authorization: Bearer $KEY" \
  -H "x-orbita-client-id: my-project" \
  -d '{"agent_profile":"default"}'

curl -X POST $API/v1/sessions/$ID/messages \
  -H "Authorization: Bearer $KEY" \
  -H "x-orbita-client-id: my-project" \
  -d '{"input":{"type":"text","text":"..."}}'

Why another agent system?

Mature agent frameworks optimize for humans in chat channels. Orbita optimizes for machines as clients — the same way you would design an internal platform API, not a product landing page with a text box.

Orbita is for

  • Cursor / Claude Code / custom orchestrators calling HTTP
  • Structured JSON intents and tool loops
  • Per-client memory, credentials vault, audit trajectory
  • Stateless replicas + Postgres/pgvector backend

Orbita is not

  • A WhatsApp / Slack / Telegram gateway
  • A human chat UI or voice assistant shell
  • OpenClaw (Jacky's separate orchestration stack)
  • The public openclaw/openclaw personal-assistant repo

What you get

TypeScript monorepo — lane packages composed into a single API host. MiniMax-M3 primary, Anthropic failover, Zeabur deploy from main.

Sessions & profiles

Session-bound agent profiles with static skills. Create, message, compress context, end — all over REST.

Memory & tools

pgvector semantic memory per client_id. Tool registry (HTTP, JSON helpers) with credential references, not inline secrets.

Trajectory & jobs

Structured execution log per session, replay API, cron/webhook scheduler, per-key rate limits.

Identity model

API key + allowed client_id allow-list. Memory and sessions scoped to the declared client, enforced server-side.

Quick start

Clone the repo, run Postgres locally, set env vars, and hit /v1/health. Production API: api.get-orbita.com.

  1. Install & database pnpm install · docker compose up -d postgres
  2. Configure environment Copy .env.example — DATABASE_URL, ORBITA_ADMIN_TOKEN, ORBITA_SECRETS_KEY, LLM keys.
  3. Run API pnpm dev → http://127.0.0.1:3000/v1/health
  4. Admin console Open /admin — create API keys, credentials, HTTP domain policy. See docs/self-host.md.
  5. Create an API key Admin console or POST /v1/admin/api-keys; bind allowed_client_ids.
  6. Verify ./scripts/agent-verify.sh · ./scripts/smoke-prod.sh for production.

Examples

Typical flows after self-hosting or using the production API. Replace API_KEY and CLIENT_ID with your values.

Echo tool

Create a session, send a message that uses the echo tool, then read trajectory.

POST /v1/sessions {"agent_profile":"default"}
POST /v1/sessions/{id}/messages
  "Use echo with text HELLO"
GET /v1/sessions/{id}/trajectory

Research + HTTP

Use research profile with http_get on allowed domains. Store API keys in the credential vault via /admin.

Memory

PUT /v1/memories/{key} then query in later sessions under the same client_id.

HTTP surface (v1)

OpenAPI at /v1/openapi.json. Auth: Authorization: Bearer <api_key> and x-orbita-client-id on every request.

Core

GET /v1/health · POST/GET /v1/sessions · POST /v1/sessions/{id}/messages

Memory & admin

PUT/GET /v1/memories · POST /v1/admin/api-keys · credentials vault

Observability

GET /v1/sessions/{id}/trajectory · GET /v1/sessions/{id}/trajectory/replay

Full design spec: ORBITA_DESIGN.md · Architecture: product-architecture.md