Skip to main content
Astrolabe is the decision layer between OpenClaw and OpenRouter. It does not just forward requests. It classifies the work, chooses a lane, picks the cheapest acceptable candidate set, enforces safety rules, and only then executes upstream.

​
Request lifecycle

For each request:
  1. normalize the request into a shared internal format
  2. extract conversation and tool features
  3. detect high-stakes signals
  4. classify category and complexity
  5. derive route modifiers such as multimodal, tool_heavy, or strict_json
  6. choose a lane
  7. select candidates from the static manifest
  8. execute against OpenRouter
  9. verify non-stream results and optionally escalate once
  10. inspect outbound tool calls before returning them

​
Primary interface

Astrolabe is now Responses-first:
  • POST /v1/responses is the primary endpoint
  • POST /v1/chat/completions is a compatibility adapter
Both endpoints run through the same routing engine.

​
Workhorse and specialists

  • m27 is the default workhorse
  • m25 is strict-budget and fallback only
  • kimiK25 handles multimodal work
  • kimiThinking handles deeper research/planning
  • glm5 handles strict JSON and tool/schema-sensitive requests
  • sonnet and opus own the safe lane

​
Safety model

Astrolabe adds policy on top of raw model execution:
  • high-stakes confirmation mode
  • untrusted-content safety floors
  • tool-call approval or blocking
  • URL allowlists for Responses file/image inputs

​
Transparency

Astrolabe exposes its behavior through:
  • GET /v1/models
  • GET /v1/lanes
  • x-astrolabe-* headers
  • inline Astrolabe metadata on JSON responses