Launched this week
AI Bridge
Every AI coding agent on your Mac, in its place
73 followers
Every AI coding agent on your Mac, in its place
73 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.
Free
Launch Team / Built With
AWS Startup AdvisorPersonalized AWS guidance that meets you where you’re already building
Promoted
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.
Congrats on AI Bridge. I am building in a relevant but complementary domain, so why did you choose to build a desktop app for local coding sessions rather than sessions running on a remote machine? Do you see more need from local vs remote sessions? Why? Thanks.
@w_fan I think both are needed to be honest. I personally use bunch of opened sessions, and they use sub-agents (whom i dont need to monitor), and I can also see a point of remote agents when your laptop is closed. I think its an additional feature that can build on the top of the product later. Its just fairly complicated to do it the correct way for remote execution, pod level security, sandbox, identity, roles, mcp access etc, something that requires a bit more investigation and its definitely on a roadmap.
Shortly both are needed, a pleasant local environment with text editing ability (similar to cursor but focusing more on AI managment), as well as ability to deploy agents remotely.
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.
Grouping agents by the job they do, rather than by repo, is a useful shift in framing. A frontend session should not have its context polluted by database queries, cluster checks, or support questions, and keeping each agent as the real CLI in a real terminal avoids hiding that context behind another abstraction. The session portability between computers is also practical for anyone who splits work across two laptops. Using your own kubeconfig and credentials for the Kubernetes view, so existing RBAC still governs what an agent can see, keeps that convenience from quietly bypassing access controls.