You’ve been there: you hook a local vLLM server into Hermes, and a few turns in it announces “context full” — even though your model handles 8K or 128K tokens just fine. Or you switch to a freshly released model that clearly has vision, and Hermes insists “this model does not support images.” The problem usually isn’t the model — it’s that Hermes’ picture of the model comes from a model catalog, and your model isn’t in it, or the entry is stale. The good news: since v0.20.1 you can correct all of that directly in config.yaml with model_overrides, and tell Hermes exactly what your model is.

Why this happens: blind spots in the model catalog

Hermes decides what a model can do — how long its context window is, whether it supports tools, vision, or reasoning — mainly from models.dev, a public model catalog, plus some built-in fallback rules. That covers mainstream cloud models well, but it always has gaps:

• Local models: your vLLM, Ollama, or llama.cpp server uses model IDs you invented; they’re not in the catalog;
• Brand-new models: just released by a vendor, not yet cataloged;
• Stale entries: the context window is marked too small, capabilities are wrong, or the vendor shipped an update the catalog hasn’t caught up with.

In those cases Hermes falls back to “safe defaults”: unknown models get a 200K context estimate, tool calling on, but vision and reasoning off. When the guess is wrong, you get exactly the weird behavior from the opening — capabilities that exist are treated as missing, and context you paid for goes to waste.

The fix: model_overrides in config.yaml

model_overrides is a new top-level config section that shipped in v0.20.1 (PR #85560). Its job is simple: for a specific model under a specific provider, you declare the metadata by hand and it overrides the catalog. Like this:

model_overrides:
  custom:my-local-vllm:        # provider name, then the model ID
    my-llava-model:
      context_window: 8192     # this model's real context is 8K
      supports_vision: true    # it does accept images
    my-llama-model:
      context_window: 32768
      supports_tools: false    # tool calls are flaky here — turn them off
  upstage:                     # you can also fix cloud models
    solar-pro4:
      context_window: 524288   # not in the catalog; actually 512K

Restart Hermes after saving (edit with hermes config edit, then restart the session) and the overrides take effect. Only write the fields the catalog gets wrong or missing — anything you leave out keeps the catalog value, so you can’t accidentally break other settings.

The three fields you’ll use most

You rarely need all of them. In daily work it’s usually one of these:

• context_window: the model’s context length in tokens. Set it too low and conversations get cut off early; set it too high and the model rambles on oversized context — look up the real number where you can.
• supports_vision: whether the model accepts image input. This is the most common trap for local vision models (LLaVA-style): without the declaration, Hermes never offers you the ability to send images.
• supports_tools: whether the model can do tool calling. If a model is unreliable at tool use, it’s better to switch it off explicitly here than watch it fail repeatedly.

The full field list

model_overrides supports all of these fields, with the same meaning as model metadata:

Field	Meaning
context_window	Context length in tokens
max_output_tokens	Maximum output tokens per reply
supports_tools	Tool-calling support (default true for unknown models)
supports_vision	Image-input support (default false)
supports_reasoning	Reasoning-mode support (default false)
model_family	Model-family identifier used by fallback matching

_default: a safety net for uncataloged models

Writing every model by hand is tedious. You can set a _default per provider — or globally — as a fallback for models the catalog doesn’t know:

model_overrides:
  custom:my-vllm:
    _default:                  # applies only to uncataloged models
      context_window: 32768
  _default:                    # global fallback, gap-filling only
    context_window: 128000

_default is gap-filling by design: it only applies to models the catalog doesn’t know and never displaces catalog data for known ones. So a global default can’t accidentally clamp every model of a provider — known models keep their catalog values.

Two real-world scenarios

Scenario one: a local vision model. You’re serving a custom-ID model through vLLM and it does accept images. Without configuration, Hermes assumes it has no vision at all:

model_overrides:
  custom:my-vllm:
    my-llava-model:
      context_window: 8192
      supports_vision: true

Scenario two: a brand-new cloud model. Upstage’s solar-pro4 wasn’t in the catalog at launch, so the fallback rule treated it as 256K context when it actually has 512K. Declare it and you can use the full window:

model_overrides:
  upstage:
    solar-pro4:
      context_window: 524288

Things to know

• Provider names accept both spellings: the Hermes provider ID (e.g. custom:my-vllm) or the models.dev ID (e.g. github-copilot) — both are recognized.
• Model IDs match case-insensitively, mirroring catalog lookup.
• Bad values warn, never crash: a malformed value (say context_window: "512k") logs a warning, and the valid siblings still apply.
• Precedence: explicit entries win over models.dev / OpenRouter / built-in defaults; a per-model context_length set under custom_providers outranks everything, so it is never clobbered.
• This pairs perfectly with custom_providers (custom API endpoints) — local servers, proxy gateways, and in-house models all run on the same combination.

Wrap-up

Wrong model metadata is one of the sneakiest traps for local-model and new-model users: the capability is there, Hermes just doesn’t know about it. model_overrides exists precisely for that — no code changes, no waiting for a catalog refresh; declare a few lines in config.yaml and Hermes finally knows your model. If you haven’t explored custom model setup yet, the installation guide covers how to configure providers, and pip-installed model providers show a complementary way to introduce Hermes to new models.