ComputeBoard is a single, OpenAI-compatible endpoint that gives you access to every major AI model through one API key. Instead of integrating each provider separately and guessing which model to use, you send one request and our router picks the best model for it in real time — scoring on latency, cost, availability, and performance — then returns an OpenAI-shaped response.

One endpoint. One key. One bill. ComputeBoard sits between your application and the underlying model providers, so you can ship against a stable interface while the routing layer keeps your traffic on the fastest, cheapest, and most reliable model that meets the quality bar for each request.

What is ComputeBoard#

ComputeBoard is an intelligent AI gateway. Every request to https://api.computeboard.xyz/v1/chat/completions is evaluated by a smart router that selects a model on a per-request basis. When you send model: "auto" (the default), the router weighs four criteria for the specific prompt you sent:

• Latency — measured time-to-first-token and total response time across providers, so interactive workloads stay fast.
• Cost — live per-token pricing for each candidate model, used to avoid overpaying for requests that a cheaper model can answer just as well.
• Availability — real-time provider health and capacity, with automatic failover away from rate-limited or degraded endpoints.
• Performance — task-quality signals (reasoning, coding, vision, long-context) that match the prompt to a model strong enough to handle it.

Why ComputeBoard#

• One API for every model — integrate once and reach 37+ models from leading providers without writing a new client for each.
• No vendor lock-in — the interface is the standard OpenAI shape. You can pin a specific model, route to a class, or fall back to direct provider access at any time. Nothing about ComputeBoard is proprietary in your code.
• Automatic savings — by routing cheaper-but-capable models when quality allows, ComputeBoard reduces spend on requests that do not need a frontier model. Each response reports how much you saved versus a fixed-frontier baseline.
• Built-in reliability — when a provider is slow or down, the router fails over to the next-best model instead of surfacing an error to your users.

How it works#

Each request flows through the same path. You send a standard chat completion; the router scores every eligible model against your prompt and current conditions; the winning model serves the request; and you receive an OpenAI-shaped response with a small computeboard metadata block that tells you exactly which model handled it and what it saved.

Drop-in compatible#

ComputeBoard speaks the OpenAI API. If you already use an OpenAI SDK, the only change you need is the base URL and your ComputeBoard key — your existing code keeps working.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY, // ck_live_...5  baseURL: "https://api.computeboard.xyz/v1",                   // the only change vs OpenAI6});7 8const res = await client.chat.completions.create({9  model: "auto",10  messages: [{ role: "user", content: "Hello from ComputeBoard" }],11});12 13console.log(res.choices[0].message.content);

Go from zero to your first routed completion in under five minutes. ComputeBoard is OpenAI-compatible, so you can use the official SDKs and only change the base URL and key.

1npm install openai

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY, // ck_live_...5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const res = await client.chat.completions.create({9  model: "auto",10  messages: [11    { role: "user", content: "Explain what an AI gateway does in one sentence." },12  ],13});14 15console.log(res.choices[0].message.content);16console.log("routed to:", res.computeboard.routed_to);

1{2  "id": "chatcmpl_8x2pQ1vK4mZ",3  "object": "chat.completion",4  "created": 1751212800,5  "model": "claude-haiku-4.5",6  "choices": [7    {8      "index": 0,9      "message": {10        "role": "assistant",11        "content": "An AI gateway is a single API that routes each request to the best available model so you don't have to integrate or choose providers yourself."12      },13      "finish_reason": "stop"14    }15  ],16  "usage": {

Full example#

Prefer to test without an SDK? This single curl command is the complete request — copy it, paste your key, and run it.

1curl https://api.computeboard.xyz/v1/chat/completions \2  -H "Authorization: Bearer ck_live_xxxxxxxxxxxxxxxxxxxxxxxx" \3  -H "Content-Type: application/json" \4  -d '{5    "model": "auto",6    "messages": [7      { "role": "user", "content": "Write a haiku about smart routing." }8    ]9  }'

ComputeBoard authenticates every request with a secret API key passed as a Bearer token. There are no sessions, cookies, or signatures to manage — one header authorizes your call.

API keys#

Authentication uses the standard Authorization: Bearer scheme. Create a key in the dashboard, then send it on every request to https://api.computeboard.xyz/v1. Live keys are prefixed ck_live_. Requests without a valid key are rejected with 401 Unauthorized.

1curl https://api.computeboard.xyz/v1/chat/completions \2  -H "Authorization: Bearer ck_live_xxxxxxxxxxxxxxxxxxxxxxxx" \3  -H "Content-Type: application/json" \4  -d '{5    "model": "auto",6    "messages": [{ "role": "user", "content": "ping" }]7  }'

When you use an OpenAI SDK, the client sets this header for you — just pass your key as apiKey (JavaScript) or api_key (Python) and point baseURL at ComputeBoard.

Keeping keys secure#

An API key is a credential that can spend money and read your usage. Treat it like a password and follow these practices:

• Never expose keys in client code. Browsers, mobile apps, and any shipped frontend can be inspected — a key embedded there is effectively public.
• Call ComputeBoard from your server. Proxy requests through your own backend so the key never leaves an environment you control.
• Load keys from environment variables (for example COMPUTEBOARD_API_KEY) or a secret manager — never hard-code them in source.
• Keep keys out of version control. Add .env files to .gitignore and scan commits for accidental secrets.
• Scope one key per environment. Use separate keys for development, staging, and production so a leak in one place cannot affect the others.
• Rotate regularly, and immediately on any suspected exposure.

Example request#

A complete authenticated request in JavaScript and Python. The key is read from an environment variable so it never appears in your source code.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY, // ck_live_... from your environment5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const res = await client.chat.completions.create({9  model: "auto",10  messages: [{ role: "user", content: "Authenticated request OK?" }],11});12 13console.log(res.choices[0].message.content);

API keys authorize your requests to ComputeBoard. You create, rotate, and revoke them from the dashboard, and you can hold as many as you need — one per service or environment is a good default.

Creating a key#

Open the dashboard and go to API Keys, then click Create key. Give it a descriptive name so you can tell keys apart later (for example web-prod or worker-staging). The full secret is shown once, at creation time — copy it immediately into your secret manager or environment, because ComputeBoard stores only a hashed version and cannot display it again.

1# Live key — shown once at creation, store it securely2ck_live_4f8c2a9d1e7b6034a5c9f12d8e0b7a363 4# Reference it from an environment variable, never inline5export COMPUTEBOARD_API_KEY="ck_live_4f8c2a9d1e7b6034a5c9f12d8e0b7a36"

After creation the dashboard only ever shows the key's prefix (for example ck_live_4f8c…) so you can identify it without revealing the secret.

Revoking a key#

Revoke a key the moment it is no longer needed or you suspect it has leaked. Revocation is immediate and permanent — any request using a revoked key is rejected with 401 Unauthorized.

Rotating keys#

Rotation replaces a key without an interruption in service. Because ComputeBoard lets you hold multiple active keys at once, you can run the old and new keys side by side during the switch — the classic create-deploy-revoke flow, with zero downtime.

Best practices#

• One key per service and environment. Separate keys for each app and for dev, staging, and production limit the blast radius of a leak and make usage easy to attribute.
• Minimize exposure. Keep keys server-side, load them from environment variables or a secret manager, and never embed them in client code, logs, or version control.
• Monitor usage.Watch each key's request volume and last-used time in the dashboard; unexpected activity is an early signal of a leak or a misconfiguration.
• Rotate on a schedule — and immediately on suspicion. Rotate keys periodically as a matter of hygiene, and revoke and replace any key the instant you think it may be exposed.

ComputeBoard speaks to every major model provider through one OpenAI-compatible endpoint. Instead of integrating, billing, and maintaining a separate SDK for each vendor, you call a single API and let the router put your request in front of the right model.

The fastest way to use the catalog is not to pick a model at all. Set model: "auto" and the router scores every healthy candidate on latency, cost, availability, and measured quality for your prompt, then dispatches to the best one — typically in under a millisecond of overhead. Every response tells you exactly which model answered and how much it saved versus a fixed baseline, so you keep full visibility while the platform does the work.

Prefer to stay in control? You can pin any model by its slug, or steer the router with a high-level policy like cheapest, fastest, or best. All four behaviors share the same request and response shape, so switching is a one-line change.

Available models#

These models are routable today. Capabilities such as vision and tool (function) calling are normalized across providers, so the same request works no matter where it lands.

Choosing a model#

The model field on a chat completion request accepts four kinds of values. Three are routing policies that leave the choice to ComputeBoard, and the fourth is a fixed model slug that pins the request to one specific model.

When you pin a slug and that model is temporarily unavailable, the request fails fast with a clear error rather than silently switching models — pinning means you get exactly what you asked for. Policies, by contrast, are designed to route around outages automatically.

Listing models#

Fetch the live catalog at runtime with a standard, OpenAI-shaped list endpoint. The response includes every model slug you can pin, so you can build dynamic model pickers without hard-coding names.

1curl https://api.computeboard.xyz/v1/models \2  -H "Authorization: Bearer ck_live_..."

Chat Completions is the core of the ComputeBoard API. It is fully compatible with the OpenAI Chat Completions schema, so any existing OpenAI SDK or integration works by changing only the base URL and API key. Send a list of messages, get a model reply — and let the router pick the best model for each request.

Every response is the standard OpenAI shape, plus one extra computeboard object that reports which model actually handled the request, the baseline it was compared against, the observed latency, and how much you saved.

Request#

Set model to "auto" to let the router choose, and pass an array of messages. The examples below are identical across transports.

1curl https://api.computeboard.xyz/v1/chat/completions \2  -H "Authorization: Bearer ck_live_..." \3  -H "Content-Type: application/json" \4  -d '{5    "model": "auto",6    "messages": [7      { "role": "user", "content": "Explain quantum entanglement in one sentence." }8    ]9  }'

Parameters#

Response#

A successful request returns a chat completion object. It matches the OpenAI schema field-for-field, with one addition: the computeboard meta object. Note that model reflects the model the router actually chose — here, gpt-4.1.

1{2  "id": "chatcmpl_8f3a1c9e2b",3  "object": "chat.completion",4  "created": 1771200000,5  "model": "gpt-4.1",6  "choices": [7    {8      "index": 0,9      "message": {10        "role": "assistant",11        "content": "Quantum entanglement is when two particles share a single state, so measuring one instantly determines the other no matter how far apart they are."12      },13      "finish_reason": "stop"14    }15  ],16  "usage": {

Response fields#

Examples#

A multi-turn conversation with a system prompt. The system message sets behavior; the remaining messages are the dialogue history.

1const completion = await client.chat.completions.create({2  model: "auto",3  messages: [4    { role: "system", content: "You are a terse assistant. Answer in one line." },5    { role: "user", content: "What is the capital of France?" },6    { role: "assistant", content: "Paris." },7    { role: "user", content: "And its population?" },8  ],9});10 11console.log(completion.choices[0].message.content);12console.log("Handled by:", completion.computeboard.routed_to);

Forcing a routing policy. Here we ask the router to optimize purely for cost with model: "cheapest".

1completion = client.chat.completions.create(2    model="cheapest",3    messages=[4        {"role": "user", "content": "Summarize this changelog in 3 bullet points."},5    ],6    max_tokens=200,7)8 9print(completion.choices[0].message.content)10print("Saved:", completion.computeboard.saved_pct, "%")

Streaming lets you display a model's response as it is generated, token by token, instead of waiting for the full completion. ComputeBoard streams using Server-Sent Events (SSE) in the exact OpenAI chunk format, so the standard SDKs work unchanged — and the first chunk tells you which model the router selected.

Enabling streaming#

Add stream: true to any chat completion request. The connection stays open and the server pushes incremental chunks as the model produces them. With the OpenAI SDK you simply iterate the returned async stream.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const stream = await client.chat.completions.create({9  model: "auto",10  messages: [{ role: "user", content: "Write a haiku about routing." }],11  stream: true,12});13 14for await (const chunk of stream) {15  process.stdout.write(chunk.choices[0]?.delta?.content ?? "");16}

SSE format#

The raw response is a stream of newline-delimited events. Each event is a line beginning with data: followed by a JSON object of type chat.completion.chunk. The text for each step lives in choices[].delta.content. The stream is terminated by a final sentinel line, data: [DONE].

ComputeBoard sends one extra piece of information: the very first chunk carries a computeboard object with routed_to and baseline, so you know which model is answering before the first token arrives.

1curl https://api.computeboard.xyz/v1/chat/completions \2  -H "Authorization: Bearer ck_live_..." \3  -H "Content-Type: application/json" \4  -d '{ "model": "auto", "stream": true, "messages": [{ "role": "user", "content": "Hi" }] }'

Handling chunks#

If you are not using an SDK, read the response body as a stream, split on blank lines, strip the data: prefix, and parse the JSON — stopping when you reach [DONE]. Accumulate delta.content as it arrives.

1const res = await fetch("https://api.computeboard.xyz/v1/chat/completions", {2  method: "POST",3  headers: {4    Authorization: `Bearer ${process.env.COMPUTEBOARD_API_KEY}`,5    "Content-Type": "application/json",6  },7  body: JSON.stringify({8    model: "auto",9    stream: true,10    messages: [{ role: "user", content: "Stream me a sentence." }],11  }),12});13 14const reader = res.body.getReader();15const decoder = new TextDecoder();16let buffer = "";

When to stream#

• Chat UIs— render the assistant's reply progressively so users see words appear instead of a spinner.
• Long outputs — for multi-paragraph answers, code, or documents, streaming avoids a long wall-clock wait for the full payload.
• Lower time-to-first-token — the first visible token arrives far sooner, which makes interactive applications feel dramatically more responsive.

For short, non-interactive calls — classification, extraction, or backend jobs where you only consume the final result — a regular (non-streamed) request is simpler and just as fast end-to-end.

Embeddings turn text into dense numeric vectors that capture meaning, so you can measure how similar two pieces of text are. ComputeBoard's embeddings endpoint will be OpenAI-compatible and routed: you send one request and the router selects the best available embedding model for your input — balancing quality, cost, and dimensionality — without you having to integrate each provider yourself.

Overview#

A single POST /v1/embeddings call will accept one string or an array of strings and return a vector for each. Because the endpoint is OpenAI-shaped, any OpenAI embeddings client will work by only changing the base URL to https://api.computeboard.xyz/v1 and using your ck_live_ key. Set model: "auto" and the router will pick the strongest embedding model that is healthy and cost-effective for your input; you may also pin a specific embedding model by slug when you need stable, reproducible vectors across a corpus.

The router treats embeddings the same way it treats chat: it filters candidates by capability (such as a required output dimension), scores the remainder on latency, cost, and availability, and dispatches to the winner — failing over automatically if a provider is degraded. Each response includes the same computeboard metadata block you get from chat completions, telling you which model produced the vectors.

Planned request & response#

Send your text as input. A single request can embed one string or a batch of strings; batching is the most efficient way to embed a large corpus.

1curl https://api.computeboard.xyz/v1/embeddings \2  -H "Authorization: Bearer ck_live_xxxxxxxxxxxxxxxxxxxxxxxx" \3  -H "Content-Type: application/json" \4  -d '{5    "model": "auto",6    "input": "ComputeBoard routes each request to the best model."7  }'

The data array preserves input order, so data[i].embedding always corresponds to the i-th string you sent. The vector length is reported in computeboard.dimensions; store vectors from a single model together, since vectors from different models are not directly comparable.

Use cases#

• Semantic search — embed your documents and queries, then rank results by cosine similarity instead of brittle keyword matching.
• Retrieval-augmented generation (RAG) — fetch the most relevant chunks for a question and pass them as context to a chat completion, grounding answers in your own data.
• Clustering — group large sets of text by topic or intent for analytics, deduplication, or dataset curation.
• Recommendations — surface similar items, articles, or products by finding the nearest-neighbour vectors to a reference embedding.
• Classification & deduplication — use embedding distance as a fast, cheap signal for near-duplicate detection and lightweight zero-shot labelling.

Image generation turns a text prompt into an image. ComputeBoard's image endpoint will be OpenAI-compatible and routed across the leading image models, so a single request can reach the best generator for your prompt — balancing quality, speed, and cost — through the same key and base URL you already use for chat.

Overview#

A single POST /v1/images/generations call will accept a text prompt and return one or more generated images. The endpoint is OpenAI-shaped, so any OpenAI images client works by changing the base URL to https://api.computeboard.xyz/v1 and using your ck_live_ key. With model: "auto" the router scores the available image models and dispatches to the one best suited to your prompt and requested size; you can also pin a specific image model by slug, or steer with policies like "fastest" for previews and "best" for final renders.

As with every ComputeBoard endpoint, candidates are filtered by capability, scored on latency, cost, and availability, and served with automatic failover. The response carries the standard computeboard metadata block reporting which model produced the image.

Planned request & response#

Provide a prompt, the output size, and how many images to return with n. The response returns a data array of image results.

1curl https://api.computeboard.xyz/v1/images/generations \2  -H "Authorization: Bearer ck_live_xxxxxxxxxxxxxxxxxxxxxxxx" \3  -H "Content-Type: application/json" \4  -d '{5    "model": "auto",6    "prompt": "A neon-pink GPU floating in a dark server room, retro pixel art",7    "size": "1024x1024",8    "n": 19  }'

Each entry in data contains a url to the generated image (downloadable for a limited time after creation). When supported by the chosen model, a revised_prompt shows how the prompt was interpreted. Requesting more than one image with n returns multiple entries in the same array.

Use cases#

• Marketing & social assets — generate on-brand hero images, thumbnails, and ad creatives from a short description.
• Product & concept design — explore visual concepts, mockups, and variations quickly before committing to a direction.
• Illustration & editorial — produce custom artwork for articles, blog posts, and documentation without stock-photo licensing.
• App & game content — create avatars, icons, textures, and placeholder art on demand.
• Personalization — render unique imagery per user, prompt, or campaign at scale.

The Responses API is a higher-level way to call ComputeBoard. Instead of assembling a message array yourself, you send a single input and get back a finished result — with the smart router, tools, and optional server-managed conversation state handled for you. It is compatible with the OpenAI Responses API, so existing Responses clients work by pointing at https://api.computeboard.xyz/v1 with your ck_live_ key.

Overview#

Where Chat Completions is a stateless, message-in / message-out primitive, the Responses API is a stateful, task-oriented layer on top of it. You provide a single input (a string or a structured list), optionally attach tools, and the API runs the request through the router — selecting the best model when model: "auto"— and returns a normalized result. To continue a conversation, pass the previous response's id as previous_response_id and the server reconstructs the context for you; you never have to resend the full history.

Every response includes a flat output_text for the common case where you just want the text, the full structured output array for tool calls and richer content, token usage, and the same computeboard metadata block you get from chat completions — so you always know which model served the request.

Request#

Send your task as input. With model: "auto" the router chooses the best model; you can also use a policy ("cheapest", "fastest", "best") or pin a model slug.

1curl https://api.computeboard.xyz/v1/responses \2  -H "Authorization: Bearer ck_live_xxxxxxxxxxxxxxxxxxxxxxxx" \3  -H "Content-Type: application/json" \4  -d '{5    "model": "auto",6    "input": "Summarize what an AI gateway does in two sentences."7  }'

Response#

The result is normalized: read output_text for the plain answer, or walk the output array when you need to inspect tool calls and message parts. The id is what you pass as previous_response_id on the next turn.

1{2  "id": "resp_8x2pQ1vK4mZ",3  "object": "response",4  "created": 1751212800,5  "model": "claude-sonnet-4.5",6  "output": [7    {8      "type": "message",9      "role": "assistant",10      "content": [11        {12          "type": "output_text",13          "text": "An AI gateway is a single API that sits between your app and many model providers. It routes each request to the best available model, so you integrate once instead of wiring up every provider yourself."14        }15      ]16    }

Chat Completions vs Responses#

Both endpoints run through the same router and return the computeboard meta. The difference is the level of abstraction: Chat Completions is a stateless primitive you control fully, while Responses manages state and orchestration for you.

Routing is the core of ComputeBoard. Every request is evaluated by a smart router that picks the best model for that specific prompt — scoring each candidate on latency, cost, quality, and availability — then serves the result and tells you exactly which model handled it and what it saved. You send one request to one endpoint; the router does the rest.

How routing works#

Each request flows through the same pipeline. You send a standard, OpenAI-shaped request; the router decides which model should serve it; that model responds; and you receive an OpenAI-shaped result with a computeboard metadata block describing the decision.

Scoring#

For every eligible model, the router computes a live score from four signals. The relative weight of each signal shifts with the routing policy — for example "cheapest" weights cost most heavily, while "best" weights quality.

Routing policies#

The model field controls how the router weights those signals. Use a policy keyword to optimize for a goal, or pass an exact model slug to pin one model and bypass routing entirely.

1// Balanced default — let the router decide2{ "model": "auto", "messages": [/* ... */] }3 4// Optimize for cost on bulk / background work5{ "model": "cheapest", "messages": [/* ... */] }6 7// Optimize for latency on interactive UX8{ "model": "fastest", "messages": [/* ... */] }9 10// Optimize for quality on hard reasoning tasks11{ "model": "best", "messages": [/* ... */] }12 13// Pin a specific model — bypass routing14{ "model": "claude-sonnet-4.5", "messages": [/* ... */] }

Savings#

Every routed response reports how much it saved versus always calling a fixed premium model. The computeboard.baseline is that reference frontier model, and saved_pct is the percentage cheaper the routed model was for this request. When the router answers a simple prompt with a small, capable model, the savings are large; when a request genuinely needs a frontier model, the router uses one and saved_pct approaches zero.

1{2  // ...standard OpenAI chat completion fields...3  "model": "claude-haiku-4.5",4  "computeboard": {5    "routed_to": "claude-haiku-4.5",  // the model that served the request6    "baseline": "gpt-5",              // the premium model compared against7    "saved_pct": 92.4                 // % cheaper than the baseline for this request8  }9}

Fallbacks#

Routing is also your reliability layer. The score already accounts for availability, but if the chosen model becomes unavailable, rate-limited, or errors at dispatch time, the router automatically retries with the next-best eligible model — so a single provider outage does not surface as an error to your users.

ComputeBoard uses conventional HTTP status codes to signal the result of a request and returns an OpenAI-style JSON error body on every failure. Codes in the 2xx range indicate success, 4xx codes indicate a problem with your request (and usually contain a message explaining how to fix it), and 5xx codes indicate a transient problem on our side that is generally safe to retry.

Because the error shape matches OpenAI's, existing error-handling code written against the OpenAI SDK works unchanged. Every error includes a human-readable message, a machine-readable type, and a stable code you can branch on.

Error codes#

The table below lists every status code ComputeBoard can return, what it means, and how to resolve it.

Error response shape#

Every error response is a JSON object with a single top-level error key. The HTTP status code and the error.code field always agree, so you can branch on either.

1{2  "error": {3    "message": "Incorrect API key provided. You can find your key in the dashboard.",4    "type": "authentication_error",5    "code": "invalid_api_key"6  }7}

For requests that pass through the router, a unique request identifier is returned in the x-request-id response header. Include it when contacting support — it lets us trace the exact request through the routing pipeline.

Handling errors#

Inspect the HTTP status and the error.code to decide whether to fix the request, re-authenticate, or retry. The OpenAI SDKs throw typed exceptions you can catch directly.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8try {9  const res = await client.chat.completions.create({10    model: "auto",11    messages: [{ role: "user", content: "Hello" }],12  });13  console.log(res.choices[0].message.content);14} catch (err) {15  // The OpenAI SDK surfaces status + the parsed error body.16  if (err.status === 401) {

Rate limits protect the platform and keep latency predictable for everyone. ComputeBoard meters three independent dimensions — requests per minute, tokens per minute, and a monthly token quota — and tells you exactly where you stand on every response through a set of X-RateLimit-* headers.

Limits#

Your account is bound by three limits, evaluated together. Whichever you hit first applies:

Limits scale with your plan. The figures below are representative starting points — your live limits are always shown on the Usage page in the dashboard.

Rate limit headers#

Every response includes headers describing your current limit and remaining budget for the window. Read them to pace your traffic before you hit a 429.

1HTTP/1.1 200 OK2Content-Type: application/json3X-RateLimit-Limit: 6004X-RateLimit-Remaining: 5985X-RateLimit-Reset: 1751212860

Handling 429#

When you exceed a limit, ComputeBoard returns 429 with a rate_limit_error. The correct response is to wait until the reset window and retry with exponential backoff and jitter, so a burst of clients does not all retry at the same instant.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const sleep = (ms) => new Promise((r) => setTimeout(r, ms));9 10async function withBackoff(fn, { retries = 5, base = 500 } = {}) {11  for (let attempt = 0; ; attempt++) {12    try {13      return await fn();14    } catch (err) {15      const retryable = err.status === 429 || err.status >= 500;16      if (!retryable || attempt >= retries) throw err;

ComputeBoard does not need a bespoke SDK. Because the API is OpenAI-compatible, any OpenAI client library — official or community — works out of the box. Install the SDK for your language, point its base_url at https://api.computeboard.xyz/v1, and use a ck_live_ key. That is the only change.

Install#

Install the official OpenAI SDK for your language:

1npm install openai

Usage#

Configure the client with the ComputeBoard base URL and your key, then call chat completions with model: "auto" to let the router choose. The request and response are the standard OpenAI shape.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: "ck_live_xxxxxxxxxxxxxxxxxxxxxxxx",5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const res = await client.chat.completions.create({9  model: "auto",10  messages: [{ role: "user", content: "Hello from ComputeBoard" }],11});12 13console.log(res.choices[0].message.content);

Configuration#

Only these settings differ from a default OpenAI client. Everything else is the SDK default.

Practical, copy-pasteable recipes for common workloads. Every example runs against https://api.computeboard.xyz/v1 with a ck_live_ key and uses the smart router — either "auto" or an explicit class like "best" — so you reach the right model without hard-coding one.

Chatbot#

Hold a multi-turn conversation by sending the full message history each turn. Keep the running array of messages and append the assistant's reply before the next user turn.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8// Conversation state: persists across turns.9const messages = [10  { role: "system", content: "You are a concise, friendly support assistant." },11];12 13async function ask(userText) {14  messages.push({ role: "user", content: userText });15 16  const res = await client.chat.completions.create({

Summarization#

Condense a long document into a few bullet points. Put the instruction in the system message and the source text in the user message; "auto" will pick a long-context model when the input is large.

1from openai import OpenAI2 3client = OpenAI(4    api_key="ck_live_xxxxxxxxxxxxxxxxxxxxxxxx",5    base_url="https://api.computeboard.xyz/v1",6)7 8with open("report.txt", "r", encoding="utf-8") as f:9    document = f.read()10 11res = client.chat.completions.create(12    model="auto",13    messages=[14        {15            "role": "system",16            "content": "Summarize the user's document into 5 concise bullet points. "17                       "Preserve key numbers and names.",18        },19        {"role": "user", "content": document},20    ],21)22 23print(res.choices[0].message.content)

Translation#

Use a system prompt to fix the target language and tone, then pass the text to translate. This keeps the instruction separate from user-supplied content.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8async function translate(text, targetLanguage) {9  const res = await client.chat.completions.create({10    model: "auto",11    messages: [12      {13        role: "system",14        content: `You are a professional translator. Translate the user's text into ${targetLanguage}. ` +15          "Return only the translation, preserving formatting and proper nouns.",16      },17      { role: "user", content: text },18    ],19  });20  return res.choices[0].message.content;21}22 23console.log(await translate("Smart routing keeps your costs low.", "Japanese"));

Coding#

For code generation, route to "best" so the request lands on a frontier coding model. Function and tool calling work exactly as in the OpenAI API.

1from openai import OpenAI2 3client = OpenAI(4    api_key="ck_live_xxxxxxxxxxxxxxxxxxxxxxxx",5    base_url="https://api.computeboard.xyz/v1",6)7 8res = client.chat.completions.create(9    model="best",  # frontier-class for hard code generation10    messages=[11        {12            "role": "system",13            "content": "You are an expert Python engineer. Output a single, complete function "14                       "with type hints and a docstring. No prose.",15        },16        {17            "role": "user",18            "content": "Write a function that merges two sorted lists into one sorted list "19                       "in O(n) time without using sorted().",20        },21    ],22)23 24print(res.choices[0].message.content)

Reasoning#

Hard multi-step problems benefit from a strong model. Route to "best" and ask the model to work through the problem before giving the final answer.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const res = await client.chat.completions.create({9  model: "best", // route to a frontier reasoning model10  messages: [11    {12      role: "user",13      content:14        "A train leaves City A at 9:00 traveling 60 km/h. Another leaves City B, " +15        "300 km away, at 9:30 traveling 90 km/h toward A. At what clock time do they meet? " +16        "Reason step by step, then give the final time on its own line.",17    },18  ],19});20 21console.log(res.choices[0].message.content);

Vision#

Send an image alongside text by using the structured content array with an image_url part. The router selects a vision-capable model automatically; only models that support images will be considered.

1import OpenAI from "openai";2 3const client = new OpenAI({4  apiKey: process.env.COMPUTEBOARD_API_KEY,5  baseURL: "https://api.computeboard.xyz/v1",6});7 8const res = await client.chat.completions.create({9  model: "auto", // router restricts to vision-capable models for image input10  messages: [11    {12      role: "user",13      content: [14        { type: "text", text: "What's in this image? Describe it in one sentence." },15        {16          type: "image_url",

Webhooks let ComputeBoard push events to your server the moment they happen — usage thresholds, key lifecycle changes, and completed requests — so you can react without polling. This feature is in active development and is not yet available.

Overview#

Once available, you will register one or more endpoint URLs in the dashboard and subscribe each to the event types you care about. ComputeBoard will deliver a signed JSON payload over HTTPS for every matching event. Planned event types include:

• usage.threshold — fired when your spend or token usage crosses a configured percentage of your monthly quota (for example 75% or 90%), so you can alert or throttle before hitting the cap.
• key.created — fired when a new API key is created on the account, for audit and security automation.
• request.completed — fired after a completion finishes, carrying routing and usage metadata (which model served it, tokens, latency, and savings) for downstream analytics.

Planned payload#

Each delivery will be a JSON object with a stable envelope — an event id, type, created timestamp, and a data object whose contents depend on the event type.

1{2  "id": "evt_3sK1pZ9aVbN",3  "type": "request.completed",4  "created": 1751212800,5  "data": {6    "request_id": "chatcmpl_8x2pQ1vK4mZ",7    "routed_to": "claude-haiku-4.5",8    "baseline": "gpt-5",9    "saved_pct": 92.4,10    "usage": {11      "prompt_tokens": 18,12      "completion_tokens": 31,13      "total_tokens": 4914    },15    "latency_ms": 41216  }17}

Verifying signatures#

Every delivery will be signed so you can confirm it genuinely came from ComputeBoard and was not tampered with. The plan is an HMAC-SHA256 signature of the raw request body, keyed with your endpoint's signing secret and sent in an X-ComputeBoard-Signature header. Verify it by recomputing the HMAC over the exact bytes you received and comparing with a constant-time check before trusting the payload.

1import crypto from "node:crypto";2 3// Planned verification — header and algorithm subject to change before launch.4function verifyWebhook(rawBody, signatureHeader, signingSecret) {5  const expected = crypto6    .createHmac("sha256", signingSecret)7    .update(rawBody, "utf8")8    .digest("hex");9 10  // constant-time comparison guards against timing attacks11  const a = Buffer.from(signatureHeader);12  const b = Buffer.from(expected);13  return a.length === b.length && crypto.timingSafeEqual(a, b);14}15 16// In an Express handler, use the RAW body (not the parsed JSON):17//   const ok = verifyWebhook(req.rawBody, req.header("X-ComputeBoard-Signature"), SECRET);18//   if (!ok) return res.status(400).send("invalid signature");

Answers to the questions we hear most often about ComputeBoard — compatibility, routing, pricing, privacy, and the feature surface. If something is not covered here, reach out from the dashboard.

Is it really OpenAI-compatible?#

Yes. ComputeBoard implements the OpenAI Chat Completions API exactly, including streaming, function and tool calling, and the standard request and response objects. You use the official OpenAI SDKs unchanged — the only difference is the base URL (https://api.computeboard.xyz/v1) and your ck_live_ key. The one addition is a small computeboard object on each response describing how the request was routed; it is purely additive and safe to ignore.

How does routing pick a model?#

When you send model: "auto", the router first filters to models that can actually serve the request — matching required capabilities like vision, tool calling, and context length — then scores each candidate on four live signals: latency, cost, availability, and performance for the task. The highest-scoring healthy model wins. You can also bias the decision with the class shortcuts "cheapest", "fastest", or "best".

Can I pin a specific model?#

Absolutely. Pass an exact model slug (for example claude-haiku-4.5 or gpt-5) as the model parameter and ComputeBoard sends the request straight to that model with no routing. This is useful when you need deterministic behavior, reproducibility, or a model with a specific capability. You can mix pinned and routed requests freely.

How much can I save?#

It depends on your traffic. Many requests do not need a frontier model, and routing those to a cheaper-but-capable model can cut spend dramatically — often 50–90% on the eligible portion of traffic. Each response reports a saved_pct versus a fixed-frontier baseline, and the dashboard aggregates total savings over time so you can measure the real number for your workload rather than rely on an estimate.

Do you store my prompts or data?#

ComputeBoard does not train on your data or sell it. Prompts and completions are processed to serve the request and to compute usage and routing metadata; we retain only what is needed to operate the service, meter billing, and provide analytics. We do not use your content to improve models. Enterprise plans support custom retention and data-handling terms.

What about latency overhead?#

The routing decision is computed from pre-aggregated, continuously updated signals, so it adds only a few milliseconds before dispatch — negligible next to model inference time. In practice ComputeBoard often reduces end-to-end latency, because it steers around slow or degraded providers and can prefer a faster model when you route with "fastest" or "auto".

Which SDKs work?#

Any OpenAI-compatible client. That includes the official OpenAI SDKs for JavaScript/TypeScript, Python, Go, and Rust (via community libraries such as async-openai), plus frameworks like LangChain, LlamaIndex, and the Vercel AI SDK that accept a custom base URL. If a tool can talk to OpenAI, it can talk to ComputeBoard.

How are tokens and billing counted?#

Billing is metered on prompt and completion tokens, the same usage object the OpenAI API returns. Because routing may select a cheaper model, your effective cost per request is frequently lower than always using a frontier model. Every response includes a usage block, and the dashboard shows per-day, per-model, and per-key breakdowns so you can attribute spend precisely.

What happens if a model is down?#

The router tracks provider health in real time. If a model is rate-limited, slow, or unavailable, it is scored down or excluded, and the request automatically fails over to the next-best healthy model instead of returning an error. This built-in redundancy is one of the main reasons teams put ComputeBoard in front of their model calls.

Do you support streaming, function calling, and vision?#

Yes to all three. Streaming works via Server-Sent Events exactly as in the OpenAI API (set stream: true). Function and tool calling are passed through to any model that supports them. Vision works by sending image content parts; the router restricts the candidate set to vision-capable models for those requests.

How do rate limits work?#

Each account has a requests-per-minute (RPM) limit, a tokens-per-minute (TPM) limit, and a monthly token quota, all scaled by your plan. Every response carries X-RateLimit-* headers so you can pace traffic, and exceeding a limit returns a 429 you should retry with backoff. See the Rate Limits page for details.

Is there a free tier?#

Yes. The Free plan lets you try ComputeBoard with a modest RPM/TPM and a monthly token allowance — enough to integrate, test routing, and validate savings before you upgrade. When you need higher limits, the Pro and Enterprise plans raise your RPM, TPM, and quota.

Notable changes to the ComputeBoard API and platform. We follow semantic versioning for the API surface and announce backward-incompatible changes here in advance.

v1.0.0 — Initial Release June 29, 2026#

The first public release of ComputeBoard: one OpenAI-compatible endpoint, intelligent routing across every major model, and a full dashboard. Live at https://api.computeboard.xyz.

• OpenAI-compatible Chat Completions — POST /v1/chat/completions with the standard request and response shape, plus Server-Sent Events streaming via stream: true.
• Smart routing — send model: "auto" to route per request on latency, cost, availability, and performance, or use the class shortcuts "cheapest", "fastest", and "best".
• 8+ models — frontier and efficient models from leading providers, all reachable through one key, with automatic failover when a provider is degraded.
• API keys & dashboard — create, name, rotate, and revoke ck_live_ keys; manage everything from the web dashboard.
• Usage analytics — per-day, per-model, and per-key token and cost breakdowns, plus realized savings versus a fixed-frontier baseline.
• GPU marketplace — the foundation for renting and offering compute capacity that backs the routing network.

Coming soon#

On the near-term roadmap. Dates are not yet committed; follow this page for announcements.

• Embeddings — POST /v1/embeddings for vector search and retrieval.
• Image Generation — text-to-image through the same routed endpoint.
• Responses API (GA) — the stateful Responses interface promoted to general availability.
• Webhooks — push events for usage thresholds, key lifecycle, and completed requests.
• More models & SDKs — an expanding model catalog and first-class SDK helpers.