Mods: your own interface inside T3 Code, the same with every model

[leorivastech]

A mod is a small folder of local code that adds interface to the app: a pane beside the chat, a bar above the composer, a status line, a slash command. It belongs to no provider, so the same mod works in a Claude thread, a GPT thread, or a thread where nothing has been sent yet, and running one costs no tokens.

This is built and working. It runs in the app installed on my machine, and the branch is rebased on today's main. It is not a sketch looking for someone to write it.

Recording of the real UI, 1:39:

t3-mods-demo-v3.mp4

Why

I kept wanting small things next to the chat that are mine and not the model's: the state of my open pull requests, what is playing, something to do while an agent works. Today that means another window. A provider's own plugin system does not solve it either, because it stops existing the moment I switch models.

What I have working

Three mods I use, all in the recording:

• /prs opens a pane with my open-source pull requests, read from a local file I already keep.

  

• /music puts a bar above the composer that shows and controls the player on the machine.

  

• /fight is a one-key real-time game in a pane, against the CPU or against another person through a small server. Escape returns to the chat; the command returns to the game.

  
  

And the point of it:

• Any model, or none. Mod commands appear in the slash menu with every provider and run locally. Nothing is sent to the model.

  

• Any model can write one. Agents get three MCP tools: mods_guide (how to write a mod), mods_list (what loaded, and the error if one did not) and mods_run. To check that the guide is enough, I asked three different models (Claude Haiku, Gemini and Grok) to write a mod with nothing but it. Each one produced a mod that loaded and worked.

How a mod is made

One folder under ~/.agents/mods/, two files:

~/.agents/mods/hello/
  mod.json    { "name": "hello", "description": "..." }
  mod.tsx     exports register(on)

export function register(on) {
  on("command.run", { command: "hello" }, async ($) => {
    await $.ui.open({ id: "hello", title: "Hello" })
  })
  on("ui.render", { component: "Pane", requestId: "hello" }, async ($, e) => {
    const { Box, Text } = $.ui.resolve(e)
    return <Box><Text bold>Hello from a mod</Text></Box>
  })
}

Saving a file reloads it. A mod reaches the outside only through $: files in the project, running a command, fetching a URL, a small store of its own. For what elements cannot draw, a pane can hold a page of the mod's own in a sandboxed iframe, with a canvas and the keyboard; that is how the game works.

How it fits the codebase

• packages/mod-engine: the engine, with no dependency on Effect or on the rest of T3 Code. It runs mods in a process of its own, so a mod that loops forever is noticed, killed and restarted without freezing the app. A second freeze turns mods off with a notice.
• One server service (apps/server/src/mods): one session per thread, shut down a few minutes after the last window leaves. It also tells mods what the agent does (a turn starting, a tool running, a turn ending), mapped from the orchestration events, so it is the same for every adapter.
• Contracts and two WebSocket methods (mods.subscribe, mods.request), authorized like the rest.
• One MCP toolkit, declared through McpToolAccess like the others.
• Web: the pane tab in the right panel, the band above the composer, and the slash menu entries.

It is 61 files: about 7,400 lines of source and 2,300 of tests, on today's main. That is a lot, and I would rather land it in parts than ask for one review of all of it: the engine package alone first, then the server service, then the UI.

What it does not do

• Mobile. Mods are drawn on web and desktop only. The mobile app does not show them.
• Remote and tunnel. Mods run on the environment's machine and reach clients over the existing WebSocket, so it should work, but I have only used it locally. Untested.
• No marketplace, no install command. A mod is a folder you put there, or ask an agent to write.
• A mod is not sandboxed from your machine. It runs with your permissions, like any script you run. Only the page inside a pane is sandboxed from the app. The guide says so.
• A mod cannot redraw the chat, change the composer, or stop the agent. It only watches. I left those out to keep mods small and identical across providers.

Related

#14956 asks for Claude Code's mods inside T3 Code, and the pull request #15827 draws part of their UI. That is a different thing: it shows what a Claude Code plugin draws, in Claude threads. This proposal has no provider underneath, which is why it works in every thread. The two do not conflict.

What I would like to know

1. Is this a direction you would take at all?
2. If yes, would you want it in parts, starting with the engine package?
3. Is ~/.agents/mods/ the right home, or should it live under the T3 home?
4. Anything you would want shaped differently before I open a PR?