hermes - ✅(Solved) Fix image_gen openai plugin: API_MODEL hardcoded, breaks third-party OpenAI-compatible backends [1 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
NousResearch/hermes-agent#18793Fetched 2026-05-03 04:54:16
View on GitHub
Comments
1
Participants
1
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
labeled ×3commented ×1cross-referenced ×1

Root Cause

  • Third-party providers that follow the OpenAI /v1/images/generations spec but have different model names cannot be used because the model name is not configurable.
  • The three-tier low/medium/high system only affects the quality parameter, not the model name sent to the API.
  • Users routing through OPENAI_BASE_URL to a compatible backend get the wrong model name.

Fix Action

Fixed

PR fix notes

PR #18796: fix(plugins): support OPENAI_IMAGE_API_MODEL env var + base_url config for third-party backends

Description (problem / solution / changelog)

Problem

The OpenAI image gen plugin hardcodes API_MODEL = "gpt-image-2" in the API request payload, making it impossible to use third-party OpenAI-compatible backends (e.g., Krill AI, OpenRouter image endpoints) that expect different model identifiers.

# Before this PR — always sends "gpt-image-2" regardless of config
payload = {"model": API_MODEL, ...}
client = openai.OpenAI()  # no base_url support from config

Closes #18793

Solution

Three new escape hatches, fully backward-compatible — defaults unchanged:

API model override

PrioritySource
1OPENAI_IMAGE_API_MODEL env var
2image_gen.openai.api_model config key
3API_MODEL (default: gpt-image-2)

Base URL

PrioritySource
1OPENAI_BASE_URL env var (standard SDK behaviour)
2image_gen.openai.base_url config key
3None → api.openai.com

Usage example (Krill AI)

# config.yaml
image_gen:
  provider: openai
  openai:
    api_model: gpt-image-2-1k-medium
    base_url: https://api.krill-ai.com/v1

Or via env var:

export OPENAI_IMAGE_API_MODEL=gpt-image-2-1k-medium

Changes

  • Added _resolve_api_model() — resolves the model name for the API request
  • Added _resolve_base_url() — resolves the base URL for the OpenAI client
  • Updated generate() to use resolved values instead of hardcoded constants
  • Updated module docstring with new precedence rules

No breaking changes. Default behaviour unchanged.

Changed files

  • plugins/image_gen/openai/__init__.py (modified, +68/-4)

Code Example

API_MODEL = "gpt-image-2"

payload = {
    "model": API_MODEL,   # always "gpt-image-2", regardless of config
    ...
}
RAW_BUFFERClick to expand / collapse

Problem

The new plugins/image_gen/openai/__init__.py (from PR #13799) has a hardcoded API_MODEL:

API_MODEL = "gpt-image-2"

payload = {
    "model": API_MODEL,   # always "gpt-image-2", regardless of config
    ...
}

This means if a user sets image_gen.model: gpt-image-2-1k or uses a third-party OpenAI-compatible backend (e.g., Krill, OpenRouter image endpoints, local proxies) where the model name is different, the request still sends "model": "gpt-image-2".

Why this matters

  • Third-party providers that follow the OpenAI /v1/images/generations spec but have different model names cannot be used because the model name is not configurable.
  • The three-tier low/medium/high system only affects the quality parameter, not the model name sent to the API.
  • Users routing through OPENAI_BASE_URL to a compatible backend get the wrong model name.

Expected behavior

The plugin should respect the model ID from config — either by using it directly as the API model, or by providing a mechanism to override API_MODEL.

Proposed solution

Option A: Allow image_gen.openai.model to serve as the actual model field in the API request when it is not one of the three recognized tier IDs.

Option B: Add an image_gen.openai.api_model config key that overrides API_MODEL.

Option C: Read OPENAI_IMAGE_MODEL_NAME env var as escape hatch for the API model name.


Discovered while trying to use Krill AI as an image backend, which supports gpt-image-2 via OpenAI-compatible API but uses different model identifiers.

extent analysis

TL;DR

To fix the issue, make the API_MODEL configurable to respect the model ID from the config, allowing compatibility with third-party OpenAI backends.

Guidance

  • Identify the desired model name configuration approach: either use image_gen.openai.model directly, introduce an image_gen.openai.api_model config key, or utilize the OPENAI_IMAGE_MODEL_NAME environment variable.
  • Update the payload dictionary in __init__.py to use the chosen configurable model name instead of the hardcoded API_MODEL.
  • Verify that the updated code correctly sends the intended model name in the API request when using different backends or configurations.
  • Test the fix with Krill AI and other third-party providers to ensure compatibility.

Example

# Option A: Use image_gen.openai.model directly
payload = {
    "model": config.get("image_gen.openai.model", "gpt-image-2"),
    ...
}

# Option B: Introduce image_gen.openai.api_model config key
payload = {
    "model": config.get("image_gen.openai.api_model", "gpt-image-2"),
    ...
}

# Option C: Use OPENAI_IMAGE_MODEL_NAME environment variable
import os
payload = {
    "model": os.environ.get("OPENAI_IMAGE_MODEL_NAME", "gpt-image-2"),
    ...
}

Notes

The best approach depends on the specific requirements and constraints of the project. Options A, B, and C offer different ways to make the API_MODEL configurable, and the chosen solution should be tested thoroughly to ensure compatibility with various backends and configurations.

Recommendation

Apply workaround by introducing an image_gen.openai.api_model config key (Option B), as it provides a clear and explicit way to override the default API_MODEL while maintaining backward compatibility.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The plugin should respect the model ID from config — either by using it directly as the API model, or by providing a mechanism to override API_MODEL.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING