Open AI interfaces

Open-source chat interfaces now do most of what Claude Desktop and ChatGPT do, with any model you point them at. That makes them a good starting point for something they don't do yet: a threads workspace where Claude Code, Codex, Jev and the models that come after them work side by side, watch what's changing in the field, and propose their own next features.

1. The interfaces worth knowing

All of these are open source and talk to any OpenAI-compatible endpoint. That one shared protocol means one interface can reach Venice, OpenRouter, Hugging Face and a local Ollama at the same time.

Features are from each project's own pages and recent reviews, not from tests on our machine. Using a less filtered model through any of these doesn't change who is responsible for its output, and each provider's terms still apply.

2. What they already solve

These projects have done the dull, necessary work: streaming chat, model pickers, file uploads, image and voice handling, accounts, and MCP so a model can call tools. Most of all, they've proved that the OpenAI-compatible API works as an adapter boundary (see Own your stack). Swapping a provider is a change of URL and key, not of code.

3. What they're missing

They're built around a conversation with a model. The work we hand to agents looks different:

• Threads are jobs, not chats. A thread owns a task, runs for hours, and ends with a result: a pull request, a page, a report.
• The worker isn't a model, it's an agent. Claude Code and Codex read a repository, run commands, and edit files. A chat interface can't host that; it can only show it.
• Status matters more than transcript. People skim a checklist and a final answer, not every tool call.
• Memory belongs to the project. What one thread learns should help the next, whichever provider handles it.

4. The design: a threads workspace on top

We don't need to fork an interface to get there. The plan is two layers:

A threads service in Rails owns projects, threads, status, memory and results. One adapter per agent runs the work. Claude Code and Codex both have headless modes that stream JSON events (claude -p --output-format stream-json and codex exec --json), so an adapter just starts the process in the right folder and turns its events into status updates.

The open interface stays the chat surface. The threads service also speaks the OpenAI-compatible API. To Open WebUI, Cherry Studio or LibreChat it looks like one more model, so starting a thread, checking on it, or chatting about its result works from whichever interface you already like, on desktop or phone.

class Thread
  def initialize(task, agent:) = (@task, @agent = task, agent)

  def run
    @agent.perform(@task) { |event| update_status(event) }
  end
end

class ClaudeCodeAgent
  def perform(task, &on_event)
    stream("claude", "-p", task.prompt, "--output-format", "stream-json", chdir: task.repo, &on_event)
  end
end

class CodexAgent
  def perform(task, &on_event)
    stream("codex", "exec", "--json", task.prompt, chdir: task.repo, &on_event)
  end
end

class ChatModelAgent  # Venice, OpenRouter, Hugging Face, Ollama: one class, different URLs
  def perform(task, &on_event) = post_chat_completion(task, base_url: ENV["MODEL_BASE_URL"], &on_event)
end

Each agent is described by data, not code paths: what it can do (repositories, vision, tools, long context), what it costs, and how it has scored on our own tasks. That's where future models fit in. A model with better reasoning, longer memory or new senses is a new row and maybe a new adapter, and the rest of the workspace doesn't change.

5. Where Jev fits

TypeSafe's Jev doesn't write prose; it turns text and application state into typed judgments with probabilities. That's exactly the glue a workspace like this needs, and it's cheaper and easier to test than asking a large model to reply in JSON:

• Routing: is this task code, research, writing or images, and which agent has done best on tasks like it?
• Checking: did the thread actually finish, or does its last message hide a blocker?
• Ranking: which of today's trends and proposals deserve a person's attention?

Every judgment is a number the code can act on, log and evaluate, so Jev's decisions show up in observability next to the agents it routes.

6. Watching what's trending

The field moves weekly: new models, new MCP servers, new features in the interfaces above. A scheduled job keeps up so people don't have to:

• Sources: release feeds for the interfaces and agents we use, new and trending models on OpenRouter and Hugging Face, GitHub trending, Hacker News, and arXiv listings in the areas we care about.
• Filtering: Jev scores each item for relevance to our projects; a larger model summarizes only what survives.
• Output: a short weekly digest posted as a thread, each item linked to its source, and a saved copy in plain Markdown so the history stays ours.

7. Proposing its own features

The workspace has two kinds of evidence about what it should do next: what the field is doing (the digest) and how it is actually used (its own telemetry: which agents fail, where threads stall, what each provider costs). Together they make a proposal worth reading:

1. A pattern shows up, such as "Codex threads on this repo fail twice as often as Claude Code" or "three interfaces shipped voice threads this month".
2. The workspace writes a proposal as a new thread: the problem, the evidence with links, a sketch of the change, and what it would cost.
3. A person approves, edits or drops it. Nothing is built without that yes.
4. An approved proposal becomes an ordinary task: an agent opens a draft pull request with tests, and it ships through the same review as any other change.

The limits are the ones in AGENTS.md: the workspace never changes its own evaluation criteria or weakens a test to get green, never ships unreviewed, spends within a budget a person sets, and every claim in a proposal links to its source. A system that improves itself is only safe when the people around it can see and stop each step.

8. First steps

1. Run Open WebUI here, on 127.0.0.1, connected to Ollama plus our hosted providers, and registered in observability.
2. Build the smallest threads service: one Claude Code adapter, one status checklist, one OpenAI-compatible endpoint for Open WebUI to call.
3. Add Codex and a chat-model adapter, then compare all three on the same held-out tasks.
4. Add Jev for routing and the weekly trend digest.
5. Only then turn on feature proposals, starting read-only: suggestions, no pull requests.

Provided as is, for information only, with no warranty and no liability. Not legal or professional advice. Security and radio material is for authorized, lawful use only. Full disclaimer.

Visits are logged on our own server: IP address, browser and device details, and pages viewed. We use them to understand traffic and spot attacks, and never share or sell them.