Nasiko

Open source alternative to Portkey

11.7K stars
Apache-2.0
Active this month
Last commit 12 days ago

Last verified Nov 4, 2026

Monitor AI agent spend, route model calls across providers, and enforce tool policies from a self-hosted gateway with no code changes required.

Visit website GitHub11.7K Deploy on Hostinger

Read the full breakdownWho it is for, how it works, trade-offs, the quick start and the FAQ

who it's for

Who Nasiko is for#

Platform engineers managing multi-agent coding stacks

Teams running Claude Code, Codex, OpenCode, or Cursor across multiple projects accumulate per-provider billing silos. Nasiko consolidates spend attribution, routes all LLM traffic through a single auditable gateway, and applies consistent policies without asking developers to change how they work.

Skip if:

Your team runs a single coding agent against one provider and cost attribution from that provider's own dashboard is sufficient. The setup overhead is not justified when spend is already attributable from one billing source.

MLOps and AI infrastructure teams optimizing LLM costs

Nasiko's routing engine matches each request to the right model at cost boundaries set by the team: smaller models handle straightforward steps, capable models are reserved for work that earns the cost. The forecast-before-run step and in-flight monitoring catch loops and runaway retries before they appear on the invoice.

Skip if:

Your agents run at low volume with predictable model choices. The routing and forecasting value scales with the number of agents, runs, and provider combinations in play.

Security and compliance teams auditing agentic tool access

Every tool call, policy decision, and block is written to a ledger with a plain-language explanation. Per-agent tool lists define exactly what each agent can reach; sensitive actions route to a human approval queue rather than executing immediately. The audit trail is on your own Postgres, queryable without sending data to a third-party service.

Skip if:

Your compliance scope covers only the LLM calls themselves and not which external tools agents can access. If audit logging of model inputs and outputs is the full requirement, a lighter observability tool may suffice.

Developers deploying autonomous agents into production

The CLI workflow handles the full agent lifecycle: nasiko new, deploy, run, chat. The embedded OCI registry stores agent images without requiring an external container registry. Each deployed agent is registered with an identity, versioned, and observable from the moment it goes live.

Skip if:

You are building and testing agents locally with no need for multi-agent coordination or production policy enforcement. Local development against direct provider APIs is simpler until production scale or compliance requirements appear.

the problem

The problem it solves#

Teams running more than one coding agent CLI end up with separate billing accounts per provider. Claude Code bills through Anthropic, Codex through OpenAI, each with its own dashboard. At month end there is a real aggregate bill but no breakdown by which agent spent it, on which model, or what it produced. Getting that breakdown from invoice reconciliation is manual and approximate at best.

The enforcement side has the same shape. A budget cap or a tool allowlist set in an environment variable can be overridden by any developer with access to that variable. Governance of agent behavior happens after the fact, in a postmortem or a code review, rather than at the moment an agent tries to reach a database or call a sensitive API. Without a controlled entry point in the call path, there is no way to prove what happened.

how Nasiko solves it

How it solves it#

Per-agent spend forecasting and attribution

Forecast what a run will cost before it starts, then watch actual spend in real time by team, agent, and model down to a single run. Usage is broken out from provider invoices rather than arriving as a single monthly number to reverse-engineer. The cost history belongs to your infrastructure, not to whichever provider billed it.

Gateway-level tool policy enforcement

Policy takes effect on each call as it lands, not in a postmortem review. Per-agent tool permissions are set to Allow, Ask, or Block; a blocked tool is never offered to the agent in its tool list. Sensitive actions can be held for human approval, and a kill switch stops a run outright. Every decision is written to an audit trail with an explanation in plain language.

LLM routing across providers and models

Register a provider and API key with Nasiko once, then point any coding agent CLI at the runtime instead of its vendor. The inbound wire protocol and outbound provider are decoupled: an Anthropic-format request from Claude Code can be served by an OpenAI key. Agents never see real API keys; they receive short-lived identity tokens instead.

Multi-agent workflow coordination across providers

Compose multi-agent workflows across models, providers, and agent frameworks in a single definition. Nasiko coordinates provider switching mid-run, carries state across steps, and traces every handoff between roles. Cost and policy are checked in flight rather than reconstructed after the run. Workflow-level traces show what each step cost and why a provider was chosen.

MCP gateway with per-agent permission filtering

One permanent URL gives every agent a merged, permission-filtered view of Composio toolkits and custom MCP servers. An agent discovers only the tools it was explicitly granted; it never holds the underlying credentials. The gateway sits between agents and tool servers, so permissions change on the next call without redeployment.

Non-invasive coding agent discovery

The CLI command nasiko agents discover scans the machine for supported coding agent CLIs, reports detection status, version, and config location for each, and exits without changing any configuration. Reporting and routing are explicit opt-ins added after discovery. Discovery sends nothing off the machine and requires no account.

strengths · trade-offs

Strengths and trade-offs#

Strengths

No application code changes requiredSession reporting is added through each CLI's own hook system: Claude Code uses the Stop hook, OpenCode uses session.idle, Codex and Cursor use their richer hook event sets. Routing replaces the agent's configured endpoint, not its code. A developer continues using the same CLI commands and interfaces after setup.
Apache-2.0 license with full self-hostingThe runtime is Apache-2.0 licensed, allowing commercial production use, modification, and redistribution with standard attribution requirements. No seat fees, no managed-service dependency. Running on your own Postgres and S3 means cost history, policy rules, and agent traces stay on infrastructure you control, satisfying data residency requirements that managed gateways typically cannot.
Single-process architecture with no separate gatewayThe server, registry, and routing layer are one process. Every agent-to-agent call is proxied back through the same process, so flow limits, ACLs, and observability apply at every hop rather than only the first. Durable state lives in Postgres, Redis, and S3; the application tier itself does not carry persistent state between restarts.
Encrypted secrets never reach agent logsPer-agent secrets are encrypted at rest with AES-256-GCM and injected only at deploy time. Agents receive short-lived JWT identity tokens rather than real provider API keys; the actual keys stay on the server. No provider keys appear in CLI history, environment dumps, or agent logs, which simplifies secret rotation and audit scope.

Trade-offs

-Self-hosting requires Postgres, Redis, and S3The runtime depends on all three external systems. Redis backs the flow guards that prevent cascade loops and runaway retries; Postgres holds agent registry, session, and cost data; S3-compatible storage is needed for the embedded OCI registry and artifact storage. The Docker Compose quick start handles this locally, but a production deployment requires provisioning and operating all three services independently.
-Routing some agent frameworks requires a restartOpenCode must be restarted after the Nasiko plugin is installed before routing takes effect. Existing OpenCode sessions do not pick up the new routing configuration; only new sessions route through Nasiko. Codex requires trusting new hooks before the routing integration is active. This is a one-time setup step per agent CLI, but it adds a brief interruption to developer workflows during initial setup.
-Relatively new projectThe repository was created in February 2026, putting it under a year old at the time of this writing. It carries 21 open issues. The star count (11,681) and fork count (3,140) indicate strong early community interest, but production usage patterns and long-term maintenance commitments are still being established. Teams with strict stability requirements should evaluate the issue tracker and release cadence before committing.

versus alternatives

Nasiko vs alternatives#

Nasiko vs Portkey

Both tools sit between AI applications and LLM providers, handling routing and observability. The primary difference is deployment model and enforcement scope.

Feature	Nasiko	Portkey
License	Apache-2.0	Proprietary
Self-hosting	Yes (Postgres, Redis, S3)	No
Deployment model	Your own infrastructure	Managed SaaS
Enforcement timing	In-flight, per call	Post-hoc analytics
Agent identity tracking	Yes, per coding agent CLI	API-level only
Secret handling	AES-256-GCM, server-side injection	Managed by provider

Nasiko is the stronger choice when data residency is a requirement, when you need policy enforcement that actually blocks calls rather than logging them after the fact, or when your agents span multiple providers and you need unified attribution on your own infrastructure. The in-flight control model (forecast before run, enforce during run, audit after) is a different architecture from an API-gateway-plus-observability approach.

Portkey's managed SaaS model means less infrastructure to operate and a faster initial setup for teams whose priority is routing and dashboarding without self-hosting complexity. If you need a hosted LLM gateway with no server management and your compliance requirements do not mandate data residency, Portkey remains a reasonable choice.

install · quick start

Quick start#

bash

Deploy the Nasiko OpenRuntime locally with the CLI install script.
```bash
curl -fsSL https://registry.nasiko.dev/r/nasiko/install-ee | bash
```

tech stack · detected from GitHub

What it's built on#

Languages: GoPythonRustTypeScript
Frameworks: React

frequently asked

FAQ#

How is Nasiko different from an LLM gateway or router like Portkey?

A router picks a model and forwards the call. Nasiko forecasts what a request will cost before it runs, routes it, watches it live, and steps in if something goes wrong, then writes every decision to a ledger. The product describes routing as one step of six. The other five cover cost attribution, pre-run forecasting, in-flight monitoring, policy enforcement, and audit logging, all applied at a gateway that also carries agent identity across every hop in a multi-agent workflow.

Does self-hosting Nasiko require installing Rust?

No, if you use the Docker quick-start path. The Docker Compose setup runs the full runtime without a Rust toolchain. Rust is needed only if you want to build the CLI from source, which the README documents as a secondary option for contributors. For most deployment scenarios the Docker path is the documented route for getting started.

Can Nasiko work with the coding agents I already run without changing my workflow?

Yes. The nasiko agents discover command scans for Claude Code, Codex, OpenCode, and Cursor, reports what it finds, and exits without modifying anything. Session reporting and routing are explicit opt-ins added afterward through each agent's own hook or settings mechanism. Developers keep using the same CLI commands after setup. The one exception is OpenCode, which requires a restart before the routing plugin takes effect for new sessions.

What does the Apache-2.0 license allow for self-hosters?

Apache-2.0 allows you to use, modify, deploy, and distribute the software for any purpose including commercial production use. The two requirements are preserving the original license notices and attributing any changes you redistribute. The license does not grant rights to the Nasiko trademark. There are no restrictions on running it as a service internally for your own team or deploying it in a commercial product.

How does the in-flight policy enforcement differ from a spend cap?

A spend cap stops all work when a number is crossed, penalizing teams running agents correctly alongside those running problematic ones. Nasiko manages each run individually: it forecasts cost before the run starts, routes each request to the model that earns its cost, and halts only the runs that are actually looping or overrunning their budget. A kill switch is available for immediate stops when needed, but the default behavior targets the specific run rather than a blanket ceiling.

also worth a look

Similar open-source tools#

Bifrost

Alternative toPortkey

Open-source AI gateway with 23+ providers, failover, and MCP support.

9,291 GitHub stars
Licence Apache-2.0

Litellm

Alternative toPortkey

Self-hosted AI gateway for 100+ LLMs in OpenAI format

62,626 GitHub stars
Licence MIT with enterprise directory carve-out

OmniRoute

Alternative toOpenRouter

352-provider AI gateway with automatic fallback and token compression

84,205 GitHub stars
Licence MIT

freellmapi

Alternative toOpenRouter

One OpenAI-compatible key for 635 free LLM endpoints

45,757 GitHub stars
Licence MIT

sub2api

Alternative toOpenRouter

One API gateway for Claude, OpenAI, Gemini, and Grok subscriptions

45,242 GitHub stars
Licence LGPL-3.0

jentic-one

Alternative toComposio

Self-hosted API broker that routes agent calls without exposing keys

220 GitHub stars
Licence Apache-2.0

by category

Open source tools in these categories#

120

Self-host Nasiko on a Hostinger VPS

Keep it running 24/7, even when your laptop is off. A Hostinger VPS gives it a server of its own.

01
Choose a plan
Starts from $6.49/mo
02
Apply
Extra 10% off yearly plans
03
Install Nasiko
On a server that stays on
04
Start building
Focus on the app, not the server

Deploy on Hostinger

Inbox Zero

Alternative toSuperhuman

AI email assistant that drafts replies and clears your inbox

12,889 GitHub stars
Licence AGPL-3.0
#Email

rakazo

Alternative toGrok Bot

AI teammates you own: your keys, your model, your machine.

6,568 GitHub stars
Licence Apache-2.0
#AI Agents

SnitchFeed

Live monitoring on LinkedIn, X, Reddit & more. Agentic social listening for startups.

Marketing & Growth

Advertise your product

The projects we add and every new guide. Free, unsubscribe any time.

Find open source alternatives to paid software

Nasiko vs Portkey

Both tools sit between AI applications and LLM providers, handling routing and observability. The primary difference is deployment model and enforcement scope.

Feature	Nasiko	Portkey
License	Apache-2.0	Proprietary
Self-hosting	Yes (Postgres, Redis, S3)	No
Deployment model	Your own infrastructure	Managed SaaS
Enforcement timing	In-flight, per call	Post-hoc analytics
Agent identity tracking	Yes, per coding agent CLI	API-level only
Secret handling	AES-256-GCM, server-side injection	Managed by provider

Who Nasiko is for#

Platform engineers managing multi-agent coding stacks

Skip if:

MLOps and AI infrastructure teams optimizing LLM costs

Skip if:

Security and compliance teams auditing agentic tool access

Skip if:

Developers deploying autonomous agents into production

Skip if:

The problem it solves#

How it solves it#

Per-agent spend forecasting and attribution

Gateway-level tool policy enforcement

LLM routing across providers and models

Multi-agent workflow coordination across providers

MCP gateway with per-agent permission filtering

Non-invasive coding agent discovery

Strengths and trade-offs#

Strengths

Trade-offs

Nasiko vs alternatives#

Nasiko vs Portkey

Quick start#

What it's built on#

FAQ#

Similar open-source tools#

Open source tools in these categories#

LLMOps & AI Tooling

AI & Machine Learning

Developer Tools

Security & Monitoring

Find open source alternatives to paid software

Who Nasiko is for#

Platform engineers managing multi-agent coding stacks

Skip if:

MLOps and AI infrastructure teams optimizing LLM costs

Skip if:

Security and compliance teams auditing agentic tool access

Skip if:

Developers deploying autonomous agents into production

Skip if:

The problem it solves#

How it solves it#

Per-agent spend forecasting and attribution

Gateway-level tool policy enforcement

LLM routing across providers and models

Multi-agent workflow coordination across providers

MCP gateway with per-agent permission filtering

Non-invasive coding agent discovery

Strengths and trade-offs#

Strengths

Trade-offs

Nasiko vs alternatives#

Nasiko vs Portkey

Quick start#

What it's built on#

FAQ#

Similar open-source tools#

Open source tools in these categories#

LLMOps & AI Tooling

AI & Machine Learning

Developer Tools

Security & Monitoring

Find open source alternatives to paid software