Example Integration: Using Select.ax With OpenAI-Compatible Tools

Simplify Your AI Stack with One OpenAI-Compatible API

If you're building with AI, you're likely juggling multiple provider accounts, API keys, and pricing pages just to test a few strong models side by side. That creates integration debt fast. One app uses one endpoint, another needs a different SDK config, and soon the team is debugging account setup instead of shipping product.

Select.ax reduces that mess to one OpenAI-compatible endpoint, one API key, and one request shape. For engineers evaluating models such as DeepSeek, Kimi, and Qwen, that's the practical example of integration that matters. Existing code often needs little more than a base URL change and a model swap.

This guide stays narrow on purpose. It shows the fastest way to make a first request, wire Select.ax into OpenAI SDKs, pin a specific model, hand routing to Smart Select, and connect agent tools that already expect the OpenAI API format. It also covers the operational side that teams usually ignore until later, namely usage visibility and spend control through a pay-as-you-go workflow.

Table of Contents

• 1. Your First API Call
  • Reach the endpoint first
  • A copy-paste request
• 2. Integrating with Python and TypeScript OpenAI SDKs
  • Python client setup
  • TypeScript client setup
• 3. Pin Your Model
  • Use direct selection when behaviour matters
  • Example request with a fixed model
• 4. Let Smart Select Route
  • When automatic routing is the better default
  • Smart Select versus a pinned model
  • Example request with smart-select
• 5. Power Your Agents
  • OpenAI-compatible tools usually need config only
  • A practical agent setup pattern
• 6. Track Everything
  • What the dashboard should answer
  • A practical review loop
• 7. Integration Comparison
• Start Building in Minutes

1. Your First API Call

The quickest example of integration is a raw HTTP request. Before wiring SDKs, frameworks, or agent loops, it makes sense to confirm three things first: the key is valid, the network path works, and the response shape matches what the app expects.

Developers often skip this and go straight into application code. That usually slows debugging down. A plain curl request isolates the problem immediately.

Reach the endpoint first

Store the API key in an environment variable instead of hardcoding it into shell history or scripts.

Practical rule: if the first request doesn't work in curl, the SDK won't magically fix it.

A minimal request to /v1/chat/completions looks like this:

curl https://api.select.ax/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SELECT_API_KEY" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {"role": "user", "content": "Reply with a short greeting."}
    ]
  }'

This uses the same general contract developers already know from OpenAI-compatible clients. The main changes are the Select.ax base URL and the model ID from the curated model catalogue.

A copy-paste request

For terminal work, two small changes improve usability right away:

• Format the response: pipe the output to jq so JSON is readable during testing.
• Inspect transport details: add -v to curl when headers or connection behaviour need inspection.
• Keep secrets out of code: export SELECT_API_KEY in the shell profile or secret manager used by the deployment pipeline.

A realistic debug version looks like this:

curl -v https://api.select.ax/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SELECT_API_KEY" \
  -d '{
    "model": "kimi-k2.6",
    "messages": [
      {"role": "system", "content": "Be concise."},
      {"role": "user", "content": "Explain what an OpenAI-compatible API is in one sentence."}
    ]
  }' | jq .

That single command already answers the basic integration question: can the app talk to Select.ax through a standard chat completions call. If yes, the rest is mostly configuration.

2. Integrating with Python and TypeScript OpenAI SDKs

For existing applications, the cleanest example of integration is reusing the OpenAI SDK already in the codebase. Teams don't need a second client abstraction if the endpoint speaks the same API shape. They usually just point the client at a different base URL and supply the Select.ax key.

This matters most in projects that already have prompts, retries, logging, and tool wrappers built around OpenAI-style calls. Rewriting all of that usually isn't worth it.

Python client setup

Python stays straightforward with the official client:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SELECT_API_KEY"],
    base_url=os.environ.get("SELECT_BASE_URL", "https://api.select.ax/v1"),
)

response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "system", "content": "Answer briefly."},
        {"role": "user", "content": "Give one practical use for model routing."},
    ],
)

print(response.choices[0].message.content)

This pattern fits local scripts, backend services, and queue workers. The important detail is keeping the base URL and key in environment variables so staging and production can switch cleanly.

TypeScript client setup

Node and TypeScript follow the same pattern:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.SELECT_API_KEY,
  baseURL: process.env.SELECT_BASE_URL || "https://api.select.ax/v1",
});

async function run() {
  const response = await client.chat.completions.create({
    model: "kimi-k2.6",
    messages: [
      { role: "system", content: "Be direct." },
      { role: "user", content: "Summarise why a single API endpoint simplifies AI integration." }
    ],
  });

  console.log(response.choices[0]?.message?.content);
}

run();

OpenAI-compatible integration works best when the application already treats model choice as configuration, not hardcoded business logic.

Two mistakes show up often:

• Old SDK versions: older package versions may use different client options.
• Hardcoded model IDs: model selection belongs in config when multiple environments or experiments are involved.
• Mixed environment variable names: standardise on one internal naming scheme, then map it once at startup.

3. Pin Your Model

Sometimes automatic routing isn't the right answer. If a team is benchmarking, investigating output drift, or building a workflow that depends on stable model behaviour, direct model selection is the safer example of integration.

Pinned models make tests easier to interpret. When output changes, the team knows it came from prompt logic, application code, or upstream data, not because a router chose a different model.

Use direct selection when behaviour matters

Direct selection is a good fit for three common cases:

• Benchmarking specific prompts: compare the same workload against a fixed model.
• Long-context or reasoning-sensitive flows: keep one known model on a task that has strict behaviour needs.
• Regression checks: lock the model during QA so failures are reproducible.

A request body with an explicit model is enough:

{
  "model": "kimi-k2.6",
  "messages": [
    {"role": "system", "content": "Return structured output."},
    {"role": "user", "content": "Summarise this support ticket and suggest next actions."}
  ]
}

The practical trade-off is simple. Pinned models give predictability, but they also put the burden of model choice on the developer. If the workload changes, someone has to revisit that decision deliberately.

Example request with a fixed model

Here is the same pattern through curl:

curl https://api.select.ax/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SELECT_API_KEY" \
  -d '{
    "model": "kimi-k2.6",
    "messages": [
      {"role": "system", "content": "Be precise and compact."},
      {"role": "user", "content": "Write a two-line release note for an API timeout fix."}
    ]
  }'

Direct model selection is usually the right baseline before enabling router-driven optimisation.

A sensible workflow is to start with one pinned model, measure quality and latency inside the app, then decide whether Smart Select should replace that fixed choice for broader traffic.

4. Let Smart Select Route

A common production pattern looks like this. The same endpoint handles FAQ replies, retrieval-backed answers, rewrite requests, and short drafting tasks. If that traffic all goes through one pinned model, the team usually ends up paying too much for simple work or accepting weaker results on harder prompts.

smart-select is the practical default for that mixed workload. The app sends the task through the OpenAI-compatible Select.ax API, and Select.ax chooses the model for the request. Code stays small, and the routing logic lives outside the application.

When automatic routing is the better default

Use Smart Select when requests vary enough that one fixed model becomes an operational compromise. Internal assistants are a good example. A user may ask for a one-sentence answer in one turn, then ask for a policy summary grounded in retrieved context in the next.

The request body only changes in one place:

{
  "model": "smart-select",
  "messages": [
    {"role": "system", "content": "Answer clearly."},
    {"role": "user", "content": "Draft a short explanation of our refund process for a customer."}
  ]
}

That makes Smart Select a strong example of integration for teams that want one stable API contract while request complexity changes over time.

Smart Select versus a pinned model

The trade-off is straightforward. A pinned model gives tighter repeatability. smart-select reduces model management work and usually fits broader production traffic better.

Pin a model for QA, prompt benchmarking, or any flow where exact behavior matters more than adaptation. Use smart-select for user-facing traffic where latency, cost, and task difficulty shift throughout the day. The key difference is who owns model choice. With a pinned model, the application does. With Smart Select, Select.ax does.

Example request with smart-select

This is the same request over HTTP:

curl https://api.select.ax/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SELECT_API_KEY" \
  -d '{
    "model": "smart-select",
    "messages": [
      {"role": "system", "content": "Respond in plain English."},
      {"role": "user", "content": "Turn these rough notes into a concise customer update."}
    ]
  }'

A sensible rollout is simple. Start by sending a slice of non-critical production traffic to smart-select, log latency and output quality, then expand from there if the routing profile matches the workload.

5. Power Your Agents

Agent tools are often the easiest place to use Select.ax because many already assume an OpenAI-compatible API. Hermes Agent, OpenCode, OpenClaw, and similar clients typically don't need custom adapters if they can read a base URL and API key from environment variables.

That makes this a strong example of integration for indie hackers and platform teams. Existing agent workflows can stay intact while model access moves behind one endpoint.

OpenAI-compatible tools usually need config only

A common setup looks like this:

export OPENAI_API_KEY="$SELECT_API_KEY"
export OPENAI_API_BASE="https://api.select.ax/v1"

Some tools expect OPENAI_BASE_URL instead of OPENAI_API_BASE. Others let users configure the endpoint in a YAML or JSON file. The pattern is the same either way: point the agent at Select.ax and choose either a fixed model or smart-select.

A practical first pass for coding agents is to keep the model pinned. Agents make lots of calls in loops, and fixed model behaviour helps when comparing diffs, retries, or tool-call patterns between runs.

A practical agent setup pattern

This shape works well for many OpenAI-compatible agent clients:

{
  "provider": "openai-compatible",
  "baseURL": "https://api.select.ax/v1",
  "apiKey": "$SELECT_API_KEY",
  "model": "deepseek-v4-flash"
}

Then switch to this when routing should be automatic:

{
  "provider": "openai-compatible",
  "baseURL": "https://api.select.ax/v1",
  "apiKey": "$SELECT_API_KEY",
  "model": "smart-select"
}

Three habits save time with agent integrations:

• Benchmark before routing: run the same task set on one pinned model first.
• Separate task classes: coding, support, and summarisation often deserve different defaults.
• Log model choice in the app layer: if an agent produces a bad action, the team needs enough context to replay it.

Agent integrations fail less often when the tool configuration is kept boring. One endpoint, one key, one known model, then iterate.

6. Track Everything

A lot of integrations look fine in staging and get expensive in production. The first week usually surfaces the key questions. Which feature is driving usage, which requests are failing, and whether Smart Select is choosing what you expected.

Select.ax is easier to operate when the team treats observability as part of the integration, not as cleanup work for later. The dashboard gives one place to check request history, model usage, and spend without stitching together logs from multiple providers.

What the dashboard should answer

After launch, these are the questions that matter:

• Which model served a given request
• Which feature or workflow generated the usage
• Where costs changed after a prompt, model, or traffic shift
• Whether failures are isolated or tied to one route, tool, or prompt pattern

That context helps with day-two work. If a support assistant is cheap and stable but a document workflow starts climbing in cost, the team can pin that path to a smaller model, tighten prompts, or keep Smart Select only where the quality gain is worth it.

A practical review loop

Use a simple operating rhythm:

• Check failed requests from the dashboard first: look for repeated status codes, timeout patterns, or malformed payloads before changing prompts.
• Review usage by feature: cost attribution is much easier when the app tags requests by workflow, such as support, search, or coding-agent.
• Watch for model drift in real traffic: if routed requests start landing on models you did not expect, compare latency, output quality, and per-feature cost.
• Assign credit monitoring to one owner: prepaid usage is easy to manage if someone checks the balance before a busy release window.

If the app does not already attach metadata in its own logs, add it there now. Even a small amount of structure makes debugging faster later. A simple app-log record might look like this:

{
  "feature": "document-summary",
  "environment": "production",
  "customer_tier": "team"
}

Pair dashboard checks with app-level logs. The dashboard is good for spotting patterns across requests. Application logs are better for tying a bad response back to the user action, prompt version, and retry path that produced it.

Teams that do this early spend less time guessing. They can answer why costs moved, replay failures with the right context, and decide where a pinned model is safer than routing.

7. Integration Comparison

By this point, the useful comparison is not a feature matrix. It is choosing the shortest path from a working request to production code without adding extra client libraries or one-off config.

Teams usually land in one of five patterns:

• Use curl first when verifying the API key, base URL, and request shape.
• Use the OpenAI SDKs in Python or TypeScript when the app already depends on them.
• Pin a model when repeatability matters more than automatic routing.
• Use Smart Select when workloads vary and the team wants routing handled at the API layer.
• Point agent frameworks at Select.ax when the agent stack already speaks the OpenAI format.

The trade-offs are straightforward. curl is the fastest way to confirm connectivity, but it stops being practical once retries, structured inputs, and application state enter the picture. OpenAI SDKs give the team a familiar client and cleaner production code, but they still require decisions about model selection and environment setup. Pinning a model gives stable behavior for testing and regressions. Smart Select reduces manual tuning, but the team should still validate routed behavior in staging before trusting it on mixed production traffic.

Agent frameworks sit in a separate category because the integration work is usually smaller than expected. If the framework already supports an OpenAI-compatible endpoint, the job is often just setting the base URL and key, then checking tool calls, streaming, and model-specific behavior under load.

Use the simplest option that matches the job. For a new integration, start with a raw request, move that exact payload into the SDK the application already uses, then decide whether the workload needs a pinned model or routing. That sequence catches config mistakes early and avoids rewriting the same request shape three times.

Start Building in Minutes

The most useful example of integration isn't theoretical. It's the one that gets a request from local machine to production app without adding another mess of credentials, vendor-specific clients, and pricing spreadsheets. This is the advantage of Select.ax. One OpenAI-compatible endpoint can sit behind raw HTTP calls, OpenAI SDKs, agent frameworks, and model routing decisions without forcing the team to rebuild its stack.

The simplest path is still the best one. Start with curl. Confirm the key works and the endpoint responds. Move that exact request shape into Python or TypeScript using the OpenAI client already familiar to the team. After that, choose how much control the application needs.

Direct model selection is the safer default when reproducibility matters. It helps during prompt evaluation, benchmark runs, agent testing, and regressions where a team wants stable behaviour from request to request. For many product workloads, that's the right first production setup.

Smart Select becomes attractive when the app serves mixed workloads and the team doesn't want to continuously retune model choice by hand. That keeps application code simpler and lets routing happen at the API layer. The practical trade-off is straightforward. More convenience means less explicit control over every individual request, so staging and production should be tested with that in mind.

Agent users have one of the easiest migration paths. Hermes Agent, OpenCode, OpenClaw, and other OpenAI-compatible tools usually just need a base URL and key change. That's a strong reason to standardise on one endpoint if the team runs multiple assistants or coding agents in parallel.

The last piece is operational discipline. Usage visibility and transparent pay-as-you-go billing aren't extras. They are part of the integration. Without them, teams can't tell which features are worth the spend or where routing choices need adjustment.

Create an account, buy API credit, and run the first curl request. That is enough to validate the endpoint, test a real model, and decide whether direct selection or Smart Select fits the workload better.

---

Realtime Comms Ltd gives developers a practical OpenAI-compatible path to a curated model catalog, direct model selection, Smart Select routing, and visible pay-as-you-go usage. Create an account, buy API credit, and make a first test request through Select.ax to simplify model access without rebuilding existing tools.