Running on a local model

FoundersOS is not a Claude product. It’s a standard MCP server, so it works with any spec-compliant client and any model behind it - including an open model running on your own laptop. The richer the client, the prettier the output; on a plainer setup it degrades gracefully to markdown tables and numbered lists. Nothing breaks. This page covers what actually changes when you run it that way.

Why it stays usable

Every render-bearing tool follows a four-tier rendering contract that lives in the server: the client uses the most visual output it can produce (a widget), and falls back cleanly to inline HTML, then a markdown table, then prose. A local or plainer client simply lands lower on that ladder - you get clean tables and numbered lists instead of widgets, from the very same tools. No plugin, no special build.

What you keep on a local model

Running an open model locally, you keep essentially all of FoundersOS:

• All 92 tools. CRM, tasks, projects, playbooks, finances, memory, feeds - the full surface. Nothing is gated behind a particular model.
• Markdown-table rendering. Dashboards, pipelines, P&L, stuck lists - they come back as clean tables (tier 3) instead of widgets.
• Numbered-option prompts. Where a rich client shows a native multiple-choice picker, a local model presents the same choices as a numbered list you answer by typing a number.
• Your data, fully local. Pointed at the same database, a local model reads and writes the same books and pipeline - now without anything leaving your machine.

What you trade

The trade is purely presentational:

• Interactive widgets and artifacts become markdown tables.
• The native multiple-choice picker becomes a numbered list.
• Some models narrate more loosely than a frontier model would.

You lose polish, not capability. The workflows are identical; they just look plainer.

A worked example

We run FoundersOS against Qwen3.6-35B-A3B (qwen/qwen3.6-35b-a3b), a mixture-of-experts model with 35B total parameters and roughly 3B active, served locally and pointed at the same Supabase project. “Catch me up” returns the session dashboard as a markdown table instead of a widget; a playbook preflight asks its questions as a numbered list. Everything works.

Use whatever local runtime you prefer to serve the model - the contract doesn’t care which one, and neither does FoundersOS.

Why this matters

Building on the open Model Context Protocol instead of a proprietary API means no lock-in: use FoundersOS with Claude today, a local model tomorrow, something else next year, and your tools come with you. For sensitive books or offline work, a local model keeps everything on hardware you own. That’s the same “your data, your rules” promise the rest of FoundersOS makes - extended all the way down to the model.

A note on rough edges

Plainer rendering occasionally surfaces small gaps worth knowing about. For example, a local model listing feed items may print article titles as plain text rather than as clickable markdown links - even though, asked directly, the same model produces a proper link without trouble.

When you hit something like this, the lever in your hands is an instruction: a nudge such as “list feed items as markdown links to the article” usually does it. The deeper fix lives in the tool itself - handing the model a ready-made link instead of asking it to assemble one - so these are also worth reporting, since they’re signals to tighten the tool output rather than limits of the model. Either way it’s cosmetic: the data and the workflow are unaffected.

If output as a whole comes back plainer than you’d like, you can also reinforce the rendering contract in your client’s own instructions - see the advanced note in Visualizations and rendering.