Independent AI intelligence Two editions daily · ET
Fervor AI
Menu

Analysis · October 28, 2026 · repo

NasikoNasiko-Labs/nasikoagent-infrastructureclaude-codecodexagent-security

Nasiko Puts All Your Coding Agents' Spend in One Dashboard. Its Router Is the Catch.

Turn on its routing and the open-source agent cost tracker becomes a gateway for every model call your connected agents make. Here is how to try it without handing it your whole machine.

Ask a team running three coding agents what they spent on models last week and you usually get a shrug. Claude Code bills one way, Codex another, OpenCode a third, and each keeps its own logs in its own format. The money is real. The picture of it is scattered across four dashboards and a credit card statement.

Nasiko, an open-source project trending on GitHub this week, promises one view: find every coding agent on your machine, track cost by agent and model, and send their model calls to whichever provider you choose.

The interesting part is the routing. Nasiko does not stop at reading logs. When you turn routing on, it moves itself into the path between your agents and the model providers. Every request from a connected agent goes through it.

That is a fine design. It is also a very different thing to install than a dashboard: connecting one agent changes its settings for every session on your machine, and the server it talks to holds your real provider keys. The README says so if you read closely.

What Nasiko actually is

The README calls Nasiko "the OpenRuntime for agents, coding harnesses, frameworks and tools." In plain terms it has three jobs:

  • Discovery: find the coding agents installed on your machine.
  • Observability: record what each one does and what it costs, in one format.
  • Routing: send each agent's model calls to a provider you pick, through a proxy Nasiko runs.

It supports four harnesses (a harness is the program wrapped around a model, the thing you actually type into): Claude Code, Codex, OpenCode and Cursor CLI. Cursor gets reporting only. Routing for it is listed as "not yet."

The project is Apache-2.0 licensed, sits at roughly 10,000 GitHub stars as of October 28, 2026, and ranked #19 on Trendshift's daily board this afternoon. The server runs as a set of Docker containers (Postgres, Redis, an S3-compatible file store, meaning one that speaks Amazon S3's storage API, and an observability stack), with a separate command-line tool written in Rust.

How it gets between your agent and the model

Start with the harmless part. nasiko agents discover is read-only. Per the README, "Discovery changes no harness settings, requires no account, and sends nothing off the machine." It lists each supported harness, whether it is installed, its version and where its config lives.

The routing part is where things change. Each harness has a setting for where it sends model requests, and nasiko connect rewrites it to point at Nasiko's LLM Router, an OpenAI-compatible proxy (a middleman server that accepts requests in the format OpenAI's API uses and forwards them on):

  • Claude Code: connect claude sets ANTHROPIC_BASE_URL (the address Claude Code sends requests to) and an apiKeyHelper (a command that hands Claude Code its credential).
  • Codex: connect codex adds a nasiko entry under model_providers in Codex's config.toml, with a helper that fetches a one-hour token from the Nasiko server.
  • OpenCode: connect opencode installs a router plugin and registers Nasiko as a provider. Only new sessions pick it up.

Once connected, your agent thinks it is talking to Anthropic or OpenAI. It is talking to Nasiko, which looks up the real provider key on the server side and forwards the call. The README says agents "never see real provider keys," and per-agent secrets are encrypted at rest with AES-256-GCM, a standard strong encryption scheme.

One neat side effect: the incoming request format is separate from the outgoing provider, so Claude Code's Anthropic-style requests can be answered by a model behind an OpenAI key.

Cost tracking is its own opt-in, separate from routing: nasiko agents install <agent> adds event hooks to the harness (for Claude Code, its Stop hook) that report each finished turn. Each interaction becomes one trace with its token counts and cost attached, broken out per agent and per model. One catch the README spells out: traces, token counts and cost need CODING_AGENT_OTLP_ENDPOINT set (OTLP is the OpenTelemetry protocol for shipping traces). Without it you see sessions, but not the numbers you installed it for.

To read the numbers, nasiko observe opens views for sessions, traces, stats and FinOps (the finance side: who spent what), and nasiko llm-config providers lists the pricing it uses to turn tokens into dollars. Completed turns queue locally during a short outage, so a blip does not drop your cost data.

One more thing to know about reporting. The install command has a flag, nasiko agents install <agent> --no-content, documented as "omit prompt and response text." That tells you prompt and response text is part of what reporting can send. Use the flag unless you need the text.

Why "gateway" is the right word

Think of it like moving your company's mail through a new front desk. The desk can now count every envelope, which is the point. It can also read them, lose them, or hand them to the wrong person if it is set up badly.

Every prompt a connected agent sends, including your code, file contents and whatever secrets end up in context, now passes through a server you run. That server holds your real provider keys. If it goes down, your agents stop working, or fall back in ways you did not plan.

None of that is a flaw in Nasiko. It is what a router is. But it changes the questions you should ask before you install it. Not "does the dashboard look nice," but "where does this run, who can log into it, and what happens to my agents if it stops."

And the README gives you real reasons to ask.

The settings are global

This is the detail most likely to bite. The README warns that ~/.claude/settings.json and OpenCode's config are global per-user files, so connecting "affects every such process on the machine, not just one project."

So you cannot try Nasiko on one side project. The moment you connect Claude Code, every Claude Code session you run on that machine, for every repo and client, routes through it. If your Nasiko server is a test install on your laptop with the demo password, that is now the gateway for all of your Claude Code work.

Then there is the demo password. The admin login defaults to admin / changeme, and the README tells you to replace it. Do that before you connect anything.

Put this into practice

Here is a cautious way to try it, using the README's own commands. You need Docker Compose V2, and Rust 1.85 or newer for the CLI.

1. Start the server.

git clone https://github.com/Nasiko-Labs/nasiko.git
cd nasiko
cp .env.example .env

Before you start it, open .env and replace the demo values. The commands below only print secrets to your terminal; paste each one into its line in .env yourself. The README gives the generators:

openssl rand -base64 32   # SECRETS_ENCRYPTION_KEY (exactly 32 bytes once decoded)
openssl rand -base64 48   # JWT_SECRET
openssl rand -base64 48   # AGENT_JWT_SECRET (a different value, for agent routing)

Set ADMIN_PASSWORD to something real while you are in there, and add OPENAI_API_KEY if you plan to use the default OpenAI-backed route. Then:

docker compose up -d

The dashboard comes up at http://localhost:8080. Keep the encryption key somewhere safe: the README warns not to regenerate it, because secrets already stored need the same key. And if you edit .env later, docker compose restart will not reload it. Use docker compose up -d again.

2. Install the CLI and look before you touch anything.

cargo install --path cli/ --force
nasiko agents discover

Discovery is read-only, so this step is free. You get a list of what is installed and where each config lives. Write those paths down.

3. Back up, then connect one agent. Copy the config files discovery showed you (for Claude Code, ~/.claude/settings.json) before you connect. Then connect a single harness and run one small task. Check the dashboard for that session and its cost. If you see sessions but no cost, set CODING_AGENT_OTLP_ENDPOINT.

4. Know the exit. nasiko disconnect <agent> reverses the settings and plugin changes. nasiko agents uninstall <agent> removes the local reporting hooks but keeps the history. A running harness may need to be stopped first, or disconnected with --force. Diff your backed-up settings file against the live one afterward to confirm it is clean.

What to expect: a working dashboard in a few minutes on a machine that already has Docker, and per-agent cost numbers once telemetry is wired. Expect a little friction too. The README lists port conflicts on 9000, 4317 and 4318 in its troubleshooting section, and on native Linux Docker host.docker.internal is not automatic, so agents can fail with name-resolution errors until you fix it.

Honest limitations

The setup is heavier than "a cost tracker" suggests. The control plane (the Nasiko server that holds keys, routes calls and stores traces) and its backing services need Docker with Compose, and the read-only discovery command needs the Rust CLI, even though the README's Docker-only path implies you need nothing else.

Release cadence is hard to read. The only tagged release on GitHub when I checked on October 28, 2026 was "Nasiko v1.0.0 - Desktop App for macOS," from February 12. Active work on main does not show up as versions, so pin a commit if you deploy it.

Model selection can surprise you. The README tells you to set each config's model explicitly, because unset values fall back through other models down to a platform-wide default. If you skip that, your agent may answer with a model you never picked, and your cost numbers will reflect it.

Coverage is uneven. Cursor CLI gets reporting but not routing. OpenCode sessions that were already open keep their original model. Codex asks you to trust the new hooks, which is good behavior, but it is one more prompt to read rather than click through.

And the core tradeoff does not go away with configuration. A router that sees every model call is a single point of failure and a single place to attack. If your agents touch client code, decide where that server runs and who can reach port 8080 before you connect anything that matters.

The real takeaway

Nasiko solves a real problem, and its approach to routing is the honest one: you cannot steer where agents spend without standing in the path the spending takes. Just treat it as infrastructure. Run discovery first, back up your configs, connect one harness, check the numbers, and know how to disconnect before you need to.

Most tools that promise visibility into your agents work the same way. Ask each one the same question before you install it: is this a window, or is it a door?

Sources: Nasiko-Labs/nasiko README on main, reviewed October 28, 2026; LICENSE; releases; Trendshift daily board, read about 15:15 ET October 28, 2026; star count from shields.io, October 28, 2026.