Quick Answer
OpenHands now exposes a Model Router choice in the editor for named agent profiles. Developers using a supported local backend can select a saved router or turn routing off for that profile. The default profile keeps its existing behavior: it launches with the router chosen on the global Model Router page.
PR #18685 merged on October 20, 2026. The official v1.29.0 release notes list the feature. This adds editor support for existing profile fields; it does not introduce a new routing algorithm.
In Plain English
An agent profile stores configuration used to launch an agent. A Model Router is a separately saved configuration that can direct tasks to LLM profiles. Selecting a router in an agent profile connects those two pieces: the agent configuration records which saved routing setup it should use.
Before this change, the underlying router fields and service already existed, but the profile editor did not expose the selection. Afterward, opening a named OpenHands profile on a supported local backend presents that choice. Changing it and saving records the enable flag and router reference together.
That distinction matters when reading the patch. OpenHands is making existing configuration editable through this screen, rather than creating profile routing from scratch. Router definitions remain managed on the Model Router page; this editor selects one for a named profile.
Code Evidence
The pinned capability implementation checks whether the active backend kind differs from cloud. Its comment explains that Cloud keeps routers in an organization store. The screen also excludes ACP agents, so the visible control is specifically for supported OpenHands profile editing.
The official diff shows a three-way save contract. A changed saved-router selection writes enable_classify_and_switch_llm_tool as true and meta_profile_ref as the selected name. Off writes false and null. An unchanged selection supplies undefined to the builder, which omits both fields.
This last case preserves existing routing configuration during unrelated edits. The profile-view mapping also passes stored router values into the editor, allowing it to open with the existing selection instead of treating every profile as newly configured.
The pinned route tests assert selection changes, Off, unchanged-field preservation, and hidden controls for Cloud and the default profile. They also cover an enabled router without a stored name: the editor displays “Alphabetically first router” without marking that existing state as changed. These tests were inspected, not executed for this article.
Why It Matters
The useful change is where a developer can express a configuration decision. A named profile can carry a particular saved router choice, while the default profile continues following the global selection. Developers can therefore configure different named profiles without replacing the default profile’s established relationship to the Model Router page.
For example, a developer maintaining two named profiles can select a different existing router in each editor. The patch supports saving those references; whether either configuration produces better task results depends on the routers and models involved.
The merge commit records 11 changed files, including implementation, translations, tests, and screenshots. That footprint helps frame the feature as an editor and persistence change. It supplies no measured evidence of faster execution, lower spending, stronger security, or improved model output.
An Open Question
If a named profile’s selected router is deleted later, should launching that profile continue to fail, or should OpenHands offer a documented fallback?
The PR describes the current behavior: the missing selection remains visible with a warning because it prevents launch. Keeping the reference visible makes the broken dependency available for correction. An official stale-router policy, paired with an integration test that removes the selected router and verifies the subsequent launch result, would resolve the question about intended behavior.
Scope and Limitations
This analysis compares the supplied parent revision with merge commit 3bf5e85c01dce3cc1a8ebdfce5cd801bd133dd27. It concerns editor support and persistence of existing router fields. Cloud does not receive this profile selector; the capability comment attributes that boundary to organization-level router storage. The default profile retains the global router behavior.
The PR timeline reports 15 passing upstream checks. That is an upstream result, not independent validation here. No tests, launch experiments, benchmarks, or model evaluations were run for this article.
The official sources were checked on October 21, 2026. Release notes confirm inclusion in v1.29.0, but the supplied research did not locate a separate official documentation page for this setting. The inspected warning test verifies displayed feedback, rather than demonstrating the complete missing-router launch path.