Cloudflare AI Gateway alternatives: routing, payments and app margin

Compare Cloudflare AI Gateway alternatives by the request path and payment relationship you want to change. OpenRouter, LiteLLM, Portkey and Kong address selected model-access, gateway or monetization requirements. ShareAI concerns an existing app routing eligible inference through an approved Builder arrangement, with an allowed app surcharge and attributed earnings. These are different responsibilities, even when several options expose a compatible model API.

Reviewed 23 October 2026. ShareAI publishes this comparison and operates one program discussed. Product facts come from current official references, with actual source screenshots. The executed code is an offline synthetic ledger. No live gateway migration, stablecoin payment, customer charge, endpoint qualification or performance benchmark was performed.

Cloudflare already documents unified billing, provider keys, custom HTTPS providers and a beta machine-payment path. A comparison that assumes it only forwards requests paid through an app owner’s provider account misses current scope. Start with the actual credential, credit and payment configuration, then evaluate any missing application commercial journey.

What current Cloudflare AI Gateway already supports

The unified billing reference describes prepaid credits for eligible model access and a 5% credit-purchase fee, with provider inference rates passed through. That purchase fee and a downstream app surcharge are different charges. Reasons to keep it: evaluate the current gateway when its model-access and operational controls already fit the app’s deployed architecture and payment requirements.

The custom-provider documentation explicitly covers HTTPS endpoints, including self-hosted model examples. The unified compatibility path requires the documented chat-completions format; the provider-specific path supports its own request structure and appended URL path. Supplying your own endpoint is therefore not an exclusive ShareAI distinction. Compare the actual authentication, path mapping and accepted onboarding of the selected implementation.

The machine payments reference describes a beta path using a stablecoin wallet for selected open models. Current requirements include a US-based account and a credit card on file. Its supported request and payment-negotiation path is narrower than all gateway traffic. Do not turn that documented capability into a claim that every application user or provider automatically receives the same payment journey.

An AI code-review app needs an explainable payer for every request

Consider a hypothetical code-review app with existing business customers. It uses a stored production provider key, a different key alias for experimentation, a custom HTTPS model and cached responses. Product wants to offer customer-paid inference with an app margin. Finance needs to know whether each delivered review consumed provider credit, gateway credit or another supported payment authorization.

A model label and cost tag are insufficient evidence. The app must distinguish a logical review from repeated attempts, identify the credential actually used and preserve whether the response came from cache. A retry can still create provider usage. A cached response can be delivered without the same upstream activity. Customer pricing needs an explicit policy for both cases rather than blindly copying a displayed request cost.

The scenario also needs an exception path. A production key expires while a different stored alias remains valid. The gateway successfully returns a review using another funding source. That is operationally useful, but finance can still receive an unexpected bill. Compare credential priority and fallback funding before concluding that a successful response means the intended customer or account paid.

Choose the responsibility you want an alternative to own

An app can retain Cloudflare components while evaluating another inference or commercial path. That requires a real integration and a clear customer explanation. No automatic synchronization, native connector or shared wallet among the products is implied. Each charged request needs an accountable owner for admission, retries, corrections and payment.

Trace the review from admission to received money

Keep those observations linked without treating them as interchangeable. A tag can attribute cost to a workspace without authorizing a price change. A dashboard can display a margin without collecting it. A payment authorization can precede final settlement. Product, support and finance should be able to explain the same logical review and its explicit adjustments.

OpenRouter: compare managed access and user-funded inference

The OpenRouter quickstart describes managed access across model providers. Its OAuth guide explicitly lets users authorize an app with a user-controlled key and pay requests from their own OpenRouter credits. Pros: compare that supported journey when the code-review app wants customers to fund their own inference rather than charge every request to the app owner.

Tradeoffs: qualify user authorization, key handling, allowed providers, fallback funding and current account terms. The app-attribution reference describes association with usage and rankings. That documented association alone does not establish an app surcharge or a received settlement. User-paid inference is not unique to ShareAI; compare the complete approved commercial arrangement.

For the code-review customer, rehearse a user disconnect, an exhausted allowance and a model whose provider changes. Preserve the user and app identity without sending a server credential to the browser. Verify the actual paying account and any separately agreed application price. A successful model response does not by itself prove an app earned money.

LiteLLM: compare custom prices and internal billing margins

The LiteLLM custom-pricing reference documents model costs, provider discounts and provider margins for internal billing. Pros: compare those existing controls when the code-review app wants to evaluate its own cost mapping and charge allocation. A claim that every other gateway lacks margins would ignore this documented scope.

Tradeoffs: qualify the selected deployment, pricing lookup, budgets and collection workflow. The current reference notes that explicitly zero input and output costs bypass budget checks, including key and team scopes. It also explains pricing-provider mapping when routing and pricing providers differ. A displayed zero therefore needs investigation rather than an assumption that the workload is free.

For the custom review model, inspect a known nonzero request and its configured price before enabling the production budget policy. Compare original provider cost, an internal allocated amount and the customer’s accepted commercial price separately. A correct internal margin calculation does not supply the surrounding app checkout, customer agreement or financial release conditions.

Portkey: compare gateway controls and observability

The current Portkey documentation describes gateway, observability, guardrail and administration capabilities, with separate deployment and feature references. Pros: compare the selected scope when code-review teams need to understand model traffic and apply gateway controls. Evaluate the actual product and deployment rather than infer every commercial feature from a model-count headline.

Tradeoffs: qualify the exact edition, hosting, routing policy, retained data and payment ownership. A trace and a spend control address different questions from receiving a customer payment. Likewise, a self-hosting reference does not automatically establish that every managed dashboard, enterprise feature or support obligation is included in a chosen deployment.

For the review app, compare the failed provider attempt, fallback response and cached result as separate observations within the same logical job. Preserve trusted customer attribution and the actual error shown to the app. The useful outcome is an explainable delivered review with its real funding and commercial treatment, rather than a successful request count alone.

Kong: compare gateway policy with metering and billing

The Kong AI monetization page describes a broader gateway and monetization path. Its current entitlement reference connects managed rate-card entitlements with separate gateway enforcement. Pros: evaluate the selected services when the review app wants gateway policy and usage commercialization considered together.

Tradeoffs: qualify service and deployment compatibility, actual policy enforcement, metering and the collection integration. A gateway on company infrastructure is a different architectural fact from the location of its managed billing service. Avoid comparing an entire product family with one proxy endpoint or assuming every hosted capability is included in an on-premises gateway.

For the review customer, inspect how a purchased right becomes an actual runtime decision and how failed or repeated reviews reach the commercial record. Preserve the selected rule at its effective time. A balance and an enforcement plugin can both exist while the app still needs to qualify their complete integration and explain financial corrections.

ShareAI: compare an approved app surcharge and settlement

The ShareAI Builder Program concerns an app that already exists with its own users. Eligible AI traffic routes through ShareAI, the Builder configures a permitted surcharge or margin, and the end customer pays ShareAI for that inference. App-attributed earnings follow the program. Pros: evaluate this arrangement when the review app wants an approved inference payment and attribution journey.

Tradeoffs: app approval, eligible traffic, model access and account terms matter. Validated company Builders have a 45-day review period before payout. Individuals currently accumulate inference value for ShareAI use, without cash-out or account transfers. The app remains built, hosted, distributed and maintained elsewhere. Other subscriptions, support delivery and financial duties remain explicit responsibilities.

Providing model infrastructure or a custom endpoint belongs to applicable Provider or Prosumer onboarding, separately from Builder attribution. Cloudflare custom providers and other gateways already address endpoint control. Compare actual acceptance, routing, payer and settlement rather than claim exclusivity. ShareAI does not establish a native machine-payment protocol, a general merchant-of-record service or a replacement for every gateway policy.

Credential priority can change which account funds a request

The unified billing guide gives credential priority to a request provider key, then a stored default provider alias, then eligible unified-billing credit. Nondefault stored aliases are not used by that unified path. The BYOK reference describes the separate stored-key and alias configuration. A key that exists in the account is therefore not proof that a particular request uses it.

For the review app, verify the chosen path when the production key is missing or fails. Documented controls can require provider credentials or prevent eligible third-party unified-billing fallback; Workers AI has a separate mode. Review the exact configuration and provider coverage. Also distinguish a provider’s zero-retention policy from the gateway’s own logging configuration, which needs its own explicit decision.

Custom cost, negotiated payment and an app price differ

The custom-cost reference describes input, output and cache-token rate mapping, including provider-specific token formats and zero recorded cost for gateway cache hits. Those analytics do not by themselves establish an accepted downstream resale price. Preserve the actual upstream charge, customer policy and correction instead of assuming a displayed cost is a paid invoice.

The beta machine-payment path requires explicit payment-method negotiation and supports a defined request endpoint and model set. Its maximum signed authorization differs from the actual amount settled. Compare those documented requirements before recommending it to the review app. No stablecoin transaction or compatibility with ShareAI was tested or implied here.

For arithmetic only, 1000 USD of inference plus a hypothetical 15% surcharge produces 150 USD gross surcharge and 1150 USD total. These synthetic amounts are not Cloudflare or ShareAI fees, received earnings, net profit or a tax result. Actual credit-purchase fees, refunds, corrections and eligibility affect the business outcome.

Check the arithmetic without confusing it with payment

The executed fixture below deduplicates identical activity, rejects a conflicting duplicate and records an explicit adjustment using integer USD cents. It does not select a provider key, submit a review, authorize a wallet or collect a payment. Those outcomes require real application and commercial evidence around the calculation.

import assert from "node:assert/strict";
const records = [
  {id: "usage-a", customer: "demo", cents: 60000n, kind: "usage"},
  {id: "usage-b", customer: "demo", cents: 50000n, kind: "usage"},
  {id: "usage-a", customer: "demo", cents: 60000n, kind: "usage"},
  {id: "adjustment-b", customer: "demo", cents: -10000n, kind: "adjustment"}
];
function netCents(rows) {
  const seen = new Map();
  let total = 0n;
  for (const row of rows) {
    assert.equal(row.customer, "demo");
    const fingerprint = [row.customer, row.cents.toString(), row.kind].join("|");
    if (seen.has(row.id)) {
      if (seen.get(row.id) !== fingerprint) throw new Error("Conflicting duplicate");
      continue;
    }
    if (row.cents < 0n && row.kind !== "adjustment") throw new Error("Invalid sign");
    seen.set(row.id, fingerprint);
    total += row.cents;
  }
  return total;
}
const base = netCents(records);
assert.equal(base, 100000n);
assert.throws(() => netCents([...records,
  {id: "usage-a", customer: "demo", cents: 1n, kind: "usage"}
]));
const numerator = base * 1500n; // Hypothetical 15 percent in basis points.
if (numerator % 10000n !== 0n) throw new Error("Define contractual rounding first");
const surcharge = numerator / 10000n;
assert.equal(surcharge, 15000n);
const usd = cents => `${cents / 100n}.${(cents % 100n).toString().padStart(2, "0")}`;
console.log(JSON.stringify({baseUSD: usd(base), grossSurchargeUSD: usd(surcharge),
  totalUSD: usd(base + surcharge), paidReceiptVerified: false}));

Observed output is 1000 USD illustrative inference, 150 USD gross surcharge and 1150 USD total, with no verified paid receipt. Preserve logical review identity, actual attempts, funding and explicit corrections in production. A correct sum cannot establish which account paid or when attributed value becomes available.

Move one review workflow with its funding exception first

• Inventory actual gateway controls, credentials, providers and customer prices.
• Select the inference, gateway or commercial responsibility that needs to change.
• Preserve trusted customer and logical-review identity across retries and cache hits.
• Rehearse missing credentials, fallback funding and an explicit correction.
• Verify actual payment evidence without duplicate live collection.
• Retain original records and rollback until the complete customer journey is qualified.

Keep Cloudflare when the current arrangement fits. Compare the selected alternatives by an explainable request, accepted customer charge and actual settlement. Begin with one review whose admission, routing, useful delivery and financial exception can be explained consistently by product, support and finance.

Frequently asked questions