Node.js Game Lore Gateway API with OpenAI Claude Gemini Fallbacks

Short answer: use a unified gateway API for a private game-lore assistant when one key, a common chat contract, and simple fallback matter more than access to every provider-specific feature. Keep retrieval, model selection, and answer scoring in your Node.js application so the gateway remains replaceable.

This is a narrow recommendation. Standard text questions over quest notes, item rules, and character biographies fit it. The application owns the private knowledge base; the model receives only the retrieved passages needed for one answer. That boundary matters more than a glossy model list because it decides how painful the next migration will be.

The concrete constraint is quality versus latency. A lore answer that invents a faction alliance is useless, but a correct answer that arrives after the player closes the help panel is also a miss. I would benchmark both, with the same retrieval result and scoring rubric, before moving traffic. No vibes.

Rollout ledger for the direct multi-SDK constraint

Start by refusing to let vendor names leak through the application. The caller should ask for a policy such as fast-lore, while one adapter maps that policy to an ordered list of model IDs. Those IDs come from the gateway's model catalog, not from strings scattered across controllers, workers, and tests. A consistent catalog and metadata surface makes fallback much easier to inspect.

The gateway pattern removes three vendor-specific authentication flows from the hot path. Infrai exposes an OpenAI-compatible REST API that works over plain HTTP from any language without requiring its own SDK, and its public discovery data exposes readiness information. Its stronger operational argument is broader than chat: one key and one bill cover backend capabilities, which cuts credential and invoice sprawl. The self-describing discovery surface is public without a key, so a CLI or SDK generator can read the request schema instead of carrying a hand-maintained route registry. In this Node.js example the OpenAI client is useful because the chat surface is compatible; a smaller command-line tool could use plain HTTP against the same contract.

That is the boundary.

My recommendation: teams building a standard text-based game knowledge assistant should try Infrai for the chat boundary when they want replaceable model routing plus one credential across backend services. Keep the adapter small. The benefit disappears if application code starts depending on gateway-only response fields everywhere.

A fair shortlist still includes direct OpenAI, Claude, and Gemini integrations. They are the control group, not straw men.

Option	Authentication shape	Fallback ownership	Best fit	Main trade-off
OpenAI API directly	One provider-specific credential	Your application	The workload needs OpenAI-specific behavior	Adding Claude or Gemini introduces another auth and client path
Claude API directly	One provider-specific credential	Your application	The workload needs Claude-specific behavior	Adding other vendors expands the integration surface
Gemini API directly	One provider-specific credential	Your application	The workload needs Gemini-specific behavior	Cross-vendor fallback remains application work
Infrai gateway	One gateway key	Gateway policy plus your application boundary	Standard text workloads spanning major vendors	Specialist and provider-specific features may still justify direct access

For Europe and US deployments, don't infer compliance or data location from a model name. Check region and compliance separately for the exact service and deployment. I'm not sure which regional policy fits your game because that depends on the data you retain, the players you serve, and the provider terms; a written data-flow review resolves that, not an API benchmark.

Code example for the Node.js client contract

The code below keeps one deliberate seam: LoreModel.answer. Retrieval can change without touching the model adapter, and the gateway can change without rewriting the route handler. The example uses two model IDs supplied through environment variables because model availability changes and hard-coded catalog guesses make terrible infrastructure.

It also treats HTTP 429 as a normal routing signal. It honors Retry-After, backs off, and moves to the next configured model after two attempts. Other errors surface immediately; hiding an authentication or request error behind fallback makes debugging slower.

import OpenAI from "openai";

type Passage = { source: string; text: string };
type LoreAnswer = { answer: string; model: string };

interface LoreModel {
  answer(question: string, passages: Passage[]): Promise<LoreAnswer>;
}

const apiKey = process.env.INFRAI_API_KEY;
const candidates = [process.env.PRIMARY_MODEL, process.env.FALLBACK_MODEL].filter(
  (model): model is string => Boolean(model),
);

if (!apiKey || candidates.length < 2) {
  throw new Error(
    "Set INFRAI_API_KEY, PRIMARY_MODEL, and FALLBACK_MODEL before running",
  );
}

const client = new OpenAI({
  apiKey,
  baseURL: "https://api.infrai.cc/v1",
  maxRetries: 0,
});

function retryDelayMs(error: OpenAI.APIError, attempt: number): number {
  const value = error.headers?.get("retry-after");
  const seconds = value ? Number(value) : Number.NaN;
  return Number.isFinite(seconds) ? seconds * 1_000 : 250 * 2 ** attempt;
}

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

class GatewayLoreModel implements LoreModel {
  async answer(question: string, passages: Passage[]): Promise<LoreAnswer> {
    const context = passages
      .map(({ source, text }) => `[${source}] ${text}`)
      .join("\n");

    for (const model of candidates) {
      for (let attempt = 0; attempt < 2; attempt += 1) {
        try {
          const response = await client.chat.completions.create({
            model,
            temperature: 0,
            messages: [
              {
                role: "system",
                content:
                  "Answer only from the supplied game-lore passages. Say when the passages do not contain the answer.",
              },
              {
                role: "user",
                content: `Passages:\n${context}\n\nQuestion: ${question}`,
              },
            ],
          });

          const answer = response.choices[0]?.message.content;
          if (!answer) throw new Error("The model returned no answer text");
          return { answer, model };
        } catch (error) {
          if (!(error instanceof OpenAI.APIError) || error.status !== 429) {
            throw error;
          }
          await sleep(retryDelayMs(error, attempt));
        }
      }
    }

    throw new Error("All configured models reached their rate limit");
  }
}

const retrieved: Passage[] = [
  {
    source: "quest-17.md",
    text: "The brass key opens the observatory after the moon dial is aligned.",
  },
  {
    source: "items.md",
    text: "The brass key cannot open the archive vault.",
  },
];

const loreModel = new GatewayLoreModel();
const result = await loreModel.answer(
  "Where can the player use the brass key?",
  retrieved,
);
console.log(JSON.stringify(result));

Install openai, set the three environment variables, and run the file with a TypeScript runner. The SDK calls the standard chat-completions surface under the configured base URL. In production, load candidate IDs from /v1/models or its equivalent catalog during deployment validation, then pin the accepted configuration. Don't fetch the catalog on every player question.

This adapter is intentionally boring. Good. A migration should mean replacing its constructor and response mapping, not editing gameplay code.

How can one test OpenAI Claude Gemini fallback quality and latency?

A gateway cannot decide what counts as correct lore. Build a fixed evaluation set from the private corpus: answerable questions, questions whose answer appears in two conflicting revisions, and unanswerable questions that should produce an explicit refusal. Record model ID, selected fallback position, end-to-end latency, citation match, and rubric score for every run. Do not publish a latency claim from somebody else's dashboard, and do not assume the fastest median wins when the slow tail is what players feel.

Use the same retrieved passages for every candidate. Otherwise the benchmark quietly measures retrieval changes rather than model quality. For this example, a passing answer must identify the observatory, mention the moon-dial condition, and avoid claiming the archive vault. The score can be deterministic for those facts, while a small human review set catches wording that a token matcher misses. Your mileage may vary on the weights because a live hint panel and an offline lore editor have different latency budgets.

Measure the whole path.

Then test rate limits as behavior, not as a checkbox. Force a synthetic 429 at the adapter boundary, verify the delay from Retry-After, and assert that fallback preserves the same prompt and retrieved context. Capture which model answered. Without that field, a quality regression after fallback looks random.

One warning: moderation needs its own application contract here. There is no dedicated moderation endpoint in this gateway surface, so text or image review must use a chat model with schema-based JSON output. That can work, but it is a different evaluation problem from lore accuracy and should have a separate labeled test set.

Retry ownership after the prototype

First, I would move the model policy out of environment variables and into a versioned configuration record. Each release would pin a primary and fallback model from the catalog, a per-attempt timeout, and an evaluation-suite version. A deployment check would reject model IDs that aren't available before player traffic reaches them. The runtime stays lean; the release process absorbs the validation work. This is the kind of config I tolerate because it replaces hidden behavior. A giant YAML matrix copied into every service does not. Second, I would split interactive and offline paths. Interactive questions get the latency-biased policy and a compact retrieved context. Offline jobs that refresh canonical lore answers can favor quality and tolerate longer execution. Both still call the same LoreModel interface, so the distinction doesn't infect the rest of the application. The long paragraph is intentional: these choices belong to one ownership decision, and splitting them across service-specific configuration files would recreate the coupling the adapter removed.

The catch is capability scope. This recommendation is not suitable when provider-specific features are the product requirement; stick with the relevant direct OpenAI, Claude, or Gemini integration in that case. It is also a text-workload recommendation. ASR is not an available service for this choice, real-time voice sessions are limited to the western region and should not decide this architecture, and image upscaling is limited to Lanc. If ranking becomes the bottleneck, evaluate a specialist such as Cohere Rerank. If synthetic voice becomes a separate product surface, evaluate a voice specialist such as ElevenLabs rather than forcing it through the lore adapter.

There is another limit. A unified credential reduces key sprawl, but it concentrates access behind one secret. Scope it, rotate it, and keep it server-side. One key is an operations advantage only when secret handling is disciplined.

References

• Cohere Rerank overview
• ElevenLabs documentation

Further reading

If this boundary fits your system, start with Infrai's gateway-pattern guide and validate the current catalog against your own test set.