Host-controlled runtime policy: model, budgets, recursion limits, capabilities, and timeouts

[axel-havard]

Summary

To embed predict-rlm cleanly inside larger agent systems, the host needs to control runtime policy rather than the runtime owning those choices internally.

Problem

Many external systems already have their own logic for:

• model selection
• budget allocation
• timeout policy
• recursion depth limits
• capability permissions
• risk/approval levels

If predict-rlm hardcodes or strongly owns those decisions, it becomes harder to adopt as a runtime backend.

Proposed direction

Expose these as caller-controlled configuration inputs:

• model choice
• max recursion depth
• max steps
• token budget
• timeout budget
• capability allowlist
• mount configuration
• optional approval/policy callbacks

Why this matters

A runtime should be pluggable into a larger control plane.

The embedding host may want:

• cheap model for low-risk runs
• stronger model for hard branches
• tighter depth limits for background jobs
• different capabilities for research vs coding tasks

Acceptance criteria

• runtime policy is externally configurable per run
• capability and mount configuration are caller-owned
• model/budget settings are externally supplied
• docs include one example of host-side policy injection