# 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.

| Setting | Value |
| --- | --- |
| Base URL | `https://qwenjon.voicelabs.uz/v1` |
| Model | `qwen3.8-27b` |
| Authorization | `Bearer YOUR_API_KEY` |
| Context | 65,536 tokens, including input and output |
| Default reasoning | Enabled, low effort |

## 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](/v1/docs/agents) or the [compact API reference](/v1/docs/llms). 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.

```bash
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.

```python
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.

```javascript
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.

```python
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:

```python
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.

```python
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](/v1/docs/agents) for a complete bounded tool loop and a copyable integration prompt.

## Supported API routes

| Method | Route | Purpose |
| --- | --- | --- |
| GET | `/v1` | Public API directory and documentation links |
| GET | `/v1/models` | Authenticated model discovery |
| POST | `/v1/chat/completions` | Chat, streaming, JSON schema, function tools |
| POST | `/v1/responses` | Responses creation; use `store: false` |
| POST | `/v1/completions` | Legacy text completions |

```python
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

| Status | Meaning | What to do |
| --- | --- | --- |
| 400 | Invalid parameters or context too long | Correct the request; trim history or reduce the output budget |
| 401 | Missing or invalid API key | Check your bearer credential |
| 404 | Route not exposed | Check the path and supported routes |
| 405 | Wrong HTTP method | Use the method listed above |
| 413 | Body exceeds 2 MiB | Send less data |
| 429 | Rate or concurrency limit | Back off with jitter; bound retries |
| 502 / 503 / 504 | Model unavailable or timeout | Retry cautiously or show an actionable error |

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](/v1/docs/llms) · [Markdown](/v1/docs/llms.md)
- [Agent integration guide](/v1/docs/agents) · [Markdown](/v1/docs/agents.md)
- [This guide as Markdown](/v1/docs/index.md)
- [Machine-readable API description](/v1/docs/openapi.json)