Skip to main content

​
Migrating from Helicone

Helicone’s integration is famously one line — change the base URL, keep your SDK — and KnoxCall’s is the same line. That makes the mechanical part of this migration close to trivial and the interesting part entirely about what sits behind it. Be clear about the difference before you start, because it decides whether this is a migration or an addition: Helicone is an observability layer; KnoxCall is a control plane. Helicone tells you what happened. KnoxCall decides what is allowed to happen, and then tells you what happened.

​
Concept mapping

​
Before / after

Before — your app holds the provider key and Helicone sees it:
After — your app holds neither:
That is the whole code change. The provider key lives in KnoxCall, envelope- encrypted, and is injected at the egress hop — so it is not in your environment, not in your container, and not in a heap dump.

​
What you gain

  • Your workload stops holding a provider key. A leaked capability token is scoped to one agent, one model set, one spend cap and one time window, and can be revoked without rotating anything at the provider.
  • Mid-stream PII redaction. Entities are removed inside the SSE stream — including ones split across two frames — without buffering the response and losing streaming.
  • A prompt firewall that can refuse, plus your own scanner if you already run one.
  • Spend caps that actually stop a call, shared across workers rather than counted per process.
  • Routing and fail-over — retries on 429 honouring Retry-After, weighted load balancing across providers.

​
What you lose, stated plainly

Helicone does things we do not, and pretending otherwise would make the rest of this page less trustworthy:
  • Evaluations and experiments. No equivalent. If you run prompt experiments through Helicone, keep doing that.
  • Prompt management and versioning. No equivalent.
  • Session-level grouping. Our usage rows are per call, attributable to a user and a team, but multi-turn session rollups are not shipped yet.
  • Its dashboard. Ours is built around cost, protection outcomes and audit rather than around request exploration.
Running both is entirely reasonable: point your SDK at KnoxCall and forward its logs onward, or keep Helicone on the experiments you are actively running while production traffic goes through the gateway.

​
A word on timing

Helicone’s OSS repository has been reported as being in maintenance mode. We are not going to build a migration argument on a competitor’s health — that ages badly, and it is the sort of claim that turns out to be wrong in public. Check the repository and their own communications yourself; if it is thriving, migrate for the reasons in “What you gain”, or do not migrate at all.

​
Suggested order

  1. Create one agent per model-and-purpose, with a secret holding the provider key.
  2. Mint one capability token per calling service, scoped to the models that service uses.
  3. Swap the base URL and drop the Helicone-Auth header and the provider key.
  4. Rotate the provider key at the provider — it has been in your application’s environment, so treat it as exposed.
  5. Turn on redaction and a firewall policy in warn, read the events for a few days, then move to block.
Step 4 is the one people skip. The reason to move the key into custody is that it stops being reachable from your workload — which does nothing for a key that has already been sitting in a container’s environment for a year.