Skip to main content
Astrolabe is built to be the easiest serious AI layer for OpenClaw:
  • one provider URL
  • one inbound key
  • virtual models instead of vendor juggling
  • routing, fallback, cost control, and safety policy handled centrally
Point OpenClaw at Astrolabe as a custom provider and use the Responses API.

​
Provider values

  • Base URL: http://localhost:3000/v1
  • API type: openai-responses
  • API key: same value as ASTROLABE_API_KEY
  • Primary model: astrolabe/auto

​
Why this is the default path

OpenClaw keeps its normal tool execution and UX layer. Astrolabe adds:
  • static lane manifests
  • m27 as the main workhorse
  • specialist promotion for kimiK25, kimiThinking, glm47Flash, and glm5
  • Responses-first compatibility
  • chat-completions compatibility for legacy clients
  • provider failover through OpenRouter
  • tool-policy and untrusted-content guardrails
  • sticky executor continuity across active sessions when OpenClaw sends the right metadata

​
Suggested model choices for OpenClaw

Most users should expose only Astrolabe virtual models inside OpenClaw:
  • astrolabe/auto
  • astrolabe/coding
  • astrolabe/research
  • astrolabe/vision
  • astrolabe/strict-json
  • astrolabe/cheap
  • astrolabe/safe
That keeps the OpenClaw config stable even when you update the raw roster behind those lanes.

​
Typical request flow

  1. OpenClaw sends a Responses request to Astrolabe.
  2. Astrolabe classifies category, complexity, and route modifiers.
  3. Astrolabe resolves a lane and candidate model set from its static manifest.
  4. Astrolabe executes against OpenRouter.
  5. Astrolabe verifies the result, checks tool policy, and may escalate once.
  6. OpenClaw receives the final response plus x-astrolabe-* routing headers.
Astrolabe stays stateless, so the best OpenClaw integration sends routing hints on each turn under metadata.astrolabe:
  • last_model
  • last_lane
  • session_phase
  • sticky_executor
  • tool_capabilities
  • allow_preview
Recommended defaults:
  • session_phase=active while the agent is in a real work loop
  • sticky_executor=true unless you intentionally want Astrolabe to re-pick aggressively
  • allow_preview=false unless you explicitly want preview research or vision branches
tool_capabilities should map tool names to capability labels like:
  • read_local
  • read_remote
  • workspace_write
  • remote_write
  • external_comms
  • credential_access
  • financial_or_destructive
  • code_exec
Astrolabe can infer some of this from tool names, but explicit metadata gives you a much safer policy surface.

​
Cross-session continuity

Astrolabe OSS is stateless. If you open a brand new OpenClaw session, Astrolabe will only see whatever OpenClaw sends in that new request. That means:
  • seeing an older transcript in the OpenClaw UI does not by itself make the model remember it
  • staying in the same session preserves conversational context because OpenClaw keeps sending prior turns
  • starting a different session requires OpenClaw memory, not Astrolabe state
For cross-session recall in OpenClaw:
  • keep using the same session when you want short-term conversational continuity
  • enable the bundled session-memory hook so /new and /reset save session summaries into memory
  • configure OpenClaw memory/session retrieval so new sessions can load relevant prior memories, not just display old transcripts in the UI
Astrolabe should remain stateless in OSS. The right place to solve cross-session memory is OpenClaw’s memory and session bootstrap layer.

​
What to inspect in debugging

When a turn behaves unexpectedly, inspect:
  • x-astrolabe-category
  • x-astrolabe-lane
  • x-astrolabe-initial-model
  • x-astrolabe-final-model
  • x-astrolabe-route-label
  • x-astrolabe-escalated
  • x-astrolabe-sticky-applied
  • x-astrolabe-sticky-reason
  • x-astrolabe-verification-skipped
  • x-astrolabe-transport-fallback-only
For JSON responses, also inspect the inline astrolabe metadata block.

​
Notes

  • POST /v1/responses is the primary API.
  • POST /v1/chat/completions still works for compatibility.
  • If you are handling untrusted content with tools enabled, keep Astrolabe’s safety gate on.
  • In production, set ASTROLABE_API_KEY. Astrolabe refuses to start in production without it.