Migrating from Portkey to Naive

• LLM routing lives behind its own API key, its own provider keys (virtual keys / Model Catalog), and its own dashboard.
• Its _user metadata tag scopes observability and budgets for LLM calls and nothing else — it knows what the agent spent on tokens, but not its virtual card, its inbox, its vault secrets, or its KYC status.
• “Who let this agent burn $400 on GPT-5, and what else can it touch?” is answered in Portkey for tokens, and somewhere else for everything else. There is no shared accountability.

• The tenant user that makes the LLM call is the same user that owns its cards, its email inbox, its vault secrets, and its KYC.
• Whether the agent may call the model at all is decided by that user’s Account Kit at execution time — not by which key happened to be in the request header.
• Every completion lands in the same per-user activity log as everything else the agent does, and is billed in the same credits as its cards and domains.

​

Concept map

​

Before / after: the core path

import Portkey from "portkey-ai";

const portkey = new Portkey({
  apiKey: process.env.PORTKEY_API_KEY!,
  // a saved Gateway Config id (or inline object) drives fallbacks/routing
  config: "pc-agent-default",
});

// Models resolve via the Model Catalog (@provider-slug/model)
const res = await portkey.chat.completions.create({
  model: "@anthropic-prod/claude-3-5-sonnet-20241022",
  messages: [{ role: "user", content: "Summarize our Q3 strategy in 3 bullets." }],
});

console.log(res.choices[0].message.content);
// token usage/cost is in the Portkey dashboard, keyed by _user metadata

import { Naive } from "@usenaive-sdk/server";

const naive = new Naive({ apiKey: process.env.NAIVE_API_KEY! });

// fallbacks are an ordered list on the request — no saved config object
const res = await naive.llm.chat({
  model: "anthropic/claude-sonnet-4.6",
  models: ["anthropic/claude-sonnet-4.6", "openai/gpt-5.2"], // fallback chain
  messages: [{ role: "user", content: "Summarize our Q3 strategy in 3 bullets." }],
});

console.log(res.choices[0].message.content);
console.log("credits:", res.credits_used); // cost returned inline, logged per user

• No provider keys to manage. In Portkey you create a virtual key / Model Catalog entry per provider and reference it. Naive holds the OpenRouter key server-side and bills you in credits — there is no upstream key to provision or rotate. (The flip side: you cannot bring your own provider key — see gaps.)
• Fallbacks are an ordered list, not a saved config. Portkey’s config (a pc-… object with strategy/targets) becomes the models: [...] array on the request, plus an optional provider object for OpenRouter routing preferences.
• Cost is inline and per-user. Portkey surfaces spend in its dashboard keyed by a _user metadata tag. Naive returns credits_used on the response and writes the event to the caller’s activity log — the same log as that user’s cards and email.

​

Keep your existing OpenAI client (drop-in proxy)

import OpenAI from "openai";
import { PORTKEY_GATEWAY_URL, createHeaders } from "portkey-ai";

const client = new OpenAI({
  apiKey: "unused",
  baseURL: PORTKEY_GATEWAY_URL,                 // https://api.portkey.ai/v1
  defaultHeaders: createHeaders({
    apiKey: process.env.PORTKEY_API_KEY!,
    provider: "@openai-prod",                   // or legacy virtualKey
  }),
});

const r = await client.chat.completions.create({
  model: "gpt-4o",
  messages: [{ role: "user", content: "Hello" }],
});

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.NAIVE_API_KEY!,                       // nv_sk_...
  baseURL: "https://api.usenaive.ai/v1/proxy/openrouter",   // transparent passthrough
});

const r = await client.chat.completions.create({
  model: "openai/gpt-5.2",
  messages: [{ role: "user", content: "Hello" }],
});

• The Naive proxy maps every path under /v1/proxy/openrouter/* to OpenRouter, authenticated by your Naive key and billed in credits — paid credits: the proxy is gated exactly like the typed route, so it is not a way to route on the free signup grant.
• The proxy is not Account-Kit gated. When you want per-tenant policy enforcement, use the typed naive.llm.chat() / POST /v1/llm/chat/completions routes instead — that is the path the consolidation below relies on.

​

Minimal viable migration

npm install @usenaive-sdk/server

​

Consolidate further once you’re on Naive

// _user is an analytics/budget label on the LLM call; it isolates nothing else.
const res = await portkey.chat.completions.create(
  {
    model: "@openai-prod/gpt-4o",
    messages: [{ role: "user", content: "Draft a welcome email." }],
  },
  { metadata: { _user: "customer-acme" } },
);

// The card, the inbox, the secrets, the KYC for this customer's agent
// live in entirely separate systems with their own tenancy.

// One tenant user per customer; isolates *every* primitive.
const acme = await naive.users.create({
  external_id: dbCustomer.id,
  email: dbCustomer.email,
});

const client = naive.forUser(acme.id);

await client.llm.chat({
  model: "openai/gpt-5.2",
  messages: [{ role: "user", content: "Draft a welcome email." }],
});

// The SAME client owns this customer's card, inbox, secrets, and KYC —
// one identity, isolated end to end, billed in one credit balance.
await client.cards.create({ name: "Ops", spending_limit_cents: 25_000, provider: "managed_virtual" });
const inbox = await client.email.createInbox({ local_part: "notifications" });
await client.vault.put("internal.api_key", "key_xyz");

​

Gain #1 — one identity across primitives

• With Portkey, the agent’s LLM usage is an island tagged by metadata. With Naive, naive.forUser(acme.id) is a single handle to LLM and cards and email and vault and KYC.
• You provision a customer’s whole agent footprint from one identity, and tear it down from one place. Sibling tenants can never read each other’s completions, cards, or secrets.

​

Gain #2 — execution-time permission enforcement

• Whether an agent may call the model at all is policy on the Account Kit — not a key that happens to be in scope, and not a budget that lives in a separate product.

const starter = await naive.accountKits.create({
  name: "Starter",
  primitives_config: {
    llm:   { enabled: true },                    // model access is on for this tier
    cards: { enabled: true, requiresApproval: true },
    email: { enabled: true },
  },
});
await naive.accountKits.assignUser(starter.id, acme.id);

• The agent’s code is identical for every tier — client.llm.chat({ model, … }). Whether the call runs is decided by the caller’s kit at execution time:
  • primitives_config.llm.enabled: false returns forbidden for that user — same line of code, no model access.
  • requiresApproval freezes a sensitive sibling action (a card charge, a domain purchase) until a human approves — the API replays it only after approval.
• Move the user to a kit that disables llm and the exact same line returns forbidden, with no code change on your side. Portkey gates which key is used; Naive additionally gates whether execution happens at all, per user, in the same model as every other primitive.

​

Gain #3 — unified accountability

• Every completion for a customer lands in one per-user activity log — alongside their card, email, and vault events, not in a separate LLM dashboard:

const { events } = await naive.forUser(acme.id).logs.query({ limit: 50 });
// "what did this agent do, and what did it spend?" — LLM, cards, email, secrets, one timeline

• Spend is unified too: LLM calls bill the same credits as the agent’s cards and domains (Naive bills OpenRouter’s returned usage.cost × a small markup), so “what did this customer’s agent cost us this month?” is one number, not a reconciliation across Portkey, Stripe, and your own ledger.

​

What does not map yet

​

Where to go next

• /llm primitive — chat, streaming, models, and the drop-in proxy
• LLM API reference — exact request/response shapes
• llm SDK sub-client — typed method signatures
• Credits — how LLM calls are metered and billed
• Account Kits and Approvals — the policy model that makes execution-time governance real
• Tenant users — the identity that the consolidation hangs off

​

Related reading (blog)

• Why consolidate agent infra on one governed identity — migration thesis behind this guide
• Building AI Agents Into Your SaaS — tenant user anchor for every migration
• The Governed Agent Profile — governed LLM routing lifecycle