Nasiko added 734 stars in GitHub Trending's September 22 snapshot while its main branch sat 834 commits beyond its only tagged release. That mismatch changes the practical story for developers. The project attracting attention is a Rust control plane for AI agents, but the downloadable release is a February macOS application from an earlier form of the product. Evaluating Nasiko today means building a moving branch rather than installing a version that represents the current code.
At 16:32 UTC, the GitHub repository metadata showed 7,574 stars and 1,633 forks. Those counters measure attention. Release fitness needs separate evidence, especially for software that asks to sit between agents, model providers, tools and container infrastructure. Nasiko has enough public code to inspect, though its packaging leaves the evaluator to define the version under test.
The control plane is a deliberate chokepoint
Nasiko's central idea is easy to locate in the project README: every agent-to-agent call passes through one server. Agents stay off the public network. The server authenticates requests, applies access rules and forwards traffic to containers that speak A2A 1.0. A routing pipeline can shortlist agents by embedding similarity, rerank them with conversation context and ask a model to make the final selection. Callers that already know the destination can use the proxy path directly.
That central path gives the project somewhere to enforce limits that individual agents often leave scattered across application code. Nasiko's A2A implementation guide documents a default maximum depth of five agent calls and a fan-out limit of 20, with token budgets, timeouts and cycle detection backed by Redis. Each dispatch and proxy hop can emit an OpenTelemetry span. The server also records model-token usage and cost from the trace attributes described by the project.
A2A is doing a specific job here. The official A2A 1.0 specification defines how independent agents advertise capabilities through Agent Cards and exchange tasks, messages and artifacts. MCP connects an agent to tools. Nasiko implements both layers: A2A traffic moves between agents, while its MCP gateway gives them a permission-filtered tool catalog. That division lets a Python agent and a Rust agent communicate without sharing an internal framework.
Nasiko does not use the authentication schemes declared inside A2A Agent Cards. Its implementation guide says the server validates a session JWT, then injects user identity headers before traffic reaches an internal agent container. That simplifies the agents, but it also makes the server's identity checks part of every downstream trust decision. A compromised control plane would occupy the same path that normally enforces the rules.
Credentials are another reason to put a server in that path. According to the coding-agent integration notes, Claude Code, Codex and OpenCode can route model calls through Nasiko. The agent receives a short-lived identity token, and the server resolves the provider, model and real key. There is an operational catch: connecting Claude Code or OpenCode changes per-user global configuration, so the new route affects every process for that user rather than one repository.
One command starts a seven-container platform
The word "single" in Nasiko's description refers to the control-plane process, not the whole installation. Its Compose file defines seven services: the server, Postgres, Redis, RustFS, an OpenTelemetry collector, Tempo and Loki. The server image builds from the checked-out source. It also mounts /var/run/docker.sock so it can create and manage agent containers, which gives the control plane a powerful connection to the host's container engine.
The documented trial is short enough to fit in a terminal:
git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .env.example .env
# Replace development secrets and add the provider credentials you need
docker compose up -d
The sample environment file ships with development values for the encryption key, JWT secret, admin password and S3 credentials. It tells operators to replace real credentials, and the README calls for TLS in production. Anyone putting the server on a shared host should also treat Docker-socket access, backups for Postgres and RustFS, and access to Tempo and Loki as part of the deployment. The command assembles the pieces; it does not remove the need to secure them.
This weight makes sense for a team running several agents. A single agent gains little from adding a database, object storage and a tracing stack. A fleet gains a common place to inspect calls, cap recursive work and remove provider keys from agent containers. The CLI surface reflects that scope with commands for deployment, scaling, logs, secrets, MCP connectors, traces, registry artifacts and multi-agent flows.
The release channel describes an older product
GitHub lists one release, Nasiko v1.0.0, published on February 12. It contains a 21.2 MB nasiko.zip asset and installation instructions for a native SwiftUI desktop application on macOS. The asset had 72 downloads when checked. That release does not package the Rust server, CLI or Compose stack described on the current main branch.
The difference is visible without interpreting a roadmap. The current Cargo workspace sets its package version to 0.1.0 and lists 21 member crates, including the server, CLI, flow guard, MCP gateway, LLM router and OCI registry. GitHub's tree contained 445 Rust files and no Swift files when reported. A tag named v1.0.0 therefore looks newer than the software a fresh clone will build, even though its commit is 834 changes behind main.
The documented Docker route does not close that gap because Compose builds whatever commit the operator checked out. Nasiko has a Docker publishing workflow for version tags and manual runs, while GitHub still exposes only the February tag. A current image may exist outside the GitHub release page, but the public version trail does not connect one to September's 0.1.0 workspace. Pinning a commit is the only unambiguous choice in the instructions.
The public automation follows main more closely than the releases do. A deployment workflow pulls the latest main branch, rebuilds the server and then checks its health endpoint. The visible workflow directory has no pre-deployment test job. A separate workflow forwards pull-request events to a private repository, so the public files cannot establish what checks run elsewhere. For an outside adopter, the available signals remain the source tree, local test commands and a health check after deployment.
The documentation has the same split. The README is detailed about A2A versioning, Linux networking and failure cases, while the public documentation homepage still identifies itself as a Mintlify starter kit. A previous hands-on run is covered in our review of Nasiko, including the setup reality, but that run used an August commit and cannot prove whether September's main branch builds cleanly. MrKeyoor did not rerun the current branch for this article.
What an evaluation can establish now
A private lab can test the project's main claim without giving it production traffic. Pin a commit, replace every development secret, keep port 8080 off the public internet and deploy two A2A agents with different permissions. The repository's Apache 2.0 license permits that inspection and modification. Traces should then show both hops, the flow guard should stop a deliberate cycle, and neither agent container should receive the underlying model or MCP credentials. Those results would say more about the control plane than the star counter.
Protocol compatibility needs its own check. Nasiko requires the A2A-Version: 1.0 header and documents a -32009 response for older versions. The A2A specification treats 1.0 as the current released line, but existing agents built for 0.2 or 0.3 still need an upgrade or adapter. The server supports JSON-RPC over HTTP and server-sent events; it does not implement every binding in the standard.
The next signal to watch is a tag for the Rust control plane, tied to a commit and accompanied by a reproducible server image or binary. A public test gate before the demo deploy would make that tag easier to trust. Until then, Nasiko's 734-star day is a reason to inspect its agent-operations design, while the 834-commit release gap tells you exactly how carefully to pin the code you test.