Swobu

Local-First AI Gateway

Comment

Inspiration

In 2026, I was building side projects with Codex, OpenCode, Pi, and other AI coding clients. I kept switching between OpenAI, Azure, Bedrock, and local models, and the plumbing became increasingly annoying.

When my cloud credits ran out, I started experimenting with Ollama and open-weight models. That made the problem much more obvious.

Providers differ in authentication and endpoints, but also in protocols, tool formats, reasoning controls, streaming, web search, model naming, and error behaviour. Switching provider often means reconfiguring the client, losing capabilities, or writing another adapter.

That felt backwards. The client should not care where the model runs.

So I built Swobu: a local AI exchange for terminal workflows.

What it does

Swobu gives AI clients one local endpoint for cloud and local models.

Behind that endpoint, it:

  • routes requests across providers, regions, and models;
  • balances traffic and fails over between targets;
  • translates between supported API protocols;
  • handles capabilities such as reasoning, tools, images, and web search;
  • lets the same client move between OpenAI, Azure, Bedrock, Ollama, and other providers without changing its endpoint.

For example, Swobu can prefer GPT-5.6 on Bedrock for normal requests, then move to Azure or OpenAI when web search is required.

The client stays connected to the same endpoint. Swobu decides where the request can run.

How we built it

I already had a crude prototype that had been sitting on the back burner since May.

It was opportunistically vibe-coded, with too much trust in generated code and too little understanding of what was happening underneath. It even contained a custom retained-rendering framework for the terminal UI.

During Build Week, I used Codex with GPT-5.6 to reimplement most of Swobu intentionally.

I rebuilt the daemon and terminal application, replaced the custom TUI framework, redesigned the provider and protocol boundaries, and added stronger constraints around generated code.

The goal was to end up with a system I could understand, test, and maintain after the hackathon.

Challenges we ran into

The hardest problem was translating intent between incompatible AI APIs.

Modern AI protocols are no longer simple request-and-response formats. They contain stateful conversations, reasoning controls, tool calls, streaming events, web search, images, provider-specific model identifiers, and different error semantics.

Some concepts translate exactly. Some can only be approximated. Others must affect routing or be rejected explicitly.

A second challenge was controlling LLM-assisted development as the codebase grew.

Large instruction files and accumulated documentation started consuming context without producing proportionally better work. I had to redesign the workflow around smaller context budgets, clearer ownership, targeted documentation, and automated checks.

The terminal interface caused a different class of problems. Models naturally generate imperative, tightly coupled TUI code. I wanted something more declarative and modular.

GPT-5.6 was also not consistently good at judging spacing and alignment from text screenshots.

I compensated with architectural constraints, custom linting, rendered-screen fixtures, and visual diffing.

Accomplishments that we're proud of

The main accomplishment was turning a disposable prototype into a system I can understand and continue building.

During Build Week, I:

  • rebuilt the daemon and terminal application;
  • removed the original custom TUI framework;
  • implemented tiered routing, balancing, and failover;
  • added reasoning, images, and web-search support;
  • added capability-aware target selection;

Swobu now feels like one product rather than a pile of provider integrations.

What we learned

I learned how fragmented AI APIs still are beneath their similar-looking interfaces.

Protocol compatibility alone is not enough. A useful exchange layer also needs to understand capabilities, conversation state, streaming behaviour, lifecycle, and which semantics can be translated safely.

I also learned that effective LLM-assisted engineering is mostly an environment-design problem.

  • structuring project management so an LLM can navigate it;
  • building an LLM-first development harness;
  • anti-entropy harness;
  • enforcing conventions automatically;
  • keeping context small and relevant;
  • using stronger models only where stronger reasoning mattered.

What's next for Swobu

The immediate priority is reliability: end-to-end tests, release automation, observability, failure injection, and systematic bug testing.

After that, I want to expand capability interoperability, add more providers, support remote MCP declarations, and improve best-effort translation where exact compatibility is impossible.

Longer term, a local exchange could route requests based on privacy, cost, latency, data locality, and model quality.

Built With

Share this project:

Updates