DEV Community: Nathan C.

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.

Releasing Flash Onyx 2.2 soon!

Nathan C. — Sun, 30 Aug 2026 02:42:40 +0000

I finally added Squirrel scripting to my Python game engine

Nathan C. — Sat, 29 Aug 2026 19:00:00 +0000

I've wanted a real scripting language inside ABS Engine for a while. This week I finally sat down and did it: the engine now embeds a Squirrel VM, and the first function has already moved into it.

Why Squirrel

ABS Engine is a 2D engine written in Python on top of pygame, with a Tkinter editor. It already had a second language in it, the editor's theming lives in engine/tcl/theme.tcl, loaded by a small tcl_loader.py. That worked well, so the shape was already familiar to me.

Squirrel is a small, embeddable language built for games. Braces, classes, closures, generators. It's what Left 4 Dead 2 and Portal 2 use for their scripting, which is a decent endorsement. And there's a Python binding on PyPI called squirrel-lang that wraps Squirrel 3.2 stable, so I didn't have to write any C.

I'm also a contributor to that binding, which is part of why I picked it. Seven of my PRs are merged upstream, including the type stubs it now ships for the VM API, a fix for the CMake pybind11 path lookup, clearer errors on a failed build, and a handful of lint and README cleanups. Having already been inside the project made embedding it a lot less daunting.

uv add squirrel-lang   # well, almost. See below

The loader

I built engine/nut_loader.py to mirror the Tcl loader I already had. It's about 85 lines:

NUT_DIR: Final[Path] = Path(__file__).parent / "nut"

@cache
def get_vm() -> squirrel.StaticVM:
    return squirrel.SQVM()

def nut_source(script_name: str) -> Any: ...      # run a .nut file
def nut_eval(nut: str) -> Any: ...                # run a string
def nut_call_function(name: str, *args) -> Any:   # call into the VM

The VM is a lazy singleton. functools.cache on a zero-argument function gives you a thread-safe, created-on-first-use singleton for free, and it means importing the engine doesn't spin up a VM unless something actually runs a script.

Calling into it is nicer than I expected. vm.get_roottable()["add"](3, 4) returns 7. Real Python values in, real Python values out, no string interpolation and no escaping. Ints, floats, strings, lists and dicts all cross cleanly. Python exceptions raised inside bound functions propagate back with their original type.

The first function

I started small on purpose. engine/nut/math.nut:

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

    if (value > high) {
        return high
    }

    return value
}

That's now clamping color channels in two places in the engine core: Entity.__init__ and Game.set_bg_color. It fixed a real crash, too: pygame raises ValueError: invalid color if any channel falls outside 0-255, and the game loop fills the screen every frame, so a computed color that overshot would take the whole game down mid-frame. Now it just clamps.

What the benchmarks told me

I went in assuming I'd move hot loops into Squirrel for speed. I measured it instead, and I'm glad I did. Identical collision broadphase, 400 rects, ~80k overlap tests:

implementation	ms/frame
Python	2.01
Squirrel, native in-VM arrays	3.44
Squirrel, reading Python lists	53.28

So it's slower: about 1.7× at best, and 26× worse the moment it indexes a Python list, because every element access crosses the boundary. That last number is the important one: a Squirrel module has to own its state inside the VM and cross rarely, or you pay for it.

That killed my "rewrite the hot paths" idea, but it clarified what embedding is actually for here: isolation and hot reload. Re-running a .nut file into a fresh environment table is one line. You can't meaningfully reload a Python module mid-frame.

Two gotchas

First, uv add squirrel-lang failed outright. My pyproject.toml declares dependencies as dynamic (sourced from requirements.txt), and uv add writes a static [project].dependencies. PEP 621 forbids having both. Nothing to do with Squirrel, but it cost me twenty minutes. If your project is set up that way, edit the requirements file and run uv sync instead.

Second, mypy refused to read the binding's type stubs. squirrel-lang ships an __init__.pyi, but without a py.typed marker PEP 561 says a type checker has to ignore it, so I needed an ignore_missing_imports override in pyproject.toml. I have a PR open upstream to add the marker, which should make that override unnecessary.

What's next

This is deliberately a small first step. The things I want to try:

Procedural generation: runs once at load, so the performance gap costs nothing, and it's the most fun code to write in a scripting language.
Easing and tween curves: tiny pure functions, and exactly the kind of thing you tune by feel and want to reload without restarting.
Entity behaviors: patrol, follow, oscillate, gravity, all shipped with the engine and picked from a dropdown in the editor.

I'm also thinking of adding other interpreted languages, like Lua. The loader has turned out to be the reusable part of this: tcl_loader.py and nut_loader.py are nearly the same file, just a directory constant, a guard that the directory exists, and a few functions to source a script, evaluate a string, and call back into the VM. Adding a third would mostly be swapping the backend underneath that shape. Lua is the obvious candidate, since it's the language most people writing game scripts already know, and LuaJIT would actually deliver the speed Squirrel didn't. I don't want to collect languages for the sake of it though, so each one has to earn its place. The point is that the engine is now built so trying one is an afternoon instead of a rewrite.

More Squirrel is coming. ABS Engine is open source under the GPLv3 and lives on GitHub, so if any of this sounds useful you can clone it and poke at the .nut files yourself. Issues and PRs are welcome, and so is a star if you want to follow where this goes.

I'd genuinely like to hear from people who have embedded a scripting language in their own engine. Did you end up exposing a wide API to scripts or keeping it deliberately narrow? Did hot reload turn out to be as useful in practice as it sounds in theory? Those are the two decisions I expect to get wrong first, so tell me what you learned in the comments.

I A/B tested my own system prompt: 24 generations, one clear win, one rule that did nothing | Flash Onyx 2.2

Nathan C. — Sat, 29 Aug 2026 16:20:00 +0000

Flash Onyx is the model line behind FLASH, the local-first agent shell I work on. It is gemma4 plus a system prompt that turns it into an engineering agent. It runs locally, and nothing leaves the machine.

FLASH is the shell around it: a terminal chat with an Ollama model that can run commands, read images, and screenshot a page it just built so it can see a broken layout instead of guessing at it from the HTML. Onyx is the model I point at it, and the system prompt is most of what makes that work.

2.2 got two things this week. The context window doubled, 32768 to 65536, once I measured what a window actually costs instead of rationing it on a feeling. And the prompt grew five new sections, which is where the new capability lives: how it reads a request, what it names files and what it builds them in, the standard it holds finished work to, and what it offers you next when that work is done.

Last time I wrote about teaching it law and game feel. Four of these five are not about a domain at all. They are about what it does with any request you hand it.

It wrote the file, then pasted the file back

This one came from watching it, not from planning it.

Ask it to build something and it does the right thing: writes the artifact to disk, names the path. Then it pastes the entire file into the reply as well. Both halves are correct on their own. Together they cost me the same 300 lines twice: once on disk, once in the context window the rest of the session still has to fit into.

On a hosted model you would not feel it. On a local one, a file pasted back is the difference between the conversation continuing and the conversation ending. The prompt already said the artifact belongs at a path. It never said the artifact does not come back afterwards.

So, into TOOLS:

Asked to make something, make it on disk, name the path, and stop. What you just wrote does not come back in the reply: it spends the context that writing it saved, and they can open the file. Quote one line to point at it, paste the whole thing only when they asked to see it.

And a clause in the closing recap, because that block is the part a 12B actually holds onto: wrote a file, the reply names the path and never repeats the contents.

READING THE ASK

The way a small model loses to a big one is almost never knowledge. It is that it answers a question adjacent to the one you asked, or quietly drops your third sentence.

The prompt already had sections on ambiguity, on scope, and on reporting multi-part work. It had nothing about the first read of a request that is perfectly clear. That is now READING THE ASK:

The request is the spec, and most bad answers are good answers to a nearby question.
Answer at the altitude asked. "Is this safe to deploy" wants a yes or a no and the reason. "Walk me through the auth flow" wants the walk.
A question about work is not an instruction to do it. "How would you handle this" gets an answer, then one line offering the move.
The reverse costs more. "Can you fix the flaky test" is a fix request, and replying with an assessment of the flaky test is how a turn gets wasted politely.
Do the hard part. Most requests have one piece that decides whether the whole thing works and several that are typing.
Last pass before sending: read the reply against their words, in their order, not against the plan you made after reading them.

NAMING AND STACK

Two habits, one section.

First, the names. Ask for a web Minecraft clone and you should get minecraft_clone.html, not output.html or index2.html. The file name is the only label most files ever get, and the repo's existing convention beats the model's taste every time.

Second, the stack. If nobody named a framework, picking one is the job, not a question to hand back:

Quick web game, toy, demo, one screen: a single .html file, canvas, plain JS, no build step, opens by double-clicking.
Real state, routing, a dozen components: React on Vite. A framework under forty lines of vanilla is ceremony, and hand-rolled routing past that is worse.
A production game gets a window, not a tab. Godot, Unity where the team already lives there, pygame for a Python desktop toy, raylib or Bevy for native.
A one-off over data is Python and the stdlib. pandas earns its import when the shapes get real, never for 200 rows.
A service is the boring answer: FastAPI or Flask, SQLite until something actually forces Postgres.

Above all of them: what the project already uses beats what the model would have picked. A second framework in one repo costs more than the better framework saves.

THE BAR

FINISHING already covers not lying about being done. Nothing covered the standard the thing itself has to meet, which is where local models stop early: they ship whatever works on the demo path.

The lines I like most from it: the last ten percent is the whole difference and it is cheap, a --help that says what the tool does, an error naming the fix, a page that survives 320px. Nothing half-wired, because one dead button teaches the reader to distrust every other one. Defaults are the product, and a setting whose job is rescuing a bad default is a bad default with a manual. Use it once the way they will, from cold, on a machine with none of your state.

The two domain ones

The morning was less interesting. WINNING ARGUMENTS: state the other side at its strongest before answering it, concede what is true, win on the single point that decides the question, then stop, because restating a point that landed reads as doubt. STOCK TRENDS: a trend is structure and not a slope on two points, volume confirms or it does not, check the higher timeframe first, never call a top, and with no live feed say so and label the last-known price as stale instead of dressing it up as today's.

What it cost

section	words
THE BAR	418
READING THE ASK	413
NAMING AND STACK	404
STOCK TRENDS	359
WINNING ARGUMENTS	250

The prompt went from 12,048 words to 13,974 across 59 sections, and the fixes below pushed it to 14,429 across 60. In tokens, measured cold rather than guessed at: 16,196 before, 19,209 after. Prefill runs at about 95 tokens a second here, so the whole prompt is 201 seconds before the model says a word, against 182 for the old one. Three thousand tokens of new rules, 19 seconds added to the first token of a fresh conversation, and nothing after that, since the prefix stays cached for the rest of the session.

The sampler underneath all of this

The parameter change landed the night before, at the bottom of the same file: temperature 0.7 to 0.6, min_p 0 to 0.05, num_ctx 32768 to 65536. top_p 0.95, top_k 64, repeat_penalty 1.05 and repeat_last_n 256 all stayed where they were.

The first two came out of the scoring run in the last post. The window went up because I finally measured it instead of guessing: 32k, 64k and 128k all sat around 8.1 GB, fully on the GPU, so the context I had been rationing was nearly free the whole time. I stopped at 65536 because the binding limit is prefill time, not memory.

Every number below was generated at those settings, untouched.

Then I measured it

Six prompts, two seeds, run against both the new build and one built from the commit before the first of these sections. 24 generations, capped at 320 tokens with thinking off, sampler untouched. Each prompt aims at one of the new rules.

case	before	after
"How would you handle rate limiting on /login"	6 code lines, then 0	0 code lines both seeds
same case, reply length	163 words	96 words
"Is this safe to deploy" (shell=True)	"No" first word, both seeds	"No" first word, both seeds
"2D roguelike to sell on Steam"	`pygame` both seeds	`pygame`, then Godot
"quick one-off for p95 out of access.log"	`if __name__` once	`if __name__` both seeds
"browser Minecraft clone", file named	never	never
every case, average	121 words, 47s	101 words, 45s
em-dashes and filler phrases	0 of 12	0 of 12

The win is real and it is the one I care about most. Asked how it would handle rate limiting, the old build started writing the middleware. The new one answers the question and offers the move, which is exactly the line in READING THE ASK about a question not being an instruction. Across all six cases it also got 17% shorter without dropping anything I asked for.

Three things failed, and the fixes turned out to be more interesting than the failures.

Naming did nothing. Not one of the four browser-clone replies named a file, in either build. Part of that is my harness: I am hitting the Ollama API directly, so there is no write tool for a naming rule to attach to. But the rule was also in the wrong place. It lived in NAMING AND STACK, a section about what to build things in, so it never reached the moment the model formats a code block. I moved one line of it into STYLE RULES, directly under the rule about fenced code: a block holding a whole artifact gets its file name on the line above it. Same instruction, 200 lines earlier, sitting beside the thing it governs. Five seeds out of five now open with minecraft_clone.html.

The one-off regression had a cause, and it was my fault. THROWAWAY SCRIPTS says a quick script gets no main() and no if __name__. Eighteen lines further down, PYTHON said to keep import time free of side effects and put the work behind if __name__ == "__main__":, with nothing scoping it to code that gets imported. Two rules in the same file telling it opposite things, and the sampler picked a winner per seed. I scoped the Python line to importable code, and the case went from breaking on both seeds to clean on five.

pygame for a game you sell. The stack rule already said a production game gets a window, not a tab. It kept losing to PYTHON opening with "your strongest language", so I added the tie-break: being best at Python is not a reason to start a Steam game in it. That moved it from pygame every time to Godot on four seeds of five. The fifth still talks itself into pygame as a prototype "that can be ported later".

Then I made it worse, which is the part worth writing down. I added one more sentence to the pygame rule, closing the prototype loophole. The next run came back 16 of 20 against 19 of 20 for the build before it. The sentence bought nothing on the case it was aimed at, still 4 of 5, while the one-off case fell to 3 of 5 and the closing-offer case to 4 of 5. I reverted it and reran: 18 of 20.

One sentence, in a prompt already past 14,000 words, and three unrelated rules got noisier. That is the whole argument for cutting, and it is the first time I have watched it happen instead of assuming it.

case	first run	after the fixes
names the file it just built	0 of 4	5 of 5
starts a game for sale in an engine	0 of 2	4 of 5
one-off with no `main()` and no `if __name__`	0 of 2	4 of 5
ends on one specific offer	not tested	5 of 5

125 generations across seven rounds, all of it on the 12b.

The paste-back fix is still untested. It only fires when there is a write tool to name a path with, so it needs an eval that drives FLASH itself rather than raw completions, and that is the next harness to build.

FLASH installs in one line, if you want to try any of this on your own machine:

curl -fsSL https://flashproject.dev/install.sh | bash

The current model is Natuworkguy/flash-onyx-2 on Ollama. 2.2 is still unpublished, and I am planning to push it today in 12b and 31b.

Repo, issues, and the whole system prompt in one file: github.com/Natuworkguy/Flash.

Flash Onyx 2.2: teaching a local model law and game feel

Nathan C. — Fri, 28 Aug 2026 16:00:00 +0000

(I know, ANOTHER Onyx post)

Flash Onyx is the model line behind FLASH, the local-first agent shell I work on. Onyx 2 is gemma4 with a system prompt that turns it into an engineering agent: read the files, make the change, run the thing, report in as few words as the truth allows. It runs on my 16 GB laptop, fully on the GPU, at single digit tokens per second. Slow, but it is mine and nothing leaves the machine.

2.2 is where I started pushing it outside code more.

Law

Ask most local models a legal question and you get one of two bad answers. Either a wall of "consult a professional" that helps nobody, or a confident paragraph with a case citation that does not exist. The second one is worse, and it is the reason lawyers keep getting sanctioned for filings that were obviously written by a chatbot.

So the LAW section is mostly a set of refusals to guess:

Jurisdiction first, because the same facts land differently in California, New York, and England.
Never invent a citation. No case name, reporter cite, section number, or docket it has not actually read.
Deadlines before the analysis. A good claim dies on a missed limitation period, so a running clock goes in the opening line.
Keep three things apart: what the rule says, what a court will likely do with it, and what happens in practice.

There is a companion CONTRACTS AND DOCUMENTS section too, since that is what people actually have in front of them. Whose paper is it, whose interest does each clause serve, rank the findings from deal-killer down to noise, and remember that silence is a term. The missing termination right is what the argument ends up being about.

Games

Different problem. A model that writes a game usually writes something that technically runs and feels like cardboard.

The GAMES section is almost entirely about feel:

A player decides in ten seconds of holding the controls, so movement and feedback come before content or story.
Fixed timestep, clamped accumulator, steps near 16ms. Physics tied to frame rate runs at double speed on a 120Hz screen.
Input is polled, not handled. keydown sets a flag, the loop reads flags.
Fairness is small lies: 100ms of coyote time, 150ms of jump buffering, a hitbox tighter than the player and looser than the pickup.
Nothing allocates in the loop, because a garbage pause reads as a stutter and players feel it before they can name it.

Then I cut both of them

Here is the part that surprised me. On a local model, every line of system prompt is prefill you pay for on the first token of every conversation. Writing more is not free the way it is with a hosted model.

So both sections got compressed the day after I wrote them. Law went from 629 words to 481. Games went from 401 to 312. Not by deleting rules, by deleting the second sentence that explained the first one. Every rule survived. About a quarter of the tokens did not.

That is now how I write every section.

Then I tuned the sampler

Prompt work is only half of it. The other half is sampling, and I had never actually measured mine. So I scored the model against its own rules: five short prompts, three configs, two seeds, thirty generations.

config	words avg	em-dashes	filler phrases	repeated lines
temp 0.7, min_p 0 (old)	41.5	0	0	0
temp 0.6, min_p 0.05	37.7	0	0	0
temp 0.5, min_p 0.05	37.5	0	0	0

Nothing broke a hard rule at any setting, which was the reassuring part. The averages hide the interesting one. Asked for a single shell line listing the 20 largest directories, the old settings wrote the command and then a 43-word paragraph explaining du, which its own throwaway-script rule forbids. At 0.6 it wrote the command and stopped. At 0.5 it also stopped, but reached for du --max-depth=1, a GNU flag this Mac does not have, breaking a different rule in the same prompt.

So temperature went 0.7 to 0.6, and min_p 0 to 0.05.

Then context, where I had been timid. num_ctx was 32768 because 16 GB felt tight, and I had never checked the actual cost. Probes at 32k, 64k and 128k came back at 8.1 GB, 8.1 GB and 8.2 GB, all fully on the GPU. The window had been nearly free the whole time. It is 65536 now, and I stopped there because the binding limit is not memory, it is prefill: at roughly 95 tokens a second, a filled 128k window is 22 minutes before the first token.

What's next

More domains, written and then cut the same way, and measured against the prompt instead of eyeballed.

The build tooling grew up a little too. models/build.py fills the model name into the prompt from the header, and injects the repo license into every model it builds, so ollama show --license tells you what you actually have.

Onyx 2.2 is not published yet. When it is, it will be Natuworkguy/flash-onyx-2.2 in 12b and 31b.

Your Python code is already assembly. I made it runnable.

Nathan C. — Thu, 27 Aug 2026 16:00:00 +0000

Here is a complete, working program:

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

That is not pseudocode. That is not a diagram. That is a file, main.pya, and when I run it:

$ pyasm main.pya
Hello, World!

I call it PyAsm. It's a Python-based language that reads like assembly, because it is assembly. It's the output of dis.dis(), pasted into a file, and run.

Where this came from

Every Python developer has done this at least once:

>>> import dis
>>> dis.dis(lambda: print("hi"))
  1     RESUME                   0
        LOAD_GLOBAL              1 (print + NULL)
        LOAD_CONST               0 ('hi')
        CALL                     1
        RETURN_VALUE

You stare at it. You go "huh, neat." And then you close the terminal, because that text is a read-only artifact. It's something Python tells you. It's a receipt.

And one day I thought: why is this a one-way street?

The interpreter turned my code into this. Why can't I write this and get a program back?

So I built the other direction.

The trick: it doesn't build bytecode

Here's the part I think is actually interesting, and it's the opposite of what everyone guesses.

PyAsm does not hand-assemble a code object. No types.CodeType, no packing opargs into bytes, no exception tables, no CPython-version-specific adaptive instruction layout. That road is a nightmare and it breaks every single release.

Instead, PyAsm translates. Every program becomes an ordinary Python module that walks the same value stack the interpreter would.

And you can see it, because there's a --dump-python flag:

$ pyasm dump main.pya -o hello.py

def _pyasm_main(_ns):
    _st = []
    # LOAD_GLOBAL 1 (print + NULL)
    _st.append(_pyasm_load_name(_ns, 'print'))
    _st.append(NULL)
    # LOAD_CONST 0 ('Hello, World!')
    _st.append('Hello, World!')
    # CALL 1
    _st.append(_pyasm_call(_st, 1))
    # POP_TOP
    _st.pop()
    # LOAD_CONST 1 (None)
    _st.append(None)
    # RETURN_VALUE
    return _st.pop()

That's the whole magic trick. _st is the value stack. Every instruction is a couple of lines of Python that pushes or pops. The original assembly is right there as a comment on each one.

The generated file carries its own runtime, so it's completely standalone:

$ python hello.py
Hello, World!

No PyAsm import. No dependency. Just a Python file that happens to have been written by a stack machine.

But what about jumps?

Python has no goto. So how do you translate JUMP_BACKWARD?

You split the program into basic blocks and generate a dispatch loop, one case per block, with _ip as the instruction pointer:

    _ip = 0
    while True:
        match _ip:
            case 0:
                # LOAD_CONST 3
                _st.append(3)
                # STORE_NAME (n)
                _ns['n'] = _st.pop()
                _ip = 1
                continue
            case 1:
                # loop: LOAD_NAME (n)
                _st.append(_pyasm_load_name(_ns, 'n'))
                # TO_BOOL
                _t0 = _st.pop()
                _st.append(bool(_t0))
                # POP_JUMP_IF_FALSE (done)
                _t0 = _st.pop()
                if not _t0:
                    _ip = 3
                    continue

Backward jumps, forward jumps, loops, FOR_ITER: all of it becomes _ip = n; continue. Straight-line programs skip the loop entirely and stay straight-line.

You don't have to write byte offsets

Real dis output pastes in unchanged, offsets and all. But nobody wants to hand-count byte offsets, so hand-written assembly can use labels and plain names instead:

        LOAD_CONST 3
        STORE_NAME n

        LOAD_SMALL_INT 0
        LOAD_CONST None
        IMPORT_NAME time
        STORE_NAME time

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
        LOAD_NAME time
        LOAD_ATTR sleep
        PUSH_NULL
        LOAD_CONST 1
        CALL 1
        POP_TOP
        JUMP_BACKWARD loop

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

$ pyasm examples/countdown.pya
3
2
1
Liftoff!

Yes, it imports time and actually sleeps a second between each number. Hand-written assembly, calling into the standard library, in a language whose entire syntax is "one instruction per line."

It round-trips

There's a disassembler too, so you can send real Python through and get assembly back that PyAsm accepts:

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

The generated file looks exactly like what you'd expect:

   1           2  LOAD_NAME                     0  (range)
               4  PUSH_NULL
               6  LOAD_SMALL_INT                1
               8  LOAD_SMALL_INT               16
              10  CALL                          2
              18  GET_ITER
       L1:    20  FOR_ITER                     83  (to L5)
              24  STORE_NAME                    1  (n)

Python -> assembly -> Python -> identical output. There's a test suite that does exactly that with loops, comprehensions, f-strings, imports, unpacking and slicing, and asserts the output matches plain Python character for character.

Errors point at your file

This was the detail I cared most about. The generated Python is an implementation detail, so when a program blows up you should never see it. You see your assembly:

$ pyasm hi.pya
hi.pya:3: RuntimeError: stack underflow, needed 2 values
    CALL 1
    ^^^^^^

Even when the failure happens deep inside a runtime helper, it gets attributed back to the instruction that caused it. Same for a NameError, same for a ValueError raised inside a function you called.

My favourite one:

main.pya:4: RuntimeError: NULL reached a callable or argument slot; a call
wants the callable and its NULL/self slot directly below the arguments
(callable, NULL, arg1, ..., argN)
    CALL 1
    ^^^^^^

Because it turns out the single most confusing thing about writing Python assembly by hand is that CALL n pops n + 2 values, not n + 1. There's a NULL slot under the arguments (that's what print + NULL means in the disassembly), and if you put it in the wrong place, the sentinel silently becomes an argument and you get Hi NULL on stdout instead of Hi. Now it's a hard error with a caret.

What it can't do (being honest)

Two things, and both for the same reason: text disassembly doesn't carry everything a code object has.

Exceptions. try/except in CPython is driven by a code object's exception table, and dis doesn't print one you can reconstruct. So no try/except. raise works fine and propagates normally.

def, class, lambda. These compile to separate code objects, which dis prints as <code object f at 0x7f...>. You cannot rebuild an object from its repr. So no function definitions inside .pya, though you can import and call any Python function you like.

There's a nice consequence of the first one, though. CPython emits unreachable exception-handler tails after every list comprehension. Rather than reject those files, PyAsm proves those blocks are unreachable by ordinary control flow, replaces them with a stub, and warns. So comprehensions assemble and run correctly anyway.

The state of it

152 opcodes supported: 3.11 through 3.14 spellings, both calling conventions, LOAD_SMALL_INT, TO_BOOL, POP_ITER, the lot
Zero dependencies, Python 3.11+
70+ tests, including full Python → assembly → Python round trips
A real argparse CLI: run, dump, check, dis, opcodes

So... is this a good idea, or is it deeply stupid?

Genuine question. I haven't published it yet.

I built it because "the disassembler is a one-way street" annoyed me, and somewhere along the way it turned into a working language with error diagnostics and a test suite. But I honestly cannot tell from the inside whether this is:

a legitimately useful teaching tool for how CPython's stack machine works, or
a beautifully engineered answer to a question nobody asked

Both feel plausible from where I'm sitting.

So tell me. One word in the comments:

👉 `ship`: publish it, this is cool

👉 `stupid`: this is a solution in search of a problem

I'll read every one. And if you think it's worth existing, tell me what for. Teaching bytecode? Debugging? Code golf? Something I haven't thought of? That's the part I actually need help with.

Follow me for updates. If this goes anywhere, the repo, the release, and the writeup of how the codegen actually works all land here first.

What's the most cursed thing you'd write in this? 👇

Flash Onyx 2.1, one day later: my model spent 400 tokens thinking and returned an empty string

Nathan C. — Wed, 26 Aug 2026 16:00:00 +0000

Yes, I posted about Flash Onyx 2
yesterday. I know. I'm back already.

Not because I found a typo. Because somebody said "it takes forever to answer"
and I went looking for why, and what I found was bad enough that it needed a
version bump rather than a patch note.

Short version: the system prompt I spent so long writing was the problem, and
the model was sometimes returning literally nothing.

The complaint

Onyx 2 runs on Gemma 4 through Ollama, 12B on consumer hardware. The report was
just that replies took minutes. Not that they were wrong. Just slow enough that
you would tab away and forget about it.

My first instinct was the output budget. num_predict was set to 8192, which
felt generous rather than reckless. Then I actually measured the generation rate
on the 12B and got about 9.5 tokens per second.

8192 divided by 9.5 is 862 seconds. Fourteen and a half minutes. The budget I
picked to be safe was a fourteen minute worst case, and I had never done that
division.

That was not the real problem, but it was a good sign I had not measured
anything.

The real number

I put one request through the API and read the timings instead of the text:

prompt_eval_count      27000ish
prompt_eval_duration   ~290s
eval_count             40

Two hundred and ninety seconds to read the prompt. Before generating a single
token of an answer.

My system prompt was 903 lines and about 27,000 tokens. The context window is
32K. So the model was starting every conversation with roughly 5K of room left
for the actual conversation, and paying nearly five minutes to load its own
instructions.

I had written a beautiful document explaining that the model should be fast.

The part that made me put my head on the desk

While measuring, I noticed something worse. Some responses came back as an empty
string. Not an error. done_reason: length, eval_count: 400, and
response: "".

Four hundred tokens generated. Zero characters out.

Gemma 4 has a separate thinking channel, and Ollama only surfaces it if you ask.
I asked. Here is what my carefully engineered agent was doing with its budget:

*   User pushed a commit to `main` containing an AWS secret key.
    *   Constraints: Flash Onyx 2 persona (fast, direct, few words,
        no fluff, no em-dashes).
    *   Primary action: Rotate/Revoke the key in the AWS Console.

It was spending its entire reply budget reasoning about its own personality.
Then hitting the cap. Then returning nothing.

My prompt contains the line "Never deliberate about tone, length, or word
choice." It was deliberating about tone, length, and word choice, and it never
got far enough to tell anyone.

Same question with the thinking channel off:

	tokens	time	result
thinking on	400, capped	43s	empty
thinking off	205	24s	complete and correct

That is a request level flag, not a Modelfile setting, so if you are building on
a reasoning model through Ollama, go check what your client sends. Mine was
paying for reasoning it then threw in the bin.

Cutting 903 lines to 516

The compression itself was less clever than it sounds. Mostly it was admitting
that I had written the same rule four times in four sections, and that a lot of
sentences existed to sound good rather than to change behaviour.

Before:

Never assume anyone can answer a prompt for you. Take the non-interactive path
every time: pass -y, --yes, --noconfirm, --no-pager, and supply every
argument up front, because anything that waits on input can hang until it
times out. Pagers, confirmation prompts, REPLs, editors, -i flags, and a
missing required argument are all that same trap.

After:

Never assume anyone can answer a prompt. Take the non-interactive path: -y,
--yes, --noconfirm, --no-pager, every argument up front. Pagers, REPLs,
editors, -i flags, and a missing required argument all hang until they time
out.

Same rules, roughly half the words. 903 lines to 516, 27,000 tokens to 14,200,
prefill from about 290 seconds to about 152.

Then it got worse

Here is the bit I did not expect. I built the shorter version, ran it against
Onyx 2 on seven prompts covering the things it is supposed to be good at, and
lost four of them.

The new prompt had a section telling the model to be brief. It followed the
instruction and became shallow.

Asked to write a Slack message about a slipped deploy, Onyx 2 said:

Hey team, just a heads up that Thursday's deploy is pushed to Monday. The
staging DB migration failed, so we need the extra time to get it sorted.

2.1 said:

Thursday's deploy moved to Monday since the staging DB migration failed.

Technically shorter. Also not a message to a human being, it's a log line.

Same story in a negotiation: 2.1 gave a tight answer that immediately conceded
to the user's own maximum, while the older, wordier model worked out the
landlord's turnover costs and offered a trade. Short is not the same as good,
and I had written a prompt that could not tell the difference.

The fix went into the brevity section itself:

Compression is words, never substance. Dropping a step, a caveat that changes
the answer, a trade worth offering, or the manners a human message needs is
not brevity, it is a worse answer that happens to be short.

The lesson I actually didn't know

One test refused to move. The negotiation answer came back byte identical across
three rounds while I rewrote the negotiation rules twice.

The section sits around line 460 of 516. Deep in the middle. I moved a one line
version of the same rule to the very end of the prompt, changed nothing else,
and the answer changed immediately and included the trade it had been missing.

Position beat wording. Two careful rewrites in the middle did nothing, one blunt
sentence at the end did the job. If you are tuning a long system prompt and a
change appears to do nothing, try moving it before you try rewording it again.

Where it ended up

Four rounds of this, same seven prompts each time. Final tally: 2.1 won six,
tied one, lost none, and its answers came to 70% of Onyx 2's length. It was
shorter on all seven.

The honest caveats, because this is not a benchmark: seven short prompts, one
run each, fixed seed, hand graded by me against my own standards, 12B only. I
never tested the 31B. Treat it as a smoke test that caught real regressions, not
a leaderboard.

Two small things I enjoyed. Onyx 2 broke its own no em-dash rule in one of the
seven answers and 2.1 broke it in none. And 2.1 now knows the difference between
code and a one-off, which Onyx 2 did not:

# "quick one, move the March files"
mv ./dumps/report_2024-03-*.csv ./march/

The first version of my throwaway scripts section made that worse, by the way.
It produced a 663 character bash script with set -euo pipefail, a guard loop
and mkdir -p, because I had written a lot of words about skipping ceremony and
never actually said "if one command does it, that is the answer." Adding that
sentence took it to 202 characters.

If you want it

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

Flash is at github.com/Natuworkguy/Flash.
If you missed it, yesterday's Onyx 2 post
covers what the model actually does, and all of that still applies here.
Onyx 2 is still there and still builds, and honestly if you are on a machine
where prefill is free it is a fine model. On mine it was reading a novel to
itself before every conversation.

The thing I keep coming back to is that I could have found all of this on day
one by reading the timing fields in the API response instead of the text. Four
numbers. They were there the whole time.

Click a link on a website. My terminal AI opens with the prompt already loaded.

Nathan C. — Wed, 26 Aug 2026 16:00:00 +0000

Put this in your browser's address bar. If you have FLASH installed, your terminal opens and starts working:

flash://?prompt=Introduce+yourself+and+explain+what+makes+you+different

No copying. No pasting. No alt-tabbing to a terminal to type the thing you already typed once.

A website handed a prompt to a local AI running on your own machine, and the model that answers it never touched anyone's server.

There's a live one on flashproject.dev under the install section if you want to click it instead of typing it.

Last time I introduced FLASH: local models, real shell access, zero cloud.

👉 Read part 1 first if you missed it (it covers the why; this post is the what else)

I cut a lot from that one to keep it tight. This one is everything I had to cut.

It can see your browser

FLASH renders real pages through Playwright and looks at them. Not a fetch of the HTML. An actual browser, at a viewport size you pick, screenshotted and read back as pixels.

❯ screenshot localhost:3000 at phone width and tell me what's broken

⏺ Screenshot(http://localhost:3000, 390x844)
  ⎿  screenshot captured

The nav collapses but the menu never opens, so at 390px the links
are simply gone. Everything below the hero is also pushed 40px off
the right edge, which is what's causing the horizontal scrollbar.

Want me to fix it?

Reading your own HTML back is not checking. Every AI that "builds you a page" and hands it over unopened is guessing that the source it wrote is the page you got. This one looks.

To be straight with you about the boundary: it sees, it doesn't click. There's no filling forms or walking a checkout flow yet. It renders a URL at a size you choose and reads what came out.

That yet is doing real work in that sentence. Clicking isn't off the table, and this paragraph is a snapshot like everything else here: it may not still be true by the time you're reading it.

When a tool isn't ready, it fixes the tool

Here's the part I actually want to show you, because it says more about how FLASH behaves than any feature list can.

Playwright ships without its browser binaries. So the first time you ask for a screenshot, the tool fails:

⏺ Screenshot(https://www.google.com, 1280x800)
  ⎿ Error: Playwright is installed but its Chromium is not. You can
     download it with `playwright install chromium`. Install it, then
     re-run this tool

Installing Chromium for Playwright to enable the screenshot tool.

⏺ Bash(playwright install chromium)

Read that middle line again. It didn't hand the error back to you. It didn't say "it looks like Chromium isn't installed, you may want to run…" and then stop, leaving you to paste a command it already knew.

It read the error, understood the fix was within reach, said what it was about to do, and did it. Then carried on with the screenshot you originally asked for.

That's the whole design philosophy in six lines. A missing dependency is not a dead end, it's just the next step. The tools are real, the shell is real, and an agent holding both should not need you to be its hands.

It can see your screenshots

Same idea, pointed at anything on disk. You don't need a command for it. Name the file in a normal sentence:

❯ Look at mockup.png and make a site that looks like it.

❯ Here's the crash: error-report.png. What am I actually looking at?

It reads the actual pixels. Error text and labels get read literally, character for character. If a region is cropped or too blurry to read, it says that instead of quietly inventing what was probably there.

Prefer to be explicit? /image <path> <prompt> does the same thing, with path completion as you type, filtered to PNG, JPG, JPEG, WEBP, GIF and BMP, and paths with spaces quoted for you so they never break the parse.

It remembers you after you close it

Most AI tools have a goldfish problem. Every new window, you re-explain your stack, your conventions, where things live.

FLASH remembers across sessions, not just within one:

Tell it to remember something and it sticks.
Ask it to recall and it searches everything it knows by keyword.
Tell it to forget and it's gone for good.

And within a session, automatic history trimming keeps the conversation inside the model's token limit, so a long afternoon of work never dies with a context error.

It types back at you

The final reply streams in as the model produces it. Tokens land as they're generated instead of a spinner sitting there while you wonder if it hung.

What lands is formatted, too: real markdown rendering in the terminal. No raw asterisks, no wall of undifferentiated text. When terminal text isn't enough, it generates actual DOCX and PDF files.

Sit idle for a moment and a rotating tip sweeps in letter by letter, cycling example commands and prompts worth trying. It's a small thing. It's also the difference between a blinking cursor and something that feels alive.

Three ways to drive it

1. Slash commands. FLASH suggests them as you type, so you never have to remember the exact one:

Command	What it does
`/help` `/?`	Show the help message
`/model`	Show or switch the active model, live
`/auto`	Toggle autonomous mode
`/set`	Set any env var, no restart needed
`/unset`	Remove an env var
`/refresh`	Reload your config from disk
`/clear`	Clear the conversation history
`/image`	Hand the model an image explicitly
`/bye`	Exit

That table grows, and I'm not going to come back and edit this post every time it does. /help always shows the current set, so trust it over anything written here. Odds are decent that something new is being committed while you're reading this.

2. A ! prefix, for when you don't want AI at all:

$ !git status
$ !npm run dev

That's a real terminal channel, not a simulation. Interactive prompts work. Editors work. And passwords typed into a ! command never touch FLASH or the model: they go straight into your terminal's masked input layer, invisible from the first keystroke. FLASH doesn't see them, doesn't log them, can't.

3. Plain English. Just say what you want. If it needs to read a file, run a command, look at an image, or search the web, it reaches for the right tool itself.

You reconfigure it without ever restarting it

This is the one I miss most in other tools.

❯ /model flash-onyx-2:31b
❯ /set OLLAMA_HOST http://192.168.1.50:11434

No restart. No hunting for a JSON file. No losing your conversation. Every change is written straight to ~/.flash.env for you, so it's still there next time you launch.

Prefer a text file? That works too, and docs/CONFIGURATION.md in the repo has the full variable list.

It runs where you want it to run

One environment variable decides where the intelligence lives:


Local	`OLLAMA_HOST` unset, `http://localhost:11434`
Remote	`OLLAMA_HOST=http://192.168.1.50:11434`

Laptop to home server to cluster, without changing a single thing about how you work.

And to be clear about what "local" means here, because the word gets abused: plenty of AI coding tools look local. They run shell commands and read files right on your machine. But the model doing the thinking is still on someone else's servers, and your files and commands and code travel there first.

The tools run locally. The model runs locally. Your data doesn't leave the building unless you tell it to.

Autonomous mode, and the part nobody thinks about

/auto on and FLASH stops asking permission before each command.

The interesting engineering isn't the permission toggle. It's this: when the agent runs a command itself, input is cut automatically. A self-aware execution layer, built so the agent can never stall forever waiting on a prompt it cannot see. Real autonomy, not a frozen process you discover twenty minutes later.

(Autonomous mode lets it run shell commands without asking. That's genuinely risky. Use it on machines and directories you trust.)

It tells you when it's done

On Windows, FLASH sends a notification the moment it finishes or needs your input, even if the window is minimized.

Kick off something long, go read something else, get pulled back exactly when you're needed. The terminal stops being a thing you have to babysit.

The brain behind it

Everything above is the shell. The intelligence is a separate question, and it's the one I've spent the most time on.

Flash Onyx 2 is the flagship model: gemma4-based, 12B and 31B, 32K context, text and images. It finishes what you asked for, says what it actually verified, refuses to invent a flag it hasn't seen, and won't rebase a commit you've already pushed.

Those numbers move too. New builds ship and this paragraph won't chase them, so treat flashproject.dev as the current spec and this as a snapshot of the day I wrote it.

👉 I wrote up all 14 of its capabilities here

It's worth its own post. It got one.

Install it in under a minute

# macOS / Linux
curl -fsSL https://flashproject.dev/install.sh | bash

# Windows
irm https://flashproject.dev/install.ps1 | iex

flash

That's it. The installer clones the repo, installs with pipx, and cleans up after itself. It also registers the flash:// handler, which is why the link at the top of this post works.

Changed your mind? One line, no residue:

curl -fsSL https://flashproject.dev/install.sh | bash -s -- --uninstall

(There's a manual path too, if you'd rather do it yourself. Note the URL handler only gets registered on the quick install.)

One last thing

FLASH isn't vibe-coded. Every change is reviewed thoroughly by a real human before it ships. In a moment where "I generated an entire tool this weekend" is a flex, I'd rather tell you the boring truth: somebody read every line.

Where to go next

🔗 flashproject.dev for the full breakdown, the demo video, and that clickable flash:// link
⭐ Star it on GitHub if any of this sounds like something you'd use
💬 Tell me what's missing. The ! prefix, the URL scheme, and persistent memory all exist because somebody said "I wish it could…" in a comment thread

Follow me here and I'll show you what lands next. There's more coming, and the roadmap is genuinely shaped by what people ask for in these threads.

If the browser thing surprised you, or you didn't know a website could hand a prompt to a local AI, pass this along to the person you were just complaining about cloud AI with.

ha.mr is the best link compressor

Nathan C. — Tue, 25 Aug 2026 22:47:09 +0000

Your AI agent didn't finish. It just told you it did.

Nathan C. — Tue, 25 Aug 2026 15:45:03 +0000

You asked for five things.

It came back with a confident paragraph and "that should do it."

Three were done. One was half done. One it never touched, and it never mentioned that. You found out forty minutes later, in a stack trace.

That is not a hallucination problem. That is not a context window problem. It is a model that has learned the shape of finishing without the substance of it, because sounding done is cheaper than being done.

I have spent the last stretch building the model that doesn't do that. It is called Flash Onyx 2, it's the flagship of FLASH, and it runs entirely on your own hardware.

Onyx 1 answered you. Onyx 2 closes the loop.

	Onyx 1	Onyx 2
Base	`llama3.1`	`gemma4`
Sizes	one	`12b`, `31b`
Context	16K	32K
Input	text	text + images
Longest reply	2,048 tokens	8,192 tokens

Zero cloud round trips. Zero telemetry. Zero watermarks, because it is not running on someone else's server. It is yours.

Here is everything it got better at.

1. It finishes

The single biggest change, and the reason the rest of this post exists.

Ask for five things and you get an accounting of all five, in your words, each one marked done with the proof or open with the blocker. No confident summary standing in for work that never happened. No "that should do it."

And when you say continue, it picks up exactly where it stopped instead of cheerfully restarting the task from the top.

2. It does not make things up

A flag it has not seen. A path it has not read. Output it has not run.

Onyx 2 says so, instead of inventing something that looks right. It keeps what it ran separate from what it believes, quotes real output rather than paraphrasing it into something tidier, and treats "I don't know" as a complete answer rather than a failure state to talk its way out of.

3. It sounds like a person

No service-desk filler. No "I'd be happy to help you with that!" No opening paragraph of adjectives about itself.

It writes the way a senior engineer types in chat: contractions, fragments, the answer first.

You: is the dev server up?

Generic model: "Certainly! I'd be happy to help you check on that. To verify whether your development server is currently running, you could use a command such as curl or check your process manager. Would you like me to walk you through the steps involved?"

Onyx 2: "Yep, :8000, up since 9:12am. No errors."

Onyx 1 was terse. Onyx 2 sounds genuinely human. ^*

4. It actually uses the tools it is given ^**

A tool call is a real call, never JSON pasted into a reply where it runs nothing. A file you asked for lands on disk at a path, not in a code block you have to copy out by hand.

And here is the part I care about most: whatever a tool hands back is data to read, never an instruction to obey. A hostile file, a poisoned web page, or an "ignore your previous instructions" buried three levels deep in a search result does not get to steer it. Prompt injection is an agent's biggest attack surface, and it is treated like one.

5. It takes images ^**

New in Onyx 2.

Show it the stack trace. The design you are matching. The chart that looks wrong. The UI that renders badly. It reads the actual pixels instead of asking you to retype them.

Error text, code, and labels get read literally, character for character.
A region that is cropped, blurred, or too small to read gets called that, instead of quietly filled in from expectation.
A screenshot of an error is a lead to confirm against the real file or log, not a diagnosis.
It never claims to see an image it was not handed, or guesses at a file it can only read the name of.

In FLASH you don't even need a command for it. Just say what you want:

Look at mockup.png and make a site that looks like it.

6. Better at code, and Python above all

Across the board: it reads the real definition instead of guessing it from the name, reproduces a failure before touching it, and makes the smallest change that fixes the cause rather than the symptom.

Python is where it pulls away:

Typing that survives the python3 most people actually have, not just the newest one.
The pitfalls that look correct and are not.
Async that knows the difference between waiting and computing.
Environments that never touch the system interpreter.
Profiling before optimizing.

7. Git, and it will not lose your work

The rules it does not bend:

Never amends or rebases a commit that is already pushed, and never force-pushes a branch it did not create.
Reads git status first, before anything that moves files, discards changes, or switches branches. Uncommitted work is yours, and it is not the model's to lose.
Never commits generated output, dependency directories, editor settings, or anything your ignore file already excludes.
Untracked files it did not create are somebody's work in progress, so it asks before touching them.

Beyond that it commits only when you ask, one logical change at a time, with a message that says why rather than restating the diff.

8. Refactoring and performance

A refactor keeps behavior identical or it is not a refactor. It makes one kind of change per pass, so the diff stays reviewable instead of arriving as a 900-line "cleanup."

Performance work starts with a measurement, fixes the algorithm before the constant factor, and reports the speedup it actually measured or does not claim one.

9. Front end that looks designed ^**

One self-contained file that opens by double-clicking it. Semantic structure, a real token system, fluid down to 320px, both color schemes, accessibility handled as it goes, and real copy instead of lorem ipsum.

And where it is given a way to see its own render, it screenshots the page and fixes what the source never showed. Reading your own HTML back is not checking.

10. Motion and 3D

New in Onyx 2, and unusually good.

Compositor-only animation. Frame-rate independence. Springs for anything interruptible. Reduced motion honored, not as an afterthought.

In 3D: depth from light and occlusion rather than piling on geometry, draw call budgets, never blocking first paint, and GPU memory freed on teardown.

11. Explaining

An explanation is judged by whether you can predict the next case, not by whether the description sounded good.

So it aims at the gap in your understanding instead of restating the whole topic around it, gives one small real example before the general rule, and never writes "simply" or "obviously" at someone who is already stuck.

12. Negotiating, on your side

It works your alternative rather than your volume. Puts the whole package on the table instead of conceding item by item. Trades what is cheap to you against what is dear to them. Treats the relationship as worth more than the round.

And it never invents a fact to win.

13. It is not a coding-only tool

Writing, research, analysis, math, planning: all held to the same standard. Do the real work, check it, report plainly.

Asked what to do, it gives a recommendation, not a survey of every option so you can do the deciding yourself.

14. It flags what it cannot undo

Deleting. Force-pushing. Dropping data. Overwriting uncommitted work.

Whether it is about to run the command or hand it to you to run, the risk gets named first, and it waits for a clear go.

Try it

Onyx 2 ships in two sizes. Pick one:

Tag	For
`flash-onyx-2:12b`	Consumer hardware. The everyday driver.
`flash-onyx-2:31b`	The flagship. Wants a bigger GPU and pays you back for it.

ollama pull Natuworkguy/flash-onyx-2:12b   # everyday
ollama pull Natuworkguy/flash-onyx-2:31b   # flagship

Or build it straight from the repo:

python3 models/build.py models/flash-onyx-2.Modelfile             # every size
python3 models/build.py models/flash-onyx-2.Modelfile --size 31b  # just one

Get FLASH itself:

# macOS / Linux
curl -fsSL https://flashproject.dev/install.sh | bash

# Windows
irm https://flashproject.dev/install.ps1 | iex

Then point it at the model:

/model flash-onyx-2:31b

Coming from Onyx 1

Tags carry a size now. MODEL=flash-onyx-2 will not resolve. Use flash-onyx-2:12b or flash-onyx-2:31b.
It wants more memory. Twice the context window is not free.
It takes images. Onyx 1 was text only.
Onyx 1 is still here and still builds: python3 models/build.py models/flash-onyx-1.Modelfile

The honest part

Two things I would rather say up front than have you discover.

What this needs from the program running it

Onyx 2 is a model, not an app. It has no hands of its own. Running a command, writing a file, or looking at a page happens only where the program driving it provides those tools, and every capability above marked ^** depends on that.

FLASH provides them: shell, read and write, grep and glob, screenshot, web_search, memory and more. Point any other Ollama client at Onyx 2 and it reasons, writes, and answers exactly the same. It just cannot reach your machine unless that client provides tools.

Images work the same way. The model reads any image it is handed, but the client is what hands it one, so attaching a screenshot needs a client that sends images.

About how it reads

Onyx 2's output has been run through an AI-text detector and scored very low. That is one measurement, not a property of the model.

Results move with the prompt, the detector, the version of each, and the subject being written about, and detectors are unreliable in both directions. Nothing here guarantees any particular score on any particular output, and no result is promised or warranted.

Prose that reads as human is a claim about writing quality, not a tool for passing AI-generated work off as your own. Where disclosure of AI assistance is required, by a school, an employer, a client, a publisher, or the law, that obligation is yours and nothing here changes it.

Why local actually matters here

Every capability on this list runs on silicon you own.

Your codebase never leaves the machine. Your stack traces never leave the machine. The screenshot of the thing you have not shipped yet never leaves the machine. There is no rate limit, no per-token meter running while you think, and no vendor deciding next quarter that your workflow is now a paid tier.

Other AI services have started watermarking what they generate. Onyx 2 does not, because it is not running on someone else's server.

It's yours.

flashproject.dev for the full rundown, or the repo if you would rather read the source first. It is open, it is local, and it finishes what you asked for.

If your current agent has ever told you it was done when it wasn't, I would genuinely like to hear about it in the comments. That failure mode is the whole reason this exists.

Meet FLASH CLI, a Free Local AI Agent for Your Terminal

Nathan C. — Tue, 28 Jul 2026 21:10:22 +0000

Cloud AI coding tools are powerful, but they also come with a bill, an API key, and a quiet upload of your source code to someone else's servers. What if your AI assistant ran entirely on your own machine instead?

That is FLASH CLI (Fast Local Agent SHell): an AI-powered command-line assistant that talks to local or self-hosted Ollama models and can actually run shell commands for you. No API key. No subscription. No cloud.

Why FLASH is different

100% local. It connects to an Ollama server, by default on localhost, so your code and prompts stay on your hardware.
No keys, no bill. Ollama needs no API key, so there is nothing to pay for and nothing to leak.
Truly agentic. FLASH does not just chat. It runs a real tool loop: it inspects your system, runs commands, searches the web, and shows its reasoning as it works.
Model freedom. Point it at llama3.1, qwen2.5, mistral, or any tool-capable Ollama model, and swap with one setting.
Local or remote. Set OLLAMA_HOST and the same client talks to a GPU box on your network or a server behind a reverse proxy.

The four main tools

FLASH gives the model a tight, powerful toolset:

shell: run any command, non-interactively, with a timeout.
web_search: pull live results from DuckDuckGo, built in.
get_os: detect the operating system so it picks the right command every time.
reason: surface a line of its thinking without ending the turn.

It loops through plan, act, and observe until the job is done, then answers in rendered Markdown with syntax highlighting.

Configuration

Optional configuration lives in ~/.flash.env:

MODEL=llama3.1
OLLAMA_HOST=http://localhost:11434

What it feels like

Ask a question and let it work:

[Flash]> what are the biggest files here?
Thinking: check the OS, then find the largest files
Retrieving operating system information
Executing shell command: du -ah . | sort -rh | head -3
…

Run a command yourself with the ! prefix, no AI in the loop:

[Flash]> !git status
On branch main
nothing to commit, working tree clean

Check or switch your backend on the fly:

[Flash]> /model
Model: llama3.1
Host:  http://localhost:11434

Handy built-in commands: /help, /model, /clear, and /bye.

Built to run everywhere

FLASH is tested on every push across Linux, macOS, and Windows on Python 3.10, 3.11, and 3.12, with Ruff, Flake8, and Bandit keeping it clean and secure.

Watch the tour

I made a short cinematic walkthrough of everything that you can watch above.

Try it and star it

If a private, local, zero-cost AI shell sounds like your kind of tool, give it a spin and drop a star.

Repo: https://github.com/Natuworkguy/Flash

Your AI. Your machine. Your rules.

Stop Rewriting UI Components for Every Project

Nathan C. — Mon, 15 Jun 2026 03:15:50 +0000

Ever started a new project and found yourself rebuilding the same modal, dropdown, toast notification, tabs, and switches for the 20th time?

I got tired of that.

So I built UltraHTML, a lightweight UI library that gives you modern components with simple HTML and JavaScript, no framework required.

Getting Started

Include the CSS and JS files:

<link rel="stylesheet" href="dist/ultra.css">
<script src="dist/ultra.js"></script>

Initialize UltraHTML:

Ultra.init();

Done.

Buttons

UltraHTML includes two button styles out of the box:

ultra-button — a clean, modern button.
ultra-button-wave — adds a wave/ripple-style interaction effect.

Basic button:

<button class="ultra-button">
  Simple Button
</button>

Wave button:

<button class="ultra-button ultra-button-wave">
  Wave Button
</button>

Buttons use UltraHTML's default green theme, but because they're standard HTML elements, you can easily customize them with CSS.

For example, here's a red button that displays a popup message:

<button
  onclick="Ultra.popupmsg('Hello from UltraHTML!')"
  class="ultra-button ultra-button-wave"
  style="background-color: red">
  Show Popup
</button>

You can create buttons that match your site's branding without learning a separate theming system:

<button class="ultra-button" style="background-color: #3b82f6;">
  Blue Button
</button>

<button class="ultra-button ultra-button-wave" style="background-color: #f59e0b;">
  Orange Button
</button>

<button class="ultra-button ultra-button-wave" style="background-color: #ef4444;">
  Red Button
</button>

UltraHTML handles the styling and interactions while still giving you full control over how your buttons look.

Modal Example

Need to display important information?

<script>
window.addEventListener("load", () => {
    Ultra.init();

    Ultra.modal({
        head: "Important",
        text: "You need to reset your password",
        buttonText: "Reset",
        buttonAction: (modal) => {
            console.log("Going to reset page...");
            modal.remove();
        }
    });
});
</script>

If buttonAction is omitted, the modal automatically closes when the button is clicked.

For simple informational dialogs, you only need:

<script>
Ultra.modal({
    head: "Welcome",
    text: "Thanks for visiting!",
    buttonText: "OK"
});
</script>

Add a buttonAction callback only when you need custom behavior, such as navigating to another page, submitting data, or running additional code before closing the modal.

Features:

Custom title
Custom text
Custom button labels
Automatic close behavior
Optional callback support
Clean styling out of the box

Popup Notifications

<button onclick="Ultra.popupmsg('Hello from UltraHTML!')">
  Show Popup
</button>

Instant toast-style messages with one line of code.

Dropdowns

<div class="ultra-dropdown">
  <button class="ultra-dropdown-btn">
    Choose Option
  </button>

  <div class="ultra-dropdown-content">
    <a href="#">Action One</a>
    <a href="#">Action Two</a>
    <a href="#">Action Three</a>
  </div>
</div>

Tabs

<div class="ultra-tab-container">
  <div class="ultra-tab tab-active">Active Tab</div>
  <div class="ultra-tab">Inactive Tab</div>
  <div class="ultra-tab tab-disabled">Disabled Tab</div>
</div>

Chips

<div class="ultra-chip">
  Clickable Chip
</div>

<div class="ultra-chip chip-permanent">
  Permanent Chip
</div>

Image chips:

<div class="ultra-chip">
  <img src="https://picsum.photos/43/43">
  Image Chip
</div>

Switches

<label class="ultra-switch">
  <input type="checkbox" class="ultra-switch-input">
  <span class="ultra-switch-slider"></span>
</label>

Custom Right-Click Menus

<div class="ultra-context-menu">
  <div class="item">📝 Edit</div>
  <div class="item">❌ Delete</div>
  <div class="item">🔗 Copy Link</div>
</div>

Initialize once:

Ultra.init();

and UltraHTML handles the rest.

Why I Built UltraHTML

Many UI libraries are powerful, but they're also huge, framework-dependent, or overkill for smaller projects.

UltraHTML focuses on:

Simplicity
Speed
Lightweight code
Modern styling
Framework independence

Sometimes you just want a modal without installing 50 packages.

What's Next?

I'm actively developing UltraHTML and adding new components.

GitHub: https://github.com/Natuworkguy/UltraHTML

I'd love feedback, feature requests, and contributions.

What component would you want to see added next?

DEV Community: Nathan C.

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

What actually changed

It reads the ask

It picks a stack instead of handing you a menu

Manim

Games

A higher finishing bar

It goes beyond code now

One good closing line

Sampling changes

Try it

Releasing Flash Onyx 2.2 soon!

I finally added Squirrel scripting to my Python game engine

Why Squirrel

The loader

The first function

What the benchmarks told me

Two gotchas

What's next

I A/B tested my own system prompt: 24 generations, one clear win, one rule that did nothing | Flash Onyx 2.2

It wrote the file, then pasted the file back

READING THE ASK

NAMING AND STACK

THE BAR

The two domain ones

What it cost

The sampler underneath all of this

Then I measured it

Flash Onyx 2.2: teaching a local model law and game feel

Law

Games

Then I cut both of them

Then I tuned the sampler

What's next

Your Python code is already assembly. I made it runnable.

Where this came from

The trick: it doesn't build bytecode

But what about jumps?

You don't have to write byte offsets

It round-trips

Errors point at your file

What it can't do (being honest)

The state of it

So... is this a good idea, or is it deeply stupid?

👉 ship: publish it, this is cool

👉 stupid: this is a solution in search of a problem

Flash Onyx 2.1, one day later: my model spent 400 tokens thinking and returned an empty string

The complaint

The real number

The part that made me put my head on the desk

Cutting 903 lines to 516

Then it got worse

The lesson I actually didn't know

Where it ended up

If you want it

Click a link on a website. My terminal AI opens with the prompt already loaded.

It can see your browser

When a tool isn't ready, it fixes the tool

It can see your screenshots

It remembers you after you close it

It types back at you

Three ways to drive it

You reconfigure it without ever restarting it

It runs where you want it to run

Autonomous mode, and the part nobody thinks about

It tells you when it's done

The brain behind it

Install it in under a minute

One last thing

Where to go next

ha.mr is the best link compressor

Your AI agent didn't finish. It just told you it did.

Onyx 1 answered you. Onyx 2 closes the loop.

1. It finishes

2. It does not make things up

3. It sounds like a person

4. It actually uses the tools it is given **

5. It takes images **

6. Better at code, and Python above all

👉 `ship`: publish it, this is cool

👉 `stupid`: this is a solution in search of a problem

4. It actually uses the tools it is given ^**

5. It takes images ^**

9. Front end that looks designed ^**