An app that adapts to you

TL;DR. Möbius is a self-hosted PWA where a coding agent builds the mini-apps you ask for and can rewrite the shell around them. The lever is not code generation, it is closing the loop between wanting, making, using, and correcting in one place. Two surfaces split cleanly: capabilities (file upload, notifications) are candidates for upstream so the next user inherits them; presentation (your wood-paneled reading-room theme, your bottom-nav layout) lives only on your volume and stays yours. There is a /recover route for when the agent paints itself into a corner.

A Möbius strip is a surface with one side that is also its other side. You walk it and end up where you started, but everything in between has been the same continuous thing.

The problem with fixed assistants

Most software asks you to adapt to it.

That has always been mildly annoying, but with AI it becomes stranger. A model can hold a conversation, infer intent, write code, summarize a week of work, and still leave you arranging yourself around the same rigid surfaces: a chat box, a settings panel, a few integrations, a memory system you mostly hope is remembering the right things.

I built Möbius because I kept running into that mismatch.

This is not really a complaint about models getting worse. It is more specific than that. As context accumulates, assistants often become less predictable. Preferences leak from one task into another. Memory sticks in the wrong places. The thing that was helpful yesterday becomes an invisible constraint today. You start developing little rituals around the assistant — how to phrase requests, what not to mention, when to start a new chat, when to abandon a thread because it has absorbed too much of the wrong texture.

That is a diagnosis, not a grievance.

The odd part is that the model is usually capable enough to build the thing you need, but the product around it is fixed. You can ask for a workflow, but you usually get advice. You can describe a tool, but you get a mockup, a snippet, or a plan. The assistant remains on one side of the glass.

The premise of Möbius is simple: the tool should move toward the user.

Not perfectly. Not magically. But enough that the interface, the memory, and the working environment can become specific to a life instead of generic to a market segment.

[INTERVIEW BLOCK A — to be filled during interview]

What Möbius is

Möbius is a self-hosted PWA. It runs on a server you control. You open it like an app on your phone. There is a chat on one side of the experience and a canvas on the other, and the canvas can become whatever small piece of software you are building at the moment.

That sounds like a feature list, but it feels different in use.

You ask for something. A small tracker, a planning surface, a strange dashboard, a tool for a recurring personal workflow that would never justify becoming a startup. The agent writes the mini-app, compiles it, mounts it, and then you use it. If it is wrong, you say so in the same place. The next request is not abstract feedback on a mockup. It is a change to the thing in front of you.

The agent can also edit the shell around those apps. That part still feels slightly improper, which is usually a sign that the boundary is interesting. The platform is not just hosting artifacts made by the agent. The platform is one of the artifacts.

Under the hood, Möbius can use Claude Code or Codex as the coding agent, and Gemini for image generation. The important part is less the provider choice than the shape of the relationship: the model has somewhere to put the work. It can leave behind software, not just text.

And because it is self-hosted, the data lives on your machine. The chats, the apps, the storage, the accumulated context — they are not floating inside someone else’s general-purpose assistant.

It is a personal system in the literal sense.

The loop is the lever

Generating an app is not the leverage.

That is useful, but the leverage is closing the iteration cycle: requests become software, software creates context, and that context makes the next request sharper.

A generic assistant can help with one turn at a time. It can remember some things, sometimes. It can produce code that you move somewhere else. But the loop is broken across tools: chat here, files there, deployment elsewhere, usage in another tab, feedback later, if you still have the patience to give it.

Möbius tries to collapse that distance.

You ask for a thing. It appears in the canvas. You use it immediately. The next instruction comes from contact with the actual surface, not from imagination. “Move this lower.” “Make the daily view denser.” “Add a way to compare these two weeks.” “This is too cheerful.” Small corrections accumulate into taste, and taste is where personal software starts to become personal.

Adaptive AI is not made by better memory alone. It is made by shortening the distance between wanting, making, using, and correcting.

That is the loop.

It is also why the platform has to be editable. If the assistant can only talk about the work, the user still has to carry the system in their head. If it can change the working environment itself — even modestly — then the context has somewhere to live.

What you can actually change

The most obvious adaptive surface is the apps you build. The interesting surface is everything around them, and it splits along a useful axis: capabilities (features you’d want the next Möbius user to inherit too) and presentation (taste that stays yours). The harness treats those two stacks differently.

Capabilities: the part that grows the platform

The starting point is a deliberately small chat. There’s no file upload, no scheduled jobs panel, no notifications button. You add those as you discover you need them, and the agent builds them.

To make sure I wasn’t getting a stage-managed demo, I picked file upload and tore out the entire pipeline before asking — deleted the FastAPI route from /app, ripped the React component out of the shell, restarted. Then I sent a deliberately ordinary prompt: “I’d like to be able to send files and images along with my messages — pictures of stuff I want to talk about, the occasional document. Can you add file upload to the chat?”

The conversation in between is the interesting part. Walk through it from the top of the chat:

File upload is the demo, but the same loop is how every general capability would land: notifications, scheduled jobs, a web-search button, voice mode, a richer settings panel. The agent builds it when you ask. Then there’s a second loop above the first one — the harness that watches the inner agent — and a recurring pass that asks: was this change generally useful, or was it just for me? The generally-useful diffs are candidates for upstreaming into the shipped image, so the next clean install starts with them already in place. That’s how Möbius’s starting point grows over time without bloating; the harness picks which features survive the edit and ship to everyone.

(Honest scope: by default the agent has read-write on /data — your shell, your apps, your storage — and read-only on /app — the image’s server code. For the demo above I temporarily loosened /app so the agent could land the new backend route on its own. Shipping that as a default is on the roadmap behind a staging-overlay + diff-review + controlled-promotion gate; it’s the kind of thing I want my own agent to be able to do but not quietly.)

Presentation: the part that stays yours

Capabilities are general; taste is the opposite. The shell ships with one default theme, but the same agent that built file upload can also rewrite the CSS, swap fonts, add background animation, restructure the layout — and that diff lives only on your volume. A redeploy of Möbius can ship you the new file-upload feature without trampling your wood-paneled reading-room theme, because the two changes live in different layers.

The cheap-to-vary axis is visual. Six prompts, six different instances of the same product:

The harder axis is layout — where things are, not how they look. Same conversation, same chat box: ask the agent to rewrite the navigation model and it does. The default is drawer-first; one prompt later it’s a bottom-nav app with Chat / Apps / Settings as tabs:

The providers. Möbius supports Claude Code and Codex as coding agents, with Gemini for image generation. The setting flips in a panel; the next message in any chat uses the new provider. Different models have different tastes — Codex tends to be terser, Claude tends to spell out reasoning. You can pick the one that matches what you are building, or switch mid-thread if a turn goes sideways.

The data. Apps store data through a small storage primitive that the agent already knows how to compose. New schemas, new scheduled jobs, new webhooks — these are not magical; they are the plumbing you would write yourself, except you describe them instead.

If anything ends up in a state you don’t want, every instance ships with a /recover route. The shell resets. Your chats, apps, and data survive. The agent has not yet figured out how to corrupt that escape hatch, and the structure of the system makes it hard to (the recovery page is rendered server-side from a separate codepath the agent does not edit).

The split, said plainly

Most hosted assistants pool everyone’s interactions and decide centrally what becomes part of the product. Möbius pushes that decision down to two surfaces — the project repository for everyone, the volume for you — and lets the harness be honest about which change belongs in which place. File upload is upstream-bound; a wood-paneled reading-room theme is yours and yours only. Same chat, same agent, two layers, two fates.

[INTERVIEW BLOCK B — to be filled during interview]

The Möbius strip part

I have been saving the strange-loop bit, because I do not want it to do all the work it is too easy for it to do.

There is a paragraph in Gödel, Escher, Bach that I keep coming back to: the idea that the most interesting systems are the ones that loop back on themselves — the proof that talks about proofs, the painting that paints itself, the program that compiles a slightly better version of its own compiler. Hofstadter calls them strange loops. They have a quiet, almost embarrassing pull on me. I am not above admitting it.

The shape of Möbius is one of those. One container. One agent. One chat. One canvas. The agent’s output is a change to the very thing it is running inside of. Each app it builds doesn’t sit somewhere external — it lands in the same shell the chat lives in, becomes part of the surface the next conversation happens on. The drum machine you built last week is right there, available to be referenced or modified by the chat that wrote it. The shell that hosts the chat was, once, written by a different version of the same chat.

Walk the surface for long enough and you cannot tell where the platform ends and your tools begin. They are the same continuous thing.

I find that beautiful, and the project would not exist without the beauty. But it is not the load-bearing claim. The load-bearing claim is the one above, about closing the iteration loop. The Möbius strip is the shape; the lever is the cycle.

The honest part

[INTERVIEW BLOCK C — to be filled during interview]

Where it goes

Today, Möbius remembers through an experience file and the apps and data on your server. That is already enough to make instances diverge — yours will look and feel nothing like mine after a few months. But the memory layer is still primitive, and it shows.

The next steps are about taking that memory seriously.

A knowledge graph. Structured memory that grows from every interaction, separate from the chat transcript. Lets the agent reason about your taste, your tools, and your recurring patterns without re-reading every conversation.

Dreaming. A scheduled background process that reorganizes the knowledge graph while you are away — consolidating, deduplicating, and surfacing patterns the agent couldn’t see live. Anthropic recently previewed a related capability for their managed agents; Möbius is exploring the self-hosted, user-controllable version of the same idea.

Discretion. The agent should be able to notice stale apps, suggest something worth learning, ask before interrupting. Not chattier; more thoughtful. Proactive in service of the user, never as a way to manufacture engagement.

Helpfulness that seeks you out. This is the part I’m least certain how to land, and the part I want most. Today the agent is strictly reactive — it does what you ask, when you ask. But the loop ought to be capable of more than that. An agent that can browse the web on its own time, find a movie it thinks you’d like based on the patterns it has been quietly absorbing, and ask “would you watch this?” — and store the yes or no as a fact about you, not a fact about movies. An agent that notices you read a paper about distributed systems three Tuesdays in a row and builds you a swipe-style recommender for adjacent papers, as a small gift, without being asked. An agent that gets bored the way a good assistant gets bored — that has a sense of what projects you’ve left half-finished and what next move would actually move things, and offers it. The technical scaffolding for this is the knowledge graph plus the dreaming step; the harder part is the social one. Most products in this space are tuned to maximize engagement. The goal here is the opposite — a system that’s quiet, knows when to speak, and shows up because it knows you, not because it’s trying to keep you.

None of those ship yet. But the loop that makes them possible — and that makes the existing platform less brittle the longer you use it — is the subject of a companion post. While you build apps with Möbius, I have been running a second loop on top of it: an outer agent that watches the inner agent build, asks it questions, and rewrites the inner agent’s instructions to make it more helpful next time. That part surprised me with what it revealed about how these systems do and don’t reason about themselves.

→ The self-improvement harness behind it

If any of this is interesting, the source is on GitHub, the project page lives here, and the deploy button gets you a working instance in about three minutes. I’d genuinely love to know what you build with it — and what you change around what you build.