Ornith-1 stress test: is this 35B local model finally agentic-ready?

01Where does Ornith-1 come from?

Ornith-1.0 was released in June 2026 by the DeepReinforce team. This is not a general conversational model simply labeled “coding”. The family was specifically post-trained for agentic programming tasks, using models from the Gemma 4 and Qwen 3.5 families.

Its particularity comes from its training method. DeepReinforce talks about self-scaffolding: during reinforcement learning, the model does not only learn to produce a solution. It also learns to improve the structure that guides this solution: search strategy, working memory, error management and tool orchestration.

To simplify, Ornith is not only trained to answer a question. It is trained to better organize his way of solving the problem. This is precisely what is expected of an agent: observe, act, verify, correct and repeat until the result is achieved.

02Why is the model so popular?

It was first the counter Ollama that caught my attention. The official page showed more than 303,000 downloads about a month after the model was made available. On Hugging Face, the total of counters displayed on the seven official repositories exceeded 11 million at the time of writing.

These figures must be interpreted with caution. A download does not necessarily represent a different person. A single user can retrieve multiple variants, and automated systems can also increase the counters.

They nevertheless show genuine interest. Ornith comes at the right time: many users are looking for a model that does not just write an isolated function, but that actually knows how to work in a project.

• a clear specialization in agentic coding;
• local variants accessible in GGUF;
• a context window announced at 256K tokens;
• an easy-to-understand MIT license;
• direct integration into Ollama;
• very high announced results for sizes 9B and 35B.

03The different variants of Ornith-1

The size displayed by Ollama is the distributed quantized file, not the total memory required. The context, the KV cache, the buffers and the agent tool add significant consumption.

04The results announced by the publisher

The following results are those published by DeepReinforce. They are useful for situating the family, but they are not a substitute for independent assessments. The benchmarks also use large contexts and specific agent environments.

The 35B is particularly interesting. In the publisher's figures, it obtains 64.2 on Terminal-Bench 2.1, against 52.5 for Qwen 3.6-35B. On SWE-bench Verified, the gap is smaller: 75.6 versus 73.4. This confirms an important idea: Ornith seems especially optimized to conduct a complete agentic task, not just to generate code.

05My test environment

My programming tests use a context of at least 64,000 tokens. This point is decisive: Ollama itself recommends a minimum of 64K for code agents. Increasing the context directly increases memory consumption.

The Ornith 35B model distributed by Ollama already weighs around 21 GB. On my two RTX 3060, there is therefore not enough VRAM left to comfortably accommodate the context, the KV cache and the buffers. Part of the work overflows to RAM and the CPU, with transfers via the PCIe bus.

ollama run ornith:35b

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

ollama ps

ollama launch codex

06Test 1: create a Flappy Bird

My first test became a classic: asking the model to create a Flappy Bird. The game is simple to understand. A bird moves forward automatically, the player makes it rise and must avoid pipes.

This type of project is extremely present in public data, tutorials and GitHub examples. Above all, it allows you to quickly check that the agent knows how to create several files, choose a technology, launch the program and correct a possible error.

07Test 2: a C calculator on two RTX 3060 GPUs

For the second test, I deliberately chose something less conventional: a calculator developed in C, with a real graphical interface inspired by Windows 3.1.

I didn't want a Python calculator made in a few lines with a modern library. I wanted to push the model towards a more restrictive environment: window management, buttons, events, native compilation and adaptation to macOS.

It was at this moment that my material limitations became visible. The quantized model, 64K context, and agent data no longer fit comfortably within the 24 GB of cumulative VRAM. Ollama and llama.cpp distributed the load between the two GPUs and system memory.

For a non-specialist reader, the problem is simple: the model spends part of its time moving data instead of calculating. The graphics cards no longer work in their optimal conditions and the generation rate collapses.

08The same test on a MacBook Pro M4

I ran the same exercise again on my MacBook Pro M4 equipped with 32 GB of unified memory. I closed all applications to leave as much memory as possible at Ollama.

The Mac blew for about 35 minutes, with the GPU used at 100%. The first result did display a calculator-like interface, but the buttons did not work correctly.

I explained the problems to the model. After about ten more minutes, he edited the project, recompiled the app, and got a working calculator in C on macOS.

The gain doesn't just come from eight additional gigabytes. Apple's unified memory allows the CPU and GPU to work in the same memory space. This avoids some transfers between system RAM and several dedicated graphics cards.

09Codex, Ollama and agent mode

I used two approaches to check if the orchestration tool actually changed the outcome.

The first was to launch Codex with Ollama as the local provider. Ollama now offers the ollama launch codex command, which configures Codex to use a local or remote model.

The second was through the command line experience launched from Ollama, with a real agent tool capable of reading files, modifying them, issuing commands and continuing the task. So I'm not talking about the simple cat obtained with ollama run.

In my setup, this second approach produced the best results. It seemed to respect the model's native settings better and handle long sessions better. Codex connected to the Ollama API worked, but less efficiently exploited the context available in my test.

10Comparison with GPT-5.6 SOL

I then asked Codex, with my Pro subscription and GPT-5.6 SOL, to create the same calculator in C.

Unsurprisingly, the first result arrived much more quickly and immediately seemed more successful. The funny thing is that the model encountered exactly the same problem: the interface was displayed, but it was impossible to click on the buttons correctly.

The cloud model, however, was more vocal in its diagnosis. It identified an issue with the handling of scale and coordinates on the Mac's Retina display. A second pass completed the application.

This comparison is not fair in the scientific sense: the models, infrastructure, quantization and orchestration tools are different. Above all, it measures what a user actually obtains with the means at their disposal.

11What this test actually shows

It’s a stupid test, and that’s precisely why it’s interesting. If I had asked for a Python calculator with a popular graphics library, Ornith probably would have finished in about ten minutes.

My goal was to move away from the most obvious path and place the model at the edge: C language, retro GUI, native macOS compilation, event handling and Retina scaling issue.

• a 35B model can now conduct a real local agentic task;
• the available memory is often more determining than the theoretical number of parameters;
• a 64K context completely transforms hardware requirements;
• the agent tool and its integration count almost as much as the model;
• local remains significantly slower than a leading cloud model;
• local models are progressing quickly enough to cover new uses.

Even six months ago, I would not have imagined obtaining this type of result so easily with a local model of this size. The weight of the model remains decisive, but training, orchestration and specialization now make it possible to do more with less material.

12What consequences for businesses?

The question is no longer simply which is the best model on the market. The real question is what level of power, privacy and cost is necessary for each use.

A DGX Spark or equivalent machine has 128 GB of unified system memory. It's not 128 GB of dedicated VRAM in the classic sense, but this architecture provides enough space to locally exploit models and contexts that are impossible to fit comfortably on a 24 GB card.

There are also intermediate options. A company can turn to a French company like Mistral, whose Le Chat has become Vibe, use a European offer or deploy certain models on its own infrastructure. It can reserve the most powerful American or Chinese models for tasks that actually justify the exposure and cost.

We must therefore stop treating AI as a uniform license purchase for all employees. Companies must experiment, measure and define their own service levels.

And for that, there is no need to search on LinkedIn for a profile with an invented title who presents himself as an absolute expert in a technology that we have all been using for only a few years. You have to start by tinkering, testing, breaking, measuring and starting again. This is still the best way to understand what is really possible.

SSources and details

• DeepReinforce — official GitHub repository of Ornith-1
• DeepReinforce — presentation of the self-scaffolding method and benchmarks
• Hugging Face — official models and variants of DeepReinforce
• Ollama — official Ornith library, sizes and downloads shown
• Ollama — documentation on context size and memory consumption
• Ollama — official integration with Codex
• Ollama — overview of the ollama launch command
• NVIDIA — DGX Spark official specifications
• Mistral — presentation of the company and its deployment possibilities

Download counts, variant availability, and runtime performance can change quickly. The values ​​presented correspond to the information visible at the time of writing.