Studio OS: A Creative Execution Layer for Small Studios

Take an idea to a finished, published piece without opening a terminal, writing a prompt, or logging into a CMS by hand. That is what Studio OS does.

Small studios fight above their weight. You go up against firms with thirty people on staff while you run on a stack of AI tools that do not talk to each other. You copy work from one app to the next. You reformat everything by hand. You lose hours to plumbing instead of the work you are good at.

The tools on offer do not fit you. Enterprise platforms are built for big companies with their own operations teams. Single task tools each do one job well and leave you to glue them together. Neither one solves the real problem.

We call that problem context collapse. You finish the creative work, then you put on a different hat to get it out the door. That hat is technical and slow. Two moments hurt the most. Making images that match your brand. Shipping the finished piece to a live site. Both kill your momentum every single time.

Studio OS fixes this. It is an execution layer, not another place to track tasks. Agents own the things you actually deliver. Workflows follow real client work, not checklists. We build it at Square Mile Design and we run it every day, on our own studio and on What If? Magazine. This is the full story. What we set out to do, how we built it, what broke, and where it goes next.

Project objectives

We scoped the first version to prove one thing. You should be able to start with a piece of content and end with a live, published article, images and all, without opening a terminal, writing a prompt, or publishing by hand.

Everything in that first build served the same loop. Install the whole AI toolchain in one step, with no manual setup. Treat your brand as a core part of the system, set once and applied to every image after that. Make a finished hero image in under a minute on your own machine. Run the full loop, from install to published, in under thirty minutes. And never make you touch a terminal.

Five rules shaped every call we made. Run on your machine first, but stay ready to move to the cloud later with a simple switch. Keep the smarts in the cloud and the muscle on your machine. Make your brand a first class part of the product, not a setting. Give each agent a real deliverable to own. Keep you out of the terminal, always.

Three parts

Studio OS runs in three parts, each in its own place.

The web app is the brain. We built it in React and TypeScript, and Claude runs the logic. It lives in the cloud and holds the interface, the agent orchestration, and every decision.

The bridge is the hands. We wrote it in Go and it runs on your machine on a locked local port. It is dumb on purpose. It runs commands and reports what it sees, nothing more. Because it makes no decisions, we ship improvements from the cloud the moment they are ready, and you never have to update the thing you installed.

The engine does the heavy lifting. ComfyUI makes the images and Kohya trains the models, both on a local NVIDIA RTX A6000 with 48 GB of video memory.

Week one gave us the bridge. One file, the full local API, an embedded copy of the web app, automatic start on login, and downloads that resume and verify themselves. That put a working node on the real hardware. The web app came next, built as three modes. Setup, Workspaces, and Settings. A real Claude agent runs the setup. It scans your machine, writes an install plan, and runs it while you watch the progress. A simulate mode lets you walk the whole flow with no GPU at all.

The Brand Studio was meant to be the edge. You drag in a set of reference images. The system captions them, reads your hardware, and builds a training config. One click trains a brand model through the bridge. After that, every image the workspace makes carries your look, with no prompt engineering on a single piece. A team of three puts out work that looks like a team of twenty made it.

Challenges faced

The build had real problems, and the biggest ones changed the product.

The first was the models themselves. We picked FLUX schnell for its open commercial license. Then its host put it behind a login, and our downloads started failing. We added a token login that keeps your credentials on your machine. The token goes into the download after planning and never reaches the language model. Soon after, a bug in the downloader saved broken files. One came down cut short. One had a corrupt header. So we made every download check its size and its hash, and refuse to resume onto a file that does not match.

The second problem was the one that hurt. FLUX schnell is a fast, stripped down model, and it could not carry a strong style. Push the style hard enough to see your look, and the image fell apart into noise. Pull it back to stay stable, and the look vanished. We proved that across two full training runs and several fixes before we called it dead. So we switched to a model called Chroma. It follows prompts properly. It keeps the same open license. And it lets us store your brand as a locked block of style text instead of a trained model. That did more than fix a bug. It changed the core idea of the product. Your brand went from a trained file to a prompt friendly model paired with a fixed style spec. A trained model became a nice option, not a must.

The third problem showed up only in real use. We pointed the engine at What If? Magazine and restyled its back catalog of forty four articles into one warm amber look, on a job that ran every night on its own. That is where a local setup spread across two machines showed its cracks. A wifi reset moved the GPU machine to a new address. The render service was not running. When it did run, it only listened to itself. The firewall blocked the port. The nightly job looked dead, and fixing it took a live round of commands across both machines. On top of that, our build sandbox could not run the GPU binaries or reach the package registry, so we split the build. Type check on one machine, bundle on the other.

Future improvements

Every problem pointed straight at the next job.

The mess across two machines led to two dashboards, one on the GPU side and one on yours. They turn that whole recovery into a simple status light and a few buttons, with every failure from that night built in. We are baking in the real fixes too. Start the render service open to the network by default. Reach the GPU machine by name instead of a fixed address. Reserve that address at the router so it stops moving.

We are also taking the platform from one project to many. What If? Magazine runs on it today. Square Mile Design and other projects come next. Publishing is moving from one shared CMS to a deploy stack for each workspace.

The longer plan holds three phases. First, a team layer with shared agents, separate client workspaces, an optional cloud GPU, and a visual way to build workflows. Then a full platform with an agent marketplace, a layer that learns your voice and style over time, an API for other tools, and a tier for larger agencies. Closer in, we are adding an install recovery loop that hands errors back to the model for a plain answer, and code signing so your machine stops warning you about an unsigned file.

What held

Studio OS is not a pitch deck. It is a working system we use every day, and we are turning it into a product for the millions of small studios that hit the same wall you do.

The build taught us one thing above the rest. Our big idea, brand as an automatic part of the system, had to bend to how the models actually behave. It moved from a trained file to a base model plus a style block, and the promise still held.

What survived every change is the part that matters. A small team can now ship work that looks like it came from a much bigger one, and do it without ever leaving the creative work to go be a technician.

Luke Paxton. Square Mile Design, August 2026.