Skip to content

feat(agent): support full OpenRouter provider routing options#246

Closed
gamedevCloudy wants to merge 3 commits into
NousResearch:mainfrom
gamedevCloudy:main
Closed

feat(agent): support full OpenRouter provider routing options#246
gamedevCloudy wants to merge 3 commits into
NousResearch:mainfrom
gamedevCloudy:main

Conversation

@gamedevCloudy

Copy link
Copy Markdown
Contributor

Implements: #238

Old:

  • The agent only supported a subset of OpenRouter's provider routing options (only, ignore, order, sort) via individual explicit parameters.
  • There was no way for CLI users to persistently configure provider routing preferences via config.yaml.

Changes:

  • Added openrouter_providers dictionary to AIAgent to natively support all OpenRouter provider kwargs (e.g., allow_fallbacks, data_collection, quantized, require_parameters).
  • Added an openrouter.provider block to DEFAULT_CONFIG in hermes_cli/config.py with bumped _config_version to 5 for auto-migration.
  • Updated cli.py to read the new config block and pass it to the agent.
  • Preserved legacy explicit parameters (providers_allowed, etc.) in _build_api_kwargs for backward compatibility with batch_runner.py and delegate_tool.py.

Expected:

  • CLI users can now globally define advanced OpenRouter routing behaviors (like disabling fallbacks or opting out of data collection) directly in their ~/.hermes/config.yaml.
  • Existing subagents and batch pipelines using explicit provider arguments continue to work identically without breaking.

Use of AI:

  • OpenCode used for support

gamedevCloudy and others added 3 commits March 1, 2026 14:06
Old:
- The agent only supported a subset of OpenRouter's provider routing options (`only`, `ignore`, `order`, `sort`) via individual explicit parameters.
- There was no way for CLI users to persistently configure provider routing preferences via `config.yaml`.

Changes:
- Added `openrouter_providers` dictionary to `AIAgent` to natively support all OpenRouter provider kwargs (e.g., `allow_fallbacks`, `data_collection`, `quantized`, `require_parameters`).
- Added an `openrouter.provider` block to `DEFAULT_CONFIG` in `hermes_cli/config.py` with bumped `_config_version` to 5 for auto-migration.
- Updated `cli.py` to read the new config block and pass it to the agent.
- Preserved legacy explicit parameters (`providers_allowed`, etc.) in `_build_api_kwargs` for backward compatibility with `batch_runner.py` and `delegate_tool.py`.

Expected:
- CLI users can now globally define advanced OpenRouter routing behaviors (like disabling fallbacks or opting out of data collection) directly in their `~/.hermes/config.yaml`.
- Existing subagents and batch pipelines using explicit provider arguments continue to work identically without breaking.
@gamedevCloudy gamedevCloudy marked this pull request as draft March 2, 2026 03:05
domvox pushed a commit to domvox/hermes-agent that referenced this pull request Mar 24, 2026
Add per-request ZDR enforcement via the OpenRouter provider preferences API.
When enabled, requests are restricted to only ZDR-compliant endpoints.

This complements the existing data_collection option with stricter privacy
control — while data_collection: deny blocks providers that train on data,
zdr: true blocks providers that retain data at all.

Configuration:
  provider_routing:
    zdr: true

Resolves NousResearch#238
Related to NousResearch#246 (closed/abandoned PR by gamedevCloudy)
@andrueandersoncs

Copy link
Copy Markdown

Starting work on this issue.

Branch: auto/issue-246-p0-adjustments-page-displays-only-20-of-availabl
Worktree: /Users/andrue/.hermes/worktrees/vantage/issue-246-p0-adjustments-page-displays-only-20-of-availabl

Investigation plan:

  1. Examine the Adjustments page to understand current directive display
  2. Find where rich directive content is generated but not displayed
  3. Expand the Current Plan card to show all directive sections:
    • Main directive (current)
    • "Do this first" section
    • "Do this next" section
    • "If things slip" fallback options
  4. Add timestamps and reasoning display
  5. Maintain clean visual hierarchy

Implementation notes:

  • Need to surface firstStep, nextStep, fallbackStep from directive content
  • Will ensure visual hierarchy isn't cluttered while adding richer content

@andrueandersoncs

Copy link
Copy Markdown

Implementation Complete

Fixed in commit: a53dbc7 on main

Changes Made

The Adjustments page now displays the full directive content that was previously only generated but not shown:

  1. Full directive sections displayed:

    • Main directive (summary title)
    • "Do this first" section with specific first action
    • "Do this next" section with follow-up actions
    • "Fallback if the day slips" section with backup options
  2. Visual hierarchy improvements:

    • Color-coded section indicators (primary dot for first step, amber for next step, muted for fallback)
    • Consistent card-based layout with proper spacing
    • Clear typography with uppercase tracking-wider labels
  3. Additional context added:

    • "Why this directive" reasoning section explaining the adaptation
    • Timestamp showing when the directive was last updated
    • History icon with relative time display

Technical Details

  • Changed from showing only todayRecommendation to displaying full directiveContent object
  • Updated both recovery mode and default plan state displays
  • Tests updated to verify new directive sections are rendered
  • All 478 tests pass, build clean

Before vs After

Before:

  • Status badge only
  • "Now" and "Next" grid with raw doFirst/doNext text
  • ~20% of available directive content visible

After:

  • Full directive with titled sections
  • Reasoning explanation
  • Fallback guidance
  • Timestamps
  • ~100% of directive content visible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants