Problem or Use Case

OpenAI GPT models that use the Responses API support a text.verbosity request parameter with values such as low, medium, and high. This lets users control how terse or expansive the model’s final natural-language responses should be without rewriting prompts or changing reasoning effort.

Hermes currently exposes related-but-different controls:

• agent.reasoning_effort controls thinking/reasoning behavior.
• agent.verbose / display verbosity controls Hermes UI/tool-progress output.
• /fast / agent.service_tier controls service tier / priority behavior.

None of these configure OpenAI’s text.verbosity.

This creates a gap for OpenAI GPT users who want Hermes to be consistently concise or consistently detailed at the model-response level. For example, I may want a gateway or Discord/Telegram Hermes instance to use low verbosity by default so answers stay short, while still preserving high reasoning effort for correctness.

This feature is specifically OpenAI/Responses-API-oriented. It should not imply that every provider supports the same parameter, and Hermes should avoid sending unsupported provider-specific request fields to non-OpenAI backends.

Proposed Solution

Add a first-class configuration option for OpenAI Responses API text verbosity, likely near the existing agent-level generation controls:

agent:
  text_verbosity: ""  # empty/default = provider default; options: low, medium, high

Recommended behavior:

• Accept only "", low, medium, and high.
• Empty/unset should omit the request field and preserve current behavior.
• When set and the active transport/provider supports OpenAI Responses API text.verbosity, include the following top-level request field:

{
  "text": {
    "verbosity": "low"
  }
}

• Do not send this field to providers/transports that do not support it.
• Document clearly that this is currently an OpenAI GPT / Responses API feature, not a universal verbosity setting.
• Keep it separate from:
  • agent.reasoning_effort, because verbosity changes answer length/detail, not reasoning depth.
  • display.* or agent.verbose, because those affect Hermes UI/log/tool progress verbosity, not model output.
  • prompt/personality configuration, because this is a provider-native request parameter.

High-level implementation guidance:

1. Add agent.text_verbosity to the default config and config documentation.
2. Add a small parser/validator similar in spirit to the existing service-tier or reasoning-effort parsing.
3. Load the value in CLI and gateway startup paths alongside reasoning_config / service_tier.
4. When building request overrides for a turn, merge the verbosity setting into the request overrides only when appropriate.
5. In the Responses API transport, ensure the resulting request includes top-level text: {"verbosity": <value>}.
6. Avoid using extra_body for this in the Responses API path; OpenAI expects text as a top-level Responses API field.
7. Add tests that verify:
   • unset/empty config preserves current request payloads;
   • low, medium, and high are accepted;
   • invalid values are ignored or warned about;
   • OpenAI Responses payloads include text.verbosity;
   • non-supporting providers do not receive the OpenAI-specific field.

A possible implementation detail is to reuse the existing request_overrides plumbing, since the Responses transport already merges top-level request overrides. Care should be taken to merge with any existing request overrides, such as service-tier / fast-mode overrides, rather than replacing them.

Alternatives Considered

1. Use prompting/personality instructions such as “be concise.”

   This works partially, but it is less reliable and mixes provider-native generation controls into the system prompt. OpenAI provides text.verbosity specifically so callers can control output detail without changing prompts.

2. Use raw extra_body configuration.

   This is lower-level and error-prone, and for the Responses API the correct shape is a top-level text field rather than chat-completions-style extra_body. A first-class config option would be safer and clearer.

Feature Type

Configuration option

Scope

Medium (few files, < 300 lines)

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)