VibeAround v0.5.12: smoother Codex launches, better provider routing, and more reliable local agents
VibeAround v0.5.12 is live.
This release is mostly about making the daily local-agent workflow feel less fragile: launch the right coding agent, point it at the right provider profile, keep API translation out of your global config, and get back to coding.
What changed:
Better Codex launch support, including trusted launch hook handling.
More reliable API Bridge routing for provider-backed profiles.
Cleaner compatibility across OpenAI Chat, OpenAI Responses, and Anthropic-style request shapes.
Improved handling for reasoning/tool-call histories, especially around DeepSeek-style and API Bridge-translated conversations.
DashScope provider profiles are now named and migrated more clearly.
Tray and web-terminal launch menus are more agent-first, so picking the right agent/profile combo is faster.
Windows ACP agent wrapper support was fixed.
The local API Bridge and session code were split up internally, which should make the next round of provider/agent work easier.
The bigger direction is still the same: VibeAround is becoming a local-first command center for AI coding agents.
Claude Code, Codex CLI, Gemini CLI, Cursor CLI, Kiro CLI, Qwen Code, and OpenCode can stay close to your repo and local tools, while VibeAround gives you desktop launch profiles, a browser terminal, IM handoff, remote previews, and provider routing in one place.
If you use multiple coding agents or switch between providers like OpenAI, DeepSeek, Alibaba DashScope, Kimi, MiniMax, or Z.AI/GLM, this release should make the whole setup feel a bit more boring in the best possible way.
Downloads:
https://github.com/jazzenchen/VibeAround/releases/tag/v0.5.12
Replies
Managing multiple providers in one layer usually becomes the hardest part. Curious how conflicts are resolved.
VibeAround
@nora_mitchell Yes, there is definitely a lot of “dirty” mapping work in this layer.
I handle this through a separate open-source project https://github.com/jazzenchen/va-ai-api-bridge (va-aab).
Its job is to be the translation/API Bridge layer. Based on the bridge config, it creates explicit one-to-one routes from the agent-side API shape to the target provider profile, instead of relying on hidden global CLI defaults or guessed compatibility.
So when Codex, Claude Code, etc. launch through VibeAround, the selected API Bridge profile determines the exact provider route and translation behavior for that session.
Have you seen more stability issues from agents themselves or from provider translation layers?
VibeAround
@ryan_cooper9 Most of the instability I see comes from provider behavior being different, even when the API shape looks similar.
Some differences are interface-level: whether the provider needs full reasoning content sent back, how strict it is about tool-call history, streaming chunks, message roles, or request fields.
Others are capability-level: multimodal support, tool calls, reasoning output, long context, supported media formats, etc.
Managing multiple coding agents locally is becoming a real mess, so this looks super useful.
How’s the experience on lower-spec machines with several agents running together?
VibeAround
@nithikanb It depends on what the agents are doing.
VibeAround itself is fairly lightweight; it mostly acts as the launcher/control layer, API Bridge layer, and IM/web bridge. The CPU pressure usually comes from the agents’ actual work: builds, tests, dev servers, browser automation, indexing, debugging, etc. If multiple agents are doing that in parallel, it can definitely add up on a lower-spec machine.
Most APIs also have QPM limits and token throughput limits, so another useful pattern is to create different profiles for the same agent.
For example, you can run Codex with different provider/API profiles depending on the task. That makes it easier to avoid hitting 429s or provider rate limits, and you can switch routes without manually rewriting CLI config each time.