Launched this week

Airuncode

Launched this week

Run multiple local coding agents on your machine

190 followers

Run multiple local coding agents on your machine

190 followers

Visit website

AI Coding Agents

•

AI Engineer

Airuncode is a local-first agent runtime for serious software work. Run multiple coding agents on your machine, bring your own API keys, switch between cloud and local models, and pay providers directly with zero token markup. It scans your codebase, debates solutions across agents, edits files, runs tests and self-heals failures. It also ships with V-CORE, a native Vulkan 3D runtime for AI-assisted game development. Available on Windows, macOS and Linux.

Free Options

Launch tags:Software Engineering•Developer Tools•Artificial Intelligence

Launch Team / Built With

LightfieldAI-native CRM that builds itself and does work for you

Promoted

Airuncode

Maker

📌

Hey Product Hunt 👋 I'm the builder of Airuncode. I started working on it because I didn't want my entire coding workflow to depend on one AI company, one subscription, or one model. The idea became pretty simple: the runtime should be the stable layer, and the model should be replaceable. Airuncode runs locally on your machine, lets you bring your own API keys, use cloud or local models, run multiple agents in parallel, work directly on your files, execute tests and automatically attempt to fix failures. I also built V-CORE into it, a native Vulkan 3D runtime, because I wanted agents to have real engine capabilities available instead of having to recreate rendering, terrain, physics and related systems from scratch every time. Airuncode is already available to try on Windows, macOS and Linux. This is still the beginning of the project. I'm actively rebuilding parts of the PWA, improving the experience and adding a community/forum where updates, bugs and feature discussions can live in one place. If you try it, I'd really like to know two things: What feels broken or confusing? And what would make you actually use Airuncode as your daily coding agent? Thanks for checking it out.

Report

1d ago

Nice job on the launch! Can each agent in a parallel run use a different model at the same time, or do they all have to share one?

Report

8h ago

Airuncode

Maker

@colegawin Thanks Cole! Yes, each agent in a parallel run can use a completely different model simultaneously.

Since Airuncode acts as a local model-agnostic runtime, you aren't locked into a single provider or model per session. You can assign different models—such as pairing an Anthropic model (like Claude 5 Sonnet) with an OpenAI model (like gpt sol) or a local Ollama/LM Studio model—to run side by side, bring their own perspective to the debate loop, or execute distinct sub-tasks concurrently.

Report

7h ago

can you also build context here like you do with claude or gpt?

Report

4h ago

Several agents in parallel on the same repo is the part I'd want to hear more about. The failure I keep hitting isn't bad code, it's a second correct implementation of something the repo already had, because each session starts from a blank slate and it reads fine in the diff. Does the debate happen after all of them have read what's already there, or are they arguing about approaches before anyone checked whether one exists? Self-healing on a failed test worries me for the same reason, green doesn't tell you the fix belonged in that layer.

Report

14h ago

Airuncode

Maker

@asadmalik901

Spot on. You hit the exact two failure modes that make most multi-agent setups frustrating in real-world codebases. Here is how we address both in Airuncode's architecture:

1. Code Duplication & Context Drift The agents don't debate abstract approaches from a blank slate. Before any debate or edit happens, the runtime generates a global symbol map and AST index of your repository.
When agents enter the multi-agent consensus loop, they review proposed diffs against this global index, not just the local file. If Agent A proposes creating a new utility function, Agent B catches that a matching helper already exists in src/utils/ and forces the proposal to reuse the existing implementation instead of introducing a duplicate.
2. "Green Test" In the Wrong Layer You're completely right—a passing test just means the assertion stopped crying, not that the fix is architecturally sound. If left unguided, an agent will lazily handle a null check across five UI components instead of fixing the broken API transformer causing the null in the first place.
To prevent "green-at-all-costs" patches during self-healing:
Stack Trace Primacy: The runtime forces the agent to trace the failure down the call stack to the originating frame, rather than patching the top-level frame where the test assertion failed.
Scope Locking: The self-healing loop locks the agent's write permissions strictly to the module under test by default, preventing it from spraying band-aid fixes across surrounding layers.
Architectural Review Step: Once tests turn green, a secondary review pass checks the diff specifically for layer pollution or added coupling before committing the change.
It's an ongoing effort to keep refining these boundaries, but making sure agents respect existing project patterns and module boundaries is core to what we're building. Appreciate the sharp feedback!

Report

10h ago

@asadmalik901

Spot on. You hit the exact two failure modes that make most multi-agent setups frustrating in real-world codebases. Here is how we address both in Airuncode's architecture:

1. Code Duplication & Context Drift The agents don't debate abstract approaches from a blank slate. Before any debate or edit happens, the runtime generates a global symbol map and AST index of your repository.
When agents enter the multi-agent consensus loop, they review proposed diffs against this global index, not just the local file. If Agent A proposes creating a new utility function, Agent B catches that a matching helper already exists in src/utils/ and forces the proposal to reuse the existing implementation instead of introducing a duplicate.
2. "Green Test" In the Wrong Layer You're completely right—a passing test just means the assertion stopped crying, not that the fix is architecturally sound. If left unguided, an agent will lazily handle a null check across five UI components instead of fixing the broken API transformer causing the null in the first place.
To prevent "green-at-all-costs" patches during self-healing:
Stack Trace Primacy: The runtime forces the agent to trace the failure down the call stack to the originating frame, rather than patching the top-level frame where the test assertion failed.
Scope Locking: The self-healing loop locks the agent's write permissions strictly to the module under test by default, preventing it from spraying band-aid fixes across surrounding layers.
Architectural Review Step: Once tests turn green, a secondary review pass checks the diff specifically for layer pollution or added coupling before committing the change.
It's an ongoing effort to keep refining these boundaries, but making sure agents respect existing project patterns and module boundaries is core to what we're building. Appreciate the sharp feedback!