Good morning everyone. I want to talk about something I've been building and running for the past several months — a developer workstation that puts AI at the center of the daily coding workflow. Not as a chatbot in a sidebar. As infrastructure.
I'll walk you through what the stack is, what it's actually good at, and — because I believe in honesty — where it falls short and what annoys me.
The stack has three layers.
Layer one: the brain. OpenCode is a terminal-based AI coding assistant. Think of it like Cursor or GitHub Copilot Chat, but running entirely in your terminal. It connects to GitHub Copilot, which means it can talk to Claude, GPT, Gemini — whatever model you need.
Layer two: orchestration. A plugin called Oh-My-OpenAgent sits on top of OpenCode. It lets you assign different models to different tasks. Cheap models for quick codebase searches. Expensive reasoning models for architecture decisions. The idea is simple — not every question deserves the same brain. A grep through your codebase doesn't need GPT-5.4. A hairy debugging session does.
On top of that sits Superpowers — a skill framework that codifies development workflows. TDD, systematic debugging, planning, code review. These aren't vague guidelines. They're executable protocols. The AI doesn't just write code — it follows a discipline.
Layer three: memory and tools. This is where it gets interesting.
Signet AI gives the agent persistent memory. When I solve a tricky bug on Monday, the AI remembers the root cause on Thursday. When I tell it "we always use conventional commits with emoji prefixes" — it doesn't ask me again. It stores that as a pinned constraint and follows it in every session, across every project.
The memory system uses SQLite with FTS5 full-text search and vector embeddings via Ollama running locally. Nothing leaves your machine for embeddings. The extraction pipeline can run through your Copilot subscription or fully locally with a small LLM. Your choice.
Then there are four MCP servers — think of them as tool extensions the AI can call directly:
- Fermat for math — plotting, NumPy, SymPy, equation solving.
- UML-MCP for diagrams — class diagrams, sequence diagrams, flowcharts, thirty-plus types.
- DBHub for database access — the AI can inspect your MySQL schema and run read-only queries.
- API Testing MCP — HTTP requests, assertion chains, OpenAPI import, even load testing.
The AI doesn't describe what a query would return. It runs the query. It doesn't suggest you should test an endpoint. It tests it.
First: multi-model routing is genuinely smart economics. My exploration agent — the one that greps through codebases — runs on Claude Haiku. It's fast and cheap. My architecture oracle runs on GPT-5.4 at the highest reasoning tier. I'm not paying for a Ferrari to drive to the mailbox, and I'm not taking a bicycle onto the highway. This model-per-role approach means I use expensive tokens where they matter and cheap tokens everywhere else.
Second: memory changes the game. If you've used AI coding assistants, you know the frustration. You explain your project structure. You explain your conventions. You explain why you made that architectural decision three weeks ago. Every single session, from scratch. Signet eliminates that. Decisions, constraints, procedures — they persist. The AI starts each session by reading what it knows. It picks up where it left off. This alone saves me probably thirty minutes a day.
And there's a hard economic argument here too. The savings from not re-explaining context and not re-exploring the codebase every session dwarf the cost of the memory injection. On a project like ours — where we enforce twenty-plus rules, specific test commands, architectural constraints — persistent memory probably saves thirty to fifty percent of input tokens per session compared to starting cold every time. The biggest lever you control is pruning: keep your memory tight and relevant. A bloated memory store full of stale facts costs tokens for zero benefit.
But memory alone isn't enough. Raw storage without discipline becomes a junk drawer. That's where signet-first comes in — a protocol, almost a manifesto, that dictates how the AI uses memory. The philosophy is simple: remember before you act, save before you speak, trust the code over your notes, and let stale knowledge fade. Eight rules enforce this — check what you know before exploring, persist your findings before answering, type your memories properly so a search for "how do we deploy" returns the procedure and not some random observation. Memories decay at ninety-five percent per day by default. Only hard constraints get pinned permanent. Everything else fades on purpose, keeping the system lean instead of accumulating context that costs tokens and misleads.
It's not fully solved. The hardest rule — store your conclusion before composing the answer — fights against the natural flow of generation. The AI has done the work, formed the insight, and wants to respond. Pausing to make a storage call mid-thought is a discipline problem, not a technical one. The protocol describes it clearly. Compliance is still inconsistent. That's an honest gap.
Third: the tool integrations are real superpowers. When I say "check how many jobs are in the queue," the AI runs SELECT COUNT(*) FROM jobs against my actual database and gives me a number. When I say "generate a class diagram for the auth module," it produces an SVG. When I say "test the login endpoint with these credentials," it fires a real HTTP request and validates the response. This is not AI generating markdown that I then have to copy-paste somewhere. This is AI doing the work.
Fourth: the terminal-native approach is underrated. No Electron app eating two gigs of RAM. No browser tab to manage. I'm already in the terminal. My git, my tests, my logs — they're all here. OpenCode lives where the work happens. It has direct access to my filesystem, my LSP, my AST tools. The feedback loop is tight.
Fifth: everything runs locally where it can. Embeddings are local. The daemon is local. The MCP servers are local processes. The only thing going to the cloud is the model inference through GitHub Copilot — and even that you can partially replace with local models via Ollama if you want to go fully offline.
Sixth: the orchestration isn't just routing — it's a conversation. When I say the AI delegates, I don't mean it fires off a request and waits. It's a back-and-forth. The main agent — Sisyphus, the orchestrator — identifies what it needs to know, fires three or four explore agents in parallel to search the codebase, fires a librarian to check external docs, and continues working on what it can while they run. When results come back, it synthesizes them, decides the next move, and delegates the actual implementation to a specialized agent with explicit instructions: what to do, what not to do, which files to touch, which patterns to follow. If the result isn't right, it resumes the same session — the subagent remembers everything from the previous exchange — and says "fix this specific thing." It's not a single prompt-response. It's an ongoing working relationship between specialists.
For critical tasks, there's an ultrawork mode — the AI equivalent of "measure twice, cut once." It forces the agent to explore thoroughly, consult specialists, produce a detailed plan, and get it reviewed before touching any code. Nothing gets implemented until the plan is solid. Nothing gets reported as "done" until there's evidence: tests pass, builds succeed, the feature actually works when you run it. It sounds obvious, but left to its own devices, an AI will happily tell you "it should work now" without having tested anything. Ultrawork eliminates that.
And before any implementation starts, two Superpowers skills act as guardrails. Brainstorming forces the AI to explore what you actually want before writing code — your intent, not just your words. If you say "add a dark mode toggle," brainstorming asks: toggle where? Persisted how? Which components affected? It catches the requirements gap before it becomes a code gap. Plan-writing turns that refined understanding into a structured execution plan with dependency analysis and parallel task graphs. The AI knows which tasks can run simultaneously and which must wait. It assigns the right model tier and the right skills to each task. By the time code gets written, the thinking is already done.
Let me be direct. This stack has real problems.
The setup cost is significant. You saw the recipe — it's a thirty-minute guided install with eleven steps, five MCP servers, three plugins, symlinks to work around bugs, and a TOML file for database connections. For a junior developer, this is intimidating. For a team lead rolling this out to ten people, it's a support burden. Cursor gives you an installer and you're done. This gives you a recipe and tells you to bring your own kitchen.
It's fragile. Oh-My-OpenAgent has a config filename bug where it reads from one file and writes to another. You fix it with a symlink. That's the kind of thing that shouldn't exist in a tool you depend on daily. Signet's daemon has had issues — I personally tracked down a file descriptor leak in Bun's fs.watch that was silently exhausting system resources. These are real bugs in real infrastructure I depend on.
The GitHub Copilot dependency is a single point of failure. The entire multi-model access — Claude, GPT, Gemini — routes through a Copilot subscription. If GitHub changes pricing, retires a model ID, or has an outage, your stack degrades. The model IDs in the config (github-copilot/claude-opus-4.6, github-copilot/gpt-5.4) are not stable contracts. They can and do change. I've had to update model IDs when providers renamed things.
The terminal-only interface is polarizing. Some developers love it. Some hate it. If your team expects a visual diff view, a file tree, inline annotations — this doesn't have that. You're reading output in a terminal. For people who think in GUIs, this is a dealbreaker.
Model quality variance is real. The cheap models are cheap for a reason. Claude Haiku is fast but sometimes misses nuance in code searches. The writing model (Gemini Flash) produces adequate but not great prose. You save money on routing, but you pay in occasional quality drops on the lower-tier tasks. The orchestration is only as good as the weakest model in the chain.
No Windows support. The recipe says WSL recommended, and the Signet daemon flat-out doesn't work on native Windows. If your team is Windows-native, you need WSL or you need a different stack.
This stack is not for everyone. It's for developers who:
- Live in the terminal
- Want AI as infrastructure, not a sidebar toy
- Are willing to invest in setup for a compounding return
- Care about keeping data local and costs predictable
- Work on long-lived projects where memory across sessions actually matters
If you're doing quick prototypes, weekend projects, or you want something that "just works" out of the box — use Cursor. Seriously. It's a great product with a great UX.
But if you're a professional developer working on the same codebase for months, making architectural decisions that need to be remembered, running the same test suites and database queries day after day — the memory layer and tool integrations compound. Week one, you're configuring YAML files and debugging symlinks. Week four, the AI knows your project constraints, your test commands, your commit conventions, your database schema. It doesn't ask. It acts.
That compounding is the real value proposition. Not any single feature. The fact that the AI gets better at your project over time.
The model layer is commoditizing fast. Today's expensive reasoning model is next year's cheap one. The orchestration layer — routing the right model to the right task — will matter more, not less, as models proliferate.
Memory is the moat. Every AI tool today starts every session from zero. The ones that persist knowledge across sessions, across projects, across team members — those are the ones that will win long-term. Signet is early and rough, but it's pointed at the right problem.
The MCP protocol — Model Context Protocol — is the standard that enables those tool integrations. It's how the AI talks to your database, your diagramming engine, your API testing framework. That's not going away. More tools will speak MCP. The stack grows by adding servers, not by rewriting the core.
So this is a bet. A bet that terminal-native, memory-persistent, model-routed, tool-augmented AI development is where the industry is heading. The stack I showed you today is an early, honest, sometimes frustrating implementation of that future.
It works. It has rough edges. And it gets better every week.
Thank you.