The Hermes Model Family by Version: From Nous-Hermes 13B to Hermes 4.3

The Hermes models are Nous Research's open-weight fine-tunes of other labs' base models, released from June 2023 (Nous-Hermes-13b on LLaMA 13B) to December 2025 (Hermes 4.3, on ByteDance's Seed-OSS-36B-Base). Each generation changed the base, the data and the training method, and each inherits terms from its base. Record a Hermes model by exact repo, revision, base and licence, never as just "Hermes".

That last point is the reason a security team should care about a model family's history. "We use Hermes" can mean a 2023 LLaMA fine-tune whose base weights carried a non-commercial licence, a Llama 3.1 derivative with Meta's attribution and naming clauses, or an Apache-2.0 model trained across the internet on a decentralised network. It can also mean Hermes Agent, which is a different product altogether. This guide walks through every generation with dated sources, explains what changed and why the Hermes tool-call format ended up inside inference servers, and finishes with a step by step way to pin, verify and inventory a Hermes model.

Key takeaways

• Five generations, many bases. Nous-Hermes (LLaMA 1, 2023), Nous-Hermes Llama 2 (2023), Nous-Hermes 2 on Yi, Mixtral, SOLAR, Mistral and Llama 2 (late 2023 to early 2024), Hermes 2 Pro and Theta (2024), Hermes 3 on Llama 3.1 and 3.2 (2024), DeepHermes 3 (2025), Hermes 4 on Llama 3.1 and Qwen3 (August 2025) and Hermes 4.3 on Seed-OSS-36B (December 2025). No Hermes 5 appeared on Hugging Face or the Nous releases page when we checked on 23 October 2026.
• Training moved from supervised fine-tuning to verified reasoning data. Hermes 3 used about 390 million tokens of supervised data, with a DPO pass kept only for the 8B model. Hermes 4 used about 5 million samples and 19 billion tokens, much of it rejection sampled against roughly a thousand verifiers, according to the Hermes 4 Technical Report.
• Hermes 2 Pro made the tool-call format stick. Its <tools> and <tool_call> structure inside ChatML is what vLLM's --tool-call-parser hermes parses, and vLLM documents that some other model families use the same Hermes-style template.
• The Hugging Face licence tag is not the licence. Several Hermes repos carry tags (GPL, MIT, Apache-2.0) that do not match the base model's terms. The base licence travels with the weights.
• Hermes 4.3 was post-trained on Psyche. Nous says it trained the model twice, once centrally and once on its Psyche network using the DisTrO optimizer, and that the Psyche version did better on its own downstream suite. That is a self-reported result.
• Inventory the model like any other dependency. Pin the Hugging Face commit, record per-file SHA-256 hashes, record the full base model lineage including merges and quantised variants, and keep the serving stack (vLLM or llama.cpp, transformers, tokenizers) in your SBOM, because that code is what receives CVEs.

Hermes models and Hermes Agent are different things

People search for "Hermes" and land on several unrelated projects, so it is worth separating them first.

The Hermes models are the subject of this post: open-weight language models that Nous Research builds by fine-tuning or post-training a base model from another lab. You download weights from Hugging Face and serve them yourself, or call them through a hosted API.

Hermes Agent is Nous Research's open source agent harness, listed on the Nous releases page on 25 February 2026 and at release v0.22.5 on GitHub when we checked on 23 October 2026. It is model agnostic: its README tells users to "use any model you want" and switch with hermes model. You can run Hermes Agent on a Hermes model, but you can just as easily run it on another provider's model, and you can run a Hermes model with no agent at all. Two CVE records exist for Hermes Agent, which we covered in CVE-2026-71963 and CVE-2026-85105; neither is about the models.

Hermes the JavaScript engine for React Native is unrelated to Nous Research, and so is the IBC relayer of the same name. If you came for the JavaScript engine, see why Hermes bytecode is not protection.

How we dated each release

Nous Research keeps a releases page at nousresearch.com/releases that lists models, papers, datasets and frameworks with dates. Where a model is on that page, we use that date. Where it is not, we use the Hugging Face repository creation date from the Hugging Face API, and we say so. The two often disagree by days or weeks, because a repository can be created, filled and kept private before a public announcement. The Hermes 3 405B repository, for example, was created on 13 August 2024, while the releases page lists the model on 24 August 2024. In one case the order is reversed: the releases page lists Hermes 4 14B on 26 August 2025, but the current Hugging Face repository for it was created on 30 August 2025.

Licence tags in the table come from the Hugging Face API on 23 October 2026. They are what the repository owner typed into the model card metadata, which is why the next sections spend time on what the base licence actually says.

The full Hermes timeline

Sources for every row are listed at the end. Two things stand out. First, the base model changed almost every generation, which means the licence and the architecture changed too. Second, the version names do not tell you the base: "Hermes 4" covers two Llama 3.1 models and a Qwen3 model, and "Hermes 4.3" is a different base again.

Generation 1: Nous-Hermes 13B on the first LLaMA

What was the first Nous-Hermes model?

The first was Nous-Hermes-13b, whose Hugging Face repository was created on 3 June 2023. Its model card describes a LLaMA 13B fine-tune on "over 300,000 instructions", led by Teknium and Karan4D, with compute sponsored by Redmond AI. Training used a 2,000 token sequence length on an eight GPU A100 80GB machine for "over 50 hours", per the card.

What data did it use?

The card says the model "was trained almost entirely on synthetic" outputs from a commercial model, gathered from community datasets: GPTeacher, a Nous Instruct set and an unpublished PDACTL set, CodeAlpaca, an Evol-Instruct derivative, GPT4-LLM, Unnatural Instructions, Camel-AI's domain datasets and the Airoboros dataset. This was the standard recipe of mid-2023 open models: distil instruction following from a stronger hosted model into an open base.

That matters for an inventory in a way people tend to skip. A dataset distilled from another provider's model carries a question about that provider's terms at the time, separate from the base model's licence. Your record should say "synthetic data distilled from a hosted model, per the model card" so your counsel can decide whether it matters for your use.

What prompt format did it use?

The Alpaca format: an ### Instruction: block, an optional ### Input: block and a ### Response: block. This is worth noting because Hermes 2 switched to ChatML, and serving an old Hermes with a ChatML template (or the reverse) quietly degrades output.

What licence applied?

The repository is tagged gpl. That tag does not describe the weights' terms. Meta's LLaMA (version 1) model card lists the licence as a "Non-commercial bespoke license", while the LLaMA repository's code was under GPL-3.0. A fine-tune of LLaMA 1 weights inherits the weight terms. If anything in your estate still loads Nous-Hermes-13b, treat it as non-commercial research use unless your counsel says otherwise, whatever the tag says.

Generation 1.5: Nous-Hermes on Llama 2

Llama 2 arrived in July 2023 under a licence that allowed commercial use, and Nous retrained Hermes on it within days. The releases page lists Nous-Hermes-Llama2-13b on 21 July 2023. The card says the model "uses the exact same dataset as Hermes on Llama-1", to keep behaviour consistent, with a 4,096 token training length. 7B and 70B versions followed in late July and August 2023.

The licence tag on all three repositories is mit. Again, the base terms are what travel. The Llama 2 Community License includes a clause requiring a separate licence from Meta for any licensee whose products had more than 700 million monthly active users in the preceding calendar month, and clause v says you will not use Llama materials or their outputs "to improve any other large language model" except Llama 2 and its derivatives. The GGML quantisation of the 13B model, created a day later, is tagged llama2, so the same family has two different licence tags depending on which repository you pulled.

Generation 2: Nous-Hermes 2 on many bases

What changed with Nous-Hermes 2?

Three things changed at once: the data, the format and the choice of bases.

• Data. The Hermes 2 cards say the models were trained on about 1,000,000 entries of primarily synthetic data from a commercial model plus open datasets, and they list teknium/OpenHermes-2.5 as the dataset. That is roughly three times the instruction count of the first Hermes.
• Format. Hermes 2 moved to ChatML, the <|im_start|> and <|im_end|> role format with explicit system, user and assistant roles. A real system role is what later made steerable, tool-using Hermes models possible.
• Bases. Instead of following one base, Nous released Hermes 2 on whatever strong open base had just appeared: Yi-34B in December 2023, SOLAR-10.7B on 1 January 2024, Mixtral 8x7B on 15 January 2024, Llama 2 70B later in January and Mistral 7B in February.

What did SFT versus DPO mean for Mixtral Hermes 2?

For Mixtral, Nous published two models on the same day: Nous-Hermes-2-Mixtral-8x7B-SFT, which is supervised fine-tuning only, and Nous-Hermes-2-Mixtral-8x7B-DPO, which adds Direct Preference Optimization on top. The DPO card says the SFT only version was released "for people to find which works best for them". DPO trains on pairs of preferred and rejected responses to shift the model toward preferred behaviour without a separate reward model.

For an inventory, the SFT and DPO variants are different artifacts with different behaviour, even though they share a base and a dataset. Nous also published a DPO adapter repository (Nous-Hermes-2-Mixtral-8x7B-DPO-adapter), whose metadata lists the DPO model itself as its base. If you apply an adapter at load time, the adapter and the model it targets are two components, and both belong in your record.

Why does the base matter so much in this generation?

Because the terms changed with it. Yi-34B, SOLAR-10.7B, Mixtral-8x7B and Mistral-7B are tagged Apache-2.0 on Hugging Face today, so the Hermes 2 models on those bases carry Apache-2.0 tags that line up with their bases. Nous-Hermes-2-Llama-2-70B is also tagged apache-2.0, but its base is Llama 2 70B, whose Community License applies. Same dataset, same recipe, different obligations.

Hermes 2 Pro: function calling, JSON mode and a format that spread

What did Hermes 2 Pro add?

Hermes-2-Pro-Mistral-7B, released on 11 March 2024, is described on the Nous releases page as a "master function-calling model". Its card says it is a retrained Hermes 2 using a cleaned OpenHermes 2.5 dataset plus "a newly introduced Function Calling and JSON Mode dataset developed in-house". It was trained to do two structured jobs:

1. Function calling. The system prompt lists available tools as JSON schemas inside a <tools> block. When the model wants a tool, it emits a JSON object with name and arguments inside a <tool_call> block. Your code runs the tool and returns the result in a tool role message, after which the model writes its answer. The card describes this as a special system prompt plus a multi-turn calling structure with a new ChatML role.
2. JSON mode. A separate system prompt supplies a JSON schema inside a <schema> block and the model answers with only a JSON object matching it. Nous published helper code in the Hermes-Function-Calling repository, including a jsonmode.py script that builds the schema from a Pydantic model.

The card reports 90% on a function calling evaluation and 84% on a structured JSON evaluation, both built with an inference provider. The evaluation section further down the same card gives 91% for function calling, so the card disagrees with itself by one point. Either way these are self-reported numbers on Nous's own evaluation set.

Why did the Hermes tool-call format spread into inference servers?

Because it was easy to parse and it shipped inside the tokenizer configuration. Hermes 2 Pro and later models carry a tool-aware chat template in tokenizer_config.json, so an inference server can render tool definitions into the prompt and then recognise <tool_call> blocks in the output. vLLM documents a hermes tool parser and states that "all Nous Research Hermes-series models newer than Hermes 2 Pro should be supported", naming Hermes-2-Pro, Hermes-2-Theta and Hermes-3 repositories. To enable it you start vLLM with --enable-auto-tool-choice and --tool-call-parser hermes.

The format then travelled beyond Nous. vLLM's documentation says the Qwen2.5 chat template "has already included support for the Hermes-style tool use", so the same hermes parser handles Qwen2.5 and QwQ-32B. The Hermes 3 Technical Report calls it the "Hermes Function Calling standard": tool definitions in <tools>, invocations in <tool_call>, results in <tool_response>. The Hermes 4 cards say the tool-call tags are added tokens, which makes them easier to detect while streaming.

This is the second common way "Hermes" shows up in an agent stack. A team can be running a non-Hermes model through a Hermes-format parser, and the security questions are the same: the parser turns model text into a function call, so whatever the model writes inside the tags becomes an action.

What should a defender take from the tool-call format?

Treat a parsed tool call as untrusted input. The parser guarantees shape, not intent. Validate arguments against the tool's JSON schema before running anything, keep an allowlist of tools per deployment, and log both the raw model output and the parsed call so you can reconstruct what happened. The same advice applies to JSON mode: a schema-valid object can still carry a malicious string in a free-text field.

Hermes 2 Theta: the merge experiment and its documented trade-off

What was Hermes 2 Theta?

The Hermes-2-Theta-Llama-3-8B card calls it "the first experimental merged model released by Nous Research", built with the team behind the open source MergeKit tool. The card says it is a merge of Hermes 2 Pro and Meta's Llama 3 Instruct model, "then further RLHF'ed". Model merging combines the weights of two or more fine-tuned models that share a base, without further training on the original data, in the hope of keeping the strengths of each. The 8B repository was created on 5 May 2024 and a 70B version followed; the releases page lists "Hermes 2 Theta" on 20 June 2024.

What trade-off did vLLM document?

vLLM's tool calling documentation carries a direct warning: Hermes 2 Theta models "are known to have degraded tool call quality and capabilities due to the merge step in their creation". So the experiment kept the Hermes chat behaviour and the Llama 3 Instruct qualities, at some cost to the exact skill Hermes 2 Pro had been trained for. If you are choosing a Hermes model for an agent that calls tools, that line is a reason to prefer Hermes 2 Pro, Hermes 3 or later over Theta.

What does a merge mean for lineage?

A merge has more than one parent. Hugging Face's model card documentation says the base_model field can be a list, specifically so that a merge can name every model it came from. The Theta 8B card lists only NousResearch/Hermes-2-Pro-Llama-3-8B as its base, even though its own description names Llama 3 Instruct as the second parent. Your inventory should record both. The licence tag also drifts again: the Theta 8B repository says apache-2.0 while both parents descend from Llama 3, and the Theta 70B repository says llama3. For more on how merge, adapter and quantisation lineage should be written down, see base model metadata for fine-tunes, adapters, merges and quantised models.

Hermes 3: what the technical report says

The Hermes 3 Technical Report (arXiv 2408.11857, first version 15 August 2024 UTC; listed on the releases page on 14 August) is the first Hermes release with a full written method. It covers 8B, 70B and 405B models fine-tuned from Llama 3.1.

What data did Hermes 3 use?

According to the report, the dataset was built from March 2024 onward from existing sources filtered for "coherence, educational value, and reliability", plus domain-specific generated data aimed at known weaknesses of older Hermes models. Filtering removed refusals and badly formatted responses. The final mixture is about 390 million tokens, of which 270 million (69%) are response tokens that contribute to the loss and 120 million are instruction tokens.

Nous published the Hermes 3 dataset on Hugging Face on 11 July 2025 under Apache-2.0. Note a numbering mismatch you will see later: the Hermes 4 model cards describe the Hermes 3 corpus as "1M samples and 1.2B tokens", which does not match the report's 390 million tokens. The report is the more detailed primary source; the card figure may count differently, and Nous does not explain the gap.

How was Hermes 3 trained?

Two phases, per the report.

• Supervised fine-tuning. AdamW with weight decay 0.01, a peak learning rate of 7e-6 on a cosine schedule after 300 warmup steps, over four epochs. Instruction and tool output tokens were masked out of the loss so the model learned only from responses and tool calls. Samples were packed into 8,192 token sequences at 96% efficiency. The best epoch per size was chosen on a normalised average of public benchmarks plus IFEval and MT-Bench.
• DPO. A LoRA adapter (rank 32, alpha 16, dropout 0.05 on all linear layers) instead of full-model DPO, to avoid holding a reference and a trained model in GPU memory at once. The report says DPO gave "a moderate but positive impact" on the 8B model but only negligible gains at larger sizes, so the 70B and 405B releases stay with the SFT checkpoints.

What does the report say about the 405B model?

The 405B model needed special handling. Under standard PyTorch FSDP, the report says the minimum setup that avoided out-of-memory errors at 8K context was seven HGX nodes with CPU parameter offloading, which the authors estimate cut training speed by 45%. A lower learning rate worked better at that size. The 405B evaluations in the report were run under FP8 weight quantisation using the llm-compressor library for vLLM, so the published 405B numbers describe the FP8 model, which is also what Nous released as a separate -FP8 repository. The 405B card describes it as the first full parameter fine-tune released since Llama 3.1 405B came out.

What else is in Hermes 3?

The report describes the models as "neutrally-aligned" and "highly sensitive to the system prompt", especially at 405B. It also trained the model on reasoning and planning tags carried in reserved Llama 3.1 tokens, such as scratchpad, reasoning and unit test markers, and on the Hermes function calling and retrieval citation formats. The context length is 128K, inherited from Llama 3.1.

The operational lesson is about who owns safety behaviour. A model trained to follow the system prompt "exactly and neutrally" puts the policy in your system prompt and your surrounding controls, not in the weights. That is a design choice Nous states openly, and it means a Hermes deployment should be paired with input and output controls you own.

DeepHermes 3: one model, two modes

DeepHermes-3-Llama-3-8B-Preview, listed on 14 February 2025, was Nous's first public step into long chain-of-thought reasoning. The card describes it as one of the first models to unify "intuitive" responses and long reasoning in one model, "toggled by a system prompt". Reasoning is switched on by a specific system prompt that asks the model to think inside <think> tags before answering; without it, the model answers directly. The card says the preview's reasoning was distilled from R1 across a range of tasks and flags it as a preview with possible quirks. Larger previews followed on Hugging Face, including DeepHermes-3-Mistral-24B-Preview on an Apache-2.0 Mistral Small base in March 2025.

In April 2025 Nous also published a set of DeepHermes specialist models whose names reference Atropos, its new reinforcement learning environments framework, such as a tool-calling specialist. They are useful context for what came next: Hermes 4 used Atropos heavily.

Hermes 4: hybrid-mode reasoning at scale

What is hybrid-mode reasoning?

The Hermes 4 Technical Report (arXiv 2508.18255; version 1 on 25 August 2025, version 2 on 2 September 2025) presents Hermes 4 as "a family of hybrid reasoning models" that combine multi-turn reasoning with general instruction following. In practice, one set of weights can either answer directly or first write a reasoning trace inside <think> and </think> and then answer. The Hermes 4 cards say reasoning mode is turned on with the chat template flag thinking=True or with the same "deep thinking" system prompt DeepHermes used, and that further system instructions can adjust the style and effort of thinking. Tool calls can be interleaved with reasoning inside a single assistant turn.

What data did Hermes 4 use?

The report describes a post-training corpus of about 5 million samples and 19 billion tokens: 3.5 million reasoning samples and 1.6 million non-reasoning samples. Reasoning samples average about five times as many tokens as non-reasoning ones, with thinking traces up to 16,000 tokens. Two pieces of tooling produced it:

• DataForge, a graph-based synthetic data generator inspired by AgentInstruct, which turns pre-training seed passages into instruction and answer pairs through a chain of transformations. The data was deduplicated semantically using embeddings.
• Rejection sampling with Atropos. The report says Nous rejection sampled against "roughly a thousand task-specific verifiers" implemented as Atropos environments. Examples in the report include an answer-format environment (rewarding the requested output format and strict use of the think delimiters), an instruction-following environment built on verifiable constraints, a reformulated reasoning bootcamp producing 70,000 samples, and a schema adherence environment that rewards JSON that validates against a Pydantic model.

The model cards describe the corpus differently, as "~5M samples / ~60B tokens". The training table in the report lists 56 billion training tokens per model, which may count repeated passes over the 19 billion token dataset. We report both figures and note that the paper's dataset description and the cards' headline disagree.

How was Hermes 4 trained?

The report says training ran on 192 NVIDIA B200 GPUs with a modified TorchTitan, a cosine schedule with 300 warmup steps, 9,000 total steps and a global batch of 384 samples at 16,384 tokens. Samples were packed ahead of time with attention restricted to each sample.

How did Nous control reasoning length?

The 14B model tended to think too long. The report says that in reasoning mode on LiveCodeBench it hit its 40,960 token context limit 60% of the time. Nous added a second supervised stage that teaches the model to close its thinking at 30,000 tokens, training only on the closing </think> and end-of-sequence tokens while leaving the model's own reasoning text untouched. In the report's Table 2, the overlong rate on AIME'24 fell from 28.2% to 0.1% while the score moved from 55.0 to 55.4; on AIME'25 the score dropped from 48.7 to 46.8. The report says this stage was not needed for the 70B and 405B models.

How did Nous evaluate Hermes 4?

The report puts weight on reproducible evaluation. All benchmarks run against one OpenAI-compatible endpoint so the inference engine is the same for every test, and Nous says it logged and released every sample generated during evaluation. It used lighteval for maths and most multiple-choice tests, an EQBench collection for subjective tests, and Atropos for LiveCodeBench and custom evaluations. One detail in the report is a useful caution for anyone comparing model numbers: in June 2025 internal testing of a popular open source evaluation framework, the authors say they found 7.3% disagreement between that framework's answer parser on one benchmark and a model-based grader. Benchmark numbers from different harnesses are not directly comparable.

The cards also describe RefusalBench, an internal Nous benchmark measuring how often a model answers rather than refuses across 32 categories of commonly refused requests, where a higher score means fewer refusals. That is a self-reported measure of steerability, not a safety evaluation. For a deployer it confirms the Hermes 3 lesson: policy lives in your system prompt and your controls.

Hermes 4.3: Seed-OSS base, Psyche training

What is Hermes 4.3 and what is its base?

Hermes 4.3 is a 36B hybrid reasoning model listed on the Nous releases page on 3 December 2025 as Hermes-4.3-Seed-36B; the Hugging Face repository is NousResearch/Hermes-4.3-36B, created on 17 November 2025. Its base is ByteDance-Seed/Seed-OSS-36B-Base, which is tagged Apache-2.0 on Hugging Face, and the Hermes 4.3 card is Apache-2.0 too. The releases page summary says it has "roughly equivalent performance to Hermes-4-70B at half the model size", and the Nous blog post says it was trained with context lengths up to 512K. Both are Nous's own claims.

What does "post-trained entirely on the Psyche network" mean?

It means the post-training run was spread across independent machines on the internet, coordinated by Nous's Psyche network, rather than run in one data centre. The Nous blog post and Psyche write-up describe three pieces:

• DisTrO and DeMo. DisTrO ("Distributed Training Over-The-Internet") is a family of optimizers designed to cut the communication needed between GPUs during training. Nous's preliminary report (26 August 2024) says it reduces inter-GPU communication "by four to five orders of magnitude" in a 1.2B parameter pre-training test, while the current DisTrO repository README says "three to four orders of magnitude". DeMo (Decoupled Momentum Optimization) is the published predecessor idea.
• A coordinator on a blockchain. Psyche's coordinator, which holds the state of a training run, the participant list and the randomness used to assign work and witnesses, lives in a smart contract on the Solana blockchain. Training gradients travel out of band over a peer-to-peer mesh.
• Witnesses. Designated participants verify other clients' work and send compressed "witness proofs" (built with Bloom filters) to the coordinator.

For Hermes 4.3, the blog says Nous trained the model twice: once with its TorchTitan setup and the Hermes 4 recipe (FSDP and AdamW), and once on Psyche (tensor parallel plus DisTrO). It reports that the Psyche run averaged 144,000 tokens per second across 24 Psyche nodes, that the run was twice the size of Hermes 4 because of the longer context and larger dataset, and that the Psyche-trained version "outperformed the traditional centralized version" on a suite of downstream tasks. Nous published the centrally trained model as a research artifact (NousResearch/Hermes-4.3-36B-centralized, created 28 October 2025) along with evaluation responses. These are self-reported results; no independent replication is cited.

What is Atropos and why does its status matter?

Atropos is Nous's framework for reinforcement learning environments with language models: environments run as services and send scored trajectories to a trainer through an API. It was released on 29 April 2025 under the MIT licence and it is how Hermes 4 implemented its verifiers. As of 23 October 2026, the GitHub repository is archived. Its README now says no further updates, bug fixes or security patches will be made, and GitHub shows it archived on 4 July 2026. If your team built training or evaluation pipelines on Atropos, it is now an unmaintained dependency, and that should be recorded and planned for like any other end-of-life component. The Psyche code repository now redirects to PsycheFoundation/nousnet and is Apache-2.0.

What does decentralised training change for provenance?

Less than you might expect for the consumer of the weights. The on-chain coordinator gives a public record of the training run's coordination, but the artifact you download is still a set of safetensors files in a Hugging Face repository. Your integrity anchor is the repository commit and the per-file SHA-256 hashes, plus whatever signatures the publisher provides. We did not find a published signature over the Hermes 4.3 weight files on its model card. That is common for open-weight models and is exactly why pinning and hashing (below) matter. For the general case, see model weights as supply chain artifacts.

Licences: what each Hermes model inherits

Which licence applies to each Hermes model?

The rule of thumb is that a fine-tune inherits its base model's terms, and the Hugging Face tag is a hint at best. We cover the general argument in does a fine-tuned model inherit its base model licence. Applied to Hermes:

What does that mean for commercial use?

For the Apache-2.0 lineages (the Mistral, Mixtral, Yi, SOLAR, Qwen3 and Seed-OSS based models), commercial use is permitted under Apache-2.0's conditions, such as keeping the licence and notices. For the Llama 2, 3, 3.1 and 3.2 lineages, commercial use is allowed under Meta's community licence terms, which add obligations that Apache-2.0 does not: the user threshold, the Acceptable Use Policy and, for Llama 3.1, the attribution and naming requirements. The Llama 3.1 licence says that if you use Llama materials to create or fine-tune a model that you distribute, you must include "Llama" at the beginning of that model's name. The Nous releases page lists the Hermes 4 models as Hermes-4-Llama-3.1-405B and Hermes-4-Llama-3.1-70B while the Hugging Face repositories are Hermes-4-405B and Hermes-4-70B; record both names so a reviewer can match them. For the LLaMA 1 lineage, plan on non-commercial use only.

Two more points for your counsel. Datasets distilled from hosted models carry their own question, separate from the base licence. And a quantised file from a third party is a redistribution of the same weights, so it carries the same terms even when its repository has a different tag.

What does that mean for an AI-BOM entry?

An AI-BOM entry needs the licence you are actually bound by, which for a Llama-based Hermes is the Meta licence for that Llama version, plus a note when the repository tag says something else. Recording the tag alone would put "MIT" or "Apache-2.0" next to a model that carries Meta's terms, which is the kind of error an audit finds. If you only call a Hermes model through a hosted API, read do you need an AI-BOM entry for a model you only call through an API for what changes.

How to record a Hermes model in an inventory

What fields matter?

Whatever format you use, these are the fields that answer real questions later.

Which standards fit?

CycloneDX has a dedicated component type, machine-learning-model, and a modelCard object. In the CycloneDX 1.6 schema, modelCard.modelParameters holds approach (with types such as supervised and reinforcement-learning), task, architectureFamily, modelArchitecture, datasets, inputs and outputs, and modelCard.considerations holds fields such as technicalLimitations, ethicalConsiderations and environmentalConsiderations. Lineage goes in the component's pedigree.ancestors, and file integrity in hashes, where SHA-256 and stronger algorithms are listed. The CycloneDX project describes its ML-BOM as covering models, datasets and the provenance of datasets and training methods.

SPDX 3.0.1 has an AI profile with an AIPackage class, defined as metadata for "an AI application or trained AI model". It is a subclass of the software Package class and adds properties such as typeOfModel, hyperparameter, informationAboutTraining, limitation, safetyRiskAssessment, standardCompliance, domain and autonomyType.

Hugging Face model card metadata is where most of the raw facts come from. Its documentation says base_model can be a single model ID or a list, to cover fine-tunes, adapters, quantised versions and merges.

How should quantised and adapter variants be recorded?

As separate components with their own hashes, each pointing back to the model they were made from. Watch for gaps in the published metadata. The Hermes-4.3-36B-GGUF repository lists ByteDance-Seed/Seed-OSS-36B-Base as its quantised base rather than Hermes 4.3 itself, and the Hermes-3-Llama-3.1-8B-GGUF repository lists Llama 3.1 8B. A naive import would record those GGUF files as quantisations of the original base model, skipping the Hermes fine-tune in between. Write the full chain: base, Hermes fine-tune, quantised file.

Step by step: pin, verify and inventory a Hermes model

This walkthrough uses Hermes 4.3 because it is the newest release, but the same steps work for any Hermes repository. The commands use curl, jq, the Hugging Face hf CLI and shasum. Nothing here changes or deletes data outside a new folder you create.

Step 1. Read the repository metadata and record the commit.

curl -s https://huggingface.co/api/models/NousResearch/Hermes-4.3-36B \
  | jq '{id, sha, createdAt, lastModified,
         license: .cardData.license,
         base_model: .cardData.base_model}'

On 23 October 2026 this returned commit 3899db2b6c4b35f16bde3b570bb7dd2775d56161, last modified 6 December 2025, licence apache-2.0 and base ByteDance-Seed/Seed-OSS-36B-Base. Save the output next to your inventory record.

Step 2. Capture the expected SHA-256 for every weight file.

curl -s 'https://huggingface.co/api/models/NousResearch/Hermes-4.3-36B?blobs=true' \
  | jq -r '.siblings[] | select(.lfs != null)
           | "\(.lfs.sha256)  \(.rfilename)"' > hermes-4.3-36b.sha256
wc -l hermes-4.3-36b.sha256

Hugging Face stores large files with Git LFS and exposes each file's SHA-256 in this API. On our check, the first shard model-00001-of-00014.safetensors had SHA-256 c92c9fa9b343f40d7ce2f58c1b0c96e4d72b6b0cad518156dac151072bb165f0.

Step 3. Download the pinned revision, not main.

pip install -U huggingface_hub
hf download NousResearch/Hermes-4.3-36B \
  --revision 3899db2b6c4b35f16bde3b570bb7dd2775d56161 \
  --local-dir ./models/hermes-4.3-36b

The hf download command and its --revision option are documented in the Hugging Face CLI guide; a commit hash, branch or tag all work, and only a commit hash is immutable.

Step 4. Verify the hashes locally.

cd ./models/hermes-4.3-36b
shasum -a 256 -c ../../hermes-4.3-36b.sha256

Every line should end in OK. A mismatch means the files on disk are not the files the commit describes; stop and investigate before serving them.

Step 5. Serve with the matching tool parser and a pinned revision.

pip install 'vllm==<version you have reviewed>'
vllm serve ./models/hermes-4.3-36b \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

The Hermes 4 cards say to set vLLM's tool parser to hermes, and vLLM documents --enable-auto-tool-choice as mandatory for automatic tool choice. Serving from the verified local folder means the server loads exactly what you hashed. Pin the vLLM version in your lockfile like any other dependency.

Step 6. Write the CycloneDX component.

{
  "type": "machine-learning-model",
  "bom-ref": "model:NousResearch/Hermes-4.3-36B@3899db2b",
  "supplier": { "name": "Nous Research" },
  "name": "Hermes-4.3-36B",
  "version": "3899db2b6c4b35f16bde3b570bb7dd2775d56161",
  "licenses": [ { "license": { "id": "Apache-2.0" } } ],
  "hashes": [
    { "alg": "SHA-256",
      "content": "c92c9fa9b343f40d7ce2f58c1b0c96e4d72b6b0cad518156dac151072bb165f0" }
  ],
  "pedigree": {
    "ancestors": [
      { "type": "machine-learning-model",
        "name": "Seed-OSS-36B-Base",
        "supplier": { "name": "ByteDance Seed" },
        "licenses": [ { "license": { "id": "Apache-2.0" } } ] }
    ]
  },
  "modelCard": {
    "modelParameters": {
      "task": "text-generation",
      "architectureFamily": "Seed-OSS",
      "approach": { "type": "supervised" }
    },
    "considerations": {
      "technicalLimitations": [
        "Behaviour depends heavily on the system prompt; policy is enforced by the deployer"
      ]
    }
  },
  "externalReferences": [
    { "type": "website", "url": "https://huggingface.co/NousResearch/Hermes-4.3-36B" },
    { "type": "documentation", "url": "https://arxiv.org/abs/2508.18255" }
  ]
}

In a real record, list every shard's hash (from step 2), not just the first. For a Llama-based Hermes, put the Llama licence for that version in licenses and add the repository tag as a note.

Step 7. Fail CI if the upstream commit changes under you.

# check_model_pin.py
import json, sys, urllib.request

PINS = {
    "NousResearch/Hermes-4.3-36B": "3899db2b6c4b35f16bde3b570bb7dd2775d56161",
}

failed = False
for repo, pinned in PINS.items():
    with urllib.request.urlopen(f"https://huggingface.co/api/models/{repo}") as r:
        live = json.load(r)["sha"]
    if live != pinned:
        print(f"{repo}: main is now {live}, pinned {pinned}. Review before moving the pin.")
        failed = True
sys.exit(1 if failed else 0)

This does not stop you serving the pinned files; it tells you when the upstream repository has moved so a person can read the change and decide. Run it on a schedule rather than on every build if you want to avoid noise.

Step 8. Keep the serving stack in the SBOM. Generate an SBOM for the service that loads the model, in SPDX or CycloneDX, so vLLM, transformers, tokenizers, huggingface_hub, PyTorch and their transitive dependencies are listed with versions. The model rarely changes after release; the code around it changes weekly and is where most of your patching happens.

Choosing a Hermes model: a decision table

This is not a ranking. It maps common requirements to the generation whose documented properties fit, so you can read the right card first.

Common mistakes

• Writing "Hermes" in the inventory. A family name is not an artifact. Record repository, commit, base, variant and licence.
• Copying the Hugging Face licence tag. Nous-Hermes-13b says GPL, the Llama 2 Hermes repos say MIT, and Hermes 3 says llama3 for Llama 3.1 models. The base licence applies.
• Pulling main. A repository can be updated after you test it. Pin a commit and verify hashes.
• Treating a GGUF file as the same artifact. A quantisation is a new set of files, often published by someone else, with different hashes and sometimes different behaviour. It still carries the original licence.
• Recording only one parent of a merge. Hermes 2 Theta's metadata lists one base; its card names two.
• Using the wrong prompt format. Alpaca for the first Hermes, ChatML for Hermes 2 and 3, the Hermes 4 chat template with optional think tags. A wrong template degrades output without an error.
• Trusting parsed tool calls. The hermes parser checks shape. Validate arguments and allowlist tools.
• Assuming the model will refuse for you. Hermes is designed to follow the system prompt. Safety policy belongs in your prompt, gateway and tool permissions.
• Comparing benchmark numbers across reports. Harnesses, quantisation (the Hermes 3 405B numbers are FP8) and reasoning mode all change scores.
• Ignoring archived tooling. Atropos is archived with no further security patches. If you depend on it, record it as end of life.
• Confusing Hermes Agent with the models. Agent CVEs are about the harness, not the weights, and the agent can run any provider's model.

FAQ

What is the latest Hermes model?

As of 23 October 2026, the newest Hermes model on the Nous Research releases page is Hermes-4.3-Seed-36B, listed on 3 December 2025. Its Hugging Face repository is NousResearch/Hermes-4.3-36B. We found no Hermes 5 on Hugging Face or the releases page on that date.

What is the difference between Hermes Agent and the Hermes models?

The Hermes models are open-weight language models. Hermes Agent is Nous Research's open source agent software, which runs on a model of your choice, including models from other providers. You can use either without the other.

Can I use Hermes models commercially?

It depends on the base. Hermes models on Apache-2.0 bases (Hermes 4.3, Hermes 4 14B, the Mistral, Mixtral, Yi and SOLAR based Hermes 2 models) follow Apache-2.0. Llama-based Hermes models follow Meta's community licence for that Llama version, which allows commercial use with extra conditions. The original Nous-Hermes-13b sits on LLaMA 1, whose model card lists a non-commercial licence. Ask your counsel for anything you ship.

What base model is Hermes 4.3 built on?

ByteDance Seed's Seed-OSS-36B-Base, per the model card's base_model field and the Nous blog post. Hermes 4 405B and 70B are on Llama 3.1, and Hermes 4 14B is on Qwen3 14B.

What does hybrid reasoning mean in Hermes 4?

One model can answer directly or reason first inside think tags, then answer. You switch reasoning on with the chat template's thinking=True flag or a documented system prompt, according to the Hermes 4 model cards and the Hermes 4 Technical Report.

Which vLLM tool parser should I use for Hermes models?

hermes, started with --enable-auto-tool-choice --tool-call-parser hermes. vLLM says it supports Hermes models newer than Hermes 2 Pro and warns that Hermes 2 Theta has degraded tool calling because of its merge step.

Was Hermes 4.3 trained on a blockchain?

Its post-training was coordinated through Psyche, whose coordinator runs as a smart contract on the Solana blockchain, while the training itself ran on GPUs across 24 nodes and exchanged gradients over a peer-to-peer network. Nous also trained a centralised version for comparison and published it.

Are Hermes models uncensored?

Nous describes Hermes as "neutrally-aligned" and steerable, and reports lower refusal rates on its own RefusalBench. That means the model follows your system prompt closely and leaves policy to the deployer. Treat it as a component that needs your own input and output controls.

Is there a Hermes 5?

Not as of 23 October 2026, based on the Nous releases page and a Hugging Face API search of NousResearch repositories on that date.

How do I add a Hermes model to an AI-BOM?

Record the repository, the commit, per-file SHA-256 hashes, the full base lineage (including both parents of a merge and the original of a quantisation), the licence you are bound by, the prompt and tool format, and the serving stack. CycloneDX's machine-learning-model component with modelCard and pedigree, or SPDX 3.0.1's AIPackage, both hold these fields.

Where Safeguard fits

Safeguard does not train, benchmark or evaluate language models, and it does not certify Hermes or any other model's behaviour. Hermes and Nous Research are not Safeguard partners or integrations. The overlap is the software around a model. A team serving Hermes runs vLLM or llama.cpp, transformers, tokenizers, huggingface_hub and PyTorch, inside a container, behind an API, and Safeguard handles that part the way it handles any codebase: SBOM generation and analysis in SPDX and CycloneDX, vulnerability matching with reachability, policies and gates in CI, and attestation and signing with SLSA, Sigstore and in-toto. AI-BOM discovery, which inventories AI assets such as model SDK imports in code, is in early access, so ask before planning around it. The model inventory steps above are yours to run with standard tools either way.

Fix it without waiting for upstream

Serving a Hermes model means running an inference server, Python libraries and a GPU runtime that are all open source components, and those receive CVEs on their own schedule. The weights rarely change after release, so the code around them is where most of your patching work lands, and that is where the steps below apply.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos loads or evaluates a Hermes model. They show how Safeguard works on the code and dependencies around one, which is the honest overlap with this topic. To try the CLI, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

The first demo connects Claude to Safeguard: you add Safeguard from Claude's connector directory, sign in with OAuth and choose which Safeguard tools Claude may use. If you already use an assistant to help run a model serving repository, the same connection lets it ask Safeguard which vLLM, transformers or tokenizers versions in that project carry known vulnerabilities, within the tools you allowed.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. Asked to fix the lodash CVE in a repo, it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan. The same approve-each-step pattern applies when a Python dependency in your inference service needs a version bump and you want each command reviewed.

Click through it at your own pace, or open it full screen.

The third demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That fits teams that keep model serving code on GPU hosts they control and would rather scan there than upload anything.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Nous Research: Releases
• Nous Research: Introducing Hermes 4.3
• Nous Research: Nous Psyche
• Hugging Face API: NousResearch models matching Hermes
• Hugging Face: NousResearch/Nous-Hermes-13b model card
• Hugging Face: NousResearch/Nous-Hermes-Llama2-13b model card
• Hugging Face: NousResearch/Nous-Hermes-2-Yi-34B model card
• Hugging Face: NousResearch/Nous-Hermes-2-Mixtral-8x7B-DPO model card
• Hugging Face: NousResearch/Hermes-2-Pro-Mistral-7B model card
• Hugging Face: NousResearch/Hermes-2-Theta-Llama-3-8B model card
• Hugging Face: NousResearch/Hermes-3-Llama-3.1-405B model card
• Hugging Face: NousResearch/DeepHermes-3-Llama-3-8B-Preview model card
• Hugging Face: NousResearch/Hermes-4-405B model card
• Hugging Face: NousResearch/Hermes-4.3-36B model card
• Hugging Face: NousResearch/Hermes-3-Dataset
• arXiv 2408.11857: Hermes 3 Technical Report
• arXiv 2508.18255: Hermes 4 Technical Report
• GitHub: NousResearch/DisTrO and A Preliminary Report on DisTrO
• GitHub: NousResearch/atropos
• GitHub: Psyche repository (PsycheFoundation)
• GitHub: NousResearch/Hermes-Function-Calling
• GitHub: NousResearch/hermes-agent README
• vLLM: Tool calling documentation
• Meta: LLaMA (version 1) model card
• Meta: Llama 2 Community License
• Meta: Llama 3.1 Community License
• Hugging Face: Model cards documentation (base_model metadata)
• Hugging Face: Command line interface guide
• CycloneDX: Machine Learning Bill of Materials
• CycloneDX: 1.6 JSON schema
• SPDX 3.0.1: AI profile, AIPackage class

Last reviewed: 23 October 2026. Nous Research publishes new models and Hermes Agent releases often; check the linked model cards and the Nous releases page for the latest status.