IronStratum

Ornith 1.5 local vs hosted: the break-even math

Running an open model on your own GPU or renting it per token is a volume question, and Ornith 1.5 is the worked example this guide uses to answer it: the family map across the 9B dense and 35B-A3B mixture-of-experts members, what each one needs in VRAM at each quantization, how fast it runs on named consumer cards including this platform's own dated measured baseline, which providers serve it hosted and at what published rates, and the crossover arithmetic that turns your electricity price and your street-price card into the daily token volume where local stops being cheaper.

All amounts in this guide are US dollar amounts, written as bare numerals, and token rates are per million tokens. This platform's own rates are never typed by hand: they render live from the catalog in the table directly above the formula, and every worked example substitutes only external anchors and fence-visible retail.

What ranks today, and what none of it answers

The pages that rank for running Ornith 1.5 locally are good pages, and the decision they serve is half of the question.

A local-AI app vendor publishes two install guides, one per runnable member, roughly 4,300 and 4,800 words each, with per-quant memory tables and their own quantized builds. They are the depth anchor for the local side, and local-only by construction: the hosted option never appears. A family comparison published 22 August 2026 frames the three sizes correctly and stops at deployment. An agent-tools vendor ran the middle model on a single A100 80GB on 20 August 2026 (about 74 GB resident, praise for its planning and self-verification), with no cost analysis. VRAM-fit trackers answer the will-it-fit question card by card.

The hosted side of the same results is two provider pages: a deployment preset on one cloud, and one inference vendor's model page with published token rates. Neither writes the decision, and the decision is the volume question this guide answers.

The demand is measurable: about 307,000 downloads on the official Ollama library page in three weeks, just over 2,000 stars on the official GitHub repository, and at least seven fresh threads on one large local-model forum arguing about the model inside the same window. The argument is the pointer: it is a speed-and-quality dispute, and measured numbers settle those.

The family in one table

Ornith 1.5 is three models under an MIT license: a 9B dense model, a 35B-A3B mixture-of-experts model, and a 397B flagship. All three accept text and image input, and all three document the same context window.

MemberShapeOllama tag and downloadNative context
Ornith-1.5-9Bdense, about 9B parametersornith-1.5:9b, 6.6 GB262,144 tokens
Ornith-1.5-35B-A3Bmixture of experts, 35B total, about 3B active per tokenornith-1.5:35b, 23 GB262,144 tokens
Ornith-1.5-397Bmixture of experts flagship, about 800 GB in BF16ornith-1.5:397b, 242 GB262,144 tokens

Tag names and download sizes are the official library listings, read 11 September 2026. A mixture-of-experts model keeps many specialist weight blocks resident and routes each token through a few of them; the 35B-A3B name says it directly, 35B total and about 3B active, 8 of 256 routed experts plus one shared expert per token by the official model config. The whole local-sizing story for this family is one sentence: speed follows the active count, memory follows the total.

The vendor describes the lineage as continued pretraining on top of Qwen3.5 and Gemma 4 followed by a self-improvement training loop; treat the story as the vendor's narrative, while the architecture facts above are what public config files and independent reads confirm. The 262,144-token window (written 256K in some listings, the same number in binary units) is native, and the official repository documents the YaRN recipe that stretches it toward one million tokens, with a caveat worth keeping: the scaling applies to every request and can slightly hurt quality at ordinary lengths. The 397B is a server model by its own deployment recipe, so the local-versus-hosted question is about the other two.

Local fit: what runs where, at which quant

Quantization (GGUF quants, in local-tool vocabulary) shrinks the weights at some cost in quality. File sizes first, from the static-quant listings on the mradermacher repository for the 35B-A3B and its 9B sibling, both read 11 September 2026:

Quant9B file35B-A3B fileWhat to expect
Q2_K3.9 GB13.3 GBdistress tier, visibly degraded
Q3_K_M4.7 GB17.3 GBusable, notably lower quality
Q4_K_S5.5 GB20.5 GBthe usual floor for daily use
Q4_K_M5.7 GB21.8 GBthe default most guides land on
Q5_K_M6.6 GB25.4 GBa quality step up, still one file
Q6_K7.5 GB29.3 GBclose to lossless in practice
Q8_09.6 GB37.9 GBeffectively the original weights

A vision projector file adds 0.7 to 1.0 GB where image input is used. File size is not memory in use: a VRAM-fit tracker that sizes both members (tracker data published 19 August 2026) puts the 9B at about 6.4 GB of total VRAM at Q4_K_M with an 8k context, comfortable on any 8 GB card, and the 35B-A3B at about 24.1 GB, which is why 24 GB cards sit at the edge and 32 GB is where it gets comfortable. Its sizing rule: budget the weights floor first, because the hybrid attention stack keeps only 8 of the 9B's 32 layers and 10 of the 35B's 40 layers growing a KV cache, so context is unusually cheap once the weights fit.

The middle path is the family's best trick. The experts are about 93 percent of the 35B's weights, but only about 3B of them run per token, so llama.cpp can park the experts in system RAM (the flags are --cpu-moe, or --n-cpu-moe N for a partial split) and keep attention, the router, and the shared expert in VRAM. A 12 GB card then serves the 22 to 23 GB build at usable, CPU-bound speed; a community thread titled around running the model on 8 GB of VRAM dates from the release window. Slower than full residence, and the honest answer for a small card. On a Mac, count roughly 75 percent of unified memory as usable, so a 32 GB Mac reads like the 24 GB row; official MLX builds at 4, 6, and 8 bits exist alongside GGUF.

How fast: measured, reported, and disputed

The speed picture has three layers, and they do not merge: our measurements, community reports, and vendor benchmarks.

Ours first. This platform's self-host fleet measured both members on single cards at release: 136.2 tokens per second for the 35B-A3B on an RTX 3090 (an official Q4_K_M build) and 47.2 tokens per second for the 9B on an RTX 3060 12GB (a Q5_K_M build), single-stream, recorded 22 August 2026 in the fleet's baseline table. The fleet that produced those numbers is currently stopped. They are a dated measurement record, not a serving promise, and this guide uses them the way you should use any number here: one labeled input, on named hardware, under named conditions.

The community layer: the most-cited forum datapoint is a thread from 28 August 2026 with 56 comments, in which a user on a 24 GB AMD card, Q4 build, 48k context, reported around 130 tokens per second with multi-token prediction enabled, called the model very good at tool calling, and named it a daily driver. That figure is community-reported, rides a different card and an MTP-enabled build, and is not merged or averaged with the 136.2 above. A community benchmark directory adds the MTP spread: up to 193.7 tokens per second for an MTP-patched 35B-A3B build on one RTX 5090 across two runs as of August 2026, and 98.3 peak for another MTP variant across six runs as of September 2026. Multi-token prediction, a head that proposes several tokens per step, is why the fastest community numbers cluster on high-end cards; the vendor added the MTP head upstream on 23 August 2026.

The same 28 August thread is also the honesty lesson, because its own top comments contradict its author. The top-voted reply (score 27) ran the 35B at Q8 through daily agentic work, tool calls, a firewall scan, and codebase recon, and wrote that all of it fell hilariously short, hard pass. Other replies in the same thread: it is just so bad at coding, I don't understand the glaze; I would rather use a slow Qwen 3.8 27B than a fast Ornith 1.5; a dismissal of benchmaxxing for hype; and a report of the model arguing with itself near 110k of context. Even the pushback concedes one point: tool calling is good, but it writes buggy code and cannot fix its own bugs.

The vendor layer: the official tables (Terminal-Bench, SWE-bench Verified, and others) score the family strongly against named peers, and they are vendor-reported numbers; one hosted provider republishes them under a label that says, in effect, these are the vendor's figures, not ours, which is the right instinct. Independent reads are cooler: a local-test writeup from the release window reports a gap between published scores and local results, and a tracker's comparison table deliberately includes rows where this family loses. The working rule: speed is measurable and settled above; quality is a live dispute, so run the model on your own tasks before you buy a card for it.

Hosted: who serves it, at what published rates

Hosted inference for this family already exists, which is the demand proof, and each lane prices differently.

One inference vendor serves the 35B-A3B at published token rates: input 0.25 and output 1.20 per million tokens, cached input 0.09, with a lower promotional column running when this guide read the page on 11 September 2026 (provider model page). A second cloud publishes a serving preset for the same member, two H100s with FP8 weights at a 256K context (provider documentation); that lane rents the whole serving stack per hour, publishes no per-token price, and the formula below does not price rented clusters.

This platform's catalog lists both runnable members, ornith-1.5-35b and ornith-1.5-9b, with published per-million-token rates on the pricing page, a 100,000-token window configured per lane, and a lower rate for cached input. Metering runs against a prepaid wallet: a key whose balance reaches zero is denied at request time, a production behavior verified 11 September 2026, so a runaway loop's worst case is a top-up rather than a debt. Per-key spend caps are an industry practice worth asking any provider for; they are not a shipped feature here, and the wallet floor is the hard stop today. The full treatment of metered-spend failure modes is its own guide: how to avoid API bill shock.

The break-even math

Here is the question nobody ranking answers: at what daily volume does the card in your desk beat the per-token bill? Six inputs, one fence. The fence renders this platform's live catalog rates; the formula's hosted-rate variable reads straight off it, and any provider's published rates substitute the same way.

ModelContext$/1M in$/1M out$/1M cached
Qwen
qwen3.8-27b262K$0.35$2.55$0.105
qwen3.6-35b131K$0.11$0.8$0.044
Minimax
minimax-m2.7197K$0.24$0.95$0.072
Muse
muse-glimmer-30b131K$0.28$1.2$0.084
Ornith
ornith-1.5-35b100K$0.35$2.55$0.105
ornith-1.5-9b100K$0.1$0.3$0.03
Glm
glm-5.3-flash1049K$0.11$0.35$0.033
Deepseek
deepseek-v4-flash-07311311K$0.15$0.42$0.045
Gemma
gemma-4-31b-it262K$0.22$0.49$0.066
Deepseek
deepseek-v4-pro1000K$1.13$2.21$0.339
Chatterbox
chatterbox-tts$25/1M chars
Kokoro
kokoro-tts$15/1M chars
Pocket
pocket-tts$16/1M chars
Audio
audio8-tts$8/1M chars
Hayamimi
hayamimi-stt$0.6/audio-hr
Bge
bge-m3$0.05/1M tokens
bge-reranker-v2-m3$1.5/1k searches
Whisper
whisper$0.25/audio-hr
hosted cost per day  =  D x P / 1,000,000

local cost per day   =  G / (30 x A)  +  D x E x R / (v x 3,600,000)

crossover D*         =  G / (30 x A)  /  ( P / 1,000,000  -  E x R / (v x 3,600,000) )

The named variables:

  • D: output tokens per day. The crossover D* is the volume where both sides cost the same, counted in output tokens because that is what the card spends its time generating.
  • P: the effective hosted rate, n x P_in + P_out, where P_in and P_out are the input and output rates per million tokens read off the fence or any pricing page, and n is the input tokens billed per output token. Agent loops run n around 4; chat runs nearer 1.
  • G: what the hardware cost you. A used card, a whole build, or zero if the box already exists.
  • A: amortization months; 24 is this guide's default.
  • E: wall draw in watts while generating, whole system. Board power is the anchor: the RTX 3090 spec lists 350 W and the RTX 3060 spec lists 170 W, plus the rest of the box.
  • R: electricity price per kilowatt-hour in dollars. The EIA Short-Term Energy Outlook puts the 2026 projected United States residential average at 18.2 cents, so 0.182; your own bill governs.
  • v: local decode speed in output tokens per second. The worked tiers use the platform's measured pins from above, 136.2 on the 3090 and 47.2 on the 3060, recorded on a fleet that is currently stopped.

Input electricity is deliberately absent from the local side: measured fresh prefill on these cards runs 1,415 to 2,350 tokens per second, so the electricity in an input token is a small fraction of the electricity in a generated one. Hosted input billing is not absent; that is what n carries.

Two rules fall out of the shape. First, the denominator is a gap between the hosted rate and your marginal electricity, and at open-weights rates electricity is a real share of it: on the 9B tier at the fence rates, marginal electricity is 0.268 per million output tokens against an effective rate of 0.70, about 38 percent of that rate and 62 percent of the denominator. Cheap hosted rates are exactly where naive math forgets electricity. Second, the crossover moves inversely with the rate: halve P and D* climbs by more than double.

The sensitivity rule in one line: at the 35B tier and the fence rates, one dollar per million on the output rate moves the crossover by about 77,000 output tokens a day.

TierCard cost GAmortization per dayElectricity per 1M output tokensD* at the fence ratesD* at the external anchor
35B-A3B, used 30901,0001.390.167367,000683,000
35B-A3B, lower tracker price7000.970.167257,000478,000
9B, used 3060 12GB2700.380.268868,000194,000

Every row uses n at 4, 24-month amortization, the EIA price, and the measured decode speeds. Street prices are September 2026 tracker reads for used cards (3090 sold averages near 1,000, low reads 700; 3060 12GB sold reads 260 to 286, and the table works 270); the fence column reads the live table; the external anchor is the provider linked above. Every number regenerates from the script kept beside this guide.

Read the table in hours, not tokens: 367,000 output tokens at 136.2 tokens per second is about 45 minutes of flat-out generation a day, and 868,000 at 47.2 is over five hours. A coding agent that runs a few hours daily is the workload this math is written for. Chat-shaped traffic, n nearer 1, pushes every crossover further out: at the fence rates, roughly 508,000 on the 35B tier and 2.8 million on the 9B.

Two variants the table skips. An always-on box burns idle power around the clock: at a 60 W idle estimate the 3090 tier adds about 0.26 a day and moves its fence crossover to about 436,000, so let sleeping boxes sleep. And a card you already own sets G to zero: the crossover disappears, local marginal cost falls to electricity alone, between 0.17 and 0.27 per million output tokens on these tiers. That pair is the quiet headline: once the card exists, its tokens cost a fraction of any published hosted rate. The same arithmetic for speech models, worked in characters per day, is its own guide: TTS local vs API, the break-even math.

The same request, two ways

Every serving path in this story speaks the OpenAI chat-completions shape: Ollama locally, the vendor's own serving recipes, and this platform's endpoint. The local-versus-hosted choice is reversible, a base-URL change rather than a rewrite.

Local, the official tag from the library page and the local endpoint that Ollama has documented as OpenAI-compatible since February 2024:

ollama pull ornith-1.5:35b

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ornith-1.5:35b",
    "messages": [{"role": "user", "content": "Refactor this function to fail loudly on empty input."}]
  }'

Hosted, the same request through this platform's endpoint, where the model string is the registry alias:

curl -sS $IRONSTRATUM_BASE_URL/v1/chat/completions \
  -H "Authorization: Bearer $IRONSTRATUM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ornith-1.5-35b",
    "messages": [{"role": "user", "content": "Refactor this function to fail loudly on empty input."}],
    "stream": true,
    "reasoning_effort": "medium"
  }'

Four contract facts before the first hosted call. Unknown or unsupported parameters fail fast with a 400 that names the parameter, the gotcha when pointing existing OpenAI-written code at a new endpoint. Streaming always ends with a final usage chunk before the done marker, carrying the request's cost at six decimal places, so cost visibility is built into the stream. Reasoning_effort, accepted values minimal, low, medium, and high, is the reader-facing thinking control for this family, which ships with thinking on by default; lowering it is the cheap-tokens lever on short tasks. And one GET, /v1/credits, returns the wallet balance and trailing 30-day spend, the number to watch against your crossover.

The base-URL swap itself, the three lines that move any OpenAI SDK between providers, is the same mechanical change for every compatible endpoint and deserves its own treatment; the OpenAI-compatible API guide is that treatment, and the two blocks above make the point.

Decision rules

Your situationThe rule
Privacy-critical or air-gapped workLocal, full stop. No rate comparison beats a data boundary.
Steady agent volume above your D*Local. Compute D* with your street price, your bill, and the fence rates; every day past crossover is payback.
Episodic or bursty work below D*Hosted. A card idling between projects is all fixed cost.
You already own a capable cardSet G to zero. Marginal local cost is electricity alone, a fraction of any hosted rate; hosted wins on convenience.
An 8 to 16 GB card, and you want the 35BThe expert-offload middle path: experts in system RAM keeps the model yours and usable, at CPU-bound speed.
Fresh, very deep context dumpsPrefer the 35B tier. On a 3060-class card the 9B's measured prefill makes a fresh 100,000-token dump take over 110 seconds before the first output token; growing conversations are far cheaper.

Both runnable members are open weights under MIT, so both paths are legitimate, and this platform sells the hosted side: metered per million tokens against a prepaid wallet, at the rates on the pricing page. To put a small wallet behind a key: sign up.

Frequently asked questions

Can my GPU or Mac run Ornith 1.5?

The 9B, almost certainly: about 6.4 GB of VRAM at Q4_K_M with a modest context, so any 8 GB card qualifies, 12 GB cards can step up to Q6_K or Q8_0, and CPU-only runs work at lower speed. The 35B-A3B wants about 24 GB at Q4_K_M, so a 24 GB card holds it at the edge, a 32 GB card comfortably, and smaller cards hold it with the experts offloaded to system RAM. On a Mac, count roughly 75 percent of unified memory as usable. The 397B is a server model, about 800 GB in BF16.

Ornith 1.5 9B or 35B-A3B: which should I run?

Memory follows total parameters, speed follows active ones. Under about 16 GB of usable memory, the 9B. At 24 GB, the 35B-A3B at Q4_K_M, or the 9B at Q6_K and Q8_0 if your work rewards per-token quality over knowledge. For agentic coding and tool-heavy loops, the 35B-A3B is the center of gravity, and it decodes fast for its weight class because only about 3B parameters run per token. One caution: this guide's measured figures were taken on different cards (a 3090 for the 35B, a 3060 for the 9B) on a since-stopped fleet, so read them as per-card results, not a head-to-head.

How much VRAM does Ornith 1.5 35B-A3B need?

About 24 GB total at Q4_K_M (roughly 21 GB of weights plus cache), per tracker sizing published 19 August 2026: a 24 GB card is a tight fit, 32 GB the comfortable floor, Q8_0 about 42 GB, FP16 about 78 GB, which is why hosted FP8 serving lives on data-center cards. Two offsets help: only 10 of 40 layers grow a KV cache, so context is unusually cheap once the weights fit, and the expert-offload flags let a 12 to 16 GB card run it from system RAM at reduced speed.

Is Ornith 1.5 actually good, or benchmark hype?

The record is split, and the split is inside the community's own threads. The vendor's tables report strong scores against named peers; those are vendor-reported numbers. The forum thread that popularized the model's speed and tool calling carries its own top-voted rebuttal from a daily agentic user who found the coding output short of the claims, plus replies calling the enthusiasm glaze and benchmaxxing. One hosted provider republishes the vendor scores under an explicit not-ours label, and an independent local test from the release window reports a benchmark gap. Tool calling is the one competence both sides concede. Test on your own workload before buying hardware; the speed claims are the part independent numbers support.

Is there an Ornith 1.5 API?

Yes, several. One inference vendor serves the 35B-A3B at published per-million rates (input 0.25, output 1.20, read 11 September 2026). One cloud publishes a serving preset you deploy yourself on a pair of H100s, rented per hour. This platform lists both runnable members with published rates, a 100,000-token window, and an OpenAI-compatible chat endpoint metered against a prepaid wallet. If you already run the model locally in Ollama or llama.cpp, moving a request to a hosted lane is a base-URL and model-string change, not a rewrite.

Does Ornith 1.5 do tool calling well?

It is the community's most consistent positive report. The speed thread that started the debate called the model very good at tool calling even while other users attacked its coding quality, and the concession inside the rebuttal is that tool calling works while code quality disappoints. The official repository documents OpenAI-compatible tool calling and ships worked examples wiring the model to tool servers and agent frameworks. Pair the optimism with the split-quality caveat above.

What does hosted Ornith 1.5 cost versus my GPU's electricity?

A volume question with an arithmetic answer; the formula section above is the tool. On this guide's worked tiers, hosted is cheaper below roughly 367,000 output tokens a day on a 1,000 used 3090 at the fence rates, and below roughly 194,000 at the external provider's rates on a 270 used 3060; above those volumes the card pays for itself inside its amortization window. Once the card is paid for, its marginal cost is electricity alone, between 0.17 and 0.27 per million output tokens at the 2026 projected United States average price. Work it with your own numbers: your street price, your bill, and the rates on the pricing page.


Both runnable members of this family are open weights; the card in your desk and the hosted lane are the same model either way. Current per-unit rates sit on the pricing page, and a wallet plus a key takes minutes on the signup page.

Last verified: 2026-09-11