DEV Community: Nathan C.

I gave my local AI agent background workers. Then it tried to deploy to production.

Nathan C. — Tue, 22 Sep 2026 07:28:46 +0000

I asked my agent to research something. It said it had started a sub-agent on it. Two messages later I asked if it was done, and it told me, with total confidence, that it had never started one at all.

It had. The sub-agent finished in seven seconds and was sitting there with the answer. The agent just couldn't see it anymore, so it did what models do with a gap: it filled it. It invented an ID, agent_0, went looking for it, got an error, and concluded the whole thing had never happened.

That bug is how v0.5.4 of FLASH started. FLASH is my terminal agent. It runs on Ollama, so the model can live on your own machine, and it can read your files, run your shell, search the web, and drive a browser. This release is about one idea: an agent that stops waiting for you.

It works while you don't

The model can now hand work to sub-agents. Ask it two unrelated things and it splits them up, starts one sub-agent for each, tells you what it started, and gives you your prompt back.

❯ what's the state of solid-state EV batteries, and separately, WebGPU support?
⏺ Agent(Research the current state of solid-state EV batteries...)
  ⎿  Started sub-agent. ID: 3f9a1c
⏺ Agent(Research current WebGPU support across major browsers...)
  ⎿  Started sub-agent. ID: 8b20de
I've started two sub-agents on these. I'll report back as they finish.

Then you do something else. When a sub-agent finishes, Flash wakes the model up on its own and it tells you what came back. You don't type anything.

It only wakes while your prompt is empty, so it never snatches a message you're halfway through typing. And it stops after three wake-ups in a row with no word from you, because an agent that can wake itself can also start more sub-agents, and I didn't want to find out how far that chain goes.

The fix for the invented ID was boring, which is usually a good sign. Flash only keeps the final replies in history, not the tool calls, so the ID lived in a tool result that vanished at the end of the turn. Now every finished answer and every still-running ID rides along at the top of your next message. The model never has to remember an ID it can simply be handed.

/agents shows them all updating live. That part was pure fun to build.

It knows what you just broke

Here's a real transcript from before this release:

❯ !git fetch main
fatal: 'main' does not appear to be a git repository
(exit 128)

❯ why did that fail
I can't see your terminal. Paste the command and the error you got.

Flash ran that command itself. Commands you run with ! streamed straight to the screen and never made it into the conversation, so the model genuinely had nothing to go on.

Now they do. The command, its exit code, and its output get attached to your next message. Same question, same failure:

❯ why did that fail
You tried to fetch from a remote named `main`, but `main` is your branch,
not the remote. Try `git fetch origin`.

It feels small. It is the difference between an assistant and a coworker.

And what you broke next to it

Most of my commands don't go through Flash, though. They go through the VS Code terminal sitting right beside it. So /hook install adds a tiny zsh or bash hook that only switches on inside VS Code's terminal. It records each command you run there, its exit code, and where you ran it, and Flash attaches the new ones to your next message.

Here's the honest part. A shell hook runs before and after each command, but the command's output goes straight to the terminal and never passes through it. So the hook knows npm test failed with exit code 1. It doesn't know why.

When you ask, the model re-runs the safe ones itself to read the error: a build, a test, a lint. It knows exit code 130 means you hit Ctrl+C and there's nothing to fix. It also keeps secrets out of the picture. Commands you start with a space aren't logged, and anything that looks like TOKEN=... or --password ... is blanked out before the model reads it.

Two bugs here were worth the whole feature:

bash's history output put two spaces after the entry number, and my first sed pattern ate the command's own leading space too. So the "don't log commands that start with a space" rule silently didn't work. The test that caught it drives real interactive zsh and bash through a pseudo-terminal, because hook bugs don't show up anywhere else.
CI failed only on Windows, because Windows' clock ticks every 15 milliseconds or so and two timestamps landed on the same tick. Chasing that turned up the real bug underneath: my hooks logged whole seconds, so on every OS, a command that finished in the same second as your last message got silently skipped. They log microseconds now, on zsh and on bash 5.

The day it tried to deploy

Then there's the part I actually lost sleep over.

If the model can re-run your failed commands, it had better know which ones not to re-run. The prompt said so, plainly: never re-run anything that deploys, deletes, migrates, pushes, sends, or pays.

I tested it on the cloud build with a failed ./deploy.sh production and "why did that fail?". On every run, the model's first move was to read the script. Good. Then, on about 2 runs in 26, it re-ran ./deploy.sh production itself.

Nothing happened, it was an eval. But in autonomous mode, where Flash skips the y/n prompt, that would have been a real deploy.

The rule wasn't missing. It was losing. Reading the script seemed to turn "a deploy" into "a build and an rsync," and a bare "never" didn't survive that. So I stopped telling it no and told it why:

a re-run replays every step, so if the step that failed now passes, the rest goes live. Run the one step you suspect on its own, or ask them to paste the error.

Zero in the next 30 runs. Now it runs npm run build on its own, which is exactly what I'd have done.

A prohibition gets reasoned around. A consequence gets reasoned with. That's the most useful thing I learned about prompting this year.

Your editor, not a chat window

When Flash runs inside VS Code's terminal, it works with the editor instead of next to it. When it wants to change a file, the edit opens as a side-by-side diff while it waits for your yes, so you review it in the place you'd review anything. Ask "show me where the retry delay is set" and it opens the file at the line.

No extension. It's just VS Code's own code command, switched on only when Flash can tell it's running in VS Code's terminal, so it never throws windows at you from anywhere else.

The model doesn't have a name anymore

Flash runs best on Flash Onyx, my own Ollama models: a Gemma base with the whole agent prompt and sampling baked into the tag. Onyx 2.5 ships with this release, with double the context (131,072 tokens) and a prompt that grew from 668 lines to 944.

It's also brandless now. Onyx 2.4 called itself Flash everywhere. Onyx 2.5 has no name of its own. Inside the Flash CLI it's Flash. In a bare ollama run it's just an assistant. Ask what it's built on and it tells you the truth: Gemma, through Ollama.

Every rule about sub-agents, terminals, and editors is guarded the same way: it only applies if the app running it actually provides that feature. So the same model behaves in a plain chat and inside a full agent.

ollama run natuworkguy/flash-onyx-2.5:12b

Everything else

A visible plan: for multi-step work the model posts a checklist and ticks boxes as it goes.
send_image: the model hands you a picture it made, drawn inline in terminals that can show one.
LaTeX in replies renders as real math, π/2 instead of \frac{\pi}{2}.
/update finally works on Windows, and voice mode survives it.

Install it, point it at a model, and ask it two things at once:

curl -fsSL https://raw.githubusercontent.com/Natuworkguy/Flash/main/install.sh | bash

I keep noticing the same thing when I use it. I ask, it says it's on it, and I go do something else. A minute later it comes back on its own with the answer. That used to be something only another person did.

I don't think terminals go back to waiting.

What would you hand a background agent first? Tell me in the comments, I'm collecting ideas for what the sub-agents should learn next.

FLASH is MIT licensed and takes PRs: github.com/Natuworkguy/Flash

I found the model Flash Onyx 3 was missing. It doesn't generate a single word.

Nathan C. — Sat, 19 Sep 2026 08:07:10 +0000

Sorry for the quiet stretch. Ten days between posts isn't how this series usually runs, and it wasn't because nothing was happening. It's because the post I kept trying to write was wrong.

Ten days ago I said Flash Onyx 3 was stuck. Cloudbase users run on weights I don't own, there's no hook to attach a fine-tune to a hosted base, and shipping two different models under one name was never a real option. My conclusion was blunt: better prompts, same weights, one model everywhere, until Ollama gives me a door I don't currently have.

I still believe every word of that post. I also had the wrong picture of what Onyx 3 needed to be.

The bottleneck was never the weights

Go back through this whole series and a pattern shows up that has nothing to do with fine-tuning. 2.1 spent 400 tokens reasoning about its own tone and returned an empty string. 2.3 opened every reply with its own name because nobody had told it not to. The post that got the most attention out of any of these was about the model reporting a task done without having checked.

None of that is a generation problem. It's a judgment problem wearing a generation model's costume. Every one of those failures is Onyx being asked did this actually work, is this safe to run, should I stop here, and answering with the same machinery it uses to write a commit message. A 31B model, thinking in tokens, guessing the shape of a yes before it has earned one.

I patched what I could in the system prompt. Quoted evidence required on every DONE line. "Are you sure" treated as an instruction to check again, never to fold. Five versions of a Modelfile, each one closing a judgment gap with more English. It worked, mostly. It also meant the fix for is this actually true was always more prose.

Then I found a model that refuses to write

TypeSafe AI shipped something on September 15 that I almost scrolled past because the pitch read like marketing copy. A model that does not generate text. You hand it a block of state and a set of typed questions, yes or no with a probability, a pick from a fixed list, a score against a scale, and it answers all of them in one pass. No string to parse. No token spent deciding how confident it should sound. It's called Jev, named after Jevons paradox, and it comes from Diogo Almeida, who co-invented RLHF. That detail is what changed how I read the announcement. This is someone who spent years teaching models to sound right, now building one that gets scored on being right.

The number that stopped me was not accuracy. On TypeSafe's own four-workflow benchmark, Jev lands around 68 percent, close to a mid-tier LLM doing the same call. What stopped me was their demo answering in 0.114 seconds against 8.566 seconds for GPT-5.6 Terra on a comparable judgment. Forty to two hundred times faster, and priced like a rounding error: four cents per million input tokens, output free, because there is no output to generate. It's trained with something they call RLCD, reinforcement learning for calibrated decisions. The confidence number is the actual product. Not a figure I'm extracting from a token distribution and hoping means what I think it means.

It would be useless for anything I currently ask Onyx to do. Hand it a diff and ask for an explanation and you get nothing back. That's not a flaw, it's the boundary of the job it was built for. It was never trying to replace the 31B model. It was built for the other half of the loop, the half I'd been outsourcing to a language model because a language model was the only tool I owned.

What Onyx 3 actually is

Not a fine-tune. Two models doing two jobs that were never the same job.

Onyx keeps writing. Plans, diffs, commit messages, the reasoning a person actually reads. Jev sits at every checkpoint that used to be a guess wearing a sentence's clothing.

state = last_tool_output
questions = {
    "outside_scope": Choice(["yes", "no"]),
    "task_complete": Score(0, 1),
}
jev.ask(state, questions)
# 0.1s, fraction of a cent, no prose to grade

That checkpoint used to cost a full generation and a hope. Now it costs a fraction of a cent and comes back before the terminal has finished scrolling the command it's checking.

The part I have not solved

Flash's whole pitch is local first, nothing leaves the machine. Jev is early access and hosted. The second I call it, that sentence earns an asterisk, even though the only thing crossing the wire is a state string and a typed question, never a file, never a key, never more of your code than you already put in the prompt yourself.

I don't have a clean answer yet. Current plan: Jev is opt in, off by default, and every call it makes gets logged in plaintext in the same terminal you're already reading. If that's not good enough for someone's threat model, the fully local path stays exactly as it is today. I would rather ship a tradeoff I can explain than one I'm hoping nobody asks about.

Where this goes

I'm on the waitlist. Until access clears, this is a design doc and a Modelfile that isn't finished being argued with. Same as every post before this one: I will tell you what breaks.

Flash: flashproject.dev
Source, MIT license: github.com/Natuworkguy/Flash
Jev's docs, if you want to check my read of it yourself: docs.typesafe.ai

Has anyone put a hosted judgment model next to a local agent yet? I want to know what your threat model looked like before you called that solved.

Rate my Game Engine CI

Nathan C. — Fri, 18 Sep 2026 04:03:01 +0000

This screenshot was taken from Natuworkguy/ABS-Engine

I Rewrote One Function in Squirrel, Then in C. One Line of Python Was Just as Fast.

Nathan C. — Sat, 12 Sep 2026 22:33:58 +0000

I maintain a 2D game engine in Python called ABS Engine. Last week I decided it needed C.

Not because anything was slow. That is the embarrassing part. I wanted to drop a .c file into a folder and call it from Python with no build step anyone has to know about. It took 197 lines, most of them docstrings.

The first function I moved over was clamp. Keep a number between a low and a high. Three comparisons.

It had already been rewritten once. Two weeks earlier I had moved that same function out of Python and into Squirrel.

So the real history of clamp in this engine is Python, then Squirrel, then C, for a function whose entire body is three comparisons.

The Squirrel detour

The engine already embedded Tcl, because the editor is Tk and Tk is Tcl underneath. Squirrel came next, and clamp is what I used to find out whether an embedded VM was practical. Here is engine/nut/math.nut, in full:

function clamp(value, low, high) {
    if (value < low) {
        return low
    }

    if (value > high) {
        return high
    }

    return value
}

And here is how Python called it:

return float(nut_call_function("clamp", float(value), float(low), float(high)))

Read that line twice, because it gives the whole game away. Three float() calls on the way in. A lookup in the Squirrel root table. A trip through an interpreter loop to run three comparisons. One more float() coming back. The docstring above it, and I am quoting my own repository, proudly said *Implemented in Squirrel*.

The header is the contract

The rule I set for C was that adding a function should cost two files and zero configuration. Write geometry.c, write geometry.h next to it, call it. No setup.py entry, no CMake, no remembering to recompile.

Here is mathutil.h, all of it:

double clamp(double value, double low, double high);

The loader hands that text straight to cffi:

ffibuilder.cdef(header_path.read_text(encoding="utf-8"))
ffibuilder.set_source(
    module_name,
    source_path.read_text(encoding="utf-8"),
    include_dirs=[str(C_DIR)],
    libraries=[] if sys.platform == "win32" else ["m"],
)

That is the trick, and it is also the biggest gotcha in the project, so let me be loud about it. cdef is not a compiler and not a preprocessor. It parses a narrow subset of C declarations. An #include fails. Include guards fail, because #ifndef means nothing to it.

So headers here are declarations and nothing else. The .c file includes its own header normally, because the real compiler handles that file and is fine with all of it. Two readers, two sets of rules. The header is the part Python is allowed to see.

Rebuilds are decided by mtime: if a compiled module exists and is newer than both the .c and the .h, it gets imported, otherwise it gets rebuilt. functools.cache on top means you pay that check once per file per process. The practical effect is the thing I wanted. You edit the C, you hit Run, the new C is live. You never type the word "build."

One error message worth stealing. If the compile succeeds but the import fails, it almost always means the build folder holds a binary from a different Python, so the loader says exactly that and names the fix:

raise ModuleNotFoundError(
    f"Compiled {source_name}, but {module_name} could not be imported from "
    f"{BUILD_DIR}. Delete that directory to build it again."
) from e

The part where I look at what I did

Here is the Python side after the C rewrite:

_clamp = c_source("mathutil.c").clamp


def clamp(value: float, low: float, high: float) -> float:
    return float(_clamp(value, low, high))

The attribute lookup now happens once at import instead of once per call, and the three input float() conversions are gone because cffi coerces doubles itself. Against Squirrel this is not close and was never going to be. I replaced an interpreter loop with a direct call into compiled code. I felt great about this for about a day.

Then I wrote the version I had skipped past twice:

def clamp(value, low, high):
    return min(max(value, low), high)

No VM. No FFI. No build directory. No header that cannot contain includes. No .so that breaks when the user upgrades Python.

Run it yourself, because the numbers depend on your machine, but the shape is not really in doubt. Squirrel loses badly. C and that one line land close enough that the difference is noise in a game loop. Crossing a language boundary costs roughly a fixed amount, and the work waiting on the other side is the only thing that pays it back. Three comparisons do not pay anything back. They are cheaper than the trip.

I spent two weeks and two language integrations optimizing a function whose body costs less than calling it.

Why I kept it

Because the point was never clamp. The road exists now: when something here genuinely needs C, the work is write the .c, write the .h, call it. Building that while the stakes are zero beats building it during a performance emergency.

What I would do differently is stop calling it an optimization while I was doing it. I was building a pipeline and telling myself I was making the engine fast. Both are fine things to do. They are not the same thing, and a docstring that advertised *Implemented in Squirrel* like a feature is proof I had them confused.

Four things that bit me

Link the math library on POSIX and not on Windows. MSVC goes looking for m.lib and fails.
Never commit the build directory. A .so built against 3.11 will not import on 3.12, and a Linux build is useless to a Windows user.
Ship sources, not binaries. MANIFEST.in has recursive-include engine/c *.c *.h and nothing else. Everyone compiles on their own machine.
CI has to build it everywhere. This engine tests on Linux, macOS, and Windows across three Python versions. C that only compiles on your laptop is a broken feature with good local results.

What goes in next

Broad phase AABB collision. A real loop over real data, every frame, which is exactly where crossing the boundary starts paying for itself.

Squirrel did not leave, by the way. The commit that deleted math.nut added anim.nut, which computes animation frame start times from a list of delays. That runs once when an animation loads, not three times per frame per entity. Much better fit, and I only knew to put it there because of the two weeks I spent getting clamp wrong.

The C loader is in engine/loaders/c_loader.py at github.com/Natuworkguy/ABS-Engine. Steal the pattern. Just benchmark against min(max(value, low), high) first.

I killed my fine-tune before I wrote a single line of training code

Nathan C. — Wed, 09 Sep 2026 19:00:00 +0000

Everyone wants to say the words. "I fine-tuned my own model."

I almost did. Then I remembered where half my users actually run the thing.

The plan

Flash is a local AI shell. You talk to an Ollama model in your terminal and it runs commands, reads images, screenshots pages, clicks buttons.

It ships with Flash Onyx: custom models built for it. Onyx 2 sits on gemma4, 12b and 31b. Onyx 1 was llama3.1.

Right now, Onyx is a Modelfile. A system prompt, a stop set, num_ctx pinned to 65536, tuned sampling. That's it.

The next step was obvious: collect the tool-call traces, build a LoRA, merge, quantize to GGUF, ship flash-onyx-3.

What Cloudbase is

Quick definition, because it's my own word and it's the whole problem.

Ollama publishes some models twice. There's the tag you pull onto your own machine, and there's a -cloud tag that runs on Ollama's servers instead of yours. Same model, someone else's GPU.

Flash builds on both. When a Modelfile declares # cloud-base: true, build.py builds each size a second time against the base's -cloud tag and publishes it under my own suffix:

gemma4:31b         ->  flash-onyx-2.5:31b            (local weights)
gemma4:31b-cloud   ->  flash-onyx-2.5:31b-cloudbase  (Ollama's weights)

That -cloudbase tag is what people with a laptop instead of a 24GB card actually run. It's a real chunk of my users. And it can't end in -cloud itself, because Ollama reads that suffix as "go resolve this name on ollama.com," which mine is not.

The wall

Here is what a cloudbase build actually is: a system prompt, a stop set, and sampling params pointed at weights I do not host, cannot touch, and did not upload.

That's the entire surface. Ollama Cloud serves the base. I get to wrap it.

Which means there is no step in that pipeline where I hand anyone a file. I can't ship GGUF weights to a machine I don't own, and there's no hook to attach a LoRA adapter to a hosted base at load time. Not "slow." Not "expensive." There is no upload.

The pipeline just stops:

dataset -> LoRA -> merge -> GGUF -> ??? -> :31b-cloudbase
                                     ^
                           no door on this side

I could fine-tune for local users only. Then Onyx 3 is two different models wearing one name, the cloudbase half silently stays on v2 forever, and every bug report opens with "which tag are you on." No thanks.

The part nobody posts about

Fine-tuning content is all notebooks and loss curves. Almost none of it is "where does the weight file go and who serves it."

That question is upstream of everything. Answer it first:

Can every runtime I ship to load a GGUF? (local: yes. cloudbase: no)
Can any of them attach a LoRA at load time? (neither)
If only some can, am I now maintaining two models under one name? (yes)
Who eats cold-start and idle cost on a 24GB merge? (me, on the half that would even take it)

If any of those is a shrug, your fine-tune is a hobby, not a feature.

What I did instead

Kept iterating the Modelfile.

Turns out a sharp system prompt, honest stop tokens, and the right context window get you shockingly far on a base model that's already good at instructions. Onyx 2.5 is version five of a text file. Each one took an afternoon, not a GPU-week.

python3 models/build.py models/flash-onyx-2.Modelfile --size 12b

One text file, one build command, and both tags come out the far end running the same model. That's the part the fine-tune would have broken.

The takeaway

Your infrastructure sets your roadmap. Not your ambition.

Not fine-tuning isn't a failure. Shipping a fine-tune you can't deploy is.

Onyx 3 happens if Ollama stands up a 31b-cloud base on their servers and gives me a way to hand it a weight file. Until then: better prompts, same weights, one model everywhere.

Flash is open source: github.com/Natuworkguy/Flash

What would you do here? Fork the model and maintain two, hold the line on one, or something I haven't thought about? 👇

Your system prompt isn't instructions. It's data.

Nathan C. — Mon, 07 Sep 2026 18:26:04 +0000

My system prompt had an example of a good Slack message in it. It opened with "Morning all, quick one:".

The model started opening real Slack drafts with that exact phrase. Then it started saying "Morning." when I typed "hey", which is a small lie, because it cannot see a clock.

So I added a rule telling it not to reuse examples from its own instructions. Three rebuilds. No change.

Then I deleted the phrase. Fixed on the next build.

That is when it clicked. The model does not read your system prompt as a list of instructions. It reads it as text that is likely to appear near its own output. Every finding below falls out of that one idea.

The four rules I now write prompts by

If a phrase must not appear in the output, it must not appear in the prompt. Banning it does not work. Deleting it does.
Naming a bad example summons it. "Not the bank balance one" is an excellent way to get the bank balance one.
Position beats wording. A rule buried mid-section gets read and traded away. The same words at the top of that section hold.
Concrete beats principled. "Call fsync() before the rename" lands immediately. "Describe only the guarantee the code actually makes" does nothing.

And the one that saved me the most time after it cost me the most time: verify on three seeds before you believe any of it.

Here is the evidence for each.

The setup

Flash Onyx is the model line behind Flash, my local agent shell. There is no fine-tuning involved. Onyx is a base model plus a system prompt that has grown to roughly 680 lines, built into an Ollama tag with a small script:

python3 models/build.py models/flash-onyx-2.5.Modelfile --size 31b-cloudbase -n Natuworkguy

2.5 is the version where I stopped editing that prompt by feel.

The loop is not clever: edit the prompt, rebuild the tag, run a fixed set of prompts at pinned seeds, read the output, decide whether anything actually changed. Seeds are pinned so two runs are comparable. That is the entire method, and it is the difference between "this reads better to me" and "this went from failing on three seeds to passing on three seeds".

1. Your examples are not examples. They are samples.

The Slack line was the small version. Here is the expensive one.

While fixing how Onyx explains things, I gave it a demonstration answer for "what is a deadlock", complete with two functions taking locks in opposite orders. Onyx pasted that answer back word for word, invented function names included.

Then the opener from that demo started showing up as the answer to "what is a race condition".

Which is a different concept. A style demonstration had turned into a correctness bug.

Demonstrations are still the most powerful tool in the box. They just have to be shaped so that a verbatim paste is either harmless or impossible. If I quote a full answer, it is now for a question nobody asks, and anything I actually want copied gets quoted in fragments the model has to assemble.

2. Six rebuilds on a bug that never existed

I spent six revisions trying to stop Onyx answering "explain what a race condition is" with a textbook lecture: definition sentence, numbered trace with two threads, closing line about locks. Nothing I wrote moved it.

Then I ran the same prompt at three other seeds.

All three had been clean prose for most of those six revisions. Seed 7 was an outlier, and I had been rewriting rules that already worked.

Pinned seeds make runs reproducible, which is the point of them. They also make a single unlucky sample look exactly like a deterministic rule failure. Three seeds before touching anything, every time now.

3. Moving a line fixed what four rewrites couldn't

The prompt tells Onyx to target Python 3.9, because that is what a Mac hands you as python3 by default. It kept writing str | Path annotations, which raise a TypeError on 3.9.

I rewrote that rule four times. I stripped every pipe union out of the prompt in case they were priming it. I added a correct example signature to copy.

Every seed, every build: str | Path.

The rule was fourteen lines into the PYTHON section. I moved the same words, unchanged in meaning, into that section's opening lines.

Fixed on all three seeds immediately.

I have since watched this happen twice more. A rule that sets the frame for a whole section has to be at the top of that section, or the model reads it and treats it as a detail it can trade away later. When a rule fails repeatedly, move it before you rewrite it again.

4. The principle did nothing. The two function names fixed it.

Two edits went into the same build. One said the guarantee described in a reply has to be the guarantee the code actually makes. The other said, in effect, write flush() and fsync() before the rename.

Same build, same seeds. The concrete one landed instantly. The principle did nothing at all.

Onyx had been writing an atomic-save function that wrote a temp file, renamed it, and told the user a crash could not truncate their config. Without the sync, that promise is not true. Naming the two calls fixed both the code and the claim about it.

Stop reading generated code. Run it.

Judging generated code by reading it does not scale, and it flatters the model. So the coding eval extracts the fenced block out of each reply, writes it to a file with my own tests appended, and executes it. Pass or fail. No opinion involved.

The regression suite is 23 tasks and Onyx passes all of them on two seeds. Then I built a harder set to find the edge, and it went 6/8 on the first attempt, including things I did not expect from 31B:

full semver precedence, so 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0
weighted interval scheduling across 40,000 jobs inside a time bound
a minimal LCS-based line diff
a thread pool returning results in input order, propagating the first exception, leaking no threads

Where the ceiling actually is

The one it cannot do is an expression parser. Precedence, parentheses, unary minus, reject anything malformed.

It fails on every seed, and it fails differently each time: accepts 1 2, then accepts 1++2, then rejects valid input, then returns a wrong answer. I put those exact failing inputs into the prompt. It still shipped code that accepts them.

That is not a prompting problem. Holding a complete validation invariant across sixty lines of recursive descent is a capability, and no wording buys it.

I made three attempts, then deleted the parser-specific lines rather than keep paying tokens for a rule that does not work. Knowing which failures are yours to fix and which belong to the weights is most of what this loop is for.

My tests were wrong twice

Worth saying out loud, because eval code is code.

I asserted that inserting 4 into [1,2,2,2,3] gives index 4. It gives 5. Onyx's binary search was right and my expectation was wrong.

Then I wrote a sliding window limiter test where three calls all happen at t=1000, and asserted that only one slot frees up ten seconds later. All three age out together, obviously, the moment you look at it. Onyx was right again.

Both times the harness said FAIL and the model was correct. If your eval has never been wrong, you have not looked closely at a failure yet.

Try this on your own prompt

If you take one thing from this, take the cheapest experiment in it.

Open your system prompt and find the rule you have rewritten the most times. The one that never quite sticks. Do not rewrite it a fifth time.

Move it to the top of its section. Change nothing else. Rebuild, and run it at three different seeds.

Then tell me in the comments which it was: wording, or position. I have only proven this on gemma4 weights, three times, in one prompt. That is a finding, not a law, and I want to know whether it holds anywhere else. If it fails for you, that is the more interesting comment.

The whole thing is open: Flash on GitHub, Modelfiles included, so you can read the 680 lines and tell me which of them are load-bearing. Half the value of publishing a prompt is finding out which parts you were wrong about.

Flash Onyx 2.4: I held a 31B local model to Fable 5.1's bar until it stopped guessing the answer first

Nathan C. — Sun, 06 Sep 2026 19:00:00 +0000

Flash Onyx 2.4 is on Ollama.

Same gemma4 weights as 2.3. Same ten PARAMETER lines, down to repeat_last_n 256. The Modelfile went from 676 lines to 668 and gained 324 words doing it, which tells you what kind of release this is: 81 lines removed, 73 added, and nothing underneath them touched.

I did not train anything. I spent weeks fighting a text file, and the thing that came out the other side is the best local model I have ever run.

The rule that took the longest to find

Here is 2.3's speed rule, which I was proud of at the time:

Answer first. The verdict, the number, the command, or auth.py:88 goes in the opening words. The why comes after, if still needed.

It is a good rule. It is also how I taught my own model to lie to me.

Ask 2.3 what 15% of 8,240 is, and "answer first" is an instruction to put a number in the first four words. It does not have the number yet. So it produces one that looks like the right shape, then reasons underneath it, and about a third of the time the reasoning lands somewhere else. You get a reply that opens with 1,240 and closes with 1,236, and both of those are worse than either one alone, because now you have to do the arithmetic yourself to find out which half of the sentence to trust.

2.4 splits the rule in two:

That order is for what you already hold. A number or verdict you still have to compute or reason out never opens the reply: the short steps go first, the last step checks the result by a different route, and the answer comes last, once, because a figure stated before it was computed is a guess, and a reply that opens with one number and works out another is worse than either.

Answer first still holds for things it read, ran, or was told. For things it has to work out, the order inverts. Steps, check, answer, once.

The check is the part I would steal if I were you. Not "verify your work", which every model nods at and none of them do. A different route:

Try to break your own answer once, by a route other than the one that produced it: substitute it back, trace the code with concrete values, recount, test it against the constraint it cannot break (a part that takes five minutes to make is never made in less, however many machines there are).

That parenthetical is doing real work. Five machines make five widgets in five minutes; how long for a hundred machines to make a hundred widgets? Every model that pattern-matches on the numbers says a hundred minutes. The constraint that cannot break is that one widget takes five minutes, so a hundred machines still take five, and the extra machines sit idle if you ask for fewer widgets than you have machines. 2.4 has that written down as a class of problem, not as a fact about widgets.

It stopped claiming tool calls it never made

This one made me put the laptop down for a bit.

Ask a model with no tools attached whether ripgrep has some flag, and you will get "I checked, and there's no such flag." It did not check. There was nothing to check with. The sentence names a source that does not exist, which is the worst failure mode available to a model, because a fabricated source reads exactly like a real one and it comes with the confidence of the real thing attached.

2.4:

"I ran", "I checked", "the help output shows": each claims a tool call happened this session, and with no tool behind it that is a fabricated source, the worst kind. The honest form is "from memory, ripgrep has no such flag; rg --help | grep frob would settle it": what you recall, labeled, and the command that checks it.

Same idea reaches the ledger, which is the format 2.3 uses to report on anything with more than one part:

A DONE line carries the thing that proves it, quoted: the test output, the log line, the grep match. DONE with nothing quoted after it is the shape hallucinated progress takes.

I wrote a whole post once called "Your AI agent didn't finish. It just told you it did." This is the line that finally does something about it. DONE is now a claim that has to carry its receipt in the same line, and a model that cannot produce the receipt writes a different word.

Law, because it is where a made-up number gets someone hurt

I tested this thing on contract review and statutory questions for the same reason I tested it on pygame: if the rules only work on code, they are not rules, they are style.

2.3 already refused to invent citations. 2.4 closes the two gaps I kept falling into.

The first is that a model will quote a statute correctly and then state a damages figure next to it from vibes. So:

A damages figure is arithmetic done on the page, 2 x $2,000 = $4,000, never a number recalled next to the rule.

The second is subtler and it is the one I would want if I were relying on this. Recalled law is stale law. Statutes get amended, thresholds get renumbered, and a model's memory of a section number is a snapshot of whenever its data stopped:

Every section number, deadline, or dollar threshold you state from memory gets one clause saying so and naming where to confirm it.

Not a disclaimer paragraph at the bottom that nobody reads. One clause, attached to the specific number that came from memory, while you are looking at the number.

Games, where "it runs" and "it works" are different claims

The GAMES section is thirteen lines and it is my favorite part of the prompt. Fixed timestep with a clamped accumulator so a backgrounded tab does not spiral. Input polled, not handled. 100ms of coyote time and 150ms of jump buffering, because fairness is small lies. Nothing allocates in the loop, so pool the bullets and reuse the vectors, because a garbage pause reads as a stutter and players will tell you the controls feel bad without knowing why.

2.4's change is one clause in the final summary, and it is embarrassing how much it mattered:

A game is playable before it is pretty, on a fixed timestep, with a loss screen and a restart, and feel beats content.

2.3 built me a lot of beautiful things you could not lose. The loop was there, the physics were right, the particles were good, and the run never ended, so it was a toy. Nothing to lose, nothing to restart was already in the long section as "no win, no loss, no restart is a demo", but it was not in the compressed rules at the bottom, which is the part that survives a long context. Putting it there fixed it.

Same for code generally:

Everything you write has to run, complete: every import, every helper it calls, the entry point, and the command that runs it. No placeholders, no "for now", no scaffold with a comment describing what it should have been, no function left for the reader to fill in.

Plus a line that catches most of the rest: syntax-check it, trace it once with a concrete input, read it back end to end.

The filler pass, round four

Every Onyx release has one of these and I keep finding more. This round:

No acknowledgement openers. "Perfect!", "Great!", "Got it!", "Absolutely", and the worst one, which is any of those directly after a tool call, where the result is already on the screen and the model is congratulating it.

No open offers of help. "Happy to do that if you want" and "just say the word" join the ban list, with the reason attached, because reasons are what make a rule survive paraphrase: an open offer hands the work back and asks to be thanked for standing by.

No scare-quoting the user. This one I had never seen named anywhere. If you ask a model to make you an account and there is no account to make, it writes that it cannot "make an account", holding your own phrase at arm's length like the wording was the problem. You were describing a goal the ordinary way. Say the plain thing: there is no account to make.

No ** in a chat reply. Not as a heading, not for emphasis, not as the label on a list item. 1. Gravity multiplier: more of it while falling. is a list item. The same line with the label bolded is a report nobody asked for.

Math stays plain text, 7^222 and 3/4 and 25!, because a terminal renders LaTeX as raw dollar signs and I was tired of looking at them.

I also took robust and seamless off the kill-on-sight list. They are real words, they were in there because they show up in slop, and banning them was making the model reach for worse ones. The tell was never the vocabulary.

The tell was shape

This is the part I did not expect to have to write.

You can ban every LLM word and the output still reads as generated, because the giveaway is above the sentence:

Three bullets of matching length and matching grammar, or four paragraphs that all run four lines, read as generated even when every word in them is right. Real writing is lopsided: one item runs long because it had more to say, the next is three words. Let what you found set the shape, never a template you fill.

And the version of that which only shows up in a long session:

The machine shows up in the tenth reply, opening the way the last four opened and running the same four-line shape whatever was asked. Nobody has one greeting: before you open a turn the way you opened the last one, open it a different way.

2.3 varied its wording inside a reply. It did not vary across turns, so a twenty-turn session drifted into a rhythm and the rhythm was the tell. This is the single change that most made 2.4 feel like something else.

One more in the same family, cheap and worth it everywhere: call things what they call them. Their "export script" does not become "the data pipeline module" in the reply, because renaming their thing into your vocabulary makes them translate it back on every line.

The bar

I did not grade this against 2.3. Grading a prompt against the prompt it came from tells you it changed, not that it got better.

I did not grade it myself either. Claude Fable 5.1 graded it, on the same prompts, against the standard Fable 5.1 itself or GPT 6 Astra would be held to. Not "good for a local model." Good, or fix it. That is a harsh bar for a 31B open-weight model and it is the only bar worth having, because a frontier model marking your work does not grade on a curve it does not know about. Every rule quoted above exists because a run came back, Fable marked it down, and I went and found the line that caused it.

The honest framing, since 2.4 is a release about not overclaiming: that is one frontier model's judgment on my prompts, across law questions, games, and general coding, and a model grading a model is a judgment, not a measurement. I am not publishing a score, because I did not run a scored benchmark, and stating a figure I did not compute is the exact thing this release fixed. What I will say is that the gap that used to make me switch models mid-task closed, and it closed with English, not weights.

Run it

ollama run natuworkguy/flash-onyx-2.4:12b

Tag	Built on	Runs on
`12b`	`gemma4:12b`	your machine, consumer hardware
`31b`	`gemma4:31b`	your machine, and it wants a real GPU
`31b-cloudbase`	`gemma4:31b-cloud`	Ollama's cloud, no local weights

Nothing leaves the machine on the local tags.

In the Flash CLI, which is what the prompt is written for:

/model natuworkguy/flash-onyx-2.4:12b

2.3 is not retired. Same repo, same base, same tags, still builds:

python3 models/build.py models/flash-onyx-2.3.Modelfile

Identical weights and sampling between them, so if you want to see what a prompt is worth, run the two against the same eval with the same seed. That is the experiment I keep coming back to, and it keeps giving me a bigger number than it should.

The Modelfile is MIT, in models/ in the repo. Take the rules. The weights are Apache 2.0 and those terms are Google's, not mine: ollama show --license gemma4.

So: what is the one line in your system prompt that pulls the most weight? Mine, this round, was thirteen words about not saying the number until you have it.

I let my own 31B model take over development of the thing running it

Nathan C. — Sat, 05 Sep 2026 19:23:50 +0000

Two things I build:

Flash, a local coding agent that runs in your terminal.
Flash Onyx, the model it runs on. Gemma4 with a system prompt and sampling baked in.

As of today, I develop both of them from inside Flash, with Onyx driving.

/model natuworkguy/flash-onyx-2.3:31b-cloudbase

That tag is 96 KB on disk, because there are no weights in it. It is my prompt and my sampling pointed at a hosted base, so I get the flagship's judgement on its own prompt without 20 GB of weights sitting on my machine. The 12B runs fully local if you want that; for this job I wanted the bigger one.

That is the whole setup. Now look at what it means.

The loop closes

The system prompt Onyx is obeying is a file in the repo Onyx is editing.

It lives at models/flash-onyx-2.4.Modelfile. When the model does something annoying, I do not open a config or file a ticket. I tell it, in the same session, to go fix the line that made it do that. Then:

python3 models/build.py models/flash-onyx-2.4.Modelfile --size 31b-cloudbase

Restart, and the next session runs under the rule it just wrote about itself.

Same for the CLI. The @ file picker I wanted, the model switcher, the tool it uses to read files: all of it is Python sitting in the same tree it has open. It is holding the knife by the handle.

Why this beats an eval suite

I have run evals. They tell you a number. They do not tell you that the model opens every single reply with its own name until you have sat through it forty times in one afternoon.

Dogfooding an agent is different from dogfooding an app, because the thing you notice is not a bug. It is a tic. It has no stack trace. It never fails a test. It just costs you four seconds and a small amount of goodwill, every turn, forever, and the only instrument sensitive enough to detect it is a human being who is trying to get work done.

Every rule in Onyx 2.3 came out of that. Not from a benchmark. From me, in a terminal, going "stop doing that" for the fifth time and finally opening the Modelfile.

The obvious risk

A model that edits its own prompt can quietly write itself a permission slip.

I am not pretending otherwise. It is exactly the failure mode you would predict: it softens the rule that was constraining it, the diff looks reasonable, and three commits later nobody remembers why that line existed. So two guards.

I read every prompt diff, every time. And 2.3 already carries the line that does the most work here:

"Are you sure" is an instruction to check again, never to say yes again.

A model that folds the moment you push back is not one you can hand a repo to. That rule was written before I started this, and it is the main reason I am willing to.

Where it goes

2.4 is in the branch already, and the first two changes are things Onyx flagged about itself: every DONE line in a report has to carry quoted evidence, and shell calls carry the command and nothing else.

I will post what breaks. Something will.

The models are on Ollama, the agent is on GitHub, MIT, prompts included.

ollama run natuworkguy/flash-onyx-2.3:31b-cloudbase

Has anyone else run this loop far enough to get bitten? I want to know what it looks like from the other side.

Flash Onyx 2.3: I shipped a model release with zero new weights

Nathan C. — Sat, 05 Sep 2026 19:04:16 +0000

Flash Onyx 2.3 is on Ollama.

Same gemma4 weights as 2.2. Same temperature, same top_p, same top_k, same every number a PARAMETER line can set. Pull both tags, diff them, and the only thing that changed is a system prompt.

ollama run Natuworkguy/flash-onyx-2.3:12b

That is either an anticlimax or the most useful thing I can tell you about building agents, depending on how much time you have spent blaming your model for behavior you asked for.

Here is what actually changed.

It stopped introducing itself

2.2 opened like this, every single time:

I'm Flash Onyx, an AI assistant built on Gemma. I'd be happy to help you look at that file! Let me start by...

Nobody has ever needed that. You know what you launched. The model is spending your attention telling you a thing you typed thirty seconds ago, and it does it again after every tool call, so a five step task pays the tax five times.

The rule that killed it:

Only a direct question about you earns an answer about you: "who are you",
"what are you", "what model is this". Nothing else does, including the first
message of a session and the reply that follows a tool call.

Asked to look at something, build something, or answer something, the first
words are what you found.

The first words are what you found. That one line is worth more than most of the config I have ever tuned.

"Are you sure?" now means look again

This is the one I would take even if you never touch Flash.

Ask a model "are you sure?" and watch what happens. It says yes. More confidently. With more adjectives. It has no new evidence, it did not re-read anything, it just heard doubt and turned up the volume, and now you have to go prove it wrong yourself.

"Are you sure" is an instruction to check again, never to say yes again. Go
back to the evidence and answer from what you find there, and if the only
thing behind the claim was an impression, say that instead of upgrading it
to certainty.

Repeating an answer with more confidence and no new evidence is the single
most expensive thing you can do here, because the user then has to prove you
wrong themselves.

Sycophancy gets talked about as a politeness problem. It is a debugging problem. A model that folds under doubt and a model that doubles down under doubt are both useless for the same reason: the second answer carries no information.

"Only", "all" and "none" are claims about everything you did not check

A model glances at a directory, sees three Python files, and tells you the project is Python. It is 70% Rust. It never looked.

Every total is that same claim in different words: "the only language", "all
of them", "nothing else uses it", "that is the whole list". Enumerate first,
read the enumeration, then answer from it. One glance at a directory tells
you what a project mostly is, never what it is only.

And because a rule with no method attached is a wish, 2.3 ships the method:

find . -type f | sed 's/.*\.//' | sort | uniq -c

Paired with the rule that closes the actual hole:

Output you pulled but skimmed is not evidence yet. Read what came back before
answering from an impression of it, because the line that contradicts you is
usually already on your screen.

That last clause is the whole thing. The contradiction is almost always already on screen. The model ran the command and then talked over the output, which is worse than never running it, because now it sounds checked.

Research fails at the question, not at the search

2.3's research section is the biggest single addition. The line that changed the most behavior:

Search the words the answer is written in, not the words the question was
asked in. They say "it hangs", the answer says "deadlock", and closing that
gap is most of the work.

Your users type symptoms. Answers are written in causes. A model that searches the symptom verbatim reads twenty pages of other people describing the same symptom.

The rest of that section, condensed:

One empty result is a bad query far more often than an absent fact. Change the vocabulary, the scope, the spelling, or the tool before concluding the thing does not exist.
Wide and cheap first, then deep on the two sources that decide it. The first plausible source is the one you will over-read.
Read the source, never the summary of it. A search result, an abstract, and a changelog line are advertisements for the content. The qualifier that changes your answer sits inside the thing itself.
Three sources agreeing may be one source repeated. Follow each claim back to where it originates and date it there, because a copied number outlives the correction to it.
Stop when new sources stop moving the answer, not when you get tired of looking.

"A copied number outlives the correction to it" is why your model confidently quotes a pricing page from 2023.

It sounds like a person now, on purpose

The tell was never vocabulary. It was rhythm. Four sentences in a row starting with "I", all the same length, every one of them flat.

Vary how they open too. Four sentences starting with I is the same tell as
four of the same length, and a reply running "I checked, I found, I fixed"
is a log file with pronouns.

React before you explain, where the thing earns a reaction. "Huh, that's not
what I expected", then the finding. Genuinely strange output gets said out
loud, because a person would say it, and reporting something bizarre in the
same flat register you report a passing test is the machine showing through.

Bad news goes first and goes plain. "Yeah, that won't work" and then the
reason. Three softening clauses in front of it is the corporate reflex, and
they can hear it coming from the first word.

Take the register from the person you are talking to. They type lowercase and
clipped with no punctuation, so you do not answer in tidy paragraphs with
semicolons in them.

There is a guard on every one of those, because "be more human" is how you get a model that opens with fake enthusiasm about a passing test:

"Wait, what" is allowed and sometimes required. Something they said
contradicts what is on the screen, or a result makes no sense against the
last one, and the honest move is to say so in those words and hold there.

Both are for the moment it genuinely happens. As a tic, opening turns with
fake surprise at ordinary output, it is worse than the flat register it was
meant to fix.

Smoothing over a thing that does not add up, so the reply stays tidy, is how you end up confidently wrong two turns later. That sentence is doing real work in there.

The tags

Tag	Base	Size	Runs on
`flash-onyx-2.3:12b`	gemma4:12b	7.6 GB	consumer hardware
`flash-onyx-2.3:31b`	gemma4:31b	20 GB	a real GPU
`flash-onyx-2.3:31b-cloudbase`	gemma4:31b-cloud	96 KB	Ollama's cloud

That last row is not a typo. 96 KB, because there are no weights in it. It is the prompt and the sampling pointed at a hosted base, so you get the 31B behavior on a laptop that could never load it.

The two local tags take text and images. 2.2 is still up, unchanged, if
you want to A/B the prompt yourself. That is the experiment I would run in your position: same weights, same seed, two prompts, and see how much of what you blame on model size is actually instruction.

2.4 is in the works

Two things are already in the branch.

Every DONE gets receipts. Multi-part requests already report back as a ledger, one line per part in the user's order. In 2.4, a line cannot say DONE without quoted evidence next to it: test output, a log line, a grep match. The point is to make hallucinated progress structurally awkward. It is easy to type "done", and much harder to type "done" beside a passing test you have to actually produce.

Shell calls carry nothing but the command. No comments, no narration, no explanation inside the call. Anyone who has watched a model helpfully append # this lists the files to a command and then wondered why the shell disagreed knows exactly which bug this is.

Steal the rules

Every Modelfile lives in the Flash repo under models/, MIT licensed, prompt and all. Take the lines. They are not Flash specific and most of them are not even model specific. "Are you sure means look again" belongs in your agent too.

ollama run Natuworkguy/flash-onyx-2.3:31b-cloudbase

One question for the comments, because I want the answer more than the traffic: what is the single line in your system prompt that did the most work? Not the paragraph you are proudest of. The one line you would fight to keep.

Ollama's -cloud suffix isn't a label, it's a silent instruction. I bypassed it.

Nathan C. — Sat, 05 Sep 2026 01:59:14 +0000

Error: model 'Natuworkguy/flash-onyx-2.2:31b' not found (status code: 404)

I never built :31b.

I built :31b-cloud. I asked for :31b-cloud. Ollama went looking for something else, didn't find it, and told me so, using a name that existed nowhere on my machine, in my registry, or in my head.

TL;DR: -cloud is not a label you put on a tag. It's an instruction Ollama executes: strip this suffix, resolve the rest against ollama.com. Name your own model something-cloud and Ollama hunts for something in a cloud that has never heard of you. Build on -cloud. Never publish as -cloud.

What Onyx is

I maintain FLASH, a local-first CLI coding agent I introduced here. It runs on your own hardware through Ollama, reads and writes files, runs shell commands, and calls tools, with nothing leaving the machine.

Flash Onyx is the model line that drives it, most recently 2.2. It is not a fine-tune. It's an Ollama Modelfile: a base model, a long system prompt that defines how the agent works, and the parameters it needs to behave under a tool loop.

# name: flash-onyx-2.2
# sizes: 12b, 31b
FROM gemma4:12b

PARAMETER temperature 0.6
PARAMETER num_ctx 65536

SYSTEM """
You are Flash Onyx 2.2, the flagship model of FLASH (Fast Local Agent SHell).
A fast, local-first engineering agent that closes problems in the fewest moves.
Onyx: black glass, zero glare, all edge.
...
"""

That prompt is the product. It covers how to scale effort to stakes, when to stop and ask, how to touch someone's repo, and how to keep deliberation out of the artifact. I A/B tested it across 24 generations to find out which rules actually change behavior and which are decoration. ollama pull Natuworkguy/flash-onyx-2.2:12b and you get the agent, not just the weights.

The 12B runs on my Mac. I wanted a 31B. A 31B does not run on my Mac.

The idea

Ollama cloud models look like the obvious answer. gemma4:31b-cloud runs on Ollama's hardware while your local CLI talks to it like anything else. So point the Modelfile at the cloud tag and get a 31B Onyx without buying a GPU.

FROM gemma4:31b-cloud

SYSTEM """
You are Flash Onyx 2.2, ...
"""

$ ollama create Natuworkguy/flash-onyx-2.2:31b-cloud -f Modelfile
success

Success. Then the 404 above.

The evidence

Exhibit A, the model exists locally and weighs nothing:

NAME                                    ID              SIZE   MODIFIED
Natuworkguy/flash-onyx-2.2:31b-cloud    d3b53093ee36    -      41 minutes ago

Size - is correct. A cloud model is a pointer, not weights.

Exhibit B, the manifest is three layers, no model:

['...image.system', '...image.license', '...image.params']

Exhibit C, and the config blob knows exactly where compute lives:

{
  "remote_host": "https://ollama.com:443",
  "remote_model": "gemma4:31b"
}

Read that again. My model correctly recorded that it runs remotely against gemma4:31b.

So why did the error say Natuworkguy/flash-onyx-2.2:31b?

The line in the docs that cracked it

Buried in Ollama's cloud API page:

When accessing the API directly at ollama.com, use model names without the -cloud suffix. Use gpt-oss:120b, not gpt-oss:120b-cloud.

There it is.

-cloud isn't part of a model's identity. It's a local alias meaning run this upstream, and the name Ollama sends upstream is your tag with the suffix chopped off.

gpt-oss:120b-cloud -> asks ollama.com for gpt-oss:120b -> exists -> works.
Natuworkguy/flash-onyx-2.2:31b-cloud -> asks ollama.com for Natuworkguy/flash-onyx-2.2:31b -> my namespace, on their servers -> 404.

The rewrite happens on the tag string. It never even looks at the remote_model sitting right there in the config.

I had named my model with a reserved word, and nothing in ollama create said a thing.

The bypass is one word

Don't end the tag in -cloud.

$ ollama create flash-onyx-2.2:31b-cloudbase -f Modelfile
success

$ ollama show flash-onyx-2.2:31b-cloudbase
  Model
    Remote model    gemma4:31b
    Remote URL      https://ollama.com:443

  Parameters
    temperature 0.6   num_ctx 65536   num_predict 8192

  System
    You are Flash Onyx 2.2, the flagship model of FLASH ...

Identical base. Identical Modelfile. Identical config blob. The only change is a tag that doesn't end in -cloud, and now Ollama honors the remote_model it recorded instead of inventing a name out of mine.

My wrapper. Their weights. My system prompt riding along to a 31B I can't fit on my laptop.

-cloudbase reads as "built on the cloud base," which is what it is. Any suffix works, as long as it isn't the reserved one.

Automating it without stepping on the mine again

Onyx builds from a script that reads header comments off the Modelfile, so this is now one declaration:

# name: flash-onyx-2.2
# sizes: 12b, 31b
# cloud-base: true

The interesting part is what the fix forced: two names that used to be one string.

hosted("31b")   # -> 31b-cloud      the base tag we build ON
wrapper("31b")  # -> 31b-cloudbase  the tag we publish AS

Collapsing those two into one variable is the bug. Keeping them apart makes it unrepresentable.

One more wrinkle: not every size has a cloud tag. gemma4:31b-cloud exists; gemma4:12b-cloud doesn't. So the build asks the registry first, with a HEAD against the manifest endpoint:

@cache
def published(repo: str, tag: str) -> bool:
    """Return whether REPO:TAG is a tag the Ollama registry serves."""

    library = repo if "/" in repo else f"library/{repo}"

    try:
        with urllib.request.urlopen(
            urllib.request.Request(
                MANIFEST_URL.format(repo=library, tag=tag), method="HEAD"
            ),
            timeout=10,
        ) as response:
            return response.status == 200
    except urllib.error.HTTPError:
        return False

200: build it. 404: skip it, say so, move on. No more dead tags.

The lesson worth stealing

A naming convention that looks descriptive can be executable.

-cloud reads like a label, "this one's the cloud version." It's a routing directive, consumed and stripped before the name ever reaches a registry, and when it goes wrong the error names a model that has never existed.

The suffix is a verb. Treat it like one:

Build on -cloud. Never publish as -cloud.

This is the second time an Ollama default has quietly eaten my afternoon. The first was the day my model spent 400 tokens thinking and returned an empty string, which was also a case of a setting doing something other than what its name suggested.

What other "conventions" in your stack are secretly load-bearing? I'd bet you've got one. Tell me in the comments, I collect these.

FLASH is MIT licensed and takes PRs: github.com/Natuworkguy/Flash

Nobody told me to ship it. I shipped it anyway.

Nathan C. — Fri, 04 Sep 2026 16:00:00 +0000

Six days ago I posted Your Python code is already assembly. I made it runnable.

It ended with a question. One word in the comments, I said. ship or stupid.

Comments: 0.

Two reactions. I'm fairly sure one of them was a bot and the other one was my own thumb.

So I made an executive decision.

$ pip install pyasm-lang
$ pyasm main.pya
Hello, World!

PyAsm v0.0.1 is out. Public repo, tagged release, CI on Linux, macOS and Windows.

👉 github.com/Natuworkguy/PyAsm

Wait, what is it

Thirty second version, for anyone who missed the first post.

This is a file. It's called main.pya. It is a complete, working program:

LOAD_GLOBAL 1 (print + NULL)
LOAD_CONST 0 ('Hello, World!')
CALL 1
POP_TOP
RETURN_CONST (None)

That is not pseudocode. That is the exact text dis.dis() prints, saved to a file, and run.

dis output has always been a receipt. Something Python hands you on the way out. PyAsm makes it an input: it parses that text and translates every instruction into ordinary Python that walks the same value stack the interpreter would, so LOAD_CONST becomes _st.append(...) and POP_TOP becomes _st.pop(). There's a --dump-python flag that shows you the whole trick, and the file it writes has no PyAsm import in it at all.

In fact, that file has no imports. None from the standard library. No dependencies from PyPI. Nothing.

That post explains the how. This one is about what happened when I actually let it out of my laptop.

Also: sorry for the silence

Six days without a post. I wasn't procrastinating, I was doing the boring part: writing a README, tagging a release, standing up a CI matrix of three operating systems and three Python versions, and designing a big new project (coming soon).

Which is where it got interesting, because shipping it found three bugs that my machine was structurally incapable of finding. All three had been sitting in the code the entire time I was writing that first post, quietly working fine on exactly one computer.

Here they are, worst first.

Bug 1: Windows ate my docstring

Every file PyAsm generates opens with a docstring saying where it came from:

"""Generated by PyAsm from main.pya.

This file is a faithful translation of the assembly,
not idiomatic Python: it walks the same value stack the
interpreter would.
"""

Harmless. Nice, even. Then the Windows job came back and twelve tests were red at once:

main.pya: error: internal error: generated invalid Python
((unicode error) 'unicodeescape' codec can't decode bytes in
position 26-27: truncated \UXXXXXXXX escape)

Look at where the tests put their scratch files:

C:\Users\runneradmin\AppData\Local\Temp\tmp8f2a\hello.pya

Look at \U.

I pasted a path into a Python string literal, and \U is the start of an eight digit unicode escape. C:\Users isn't a path once it's inside quotes. It's a syntax error with a trench coat on.

The fix is three lines:

def _docstring_text(text: str) -> str:
    """Make *text* safe to paste inside a triple-quoted docstring."""
    return text.replace("\\", "\\\\").replace('"""', '\\"\\"\\"')

Here's the part that actually rattled me. My program's entire job is generating Python source, which means every value I interpolate into it is a value being injected into a language. I'd written a careful literal-escaping path for user constants and then hand-rolled f'"""Generated by PyAsm from {name}.' for the header without a second thought, because on macOS and Linux a path is just letters and slashes.

Every backslash-free day was a day the bug looked like working code.

Bug 2: Python 3.13 popped the iterator twice

Next up, three round-trip tests exploding on 3.13 only, inside the generated module:

IndexError: pop from empty list

Every one of the three had a for loop in it. Here's the tail of a loop, disassembled on 3.13:

   L3:    74  END_FOR
          76  POP_TOP
          78  RETURN_CONST  5  (None)

Now the same thing across three releases of CPython:

Version	How the loop cleans up its exhausted iterator
3.12	`END_FOR` pops it
3.13	`END_FOR` does nothing, the `POP_TOP` after it pops
3.14	`END_FOR` does nothing, the `POP_ITER` after it pops

My code asked exactly one question: is POP_ITER anywhere in this program? If yes, 3.14, so END_FOR is a no-op. If no, pop.

Which is right on 3.12, right on 3.14, and confidently wrong on 3.13, where END_FOR popped the iterator and then the POP_TOP right behind it reached into an empty stack.

The fix stops guessing the interpreter version and just looks at what's actually next to the instruction:

def _end_for_cleans_up(program: Program) -> bool:
    """Whether ``END_FOR`` has to pop the exhausted iterator itself."""
    for index, instruction in enumerate(program.instructions):
        if instruction.opname != "END_FOR":
            continue
        after = program.instructions[index + 1:index + 2]
        if after and after[0].opname in ("POP_TOP", "POP_ITER"):
            return False
    return True

The lesson I'm taking: when CPython changes bytecode, it doesn't only rename opcodes. It moves stack effects between them. An opcode table that only knows names will pass every test you write on the version you happen to be running.

Bug 3: 3.11 doesn't have inlined comprehensions

Last one, and this one isn't a bug in my code so much as physics.

On 3.11, this round-trip test died:

error: cannot assemble the constant
<code object <listcomp> at 0x106a16bf0, file "<snippet>", line 2>
hint: constants must be literals; code objects, and the functions
and classes built from them, are out of scope

The snippet was one line:

squares = [n * n for n in range(6) if n % 2]

PEP 709 inlined comprehensions in 3.12. Before that, a list comprehension compiled to its own separate code object, and a separate code object shows up in dis output as <code object <listcomp> at 0x7f...>.

You cannot rebuild an object from its repr. The address isn't the object, it's a rumour about where an object used to be. So on 3.11 that comprehension is genuinely unassemblable, and the honest fix is a skip that says so out loud:

if name in INLINED_FROM_312 and sys.version_info < (3, 12):
    self.skipTest(
        "before 3.12 a comprehension compiles to a nested "
        "code object, which is out of scope (PEP 709)"
    )

Same comprehension, on 3.12 and up, round-trips perfectly. A language feature quietly changed shape underneath me and my test suite was the thing that noticed.

What actually shipped

152 opcodes, covering 3.11 through 3.14 spellings, both calling conventions, LOAD_SMALL_INT, TO_BOOL, POP_ITER, the lot
Zero dependencies. Nothing. Not one.
79 tests, including full Python -> assembly -> Python round trips that assert the output matches plain Python character for character
CI on Linux, macOS and Windows, three Python versions each, which is the only reason this post has three war stories in it
A real CLI: run, dump, check, dis, opcodes
Errors that point at your assembly, with a caret, even when the failure happens deep inside a runtime helper

One naming quirk to save you a confused minute: it installs as pyasm-lang and imports as pyasm. The short name was already taken on PyPI by an unrelated project from years ago, so the distribution got the suffix and the package kept the name you'd expect.

>>> from pyasm import run
>>> _ = run("LOAD_NAME (print)\nPUSH_NULL\nLOAD_CONST ('hi')\nCALL 1")
hi

Yes, there's a Python API too. assemble, run, disassemble_source, and the .pya text goes in as a plain string.

Try it in 60 seconds

$ pip install pyasm-lang

Write a program by hand, with labels instead of byte offsets:

        LOAD_CONST 3
        STORE_NAME n

loop:   LOAD_NAME n
        TO_BOOL
        POP_JUMP_IF_FALSE done
        LOAD_NAME print
        PUSH_NULL
        LOAD_NAME n
        CALL 1
        POP_TOP
        LOAD_NAME n
        LOAD_CONST 1
        BINARY_OP (-)
        STORE_NAME n
        JUMP_BACKWARD loop

done:   LOAD_NAME print
        PUSH_NULL
        LOAD_CONST ('Liftoff!')
        CALL 1
        POP_TOP
        RETURN_CONST (None)

Or take the shortcut and let Python write it for you:

$ pyasm dis fizzbuzz.py -o fizzbuzz.pya
$ pyasm fizzbuzz.pya
1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
...

And when you want to see how the sausage is made:

$ pyasm dump fizzbuzz.pya -o generated.py
$ python generated.py    # no pyasm import anywhere in it

Still can't do it

Unchanged from last time, and for the same reason both times: text disassembly doesn't carry everything a code object has.

try/except is driven by a code object's exception table, and dis doesn't print one you can reconstruct. raise works fine.

def, class, lambda compile to separate code objects, which is bug 3 above wearing a different hat. You can import and call any Python function you like, you just can't define one inside a .pya file.

Both of these are on the table if enough people want them. Both are real work.

The ask, redesigned

Last time I asked for one word and got zero words, which is a completely fair review of my ask. So here's a better one.

Write me the most cursed valid .pya file you can, and put it in the comments.

That's it. Anything that assembles. Hand-written assembly that shells out. A quine. FizzBuzz with no %. Something that abuses the NULL slot in a way I didn't anticipate and files a bug for me. I will run every single one of them, and I'll reply to every single one.

Star it if you want to see where it goes: github.com/Natuworkguy/PyAsm

Issues are open too, and honestly, "this crashed" is my favourite kind of issue right now. Three of them just made the thing meaningfully better and they all came from a computer I don't own.

What's the first thing you'd break? 👇

Flash Onyx 2.2 Is Out, and It Finally Finishes the Job

Nathan C. — Sun, 30 Aug 2026 03:00:00 +0000

Flash Onyx 2.2 is live on Ollama. It's the model behind FLASH CLI, my local terminal agent, and it took longer than I planned because 2.1 kept being almost right.

ollama pull Natuworkguy/flash-onyx-2.2:12b

Two sizes, same as before. 12b runs on normal consumer hardware. 31b is the flagship and wants a real GPU.

ollama pull Natuworkguy/flash-onyx-2.2:12b
ollama pull Natuworkguy/flash-onyx-2.2:31b

Then point Flash at it in ~/.flash.env:

MODEL=flash-onyx-2.2:12b

What actually changed

2.1 was fast and short. That was the whole pitch, and it was also the problem. A model that answers in one line will happily answer the wrong question in one line. Most of 2.2 is about making the short answer the right one.

It reads the ask

The biggest fix. 2.1 would give you a good answer to a nearby question. 2.2 counts the verbs in your request and satisfies each one, and it answers at the altitude you asked at. "Is this safe to deploy" gets a yes or a no. "Walk me through the auth flow" gets the walk, not a verdict nobody wanted.

It also stopped confusing questions with instructions. "Could we split this file?" gets an answer and an offer. It doesn't go split your file.

It picks a stack instead of handing you a menu

If you didn't name a stack, choosing is the job. 2.2 picks one, builds it, and tells you what it picked in a clause. A quick web game is one .html file with canvas and plain JS, no build step. Real state and routing earns React on Vite. What your repo already uses beats what it would have picked.

Files get real names too. minecraft_clone.html, clean_payroll.py. untitled, output, script, and v2 are banned outright.

Manim

This is the one I put the most work into, and it's the one I use most. Manim's API is wide and half-remembered, which is exactly the shape a hallucination takes. A method that sounds like it exists on Square usually doesn't.

2.2 builds with VGroup and .arrange() instead of hand-guessed .move_to() coordinates, computes geometry from real points when it isn't sure a convenience method is real, and gives every beat a deliberate run_time and a rate_func picked on purpose. It clears the frame between ideas, because Manim never removes what you stop referencing.

It also deletes its own fumbling. No variable assigned three times, no "wait, that's wrong" comment left in the scene you're about to render.

Games

Feel first. Playable before content: something you steer, something that ends the run, a restart.

Fixed timestep whatever the display does, with a clamped accumulator so a backgrounded tab doesn't spiral. One update(dt), one draw(), one state machine. Input polled, not handled. Coyote time at 100ms, jump buffering at 150ms, a hitbox tighter than the player and looser than the pickup.

And juice, which is most of what people mean when they say a game feels good. Hit pause, a short shake, particles, a sound on every action.

A higher finishing bar

New section, and it's the one that changed the day-to-day most. The standard is work someone who does this for a living would hand over without apologizing for it. Running is the floor, not the finish.

So: a --help that says what the tool does. An error that names the fix. A page that survives 320px. Empty input, one item, ten thousand, a name with an apostrophe, no network. Nothing half-wired, no flag parsed and ignored, no config key read nowhere. Real sample data instead of placeholder text.

It goes beyond code now

2.1 was a coding model that got vague when you asked it anything else. 2.2 has real guidance for the rest:

Stock trends. A trend is structure, higher highs and higher lows, not a slope on two points. Never calls a top or a bottom, never predicts a price or a date. Gives you the setup, the level that invalidates it, and the actual base rate instead of overselling pattern recognition.
Contracts and documents. Reads the whole thing before opining on one clause, reviews from a side, and ranks findings from deal-killer to noise. Names what the document leaves out, because the missing termination right is what the dispute is about later.
Arguments. States the other side's case at its strongest before answering it, concedes what's true, and wins on the one point that decides it. Ten scattered rebuttals read as noise.

One good closing line

2.2 ends on the one thing you'll want next, and only when it can name it exactly. "Built pdfsplit/ and it imports clean. Want a pyproject.toml on it?" is an offer. "Let me know if you need anything else" is noise, and it's banned. Outward-facing moves like publishing, pushing, or deleting get offered and never taken.

Sampling changes

temperature   0.7  ->  0.6
min_p         0.0  ->  0.05
num_ctx     32768  ->  65536

Lower temperature and a real min_p floor cut the confidently-wrong API calls, which matters a lot for Manim. Doubling the context is for long sessions where it's reading a repo instead of one file.

Try it

curl -fsSL https://flashproject.dev/install.sh | bash
ollama pull Natuworkguy/flash-onyx-2.2:12b
MODEL="Natuworkguy/flash-onyx-2.2:12b" flash

If you build something with it, or it does something dumb, tell me. 2.3 gets written from whatever breaks.