RLM data sources

Choose a data source based on where the data lives and where the RLM runtime should execute. The available data-source types are not identical between local and hosted execution.

Availability

Local SQLite

Use --db to expose a SQLite database as a read-only data source:

mrl rlm \
  "Compare monthly revenue by plan and explain the largest changes" \
  --db ./billing.db

The default sandbox name is db. Change it when the name carries useful meaning:

mrl rlm "Find suspicious refunds" \
  --db ./commerce.db \
  --db-name commerce

--sql-profile applies a configured SQL policy. Without one, the CLI uses its default permissive read-only policy. In local mode this policy is a guardrail, not a confidentiality boundary: generated Python runs on the same machine and can open files the current user can read. Point local RLM only at a database the caller may fully inspect, and use a restricted copy or view when sensitive tables must be excluded.

SQLite support is available today. Do not generalize this command to Postgres, MySQL, Snowflake, or BigQuery; those require a runtime or adapter deployed beside the database.

Local files

Attach one or more local files:

mrl rlm "Summarize the recurring incident patterns" \
  -a ./incidents/*.md \
  -a ./service-map.json

Piped stdin is automatically attached when no explicit attachment is supplied:

git log --stat --since="3 months ago" | \
  mrl rlm "Which areas changed most, and what risks follow?"

Attachments are represented in context["files"]. Small text files include an inline text field; larger inputs can be loaded from their local path by the local runtime.

Inline JSON

Hosted /rlm/execute accepts arbitrary JSON in context:

curl https://api.modelrelay.ai/api/v1/rlm/execute \
  -H "Authorization: Bearer $MODELRELAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "query": "Find the changes that need follow-up",
    "context": {"events": [{"kind": "deployment", "status": "failed"}]}
  }'

Use this path for application-owned data already available in memory and small enough to send with a request.

Uploaded context

Upload larger, reusable JSON once with POST /rlm/context, then pass its UUID as context_ref to multiple executions. Context handles are immutable, scoped to their owner, and expire after their configured TTL.

See Create Context Handle for exact limits and request fields.

Hosted wrapper_v1

For hosted access to an external system, run an HTTPS wrapper in your own infrastructure. The wrapper keeps its database credentials or OAuth tokens and exposes three resource-oriented operations:

Then provide its URL and a short-lived bearer token:

{
  "model": "claude-sonnet-4-5",
  "query": "Compare the renewal risks across these contracts",
  "data_source": {
    "type": "wrapper_v1",
    "base_url": "https://data.example.com/modelrelay",
    "token": "short_lived_session_token",
    "limits": {
      "timeout_ms": 15000,
      "max_requests": 20,
      "max_response_bytes": 1048576
    }
  }
}

Hosted base_url values must use HTTPS and cannot resolve to localhost or a private IP. Use a private ModelRelay deployment when the adapter must remain on a private network.

The complete endpoint schema and security requirements are in the wrapper_v1 contract.

Choosing a source

• Start with local SQLite for a prototype over structured data.
• Use attachments for local files, exports, logs, and document collections.
• Use inline JSON or a context handle when your backend already has the data.
• Use wrapper_v1 when hosted RLM needs controlled access to a SaaS API or customer-hosted dataset.
• Use a private deployment when credentials and data access must remain inside a VPC.