When we reached version 1.0 last week, FractalOS could boot as a physical appliance on a Raspberry Pi and toggle GPIO pins directly from our Python kernel. But a computer sitting alone in a room is only half the story. Over the past week, we turned FractalOS into a collaborative, decentralized operating system that talks across devices, orchestrates AI agent swarms, and provides a desktop-grade workstation experience with a full community package manager.

Connecting the Dots: The Peer-to-Peer Mesh

Modern operating systems rely heavily on central servers and cloud accounts. FractalOS takes the opposite road: machines discover each other locally over WebRTC and browser broadcast channels without intermediaries.

You can now attach to a friend's live terminal session across the LAN with attach, send broadcast messages to everyone on the network with wall, copy files peer-to-peer with mesh-cp, or play interactive turn-based multiplayer terminal games. There is no server to configure and nothing to sync to the cloud. You open the terminal, and you are part of the mesh.

Agent Swarms and Physical Autopilot

Samwise, our built-in terminal language model agent, has grown up. In earlier versions, Samwise was confined to answering questions or executing validated plans on a single file system. Now, Samwise can act across the mesh.

If one machine is reading sensor pins on a Raspberry Pi and another has a faster model or free compute, Samwise on the first node can delegate tasks to a peer node's agent, await the synthesized answer, and react in the physical world. To make sure an autonomous agent doesn't run wild on your hardware, we built a strict voltage budgeting system: remote actions, hardware toggles, and destructive operations have defined safety costs and require explicit operator confirmation before they execute.

A Workstation You Can Actually Use

A real operating system needs more than a single scrolling prompt. We added a built-in terminal multiplexer that lets you split panes horizontally and vertically (split-h and split-v), complete with keyboard shortcuts to hop between active shells.

Our graphical and TUI applications—the text editor, the paint tool, the process monitor, and the adventure game—no longer force a modal overlay. They now live in draggable, resizable floating windows that dock cleanly beside your shell sessions. Along the top, a persistent status bar displays active background jobs, mesh peer count, system notifications, and audio state. You can drag and drop files from your host operating system directly into the terminal window to import them into the virtual file system, or use pbcopy and pbpaste to share text seamlessly with your system clipboard.

A Thriving, Sandboxed Package Ecosystem

To ensure FractalOS can grow far beyond what we write ourselves, we built a complete package management toolchain (pkg). Developers can scaffold a starter template with pkg init, validate functions and metadata with pkg validate, package everything into verified archives with pkg pack, and publish them locally or broadcast them over the mesh network with pkg publish --mesh.

The package manager resolves nested dependencies recursively, prevents circular installation loops, and loads necessary Pyodide WebAssembly wheels directly into the runtime without requiring a system reboot. To celebrate, we added a standard library of community classics—fortune, cowsay, cal, and banner—that work seamlessly with shell pipes like fortune | cowsay.

Because running community code in a browser requires vigilance, every package is cryptographically verified with SHA256 checksums at install time and before execution. If someone alters a package file on disk, the kernel refuses to run it. Packages declare their required permission scopes (like network, root, or hardware access), and anything requesting elevated capabilities requires explicit operator trust (--trust). A built-in security audit tool (pkg audit) inspects package source code using static syntax analysis before you ever run it.

Packaging the Official Release

With all Phase 7 milestones complete and every test suite passing across both browser and desktop modes, FractalOS is ready for its first official release. Whether you open it in a tab or flash it onto a dedicated device, it offers a glimpse of a different computing paradigm: personal, playful, resilient, and built from first principles.

Today we reached version 1.0! The project started as a weird experiment—a full UNIX-like terminal and Python environment entirely isolated in the browser via WebAssembly. But today, we broke out of that sandbox and brought it into the physical world.

We implemented the Fractal Pi Appliance architecture. By using Neutralinojs in portable mode on top of a bare-metal Linux environment (like a Raspberry Pi running an Openbox kiosk), FractalOS can now act as the primary interface for physical hardware. We wrote a universal build script that auto-detects architecture (x86_64 or ARM), sets up the display server, and drops you straight into the FractalOS full-screen terminal on boot.

Because the kernel runs in a browser sandbox, it couldn't naturally talk to physical hardware. So, we built an asynchronous bridge that allows the Pyodide environment to synchronously call out to the host system. This means you can now natively toggle Raspberry Pi GPIO pins directly from the FractalOS terminal by simply typing gpio write 18 1!

Finally, we made peer discovery entirely automatic. During the first-boot onboarding screen, you can check a box to tell the OS to spawn its own WebSockets signaling server silently in the background, instantly turning that node into the mesh network hub for all other devices on the LAN. And to cap it off, we launched a community package registry, proving our dynamic VFS package manager by writing an interactive, turn-based ASCII Tetris game.

Four days ago FractalOS was a pile of ideas that had never been run end to end. Today every automated test passes, a local language model can drive the whole system through ten graded tasks, and the list of known holes is short enough to read in one sitting.

This entry covers the last round of work and where things stand.

Learning from the Last Mistake

Yesterday's testing showed that the smaller model, llama3.1:8b, had a habit worth breaking. Asked to delete a folder, it would step inside it and delete everything there, leaving an empty folder behind. The plan was perfectly legal, so none of the safety checks objected. It just didn't do what was asked.

Samwise's instructions now say plainly: delete a directory by its name, never by stepping into it and deleting *, and always use full paths.

Samwise also has a short-term memory for failure. When a step goes wrong, the error is kept, and the next time the model is asked for a plan it is told, in effect, "this is what went wrong last time; don't do it again." A successful run clears the note. Internally we call this scar tissue.

Every AI Command Gets Tested

Samwise isn't the only part of FractalOS that talks to a model. remix, storyboard and the Chidi document reader do too, and until now nobody had ever run them against a real one.

The agent test run now includes all three. The latest run against llama3.1:8b passed all ten tasks. That model varies from run to run, so one clean sweep is encouraging rather than conclusive; more runs will tell.

Choosing Your Own Model

Until now the AI provider and model lived in a config file most people would never find. The first-run setup now has an AI step: pick Ollama (local) or Gemini (cloud), and optionally a model name. Samwise Chat and Chidi gained a model picker that lists the models your Ollama install actually has.

The Gemini model is no longer hard-coded either, though it is still the one path nobody has tested: we have never run FractalOS with a Gemini key.

Sweeping Up

• A new structural test checks that every one of the 124 commands has both a run function and a manual page. It immediately caught true, which had no manual page.
• About 120 lines of old kernel functions, exposed to the browser but called by nothing, are gone. Everything now crosses between JavaScript and Python through two doors, which makes the boundary much easier to reason about.
• The stock Neutralino template folder moved out of the project root and into neutralino/, where it belongs.

Where the Project Stands

Every automated suite is green:

• Structure checks: pass
• Browser smoke test: 75 of 75
• The in-OS diagnostic script: 40 passed, 0 failed
• Agent unit tests: 24 pass; grader self-test: 22 cases pass
• Real-model agent run (llama3.1:8b): 10 of 10

What has not been checked is just as important:

• Anything involving a Gemini key
• The graphical apps by hand: the editor, paint, the adventure engine, top, BASIC and Chidi
• Sounds, themes, and the portable desktop build
• Firefox and Safari

Next: Hands on the Apps

The agent has had most of the attention this week. Next it's time to sit down with the apps themselves, one at a time, finish the model-selection work, and get a Gemini key through the full test run.

Two bigger questions are still open: what "long-term memory" should mean for Samwise, and whether the agent should eventually be allowed any command a user can run, with the voltage brake as its only limit.

When you give a language model a shell, the interesting bugs are not the ones where something crashes. They are the ones where something works that shouldn't. Today was mostly about those.

A Chat Window That Could Run Commands

Samwise Chat is the conversational side of Samwise: you type, the model answers. Under the hood, the chat app pasted your message into a shell command line and ran it.

That meant a message containing $(touch hello) didn't reach the model at all. The shell ran it first and created the file. $HOME was replaced by your home directory, and quotation marks disappeared.

Messages now travel to the kernel as a sealed package of data, never as part of a command line. What you type is exactly what the model reads. This is now a rule for every app: user text never goes on the command line.

A Rehearsal That Wasn't

samwise --dry-run is supposed to show what Samwise would do without doing it. In practice agent mode ran the plan anyway, and autopilot ignored the flag entirely.

Planning and doing are now two separate steps inside Samwise. A dry run stops after planning and reports the plan, which steps would ask permission first, the plan's voltage, and whether the safety brake would engage. It runs nothing, even when combined with --force.

Waiting Forever

If the model server stalled, Samwise stalled with it, forever. The timeout in the code had never done anything: the function it was passed to quietly ignores that setting.

Model calls now give up after two minutes by default, adjustable in /etc/ai.conf. The error messages also got a lot more useful. Instead of a generic failure, you now see things like "can't reach Ollama at localhost:11434", or a reminder to run ollama pull for a model you don't have.

A Second Chance for a Bad Plan

FractalOS checks every plan before running any of it. Until today, a rejected plan was simply the end of the conversation. Now the model is told why its plan was rejected and gets up to two more tries.

The safety brake is the exception. A plan that is stopped for being too destructive is not retried. Asking again until the model finds a way around the brake would defeat the purpose of having one.

Small Things That Matter

• sudo with a password had stopped working after a rename. The in-OS diagnostic script caught it the first time it ran.
• The prompt had read ~\$ instead of ~$ since the very first commit, and never showed # for root.
• The gemini command is now samwise everywhere. "Gemini" now only means Google's model provider. The chat app, which the rename had broken completely, works again.
• The terminal speaks colour. llama3.1:8b kept trying tree -C in its plans. FractalOS's tree had no -C, so we added it: directories, links and executables are now coloured, and the terminal renders standard ANSI colour codes for any command that wants them.

How Each Fix Was Proven

Every fix today came with a test, and every test was checked the hard way: put the bug back and confirm the test fails. A test that passes either way proves nothing.

Running the agent tests over and over also showed something worth knowing. The larger model, gemma4:12b, passed all seven tasks every time. llama3.1:8b scored between five and seven. Its misses were bad plans of its own, not faults in the OS, and that set up tomorrow's work.

FractalOS was always meant to be an operating system with a language model at the centre. Today, for the first time, a real model actually drove it.

The Agent That Never Acted

The AI command (then called gemini, now samwise) has two modes. Autopilot plans and runs commands on its own, watched by a safety brake. Agent mode plans, asks permission for risky steps, runs the plan, then summarises what it found.

While giving the agent access to the new python command, I found that agent mode had never run a single plan. The code that reads a numbered plan out of the model's reply was broken by 58 doubled backslashes, a copy-and-paste accident, so no plan line ever matched. The model's plan was simply handed back as the answer. The same accident had put literal \n characters into every prompt sent to Ollama.

A Test Track for the Agent

To stop guessing, I built a test track: seven tasks such as "create a file", "move this into a folder" and "delete this directory". Each run is graded by looking at what actually changed in the file system, not by what the model says it did. Every prompt, reply and timing is saved to a transcript.

A stand-in model server answers with canned plans, so the plumbing can be tested without a real model. That alone found two bugs:

• The agent always thought it was in /. The step that looks around before planning reset the current directory to the root. Every plan the OS ever built said "Current Directory: /".
• Agent mode crashed instead of asking permission. The confirmation dialog for risky commands had never once appeared.

Meeting Real Models

Then came the real thing, with two local models through Ollama.

gemma4:12b "thinks" before answering by default, and it spent its entire output budget thinking: 3,296 tokens, 74 seconds, and an empty reply. With thinking switched off, the same request produced a clean two-line plan in one second.

llama3.1:8b was quick and obedient in autopilot, but chatty in agent mode. The OS tried to run its explanations as commands.

Neither model was the real problem, though. The real problem was what they revealed:

• The safety brake scored the words in a plan, not the operations. Rearranging the flags of an rm command changed its danger score from 60 to 10.
• Autopilot ran a plan line by line and carried on after a failed step.
• forge, the file-writing tool built for the AI, mangled Python code that contained its own escaped strings.
• The planner was told about commands it wasn't allowed to use.

Rebuilding the Brakes

Each of those is now fixed:

1. Plans are checked in full before the first step runs
2. Execution stops at the first failed step
3. The brake prices the operation itself, whatever its spelling
4. Before autopilot writes anything, it saves a real, verified checkpoint of your home directory
5. Agent mode picks up the plan where it left off after you say "yes"
6. The planner sees exactly the tools it may use

By the end of the day both models passed all seven tasks, and the AI command had its new name: samwise.

FractalOS sat quietly for most of the year. Coming back to it, the first job was not new features. It was making the project something a person (or an AI coding agent) could pick up, understand, and trust.

415 Megabytes of Python We Didn't Use

FractalOS runs a real Python interpreter inside the browser, using Pyodide. The project carried a full copy of it: 413 files, 415 MB, and hundreds of packages the OS never loads.

It now carries 9 files and 16 MB: the interpreter itself plus the one package the kernel needs, the cryptography library used for passwords. It is also newer, moving from Python 3.13 to Python 3.14.

The old copies still lived on in the git history, so a fresh clone downloaded 335 MB. With some careful history surgery, a clone is now about 9 MB.

Writing Things Down

The project now has a small set of working documents:

• A roadmap, with a permanent ID for every item
• A decision record, explaining why things are the way they are
• A testing guide, including every trap already fallen into
• A handoff note, rewritten at the end of every session, so the next session (mine or an agent's) starts from the truth

This diary is the newest member of that family.

Tests That Run Themselves

FractalOS already had a 1,400-line diagnostic script that exercises its commands from inside the OS. The catch was that someone had to open the OS, log in and run it by hand.

A headless browser now does all of that: it boots FractalOS, completes the first-run setup, logs in as root, runs the script, and grades every line. First result: 40 passed, 0 failed, and nothing in the kernel needed changing for Python 3.14.

A quick smoke test and a structure check joined it. The structure check catches the most common mistake in this codebase: adding a file and forgetting to register it. The list of kernel files is now generated, not typed by hand.

Python Inside the OS

The README had promised Python inside FractalOS for a while. Now it's real. python script.py, python -c "...", or piping code in all work, running in the same interpreter as the kernel.

open() reads and writes the FractalOS file system and respects its permissions. A step budget stops a runaway loop before it can freeze the page.

Building it turned up an old bug. When JavaScript passed "nothing" to Python, Python didn't see nothing: it saw a special stand-in object. Commands that asked "was I given any input?" got the wrong answer, and wc with no input crashed. It is now converted once, at the front door, for every command.

FractalOS is an operating system that runs in a web browser, built around a simple idea: instead of memorising commands, you talk to the system, and a language model helps it act on your behalf.

Two Halves, One Contract

The heart of FractalOS is a Python kernel running inside the browser. It owns everything that matters: the file system, users and permissions, processes, and roughly 120 commands.

The JavaScript side is the stage manager. It draws the terminal and the windows, plays sounds, and handles the browser.

The two meet through what I call the effect contract. When the kernel wants something only the browser can do, like playing a chord or opening an editor, it doesn't reach into the page. It returns a short description of the effect it wants, and the front end carries it out. This keeps the logic testable and the display replaceable.

The First Apps

The first public version, in November, arrived with a text editor, a paint program, a process viewer, a text adventure engine, a BASIC interpreter, and Chidi, a reader that can answer questions about your documents. It can also run as a desktop app through Neutralinojs, saving to real files instead of browser storage.

BoneAmanita Takes the Wheel

The big addition over the holidays was an autopilot. You describe what you want, and the model plans and runs the commands itself.

Letting a model loose on a file system needs a conscience, so every plan is given a "voltage": a risk score. Listing files is low voltage; deleting them is high. Past a threshold, autopilot refuses to continue unless you force it.

forge, the file-writing command, was reworked for the model's use, so it can write whole files cleanly instead of wrestling code through echo and redirection.

What Comes Next

It runs. The autopilot plans, the kernel executes, and the terminal shows the result. Whether all of it works as intended, and whether the brakes hold when a real model is driving, is a question for proper tests.