Ornith-1.5-35B-A3B (Ornith 1.5 35B) for AI Agents

A 35B model that only wakes up 3B parameters per token, fits on one 24GB card at Q4, and posts a 79 on SWE-bench Verified. Here's the hardware math, the exact Ollama, OpenClaw and Hermes configs, and where it actually belongs in a routing stack.

The r/hermesagent thread hit 192 upvotes with "MIND BLOWING" in the title, which is usually the signal to be skeptical. So I pulled the GGUF, read the model card twice, and ran it against the same agent loop I use for every local model. Some of the hype holds. Some of it is people confusing the 9B and the 35B. Here's the sorted version.

Run Ornith-1.5-35B-A3B in one command

If you're running it behind an agent, pull it from the official GGUF repo. This is the command the model card gives, with :Q4_K_M pinning the 21.7 GB file that fits a 24GB card:

ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M

The Ollama library also carries it under its own tag, the same Q4_K_M weights plus the vision projector as a 23 GB download:

ollama run ornith-1.5:35b

That one is fine for chat, but as of 13 Oct 2026 the ornith-1.5 library page lists only the vision capability, not "tools" or "thinking", so agents that send tools can hit a "does not support tools" error. Use the hf.co pull for agents, and run the one-request tool-calling check further down either way.

One more trap. The Ollama library also has an older model called plain ornith (ornith:35b, ornith:9b, and latest, which is the 9B). That's Ornith-1.0, and it's text-only. ollama run ornith:35b does not give you 1.5.

To point an agent at it, the card gives three environment variables rather than framework commands. This is its OpenClaw block, with vLLM serving on its default port (the Hermes block is the same but names the last one MODEL):

export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"
export OPENAI_MODEL="ornith-ai/Ornith-1.5-35B-A3B"

On Ollama, the base URL is http://localhost:11434/v1 and the model name is the hf.co/... string you pulled. The rest of this post covers the hardware math, the tool-calling check, and the framework setup.

What Ornith-1.5 actually is

Ornith-1.5-35B-A3B is the mid-size mixture-of-experts member of the Ornith-1.5 family from the Ornith team (published under DeepReinforce for the 1.0 release, now under the ornith-ai org on Hugging Face). The A3B in the name is the whole story: about 35B total parameters, roughly 3B activated per token. You pay disk and memory for 35B and compute for 3B.

Under the hood it's the Qwen 3.5 MoE architecture: a hybrid of GatedDeltaNet linear-attention layers and full-attention layers, 256 routed experts plus one shared, 262K native context (262,144 tokens, extendable toward 1M with YaRN), a vision tower, and a thinking block that opens every answer by default. MIT licensed, no regional restrictions.

What makes it different from the Qwen it was built on is the training. Ornith-1.0 added continued pretraining and RL on top of Qwen 3.5 and Gemma 4. Ornith-1.5 widens the self-improvement loop: the model generates its own training tasks, builds its own scaffolds, and learns from the rollouts, rather than training on a fixed human-curated set. It's a coding-agent model first and everything else second.

Terminal-Bench 2.1 (run through Claude Code): 68.5. SWE-bench Verified: 79.0. SWE-bench Pro: 59.6. Qwen3.6-35B-A3B, the closest architectural peer, scores 49.2, 73.4, and 49.5 on the same rows. The 49.2 is the Ornith team's own Terminal-Bench 2.1 run; Qwen hasn't published a 2.1 score for it.

Those are the model card's numbers, with git history stripped and network disabled during the SWE-bench evaluations to block reward hacking. And people are pulling it: the GGUF repo's Hugging Face download counter showed about 3.66 million on 13 Oct 2026, which is not nothing for a model most people hadn't heard of in July.

Ornith 1.5 35B benchmarks and specs

Everything in this table comes from the model card, the GGUF repo and the Ollama library page, checked on 13 Oct 2026.

And the benchmark rows the card reports, each averaged over five runs:

These are the Ornith team's own runs, so read them as the vendor's numbers.

Ornith-1.5-35B-A3B vs Qwen3.6-35B-A3B vs Qwen3.5-35B-A3B

Same size, same active parameters, same architecture family. The differences are training, license, and how easy each one is to pull.

Sources: each model's own Hugging Face card (Ornith-1.5-35B-A3B, Qwen3.6-35B-A3B, Qwen3.5-35B-A3B), except the Qwen3.5 SWE-bench Pro, MCP-Atlas and Claw-Eval figures, which come from the Qwen3.6 card because the Qwen3.5 card doesn't report them. (The Qwen3.6 card also lists Qwen3.5 at 70.0 on SWE-bench Verified, against 69.2 on its own card.) Qwen's own cards only report Terminal-Bench 2.0 (51.5 for Qwen3.6, 40.5 for Qwen3.5), so the 2.1 row isn't a like-for-like comparison with Qwen's numbers. Download sizes are from each model's Ollama tags page on 13 Oct 2026, include the vision projector and exclude the KV cache.

The read: Ornith leads on every agentic coding row, by 5.6 points on SWE-bench Verified and 10 on SWE-bench Pro over Qwen3.6. Qwen3.6 is the pick if you want Apache-2.0, or an Ollama tag that Ollama itself lists with tool calling and thinking support.

The Ornith-1.5 family

The 9B is the one for 8GB to 16GB machines, the 35B-A3B is the single-24GB-card model this post is about, and the 397B is datacenter hardware only.

Hardware requirements, by quant

This is the question everyone actually has, so here are the file sizes straight from the GGUF repo, plus what you need around them.

Two things the table hides. First, context eats memory fast: the card's reference vLLM setup uses two 80GB GPUs specifically to leave headroom for 256K. On a 24GB card at Q4 you'll run 16K to 32K comfortably and should not expect 256K. Second, because only 3B parameters activate per token, decode speed scales with the 3B active, not the 35B total, which is the MoE dividend. Neither the Ornith team nor Ollama publishes a tokens-per-second figure for a 24GB card, so measure it on your own hardware rather than trusting a number from a thread.

Minimum I'd actually recommend: 24GB VRAM or a 32GB Apple Silicon machine for Q4_K_M. Below that, this is the wrong model and the 9B is the right one; the Gemma 4 12B vs Qwen 3.5 9B post covers that tier.

How to run it on Ollama

The GGUF repo publishes an Ollama pull directly, and it's the one to use for agents:

ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M

Drop the tag to get the repo default, or swap Q4_K_M for any quant in the table. Ollama's qwen3.5 architecture support handles the hybrid MoE layout, so this works on a current Ollama without a custom Modelfile for chat. The library tag ollama run ornith-1.5:35b gets you the same Q4_K_M weights for chat, without the tools capability.

Tool calling needs one check before you trust it. Ornith emits <tool_call> blocks that a server-side parser turns into OpenAI-style tool_calls; on vLLM that's --tool-call-parser qwen3_xml, and the card notes it adjusted the Qwen chat template for its own benchmarks. On Ollama, the hf.co pull uses the template embedded in the GGUF, which is usually fine for this architecture, but verify it with a single tools request before wiring it into an agent. (The ornith-1.5 library tag doesn't list the tools capability at all, checked 13 Oct 2026.) If the model returns raw <tool_call> text inside content instead of a structured tool_calls field, you have a template problem, not a model problem. Our Ollama tool-calling support reference has the test call and the Modelfile fix.

Sampling that the card recommends for general use: temperature 0.6, top_p 0.95, top_k 20. It's a reasoning model, so expect a thinking block first; for short agent turns where you don't want it, /nothink in the system prompt or think: false in the API cuts it, at some cost to multi-step quality.

Ornith vs Gemma 4 12B vs Qwen 3.5 9B

The searches landing on this site pair Ornith against Gemma 4 12B and Qwen 3.5 9B. That's the 9B Ornith's weight class, not the 35B's, so here's the honest version of the table: the published numbers side by side, with a note on where they came from.

Sources matter here. The Ornith-1.5-35B row is from its own card. The Ornith-1.0-9B, Gemma 4 12B, and Qwen 3.5 9B rows are from the Ornith-1.0-9B card, where the Ornith team ran all three through the same evaluation setup. That's a vendor-run comparison, and Google and Alibaba didn't publish those two benchmarks for those two models, so treat the gap as directional. It's a large gap even with a generous discount.

The table still shows Ornith-1.0-9B because that's the card with the Gemma and Qwen runs. Ornith-1.5-9B is out now (18 Aug 2026) and edges past it: 70.6 vs 69.4 on SWE-bench Verified and 46.2 vs 43.1 on Terminal-Bench 2.1 (Terminus-2), per its own card.

The practical read: if you have 8GB, Ornith 9B replaces Qwen 3.5 9B for coding and matches it on VRAM. If you have 24GB, the 35B is a different tier, and the only real local competitor is Qwen3.6-35B-A3B, which it beats on every published row. Gemma 4 12B's edge is native audio and a slightly more polished multimodal decoder, which isn't what a coding agent needs.

Setting it up in OpenClaw and Hermes

Both frameworks talk to any OpenAI-compatible endpoint. The model card doesn't ship framework-specific commands for either; it gives environment variables and leaves the rest to you. Serve the model first, either with Ollama (port 11434, /v1 path) or llama.cpp on the card's port:

llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M --port 8000 -c 32768

The card's version uses -c 262144; 32768 is what actually fits next to Q4 weights on a 24GB card.

OpenClaw

The card's OpenClaw block is three environment variables:

export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"
export OPENAI_MODEL="ornith-ai/Ornith-1.5-35B-A3B"

If you'd rather keep it in config, OpenClaw reads JSON5 from ~/.openclaw/openclaw.json. A custom provider needs each model listed with both an id and a name, and the agent's model ref goes under agents.defaults.model.primary:

{
  models: {
    providers: {
      "llama-cpp": {
        baseUrl: "http://localhost:8000/v1",
        apiKey: "EMPTY",
        api: "openai-completions",
        models: [
          { id: "ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M", name: "Ornith-1.5-35B-A3B" },
        ],
      },
    },
  },
  agents: {
    defaults: {
      model: { primary: "llama-cpp/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M" },
    },
  },
}

For Ollama instead of llama.cpp, use OpenClaw's native Ollama provider (api: "ollama", baseUrl: "http://127.0.0.1:11434", no /v1) and the hf.co/... model name; OpenClaw's docs warn that the OpenAI-compatible Ollama URL breaks tool calls. If the agent starts but tool calls come back as text, see the template note above; the local model not working decision tree walks the rest.

Hermes

Same idea, with one difference in the variable name. The card's Hermes block uses MODEL rather than OPENAI_MODEL:

export OPENAI_BASE_URL="http://localhost:8000/v1"
export OPENAI_API_KEY="EMPTY"
export MODEL="ornith-ai/Ornith-1.5-35B-A3B"

On llama.cpp or Ollama, swap the model name for the one your server actually reports.

One setting that matters on both: context. A 35B-A3B at Q4 on a 24GB card does not have room for the 256K the model supports. Set the server's context to what fits (32K is a sane start) and let the framework's context management handle compaction, rather than letting the server silently truncate.

Where it fits in a routing stack

Here's what nobody tells you about local coding models: the win isn't replacing your cloud model. It's making the cloud model optional for the tasks that don't need it.

Ornith-1.5-35B is the model I'd route to for local coding work: refactors, test writing, code review, terminal tasks inside a repo, anything where the code shouldn't leave the machine or the volume is high enough that $10 per million output tokens hurts. On those tasks it's within striking distance of frontier models on the benchmarks and costs electricity.

It is not the model for web research, long-context reasoning over a quarter of Slack, or anything that needs a 1M window on consumer hardware. Route those to a cloud model. And for the fifty-a-day triage tasks (classification, drafting, summaries), a cheap cloud model like DeepSeek V4.1 Flash (deepseek-flash, $0.30 input and $1.20 output per million tokens at peak, half that off-peak) is faster and doesn't tie up your GPU.

The routing rule ends up simple: code in a repo goes local, everything else goes to the cheapest cloud model that clears the bar, and a frontier model is reserved for what measurably needs it. That's the same logic as the OpenClaw model routing guide, with one more slot on the local side.

If you'd rather set that up as per-agent model selection than as config files, that's how BetterClaw works: bring your own keys for the cloud models, point an agent at a local endpoint for the ones that should stay home, and track what each agent costs. Free plan, no card, one agent with 100 credits a month.

The honest verdict

Ornith-1.5-35B-A3B is the best local coding-agent model I've run on a single 24GB card, and it isn't close. The MoE dividend is real: 35B quality at 3B speed. The reasoning block is worth keeping on for multi-step work and worth turning off for one-shot tool calls.

What it isn't is a general assistant. Its lineage is Qwen, its training is coding scaffolds, and its benchmark lead is on exactly those. Use it for what it was built for, route around it for the rest, and the "MIND BLOWING" thread starts to look accurate rather than excitable.

If any of this resonated, give BetterClaw a try. Free plan with 1 agent and 100 credits a month, bring your own API keys, no inference markup. Pro is $49 a month for 5 agents. Local endpoints and 28-plus cloud providers on the same agent, with cost tracking on each. Start free or see full pricing.

Frequently Asked Questions

What is Ornith-1.5-35B-A3B?

It's an open-weight, MIT-licensed mixture-of-experts model for coding agents from the Ornith team (DeepReinforce), built on the Qwen 3.5 MoE architecture with about 35B total parameters and roughly 3B active per token. It has 262K native context, vision input, a default thinking block, and tool calling, and posts 79.0 on SWE-bench Verified and 68.5 on Terminal-Bench 2.1 when run through Claude Code per its model card. For agents, run it with ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M. The Ollama library's ornith-1.5:35b tag works for chat but isn't listed with tool support, and the plain ornith model is the older, text-only Ornith-1.0.

How does Ornith-1.5-35B-A3B compare to Qwen3.6-35B-A3B and Gemma 4?

On the model card's published rows it beats Qwen3.6-35B-A3B on every coding and agentic benchmark (79.0 vs 73.4 SWE-bench Verified, 59.6 vs 49.5 SWE-bench Pro, and 67.8 vs 52.5 on Terminal-Bench 2.1 Terminus-2 in the Ornith team's runs) at the same size and speed. Qwen3.6 keeps the Apache-2.0 license and an Ollama tag that Ollama lists with tool calling. Against Gemma 4 31B the gap is wider still on agentic coding. The Gemma 4 12B and Qwen 3.5 9B comparisons belong to Ornith's 9B, which the Ornith-1.0-9B card shows leading both.

How do I run Ornith-1.5-35B-A3B on Ollama with tool calling?

Pull it with ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF:Q4_K_M (the library tag ornith-1.5:35b isn't listed with tool support), then send one test request with a tools array before wiring it into an agent. If the response has a structured tool_calls field you're set; if the call appears as raw <tool_call> text in content, the embedded chat template needs a Modelfile override. Use temperature 0.6, top_p 0.95, top_k 20 for general work.

Is Ornith-1.5-35B-A3B worth running locally instead of a cloud API?

For high-volume coding inside a repo, or code that can't leave the machine, yes: at Q4 it runs on a single 24GB card or 32GB Mac, decodes at 3B-model speeds, and costs electricity rather than $10 per million output tokens. For web research, very long context on consumer hardware, or cheap triage tasks, a cloud model is faster and often cheaper once you count the GPU's time.

Is Ornith-1.5-35B-A3B reliable enough for unsupervised agent work?

As reliable as any open-weight model this size, which means: good on structured tool calls, strong on terminal tasks, and still a model that will confidently do the wrong thing if the agent framework lets it. Run it behind the same controls as a cloud model, action approvals on anything that writes to production, a sandboxed working directory, and a cost or time cap per task. The model card's evaluations disabled network access for a reason.