ornith-1.5-35b: the Ornith 1.5 35B-A3B chat model as a metered API

ornith-1.5-35b is this platform's serving alias for Ornith 1.5 35B-A3B, the mid-size model of the Ornith 1.5 family that Ornith AI released in August 2026. It is a mixture-of-experts chat model. It has 35 billion parameters in total and about 3 billion active per token. It is MIT-licensed, with a 262,144-token native context window and a reasoning mode you can switch per request. This page gives the identity facts with their owners. It gives an honest split between hosting it here and running it yourself. It also gives the exact call contract and the throughput numbers measured on the reference GPU class, dated. The model is coming soon on this platform. No date is promised.

Last verified: 2026-09-25

What it is

The interesting number pair in this model is 35B total against about 3B active. A router picks 8 of 256 expert blocks for each token, so a forward pass only reads a small slice of the weights. Speed follows the active count. Memory follows the total count. All 256 experts must sit resident. That split is why the same model can decode fast on a single 24 GB card while needing about 70 GB of storage for full-precision weights. That fact drives every hosting decision on this page.

Ornith 1.5 is the second generation of a self-improvement training program. Per the official release blog, Ornith 1.0 was built on top of Qwen3.5 and Gemma 4 with additional pretraining and post-training. Ornith 1.5 extends the loop. Instead of training against a fixed set of human-written tasks, the model generates its own tasks and builds its own scaffolds for them. It then improves through reinforcement learning over the results. The family spans three sizes: a 9B dense model (with a mobile build for phones), this 35B MoE, and a 397B MoE flagship.

The facts that matter for planning, each with its owner:

Two of those rows need plain words. The context window is 262,144 tokens in the model itself. The card extends it to roughly one million through YaRN RoPE scaling when a task truly needs it. This platform's route sells a 100,000-token window, set by the platform's route configuration rather than by the model. If you need more than 100k, the model supports it and this route does not. The modality row needs plain words too. The model family carries vision-capable tags on its card. Ollama distributes a separate vision projector for it. But this platform serves the pinned text build, so this route is text in, text out.

Against its peer group, the model card claims a clear lead. It sits significantly ahead of Qwen 3.6 35B-A3B across its published coding and agentic benchmarks. It is ahead of larger dense models on agentic coding too. Those are the publisher's own numbers, measured on the publisher's named harnesses. The Benchmarks section below puts them next to the independent record, which is less uniform.

On this platform the model answers to ornith-1.5-35b on the chat route, alongside the rest of the chat catalog. It is coming soon, with no date, and the models index reflects the catalog as it stands.

Use cases

The card's own emphasis, and the community's daily-driver reports after release, point at the same jobs:

• Tool-calling agents. The model emits well-formed function calls that parse into the standard tool_calls field. The card's agentic results (MCP-Atlas 70.2, Toolathlon-Verified 48.7 on its own table) are built on that behavior. Community daily-driver threads single out tool selection as its strongest habit.
• Terminal coding agents. The card is explicit that the model is tuned for OpenAI-compatible coding CLIs. Point one at the endpoint and it is meant to hold up on repository-scale work. That is also where its self-checking behavior shows. It plans, executes, and verifies before answering.
• Long-context reading. A 262,144-token native window makes whole-repository and long-document prompts realistic. On this route the practical ceiling is the 100k window. That still holds a large codebase or a long transcript.
• General chat with a thinking switch. It reasons by default and can skip the reasoning pass when a request is simple. That saves latency and tokens on trivial turns.
• What it is not for on this route: image input (text build only), and, per repeated community reports, heavy compression chores and other mechanical tasks where smaller models do fine.

Local or hosted: the honest split

This model has a real local ecosystem, and for some readers the right answer is to download it. The split:

Run it locally when a 24 GB-class GPU or a 32 GB Mac is already on the desk and traffic is steady. Run it locally when you want the community quant ecosystem. The official repository ships Q4_K_M, Q5_K_M, Q6_K, and Q8_0 builds, and independent repackagers ship more. Run it locally too when the data must not leave a boundary you control. Ollama's library carries it as ornith-1.5:35b, a 22 GB Q4_K_M model plus the 903 MB vision projector, about 23 GB in total. The official card gives exact vLLM and SGLang recipes for bigger iron. The floor is lower than you might expect. With the expert weights offloaded into system RAM, a 12 GB card runs it, slowly.

Call the hosted route when there is no GPU to dedicate or traffic is bursty or occasional. Call it hosted when you want the metering, key revocation, and billing ledger wrapped around the model. Or call it hosted when you would rather not own the running of it yourself. A pinned build and a route kept ready are the real work this platform performs for the model. The Benchmarks section names each piece.

One honest warning that belongs to this model specifically: quality moves with the build. Community testing after release graded the quant ladder hard, from passable at 4-bit to a clear step up at 8-bit. Different distributors ship different files under the same quant name. The official Q4_K_M, for instance, is not byte-identical to independent Q4_K_M repacks of the same model. When you compare hosted routes for this model, ask which build is served. This platform's answer is public below: the official Q4_K_M GGUF, pinned by checksum.

If the job is small, the 9B sibling runs in this catalog too. If you need more context than this route's 100k window, other chat models in the catalog serve larger windows. The models index maps them.

API usage

The route is POST /v1/chat/completions, OpenAI-compatible in shape. It carries a Bearer key issued on the console. The model id is ornith-1.5-35b.

Four laws of this route that save debugging time:

1. The thinking knob is reasoning_effort, and the nesting is done for you. The model's own server reads its thinking switch from a nested chat_template_kwargs object in the request body; a top-level field is a silent no-op at that layer. You do not send the nested object. The gateway maps reasoning_effort onto the model's nested switch on the way through. If you send a top-level enable_thinking or a chat_template_kwargs of your own, the gateway answers with a named unknown-parameter error, because the contract accepts only documented parameters. One name in, correct nesting out.
2. Reasoning arrives separated. When thinking is on, the model's reasoning text comes back in a reasoning_content field, distinct from the answer in content. On streamed responses the reasoning deltas stream first.
3. Every response carries your cost. The usage object that comes back includes cost, the retail charge for that call at this platform's rates. It is computed from the input, cached-input, and output token counts. Recording the call and debiting the prepaid wallet happen in one transaction, and the wallet balance is the stop. Per-key spend caps are on the roadmap, not live. Per-key revocation is live.
4. Deep fresh contexts take time to first byte. The route serves a 100,000-token window. A request whose entire context is new (no cached prefix) prefills at a measured 2,350 tokens per second at the 100k mark. That is about 43 seconds before the first output token. Long conversations with a stable prefix prefill much faster. Budget the first call accordingly.

curl

curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ornith-1.5-35b",
    "messages": [
      {"role": "user", "content": "Write a one-line Python lambda that squares a number."}
    ],
    "reasoning_effort": "minimal",
    "max_tokens": 1024
  }'

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    json={
        "model": "ornith-1.5-35b",
        "messages": [
            {"role": "user", "content": "Refactor this loop into a list comprehension and explain the change."},
        ],
        "reasoning_effort": "high",
        "max_tokens": 2048,
    },
    timeout=120,
)
resp.raise_for_status()

message = resp.json()["choices"][0]["message"]
# The thinking pass, when enabled, lands in reasoning_content;
# the answer itself is in content.
print("reasoning:", message.get("reasoning_content"))
print("answer:", message["content"])

openai-sdk

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

response = client.chat.completions.create(
    model="ornith-1.5-35b",
    messages=[
        {"role": "user", "content": "What is in the tools array I should pass you for file search?"},
    ],
    tools=[
        {
            "type": "function",
            "function": {
                "name": "search_files",
                "description": "Search a repository for a pattern",
                "parameters": {
                    "type": "object",
                    "properties": {"pattern": {"type": "string"}},
                    "required": ["pattern"],
                },
            },
        }
    ],
    tool_choice="auto",
    reasoning_effort="high",
    max_tokens=2048,
)

message = response.choices[0].message
if message.tool_calls:
    call = message.tool_calls[0]
    print(call.function.name, call.function.arguments)
else:
    print(message.content)

An OpenAI-SDK integration already in production shifts here with two lines changed: the base URL and the model id.

Benchmarks

Two layers of evidence, both dated, and both carrying their basis.

This platform's lane. Measured 2026-08-22 on a US-hosted RTX 3090, 24 GB. The measurement record is the platform launch catalog, section C, with the full basis recorded beside the model's row.

For calibration against the community record: independent post-release testing lands in the same range. The tests ran this model on the same card class under llama.cpp. That range is roughly 130 to 172 tokens per second. The range is condition-dependent: quant file, context depth, synthetic versus live basis, speculative decoding on or off. A widely shared figure of 155 tokens per second on a 4090 traces to a single social post that never named its engine. Treat it as flavor, not data. Our 136.2 is a live-service, single-stream, through-the-gateway number. That is the honest basis for planning a hosted workload.

One caveat we state before you ask: the card's benchmark table below comes from full-precision reference serving, and this route serves the pinned Q4_K_M build. The community quant ladder for this model is steep and 4-bit is its floor. If your evaluation of this model happens on this route, you are evaluating the Q4_K_M lane, not the reference model. That is the same build class as the default local distribution, so a local trial at the default quant transfers well.

The model itself. From the official model card, publisher-reported, with the harness named for each. SWE-bench Verified via OpenHands; Terminal-Bench 2.1 via Harbor/Terminus-2 and the Claude Code harness; DeepSWE via the Claude Code harness; all at temperature 1.0.

Read that table with its label on: self-reported, reference configuration, harnesses named. The independent record so far is thinner and less uniform. One published independent run after release had the 35B trailing a smaller Qwen release on Terminal-Bench 2.1, SWE-bench Pro, and DeepSWE. Community daily-driver threads praise its tool calling and simultaneously report coding slips and refusal streaks. None of that settles the question. It defines the honest state of the evidence while the model is three weeks old. If a workload matters, run it on your own tasks before committing, on this route or any other.

Getting started

1. Get an account via the console. The console's invite flow is the entry during beta. Wallet balance and key rotation are managed there.
2. Cut an API key per project. Keys are independent shutdown switches. Kill a compromised one and the rest serve on. Spend is bounded by the wallet balance for now. Per-key ceilings are still roadmap.
3. Check the rate. Each leg of the call, input, cached input, and output, bills at its own rate from the pricing page. The usage.cost field reports the running total on every response.
4. Make the first call. Lift the curl tab, export KEY, and fire a one-liner with reasoning_effort: "minimal" for a quick first reply. From there the same request simply carries a longer messages array.

For a deep fresh-context first call, expect the prefill time from the Benchmarks table. Set your client timeout past it. The chat category page rounds up the other chat lanes, and the models index is the platform-wide view.