Launching today

AI Bridge
Every AI coding agent on your Mac, in its place
43 followers
Every AI coding agent on your Mac, in its place
43 followers
AI Bridge runs Claude Code, Codex, Grok and OpenCode side by side on your Mac: each the real CLI in a real terminal, on your own subscription. Group your agents like a team, by department or by what each one owns. Open a Kubernetes cluster or talk to your database in plain words, right beside them. Prefer terminals? The Grid puts them all on one wall, with cluster and database chats where you need them. Open as many windows as you like, and put agents in Slack that reply when you approve.











Hey Product Hunters π
I built AI Bridge to solve a few of my own problems. Since Claude Code and Codex arrived, I've worked mostly in terminals. I've almost completely stopped using VS Code, except to change the odd .env file: my whole workflow shifted to investigating and approving code with agents in the terminal.
The whole Cursor revolution flew over my head. I had a Cursor subscription from work, but I barely used it; I never felt I needed to look at the codebase in its entirety. If I needed something, I asked AI to find it and show me the file in the terminal. If I needed a change, I asked AI to make it, then watched and approved.
π‘ Then a friend showed me a tool for managing agents, and it was my light-bulb moment: making agents easier to manage is the right idea, but that implementation didn't fit my workflow. That's when I started building AI Bridge.
π© The pain A pile of terminal windows to manage. I'd rather have a session only for frontend and design work, without polluting its context with database queries, cluster checks or random support requests from colleagues. I wanted to group agents by department or area within a company, with my personal projects and consultancy work in the same app.
π What AI Bridge does for me
π Groups my agents (the real CLIs) by the job they do rather than by repo, still in a terminal view.
π Lets me chat to a database and see the data directly. Before, I'd ask an agent to query it, with no proper way to see the results unless I opened phpMyAdmin or Postico.
βΈοΈ Connects to Kubernetes clusters directly: I can see pods update, check that External Secrets, Argo or Flux has synced, or explore the cluster visually. AI can check a cluster's health quickly, but so can an experienced engineer with a good visual, and for me that's faster than asking another agent.
π¬ Connects an agent to a Slack channel. When a colleague asks me a DevOps or platform question, it comes into AI Bridge and I approve it. The agent runs from my terminal with the permissions I gave it, and I approve the reply before it goes back to Slack.
π² Gives me the Grid when I want the same feel as zsh and my other terminals, plus everything above.
π Moves Claude Code and Codex sessions between computers: with AI Bridge on both laptops, I export on one and import on the other.
π About me
Over the last few years I've been a cloud lead, principal engineer and head of engineering, and I run my own consultancy helping clients with infrastructure, automation, compliance and internal tooling. If you work across the full stack, cloud, product and support, you'll find it helpful.
I use it every day in my own job, and I'd love to hear what you'd want it to do next.
When several agents are grouped as a team, can they see each other's output, or is each terminal fully isolated? I'd also like to know how the Kubernetes view handles read-only access.
@yuv23639661Β Each agent is its own CLI session, so they don't see each other's output. Claude Code can run its own sub-agents, but separate agents, especially Claude vs Codex, stay apart. What they share is the workspace: same instructions, context files and repos.
If I want two agents to work together, I use Relay: they go back and forth until they agree. Handy on bigger features, e.g. Codex reviewing Claude's work and vice versa.
Grouping for me is mainly about clean context. Good context takes hours to build, and I don't want my UX/UI agent polluted with random support requests. So a product team might have a full-stack (debuger for incidents), super dev for big feature development, a UX/UI and a Slack support agent, each with its own job. Plus I can see at a glance which one needs me, I can also see what exactly is being processed by reading terminal outputs. The final call on what gets approved and merged stays with you though, I wouldn't hand that to AI on production
K8s works pretty much like Lens. It uses your own kubeconfig and credentials, so if your RBAC/IAM is read-only, it's read-only in AI Bridge too. If you do have write access, every change asks first, names the cluster and gets logged.