Ornith-1.5-122B: Coding Agents, Setup and Memory
Ornith-1.5-122B is an MIT-licensed reasoning and text-generation model with a Qwen3.5 MoE architecture. It supports tool calls and a native 262,144-token context. Start by choosing a checkpoint format and a serving runtime: the public BF16 weights occupy about 250GB, before runtime memory and request state.
Content reviewed:
Open the official Ornith-1.5-122B model card ↗Use this model
Official model repository
- Inspect official weights and configuration
Model card, downloads and license conditions.
Try a bounded repository task
- Ask an agent to fix one reproducible bug, run the relevant tests and explain the change.
- Check whether it recovers from a failed tool call and verifies its own edits.
- Compare the complete accepted change, including retries and waiting time, with your current model.
Choose an Ornith-1.5-122B checkpoint before hardware
The official repository provides BF16 tensors; its roughly 250GB storage figure does not describe a quantized download or peak GPU memory. Plan additional room for the runtime, request state and concurrent sessions. A 262,144-token context limit is a model capability, not evidence that every device can serve that context at useful speed.
For a smaller memory footprint, choose an explicitly identified quantization and read its own deployment instructions. The main card also mentions a separate Mobile variant. That reference does not establish a phone configuration for these BF16 weights. Likewise, its single-80GB-GPU statement lacks a matching quantization and memory recipe for the supplied weights; use a measured configuration before renting one card.
If your runner offloads experts to the CPU, include system RAM, CPU work and transfers in the deployment budget. A run that uses one GPU with offload does not establish that the complete model resides in that GPU’s memory.

Connect a runtime and an agent client
The model card calls for Transformers 5.8.1 or newer, vLLM 0.19.1 or newer, or SGLang 0.5.9 or newer. Its vLLM recipe uses the qwen3_xml tool parser and qwen3 reasoning parser; the SGLang recipe uses qwen3_coder and qwen3. Keep the parser with its runtime rather than copying one option across both servers.
Provision the exact weight format first, then follow the corresponding server recipe and connect an OpenAI-compatible client to its /v1 endpoint. Start with a short context and one request. Confirm that tool calls arrive as structured tool_calls and that the client separates reasoning from the final answer before giving it repository write access.
For precise coding, the card recommends temperature 0.6, top_p 0.95, top_k 20 and presence_penalty 0. Keep the checkpoint revision, runtime build, context, sampling and agent tools with the run record. A parser mismatch can turn an otherwise valid response into a failed agent step.
curl http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"Ornith-1.5-122B","messages":[{"role":"user","content":"Explain what this failing test checks before proposing a fix."}],"temperature":0.6,"top_p":0.95,"max_tokens":2048}'Measure the cost of finishing the change
Compare a fixed issue, repository revision and test command. Record model loading, prompt processing, generation, tool execution and retries. Count a run as accepted only when the requested behavior and tests pass; a short response that leaves work unfinished is not a cheap completed task.
For rented hardware, multiply the full allocation time by the hourly rate and add storage. As an illustration, a $4/hour allocation used for 30 minutes costs $2 before storage. If only two of four attempts are accepted, that session costs $1 per accepted result.
In the linked Reddit discussion, fgk55555 describes less thorough task completion than Qwen Flash Next, then clarifies the observation with a file-management example. The thread does not provide a reproducible coding benchmark with a pinned quantization, hardware and matched tasks. Use it to choose what to test, rather than to assign a token rate or success score.
Keep the 122B model separate from the earlier family
The Ornith 1.5 family article is dated August 2026 and describes the 397B, 35B and 9B models. Use the 122B card for this checkpoint’s current deployment instructions. Results for a 35B quantization or the Mobile variant do not establish the memory or task quality of the 122B BF16 release.
The card’s benchmark comparisons are the developer’s evaluations. An agent’s tools, task budget and stopping behavior can change the result you obtain in a repository. Keep your own test conditions alongside any published score you use when choosing a model.
Before you use it
- MIT permits reuse under its terms; retain the license notice when redistributing the weights.
How to get started
Choose the exact checkpoint and a compatible server, verify structured tool calls, then compare the full cost of an accepted repository change.
Sources
Sources (4)
- Official model card, MIT license and runtime recipes ↗
Source checked:
- Official BF16 file inventory and model configuration ↗
Source checked:
- August 2026 family article ↗
Source checked:
- Community agent discussion; incomplete measurement conditions ↗
Source checked: