Open-Weight vs. API Models: Own a Domain Model with Hermes

The last stage of the evolution is owning the model instead of renting it. Up to now, we've rented models. We typed prompts into a chat window (Part 1), handed over code (Part 2), passed off the loop (Part 3), and designed a harness around it all (Part 4).

> Part 5 (final) of the "Evolution of LLM use" series. ① Prompting · ② Vibe coding · ③ Agents · ④ Harness engineering · ⑤ Open models.

Why own the model?

Renting a frontier model through an API is convenient, but it comes at a price. When pricing or policies change, you're dragged along; you have to send your data outside; and you can't change the model to fit your domain. Open-weight models flip all three. Here it is in a table.

A leading example is the Hermes family from Nous Research. Through its most recent version, Hermes 4.3 (December 2025, based on ByteDance's Seed-OSS-36B), Hermes has established itself as an open model strong at system-prompt adherence, steering, and function calling ^[1][3]. What's interesting is that Nous doesn't just release models; it also opens up an open agent framework (Hermes Agent) and a native desktop app (Hermes Desktop, released in 2026, MIT). You can own the model, the agent, and the harness as a whole.

Function calling has a standard too

Remember the structured output (tool_use) from Part 1? Open models have the same thing. The Hermes Function Calling standard ^[2] puts tool definitions (JSON schema) in <tools>, calls in <tool_call>, and results in <tool_response>.

<!-- Hermes function calling: tool definitions go inside <tools> as JSON schema -->
<tools>
[{"name": "emit_slides",
  "parameters": {"type": "object",
    "properties": {"slides": {"type": "array"}},
    "required": ["slides"]}}]
</tools>

<!-- The model calls tools in this format -->
<tool_call>
{"name": "emit_slides", "arguments": {"slides": [/* … */]}}
</tool_call>

Only the format differs; it's exactly the same idea as tool_use in Part 1: enforce output as an interface. So you can move a harness designed for frontier models to an open model almost as is.

The harness is a data factory

This is where the side effect from Part 4 comes to life. A well-designed harness leaves standardized data with every run: input → tool call → verified output. That's an instruction-tuning dataset as is.

Then the flywheel turns. The more you use the harness, the more domain data piles up → you use that data to fine-tune an open model (e.g., Hermes) for your domain → your existing workflows become the evaluation criteria (evals) as they are → the better-fitted model runs the harness again. The structured output our generation pipeline leaves through tool_use, and the held-out judge we use for verification, are the raw material for exactly this flywheel.

Honestly, this stage is still closer to a hypothesis. It assumes enough data, quality control, and sustained investment. But the direction is clear: from renting models toward owning the model, the harness, and the data as a whole.

Closing the series

We've gone through five stages: typing prompts into a chat window, building by vibe, handing the loop to agents, designing a harness around it, and finally owning even the model layer. The one line that runs through it all: LLM use is moving away from individual instinct and toward systems that teams design and own.

The way we build content automation sits exactly on this trajectory: treat prompts as interfaces, add verification to generation, raise the quality floor with a harness, and improve with the data it produces. Trail Studio is the result of applying that system to content.