Ornith 1.5 35B-A3B is an open-weight mixture-of-experts model aimed at coding agents, terminal work, tool use, and long-running software tasks. It has roughly 35 billion total parameters but routes each token through about 3 billion active parameters. The weights still have to fit in memory: “3B active” describes inference compute, not a 3B-model download or memory footprint.

This is research-based coverage of the official model card, configuration, and Ornith 1.5 technical write-up. We have not run the model or independently reproduced its benchmark results.

Ornith 1.5 specs

Specification	Ornith 1.5 35B-A3B
Model ID	ornith-ai/Ornith-1.5-35B-A3B
Release	August 18, 2026 on Hugging Face
Architecture	Qwen3.5 MoE (Qwen3_5MoeForConditionalGeneration)
Parameters	Approximately 35B total, 3B active per token
Experts	256 routed experts, top 8 selected per token
Layers	40: 30 linear-attention and 10 full-attention layers
Native context	262,144 tokens, combined input and output
Inputs / outputs	Text and images in; text out
License	MIT
Vocabulary	248,320 tokens
Official runtimes	Transformers, vLLM, SGLang, llama.cpp/Ollama through GGUF, MLX

The project does not document a separate fixed maximum output length. The native 262,144-token window is a combined context budget. Ornith also documents YaRN scaling toward roughly one million tokens, but warns that always-on scaling can reduce quality at ordinary context lengths.

Is Ornith based on Qwen or Gemma?

The exact 35B-A3B checkpoint uses the Qwen3.5 MoE model family and tokenizer structure. Its config declares qwen3_5_moe, with Qwen-style reasoning and tool-call parsers in the official serving commands.

The broader lineage needs more nuance. Ornith says version 1.0 was developed on top of Qwen3.5 and Gemma4 through continued pretraining, mid-training, and post-training; Ornith 1.5 then extends that project with a self-improvement training approach. That does not make this checkpoint a Gemma fine-tune. Qwen3.6 appears in Ornith’s comparison tables, but it is a benchmark peer rather than the declared base architecture.

What the self-improvement claim means

Ornith describes a reinforcement-learning loop that improves more than model weights. It jointly works on generated tasks, the scaffolds and harnesses used to solve them, and the resulting rollouts. The practical goal is better long-horizon behavior in terminals, repositories, and tool-using environments.

That positioning makes Ornith more relevant to coding-agent research than a general chat benchmark would. It also means the published results depend heavily on each benchmark’s harness, tools, context, and judge. Treat them as project-reported evaluations, not independent proof of real-world superiority.

Project-reported coding and agent benchmarks

Benchmark	Ornith 1.5 35B-A3B	Important setup note
SWE-bench Verified	79.0	OpenHands; network disabled; five-run average
SWE-bench Pro	59.6	Project evaluation; five-run average
SWE-bench Multilingual	71.4	Project evaluation; five-run average
Terminal-Bench 2.1, Terminus-2	67.8	Terminus-2 harness
Terminal-Bench 2.1, Claude Code	68.5	Claude Code harness with Ornith as the model
MCP-Atlas	70.2	500 public tasks; Opus 4.8 used as judge
Toolathlon-Verified	48.7	Project-reported tool-use evaluation

All figures above come from Ornith’s own model card or technical report and were reported as averages over five runs. They had not been independently reproduced when this article was published.

Hardware and memory: why 3B active is not a 3B footprint

Ornith’s official deployment notes put the BF16 weights at roughly 70 GB and recommend two 80 GB GPUs when serving the full 262K context with headroom. That is the clearest supported production baseline.

Quantization reduces weight storage, but runtime memory also includes KV cache, framework overhead, image processing, and the chosen context length. A 4-bit estimate for 35–36B weights starts around 18–22 GB before that overhead. A 24 GB GPU may therefore load an aggressive quantization at a shorter context, but it should not be presented as a verified full-context configuration. Unified-memory Macs can use the official MLX quantizations, provided total system memory leaves enough room for the OS and cache.

Official Ornith releases currently include GGUF, FP8, NVFP4, MLX, and 4/6/8-bit MLX variants. Choose the format that matches your runtime rather than assuming the smallest file preserves the same quality.

Run Ornith 1.5 with Ollama or llama.cpp

Ornith publishes a GGUF repository and gives these direct examples:

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

Or use llama.cpp’s server:

llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF \
  --port 8000 \
  -c 262144

Do not request the full 262K context by default on constrained hardware. Start smaller, monitor memory use, and increase context only when the workload requires it. Our local AI guide explains the difference between model weights, quantization, context memory, and runtime overhead.

Serve Ornith 1.5 with vLLM

The official model card requires vLLM 0.19.1 or newer and provides an OpenAI-compatible server configuration:

vllm serve ornith-ai/Ornith-1.5-35B-A3B \
  --served-model-name Ornith-1.5-35B-A3B \
  --host 0.0.0.0 --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --trust-remote-code

For production tradeoffs, see our vLLM, Ollama, llama.cpp and TGI comparison and vLLM serving guide.

Serve it with SGLang

The official SGLang example requires version 0.5.9 or newer:

python -m sglang.launch_server \
  --model-path ornith-ai/Ornith-1.5-35B-A3B \
  --served-model-name Ornith-1.5-35B-A3B \
  --host 0.0.0.0 --port 8000 \
  --tp 2 \
  --context-length 262144 \
  --mem-fraction-static 0.85 \
  --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3

Ornith also documents Transformers 5.8.1 or newer. These minimum versions matter because older releases may not recognize the architecture or its reasoning and tool-call formats.

Hosted API availability

At publication time, Hugging Face returned no inference-provider mapping for this checkpoint, and we could not verify a listing on OpenRouter, Together, Fireworks, or Nebius. The official vLLM and SGLang commands create your own OpenAI-compatible endpoint; they are not hosted Ornith APIs.

The MIT license makes the weights free to use under its terms. Compute, storage, traffic, and operations are still real costs, and free weights do not mean “$0 API pricing.”

Ornith 1.5 versus nearby Qwen models

Qwen 3.5 supplies the declared architecture family. Ornith adds its own training process and agent-oriented evaluations. Qwen 3.6 35B-A3B is a separate Qwen release with a similar total/active parameter label and native context, not the parent checkpoint named in Ornith’s config.

Compare them on the workload you actually run:

• Choose Ornith for evaluation if repository agents, terminals, MCP tools, or permissive MIT licensing match your use case.
• Choose an established Qwen release if broader runtime adoption and more independent hardware reports matter more than the latest agent-focused training.
• Choose a hosted model if you do not want to operate GPUs, quantization, context memory, and an inference server.

Who should try it—and who should wait

Ornith 1.5 is a credible trial candidate for teams evaluating self-hosted coding agents, long-context repository work, MCP/tool use, or multimodal developer workflows. Its official quantizations and vLLM/SGLang instructions make it more deployable than a weights-only announcement.

Wait for more evidence if you need predictable throughput on a particular GPU, an SLA-backed API, audited safety behavior, or independently reproduced coding benchmarks. The project does not publish universal tokens-per-second figures or a consumer-hardware matrix, and benchmark harness results do not guarantee success in your repository.

Bottom line

Ornith 1.5 combines a Qwen3.5 MoE architecture, approximately 35B total and 3B active parameters, 262K native context, vision input, MIT licensing, and unusually detailed agent benchmarks. The release is technically substantial enough to evaluate—but not enough to declare a winner. Its strongest case today is controlled self-hosted testing, with project-reported results treated as a starting point rather than a verdict.