Migrating from Helicone

Helicone is great at observability, with caching and rate limits as features layered in. prxy.monster’s emphasis is composability — modules first, observability emerges from the metadata they emit.

What’s the same

• Drop-in BASE_URL gateway.
• Caching at the gateway layer.
• Rate limiting per-key.
• BYOK-friendly.

What’s different

Diff: env vars

- OPENAI_BASE_URL=https://oai.helicone.ai/v1
- OPENAI_API_KEY=sk-xxx
- # Plus header: Helicone-Auth: Bearer sk-helicone-xxx
+ OPENAI_BASE_URL=https://api.prxy.monster/v1
+ OPENAI_API_KEY=prxy_live_xxx
+ # No additional headers required.

For Anthropic:

- ANTHROPIC_BASE_URL=https://anthropic.helicone.ai
+ ANTHROPIC_BASE_URL=https://api.prxy.monster

Mapping Helicone caching

Helicone caching:

Helicone-Cache-Enabled: true
Helicone-Cache-Bucket-Max-Size: 100

Equivalent in prxy.monster:

pipeline:
  - semantic-cache:
      similarity: 0.85
      ttlSeconds: 3600

Or via per-request header:

curl ... -H "x-prxy-pipe: semantic-cache,patterns"

Mapping Helicone properties + sessions

Helicone tags requests with custom properties for filtering. prxy.monster doesn’t have a dedicated property system in v1 — but you can:

1. Pass properties in the request metadata field (Anthropic + OpenAI both support it).
2. Build a custom module that reads ctx.request.metadata and writes to your DB / metrics backend.

Example:

async post(ctx) {
  await ctx.storage.db.from('events').insert({
    user_id: ctx.apiKey.userId,
    properties: ctx.request.metadata,
    duration_ms: ctx.durationMs,
    input_tokens: ctx.response.usage.inputTokens,
    output_tokens: ctx.response.usage.outputTokens,
  });
}

What you gain

• Cost guards — hard daily/monthly caps that block requests, not just alert.
• Persistent memory — patterns doesn’t just log; it learns and injects.
• Local mode — first-class Docker container, no separate self-hosting setup.
• Per-request pipeline override — x-prxy-pipe header for A/B testing modules in production.

What you lose (and the workaround)