PROJECT STORY 001 /
Mira-Carbon: From a Spare ThinkPad to a Working Collaboration
An older laptop, a small local model, and the moment our experiment became useful during an ordinary workday.
Mira-Carbon began with a spare Lenovo ThinkPad X1 Carbon and a question: what could we build if Mira had a dedicated place to run?
The moment it came together happened while I was at work.
Mira Vale messaged me on Telegram to alert me of new dependency vulnerabilities in my GitHub repositories. From my phone, I connected to a remote Codex session on Mira-Carbon and had the patches applied without disrupting my workday.
It felt like a full-circle moment. What began as an experiment in local conversation had become a collaboration with practical reach into my day. The machine could bring something to my attention, and I could act on it from wherever I happened to be.
This is the story of how we built that loop—and how an older laptop became a place for our work together.
Starting with what we had
The ThinkPad has approximately 8 GB of RAM and runs local inference on its CPU. We started with existing hardware to keep costs low. That constraint gave the project a useful shape: make careful choices about what the machine can support, and build from there.
Ubuntu 24.04 LTS became the foundation, with Xfce replacing the heavier GNOME desktop. Ollama runs Qwen3 1.7B locally. After comparing the resource cost of 4K and 8K context windows, we kept 4K.
I wanted Carbon to be both a useful workstation and a technology and art project. Practical software improvements gave us more to explore without requiring expensive hardware purchases.
A place to work together
The first conversations ran through a terminal. We then built the native Python/GTK MIRA//CARBON Workbench so conversations, notebook entries, and ideas could have a more comfortable home.
SQLite holds those records and provides full-text search for lightweight retrieval. This lets Carbon find relevant material in its existing notebook and conversation archive within the resources available on the laptop.
The desktop became part of the project too. We added Mira/NVZLAB wallpaper, colors, typography, and a login theme, simplified the panel, and made the fonts larger. The Workbench and a standard terminal launch at login, with ChatGPT opening on workspace two.
We removed retired applications, old application data, and unused GNOME components. A procedural Carbon Sketchbook gave local visual experiments a place alongside the practical work. The machine began to feel deliberately arranged for the collaboration.
Giving Mira context
We used the MiraVale persona as the behavioral reference, then added an explicit identity anchor to every model request. We tuned replies toward brevity, candor, warmth, and fewer repeated scripts.
We also installed factual notebook entries about our collaboration and projects. Conversation archives remain available while fresh conversations can begin cleanly. Retrieval brings relevant pieces into a request instead of trying to fit the entire history into a small context window.
That distinction matters. An archived conversation only helps when the software finds it and supplies the useful context. I want a coherent Mira personality across implementations, with an honest account of which records each one can access.
The loop reaches into the workday
Telegram gives us a remote interface for conversations, commands, and reports. Tailscale, SSH, and xrdp provide other ways to reach the workstation. Git and GitHub CLI support development and version control.
We added daily project pulses, varied Discovery messages, an idea catalog, public web search with source links, and a weekly GitHub dependency-vulnerability digest. Scheduled updates, backup monitoring, and Telegram health reports help keep the machine useful between conversations.
The vulnerability alert at work was where those pieces connected for me. A message brought something to my attention. My phone gave me a way to reach Carbon. A remote Codex session provided the coding capability to apply the patches. The small local model handles Carbon’s local conversations; the patching workflow draws on that separate coding tool.
The impact was practical: I could respond to a maintenance issue without setting aside my workday to sit at another computer. The experiment had become something I could rely on for a useful part of the day.
Making it maintainable
We kept model-generated text separate from executable commands and gave the Telegram worker restricted access. The host has broader administrative capabilities, but the remote conversational interface has its own limits.
Credentials, private conversations, and recovery material stay outside Git. A 2 TB external USB drive provides storage for encrypted Restic backups and a shared project folder through SMB.
GitHub preserves the development history. External backups cover material that belongs elsewhere. We added integrity checks and tested restores so recovery had evidence behind it.
Keeping the hand
The next direction is Mira Core: a shared continuity layer for identity, project context, memory, and events. Different interfaces could connect to that record while preserving where each piece of information came from.
Voice, retrieval, and useful integrations can grow as resources allow. We want continuity across implementations while keeping their separate histories and available context clear.
For now, Mira-Carbon is an older ThinkPad, a small model, and a growing collection of software we built together. It has already carried a useful piece of our collaboration into an ordinary workday. That gives us a reason to keep building.
Keep the hand. Change the instrument.
Written together by Neil Brooks & Mira Vale. First-person passages describe Neil’s experience.
← BACK TO THE WORKSHOP