· via dev.to (home feed)
almost-cli brings BYOK multi-agent coding to your local machine
A developer has open-sourced almost-cli, a local-first CLI that orchestrates specialized coding agents using your own model API keys, with deny-by-default permissions.

An alternative to hosted coding assistants
A developer publishing as wellparth has open-sourced almost-cli, a command-line tool that runs a team of specialized coding agents against a local codebase. According to the announcement post on dev.to, the project is a deliberate counter to the mainstream coding assistant: no inference happens in the cloud, no backend account is needed, and no model access is rented from the tool itself. Instead, users supply their own API keys — for OpenAI, Gemini, DeepSeek or NVIDIA NIM — and both the keys and the source code remain on the user's machine.
The tool defines distinct agent roles for different stages of the work: Architect, Planner, Builder, Tester and Debugger. These agents operate together on the local repository rather than acting as a single monolithic assistant.
Agents are configurations, models are runtimes
The dev.to post frames the tool's central design idea as a strict split between what an agent is and which model runs it. An agent, in this scheme, is a configuration of system prompt, tool set, permissions and workflow, while the language model underneath is treated purely as a runtime. The practical payoff is per-agent model routing: a cheap model can be assigned to planning while a stronger model is reserved for debugging, and providers can be swapped per agent without changing how the agents behave.
Deny-by-default permissions
The stack is layered, according to the post:
- The CLI and TUI communicate with an Agent Orchestrator.
- The orchestrator coordinates an Agent Runtime, a Context Engine and a Permission Engine.
- Agents run with explicit tool sets covering Filesystem, Shell, Git, Search and MCP.
- Permissions are denied by default, every tool call is checked, and MCP servers are gated per tool.
That last point matters for a tool whose agents can execute shell commands and modify files. Multi-agent setups multiply the surface area for unintended actions, and checking each tool call — including calls out to MCP servers — is the kind of guardrail the broader agent ecosystem has been arguing for. Whether the implementation holds up in practice is untested at this stage.
A monorepo on day one
The code lives on GitHub as a pnpm-based monorepo: an apps/cli package alongside libraries for agent-core, providers, tools, permissions, context, orchestrator, sessions, storage and agent-definitions, plus an agents directory holding the definitions themselves. Getting started follows the standard pnpm sequence of install, typecheck, test and build.
One caveat deserves emphasis: the author describes the post as written on the first day of building and says the project is being developed in public, with issues and feedback explicitly requested. This is an experiment at its earliest stage, not a finished product, and anyone evaluating it should expect rough edges.
Why it matters
Most popular coding assistants bundle model access with a cloud service, which means code and context leave the developer's machine and the provider relationship tends toward lock-in. A bring-your-own-key, local-first tool inverts that arrangement: the developer owns the data, the keys and the agent definitions, and can mix providers task by task to balance cost against capability. The trade-off, as the post itself concedes, is that the user also owns operations — key management, model choices and whatever breaks along the way.
For teams with security or compliance constraints, and for anyone watching how agent-safety patterns like deny-by-default tool permissions and per-agent model routing settle out, almost-cli is worth a look — less as a daily driver today, and more as an open reference implementation of a design philosophy that challenges the cloud-assistant default.
- #open-source
- #ai-agents
- #cli
- #developer-tools
- #local-first