Completion runtime drops provider reasoning controls #185

New issue

Closed

opened 2026-08-25 02:55:25 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-25 02:55:25 +00:00

(Migrated from github.com)

Integration finding

Auto-Dig's new expert model router needs to select both a model and reasoning effort (for example openai/gpt-5.6-luna with reasoning.effort=max). The OpenAI-compatible transport already allows a reasoning generation field, but the completion runtime currently constructs request options with only token and temperature fields.

At pinned runtime 982bad23c59dba0dd9157c1904e7723950889717:

rlm_openai_compatible:allowed_generation_options/2 includes reasoning;
rlm_completion:planner_request_options/3 emits only max_tokens and temperature;
rlm_completion:model_request_options/3 emits only max_tokens and temperature;
the CLI therefore has no end-to-end way to request Luna Max through rlm/direct.

Desired contract

Completion options can carry an explicit, closed reasoning control without allowing arbitrary provider payload injection.
Direct model calls and recursive child model calls receive the selected reasoning control.
Planner reasoning can be controlled independently, with an explicit inheritance/default rule.
CLI exposes a bounded enum such as --reasoning-effort none|low|medium|high|xhigh|max and optionally --planner-reasoning-effort ....
Deterministic tests prove the reasoning dict reaches the trusted provider request for direct, planner, and recursive paths.
Existing callers remain backward compatible when no reasoning option is supplied.

Why this matters

This blocks task-aware expert routing from selecting a model configuration rather than only a model ID. It was found by the Auto-Dig GitHub Actions integration while attempting to make Luna Max the default bounded worker route.

## Integration finding Auto-Dig's new expert model router needs to select both a model and reasoning effort (for example `openai/gpt-5.6-luna` with `reasoning.effort=max`). The OpenAI-compatible transport already allows a `reasoning` generation field, but the completion runtime currently constructs request options with only token and temperature fields. At pinned runtime `982bad23c59dba0dd9157c1904e7723950889717`: - `rlm_openai_compatible:allowed_generation_options/2` includes `reasoning`; - `rlm_completion:planner_request_options/3` emits only `max_tokens` and `temperature`; - `rlm_completion:model_request_options/3` emits only `max_tokens` and `temperature`; - the CLI therefore has no end-to-end way to request Luna Max through `rlm`/`direct`. ## Desired contract 1. Completion options can carry an explicit, closed reasoning control without allowing arbitrary provider payload injection. 2. Direct model calls and recursive child model calls receive the selected reasoning control. 3. Planner reasoning can be controlled independently, with an explicit inheritance/default rule. 4. CLI exposes a bounded enum such as `--reasoning-effort none|low|medium|high|xhigh|max` and optionally `--planner-reasoning-effort ...`. 5. Deterministic tests prove the reasoning dict reaches the trusted provider request for direct, planner, and recursive paths. 6. Existing callers remain backward compatible when no reasoning option is supplied. ## Why this matters This blocks task-aware expert routing from selecting a model configuration rather than only a model ID. It was found by the Auto-Dig GitHub Actions integration while attempting to make Luna Max the default bounded worker route.