Build with HyperQwen

Connect your application to HyperQwen, a text model served through an OpenAI-compatible API. Use your existing OpenAI client with a different base URL and model name.

Just want to use it?

Open the chat and connect with the API key provided by your team administrator. Your key and conversation stay in this tab’s memory. Export the conversation before reloading if you want to keep it. Prompts and responses are sent to the model server for processing.

Building with an AI coding assistant? Give it the agent integration guide or the compact API reference. Both have plain Markdown versions you can copy or download. Documentation is public; inference requires a key.

Your first request

Get a key from your team administrator and set OPENAI_API_KEY in your application's secret environment. Keep it out of source control and frontend bundles.

export OPENAI_BASE_URL='https://qwenjon.voicelabs.uz/v1'
# Set OPENAI_API_KEY securely in your environment before running this.
curl --fail-with-body "$OPENAI_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3.8-27b",
    "messages": [{"role": "user", "content": "Salom! Introduce yourself briefly."}],
    "max_tokens": 1024
  }'

Read the answer from choices[0].message.content. Reasoning consumes part of the output budget, so allow enough tokens for both reasoning and the answer. finish_reason: "length" means the budget was reached.

Python

Install the official client with pip install openai. It reads OPENAI_API_KEY from the environment.

from openai import OpenAI

client = OpenAI(
    base_url="https://qwenjon.voicelabs.uz/v1",
    timeout=180,
    max_retries=0,
)
reply = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Explain webhooks in three sentences."}],
    max_tokens=2048,
)
print(reply.choices[0].message.content)

JavaScript / TypeScript

Install openai with your package manager. Run this on your application's backend, where environment secrets are available.

import OpenAI from 'openai';

const client = new OpenAI({
  baseURL: 'https://qwenjon.voicelabs.uz/v1',
  apiKey: process.env.OPENAI_API_KEY,
  timeout: 180_000,
  maxRetries: 0,
});
const reply = await client.chat.completions.create({
  model: 'qwen3.8-27b',
  messages: [{ role: 'user', content: 'Explain webhooks in three sentences.' }],
  max_tokens: 2048,
});
console.log(reply.choices[0].message.content);

A website or mobile application should call its own authenticated backend. That backend holds the team key and calls qwenjon. The standalone chat here is a bring-your-own-key client, not a template for embedding a shared key in a public app.

Streaming and reasoning

Use stream: true for server-sent events (SSE). The server sends data: {JSON} events and finishes with data: [DONE]. A network chunk may contain part of an event or several events. Parse event boundaries before parsing JSON.

stream = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Suggest three small automation projects."}],
    max_tokens=2048,
    stream=True,
    stream_options={"include_usage": True},
)
with stream:
    for event in stream:
        if event.usage:
            print("\nUsage:", event.usage.model_dump())
        if not event.choices:
            continue
        delta = event.choices[0].delta
        reasoning = getattr(delta, "reasoning", None)
        if reasoning:
            pass  # Optional: show in a separate, collapsible reasoning view.
        if delta.content:
            print(delta.content, end="", flush=True)

The deployed server uses delta.reasoning for reasoning and delta.content for the answer. Some clients/providers use reasoning_content; a portable client can accept either. Do not send the reasoning trace as an assistant answer in the next turn. Send the final answer as content.

The final usage event can have an empty choices array. completion_tokens includes reasoning; completion_tokens_details.reasoning_tokens is its reasoning portion. For live counts, the server also accepts stream_options: {"include_usage": true, "continuous_usage_stats": true}. Count server tokens, not SSE events.

Reasoning effort can be set through this vLLM extension:

reply = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Check this plan for missing steps."}],
    max_tokens=4096,
    extra_body={"chat_template_kwargs": {
        "enable_thinking": True,
        "reasoning_effort": "medium"  # low, medium, or xhigh
    }},
)

Higher effort can take longer and consume more output tokens. Low effort is the default. The chat reports time to the first answer (including any reasoning and queue time), total duration, actual token usage, and answer throughput when more than one answer chunk can be measured. These are per-request observations, not guaranteed server performance.

Reliable JSON

Use a strict JSON schema for machine-readable output, then validate the result in your application. Asking for JSON only in the prompt is not a reliable contract.

import json

reply = client.chat.completions.create(
    model="qwen3.8-27b",
    messages=[{"role": "user", "content": "Return status ok and count 3."}],
    max_tokens=1024,
    response_format={"type": "json_schema", "json_schema": {
        "name": "status_check",
        "strict": True,
        "schema": {
            "type": "object",
            "properties": {
                "status": {"type": "string", "enum": ["ok"]},
                "count": {"type": "integer", "enum": [3]},
            },
            "required": ["status", "count"],
            "additionalProperties": False,
        },
    }},
)
result = json.loads(reply.choices[0].message.content)

Tools and agent workflows

Chat Completions accepts function tools and tool_choice: "auto". The model proposes a function name and JSON arguments. Your application validates the proposal, performs the permitted action, and returns a role: "tool" message with the matching tool_call_id. The model server does not execute tools or grant access to your systems.

See the agent guide for a complete bounded tool loop and a copyable integration prompt.

Supported API routes

response = client.responses.create(
    model="qwen3.8-27b",
    input="Suggest a name for a tiny gardening app.",
    max_output_tokens=1024,
    store=False,
)
print(response.output_text)

This is OpenAI-compatible inference, not the full OpenAI platform. Stored response retrieval/cancellation, hosted tools, files, embeddings, vision, audio, fine-tuning, and administration routes are not exposed. For a conversation with Responses, manage history in your application; do not depend on stored response IDs. Use Chat Completions for the examples in these docs.

Limits and errors

The gateway permits 2 requests/second per IP with a burst of 20, up to 8 concurrent generation requests per IP and 16 across the hostname. People behind one network share the IP limits. The model admits up to 8 sequences; longer contexts and queued work affect latency. These limits are ceilings, not a throughput guarantee.

The upstream read timeout is 600 seconds between reads. Choose a client timeout and cancellation behavior suited to your application. Use streaming for long generations. Never blindly replay a partially completed stream or a tool with side effects. An interrupted request may already have consumed model work.

Security and privacy

Use HTTPS, keep the team credential on your backend, and redact it from logs. This deployment uses a shared team credential; individual user accounts, quotas, and billing are not provided. Add your own application authentication and authorization before opening an integration to end users. Cross-origin browser access is not enabled.

Gateway access logs record request metadata, not authorization headers, query strings, or request bodies. This is not a zero-retention guarantee for the complete model hosting stack. Follow your team's data policy for sensitive content. Model output is untrusted: validate structured results, sanitize rendered Markdown, and require appropriate approval before consequential tool actions.

Copy for your assistant

• Compact model/API reference · Markdown
• Agent integration guide · Markdown
• This guide as Markdown
• Machine-readable API description