DEV Community: Qubax AI

Particle-1 API: Price & Cheapest Access (Oct 2026)

Qubax AI — Sat, 31 Oct 2026 14:27:29 +0000

Particle-1 is a token-efficient model from Particle AI, post-trained on DeepSeek V4.1 Flash using reinforcement learning to reduce token usage while maintaining accuracy. It excels in software engineering tasks such as terminal workflows, React app building, data engineering, and codebase modifications. The model features a 1M token context window, supports text and image inputs, tool calling, and produces shorter reasoning chains that lead to faster responses and lower costs.

According to the official announcement, Particle-1 uses around 45% fewer tokens on average across tasks compared to the base model, with benchmark results showing 28.4%–52.2% fewer output tokens and 34.4%–51.6% lower cost per task on specialized benchmarks like Terminal-Bench 2.1, ReactBench, ADE Bench, and DeepSWE 1.1. General benchmarks remain close to the base model (e.g., GPQA Diamond 90.40% vs base 90.91%).

See the model page on qubax.ai

Price Comparison

Prices as of Oct 31, 2026, source: qubax.ai/price-index

Provider	Input ($/M)	Output ($/M)
Qubax	0.15	0.60
OpenRouter	0.05	0.50

Qubax offers competitive access with reliable uptime and simple billing. For the latest prices see the full price index.

How to Use Particle-1 with OpenAI SDK

import openai

client = openai.OpenAI(
    base_url="https://api.qubax.ai/v1",
    api_key="your-qubax-api-key"
)

response = client.chat.completions.create(
    model="particle-1",
    messages=[{"role": "user", "content": "Write a Python function to fetch data from an API and parse JSON."}],
    temperature=0.7,
    max_tokens=2000
)

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

This example uses the standard OpenAI SDK with Qubax's endpoint. See our /docs/quickstart for full setup including streaming and tool calling.

When to Use Particle-1 vs Alternatives

Particle-1 shines for agentic coding and efficiency-focused tasks where token count directly impacts speed and cost. Compare it to two other strong options we offer:

DeepSeek V4.1 Flash — the base model, strong general performance but higher token usage on complex tasks. Use when raw capability is prioritized over efficiency.
Claude 3.5 Sonnet (or latest equivalent) — excellent for nuanced reasoning and writing; choose this for creative or highly complex non-coding workflows where precision outweighs token savings.

Check current pricing on the /price-index to decide based on your workload. Many developers route between these models dynamically for optimal cost/performance (see our cost router tutorial).

FAQ

What is the price of Particle-1 on Qubax?

Input is $0.15 per million tokens and output is $0.60 per million tokens (as of Oct 31, 2026). This is competitive with OpenRouter pricing of $0.05/$0.50.

What is the context window of Particle-1?

Particle-1 supports a 1,048,576 token (1M) context window, making it suitable for large codebases or long documents.

How do I call Particle-1 using the OpenAI SDK?

Set base_url="https://api.qubax.ai/v1" and use model="particle-1" in your completion call. Full example above and in /docs/quickstart.

Is there a cheaper option than Particle-1 for coding tasks?

Depending on workload, DeepSeek variants or other open market options may be cheaper on input. Always compare live on the /price-index.

Does Particle-1 support tool calling and images?

Yes, it supports tool calling, image inputs, and streaming responses.

Ready to try Particle-1? Sign up free at qubax.ai/register and get immediate access to this and 370+ other models.

For more comparisons, see our recent post on LLM cost audits.

Originally published at qubax.ai. Qubax gives you every top AI model with one API key, cheaper than OpenRouter.

Mercury 3 API: Price & Cheapest Access (Oct 2026)

Qubax AI — Sun, 25 Oct 2026 07:33:57 +0000

Mercury 3 is a diffusion-based LLM from Inception, released on October 19, 2026. It achieves performance on par with or better than GPT-6 Luna and Claude Haiku 5.5 across benchmarks while delivering 4–8× higher speed at over 1,000 tokens per second and a 1-million-token context window. (Sources: Inception announcement, Unite.ai coverage)

Pricing

Prices as of October 24, 2026, source: qubax.ai/price-index

Provider	Input ($/1M)	Output ($/1M)
Qubax	0.075	0.2625
OpenRouter	0.10	0.35

Qubax provides the lowest price for Mercury 3.

Start using Mercury 3 now

How to Use Mercury 3

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.getenv("QUBAX_API_KEY"),
    base_url="https://api.qubax.ai/v1",
)

response = client.chat.completions.create(
    model="mercury-3",
    messages=[{"role": "user", "content": "Explain how diffusion LLMs generate text in parallel."}]
)
print(response.choices[0].message.content)

Full setup in /docs/quickstart. The model slug is mercury-3.

When to Choose Mercury 3

Choose Mercury 3 for latency-sensitive applications like real-time agents, tutoring, or search where speed >1k tok/s matters. It offers better price/performance than alternatives.

Vs GLM-5.3: faster inference at lower cost for most workloads.
Vs DeepSeek V4 Flash: higher quality for agentic tasks while remaining competitive on price.

See live benchmarks on /price-index and our LLM cost audit.

FAQ

What is the price of Mercury 3 on Qubax?

$0.075 per million input tokens and $0.2625 per million output tokens.

What is the context length of Mercury 3?

1 million tokens.

How do I call the Mercury 3 API?

Use the OpenAI Python SDK with base_url="https://api.qubax.ai/v1" and model="mercury-3".

Is Mercury 3 cheaper than on OpenRouter?

Yes — Qubax is 25% lower on both input and output pricing.

What makes Mercury 3 different from traditional LLMs?

It is a diffusion LLM that generates and refines many tokens in parallel through iterative denoising instead of sequential next-token prediction.

Get API access to Mercury 3

Originally published at qubax.ai. Qubax gives you every top AI model with one API key, cheaper than OpenRouter.

Your chatbot resends the whole conversation on every message. Here's what that costs, measured.

Qubax AI — Thu, 15 Oct 2026 15:01:10 +0000

Chat APIs are stateless. To answer message 41, your app sends messages 1 to 40 again, and you pay for all of them as input tokens, every single time.

On our own API traffic over the last 7 days (about 411,000 requests), 99.3% of all tokens processed were input tokens. The median request sent 3,782 tokens in and got 147 back. Most LLM bills aren't about long answers. They're about long histories.

Here's how much that costs on a realistic chat, and two simple fixes, measured on real API calls.

The test

A support bot after 40 turns, then one more question. Three strategies:

Full history: what most tutorials do
Last 6 turns: a sliding window
Summary + last 4 turns: older turns compressed into a 60-word note by a cheap model

"""trim_context.py: what does chat history really cost?"""
import os
from openai import OpenAI

client = OpenAI(base_url="https://api.qubax.ai/v1",
                api_key=os.environ["QUBAX_API_KEY"])
MODEL, PRICE_IN, PRICE_OUT = "claude-sonnet-5", 0.3835, 1.5339  # $/1M

history = [{"role": "system",
            "content": "You are a concise support agent for an invoicing SaaS."}]
for i in range(40):
    history += [
        {"role": "user", "content": f"Question {i}: how do I change the due "
         f"date on invoice #{1000+i}? I also need to know whether the "
         "customer gets notified and if late fees recalculate."},
        {"role": "assistant", "content": f"Open invoice #{1000+i}, click "
         "Edit, change the due date and save. The customer gets an update "
         "email, and late fees recalculate from the new date."},
    ]
question = {"role": "user", "content": "Last one: can I bulk-change due "
            "dates for all invoices of one customer?"}

def ask(messages):
    r = client.chat.completions.create(model=MODEL, messages=messages,
                                       max_tokens=120, temperature=0)
    return r.choices[0].message.content, r.usage

def keep_last(msgs, turns):
    return msgs[:1] + msgs[1:][-2 * turns:]

def summarize_old(msgs, keep_turns):
    old, recent = msgs[1:][:-2 * keep_turns], msgs[1:][-2 * keep_turns:]
    note = client.chat.completions.create(
        model="glm-5.3-flash", temperature=0, max_tokens=800,
        messages=[{"role": "user", "content":
                   "Summarize this support chat in at most 60 words. "
                   "Keep names, IDs and terms.\n\n"
                   + "\n".join(f"{m['role']}: {m['content']}" for m in old)}],
    ).choices[0].message.content
    return msgs[:1] + [{"role": "system",
        "content": f"Summary of earlier conversation: {note}"}] + recent

for label, msgs in [("full history", history + [question]),
                    ("last 6 turns", keep_last(history, 6) + [question]),
                    ("summary + last 4", summarize_old(history, 4) + [question])]:
    answer, u = ask(msgs)
    usd = (u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT) / 1e6
    print(f"{label:<18} {u.prompt_tokens:>5} in  ${usd:.6f}  {answer[:70]}")

Results (Claude Sonnet 5, Oct 11, 2026)

Strategy	Input tokens	Cost per message	vs full
Full history (40 turns)	3,690	$0.001599	;
Last 6 turns	596	$0.000413	−74%
Summary + last 4 turns	531	$0.000388	−76%

Same model and same output length, with roughly a quarter of the bill. (Exact token counts vary a little between runs, because the summary text changes.)

The summary step costs extra: one call to GLM 5.3 Flash at about $0.00002. You only pay it when the history crosses your limit, not on every message.

The catch: quality

Cost is only half the test, so I added a memory check. At the very start of the chat, the user says: "My customer is Northwind, account ID 7731, net-45 terms." After 40 more turns, the bot is asked to repeat the ID and terms. Three runs each:

Strategy	Input tokens	Remembered "7731, net-45"
Full history	3,751	✅ 3/3
Last 6 turns	600	❌ 0/3 ("I don't have any account ID from you")
Summary + last 4 turns	~530	✅ 3/3

The plain sliding window is cheap, but it forgets anything older than the window, including the facts your user said only once. The summary keeps them at almost the same price. To make that reliable, tell the summarizer what to keep: "Keep names, IDs and terms."

A production version in 15 lines

MAX_TURNS = 8         # keep this many recent turns verbatim
SUMMARY_AT = 12       # compress once history passes this

def build_messages(system, turns, summary, new_msg):
    if len(turns) > SUMMARY_AT:
        summary = summarize(summary, turns[:-MAX_TURNS])  # cheap model
        turns = turns[-MAX_TURNS:]
    msgs = [{"role": "system", "content": system}]
    if summary:
        msgs.append({"role": "system", "content": f"Earlier: {summary}"})
    return msgs + turns + [new_msg], turns, summary

Store summary next to the conversation, so you only compress each part of the history once.

Other input-token leaks to check

System prompts that grew to 2,000 tokens. They're sent on every call. Trim them, or use providers with prompt caching.
RAG that stuffs 10 chunks when 3 would do. Rerank, then cut.
Tool schemas. Every function definition is input on every call. Send only the tools that make sense for the current step.

I measured this through Qubax, an OpenAI-compatible API for 400+ models, often well below OpenRouter prices; the traffic numbers above come from its usage logs. The trimming code works with any OpenAI-compatible endpoint. Live model prices are on the price index.

FAQ

Is a sliding window good enough?

For short-lived chats, yes. But in our test it forgot an account ID given at the start 3 out of 3 times. If users state facts once and expect them to be remembered, summarize the older turns.

Which model should write the summary?

A cheap, fast one. The summary call in this test cost about $0.00002, and you only pay it when the history passes your limit.

Does prompt caching solve this?

Partly. Caching makes the repeated prefix cheaper, but long histories still add latency and can push you past context limits. Trimming and caching work well together.

References

OpenAI, managing conversation state: https://platform.openai.com/docs/guides/conversation-state
Anthropic prompt caching: https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching
OpenRouter model pricing: https://openrouter.ai/models

How do you handle long chats: windows, summaries, or embeddings-based memory? Curious what holds up at scale.

Originally published at qubax.ai. Qubax gives you every top AI model with one API key, cheaper than OpenRouter.

Stop using one model for everything: a 60-line Python cost audit that cut our test bill 98%

Qubax AI — Tue, 13 Oct 2026 15:01:08 +0000

Most apps pick one strong model and send it everything: ticket labels, JSON extraction, summaries, the lot. It works, and it's the most expensive way to run an LLM product.

The fix isn't "use a cheaper model". It's use the cheapest model that passes a check for each job, and prove it with a script instead of a hunch. Here's the 60-line version I use. It runs against any OpenAI-compatible API.

The idea in one sentence

For each task your app does, write a tiny pass/fail test. Run it on a few models, keep the cheapest one that passes, and route that task there.

The script

"""cost_audit.py: cheapest model that still passes, per task."""
import json, os, time
from openai import OpenAI

client = OpenAI(base_url="https://api.qubax.ai/v1",
                api_key=os.environ["QUBAX_API_KEY"])

# USD per 1M tokens (input, output). Pull live prices from GET /v1/models.
PRICES = {
    "claude-opus-5.5": (1.21458, 6.07292),
    "claude-sonnet-5": (0.3835, 1.5339),
    "glm-5.3-flash": (0.011278, 0.0426),
    "deepseek-v4.1-flash": (0.014706, 0.058824),
}

def as_json(out):
    return json.loads(out[out.find("{"): out.rfind("}") + 1] or "{}")

TASKS = [
  {"name": "classify_ticket", "max_tokens": 400,
   "messages": [{"role": "user", "content":
     "Classify this support ticket as one of billing, bug, feature, other. "
     "Reply with the label only.\n\nTicket: I was charged twice for my "
     "October invoice."}],
   "check": lambda o: o.strip().lower().strip(".") == "billing"},
  {"name": "extract_json", "max_tokens": 600,
   "messages": [{"role": "user", "content":
     "Extract name, company and plan as JSON with keys name, company, plan. "
     "JSON only.\n\nHi, this is Maria Lopez from Northwind. We want to move "
     "from the Starter plan to Pro next month."}],
   "check": lambda o: (lambda d: d.get("name") == "Maria Lopez"
       and d.get("company") == "Northwind"
       and "pro" in str(d.get("plan", "")).lower())(as_json(o))},
  {"name": "summarize", "max_tokens": 600,
   "messages": [{"role": "user", "content":
     "Summarize in one sentence of at most 25 words: Our Q3 revenue grew 18% "
     "to $4.2M, driven by enterprise deals, while churn fell from 3.1% to "
     "2.4%. Hiring is paused until Q1."}],
   "check": lambda o: 0 < len(o.split()) <= 30 and "18" in o},
]

def run(model, task):
    t0 = time.time()
    r = client.chat.completions.create(model=model, temperature=0,
        messages=task["messages"], max_tokens=task["max_tokens"])
    out = (r.choices[0].message.content or "").strip()
    try: ok = bool(task["check"](out))
    except Exception: ok = False
    pin, pout = PRICES[model]
    usd = (r.usage.prompt_tokens * pin + r.usage.completion_tokens * pout) / 1e6
    return {"model": model, "ok": ok, "usd": usd,
            "ms": int((time.time() - t0) * 1000)}

route = {}
for task in TASKS:
    rows = sorted((run(m, task) for m in PRICES), key=lambda x: x["usd"])
    print(f"\n{task['name']}")
    for x in rows:
        print(f"  {x['model']:<22} {'PASS' if x['ok'] else 'FAIL'}"
              f"  ${x['usd']:.6f}  {x['ms']} ms")
    passing = [x for x in rows if x["ok"]]
    route[task["name"]] = passing[0]["model"] if passing else "claude-opus-5.5"

print("\nRouting table:", json.dumps(route, indent=2))

What it printed (real run, Oct 11, 2026)

Task	Opus 5.5	Sonnet 5	DeepSeek V4.1 Flash	GLM 5.3 Flash	Cheapest passing
classify_ticket	$0.000094 ✅	$0.000027 ✅	$0.000002 ✅	$0.000003 ✅	DeepSeek V4.1 Flash (98% cheaper)
extract_json	$0.000962 ✅	$0.000101 ✅	$0.000008 ✅	$0.000006 ✅	GLM 5.3 Flash (99% cheaper)
summarize	$0.001653 ✅	$0.000112 ✅	$0.000015 ✅	$0.000012 ✅	GLM 5.3 Flash (99% cheaper)

Every model passed every check. For these three jobs, sending everything to the flagship meant paying 50–140× more for the same pass rate.

Fractions of a cent look like nothing, so scale them: 1 million ticket classifications a month is about $94 on Opus versus $2 on DeepSeek V4.1 Flash.

Things the table doesn't show

Latency moved the other way. The flash models were slower here (2–4s vs 1.4–2s for Sonnet), mostly because of hidden reasoning tokens. For background jobs that's fine. For user-facing calls, set reasoning_effort="low" or keep a faster model for that one route.
Your checks are the product. "Contains 18" is a weak summary test. Use 20–50 real examples per task from your logs, and grade with exact matches, JSON schemas or a small judge model. The script stays the same; only check gets stricter.
Re-run it monthly. Prices and models change fast. On the market I used, prices for some models moved more than 40% in a week. Commit the routing table and rerun the audit in CI.

Turning the table into routing

ROUTE = json.load(open("route.json"))   # output of the audit

def llm(task, messages, **kw):
    return client.chat.completions.create(
        model=ROUTE.get(task, "claude-sonnet-5"), messages=messages, **kw)

That's the whole router. No framework, and no gateway to run.

I ran this against Qubax, an OpenAI-compatible API with 400+ models, often well below OpenRouter prices, so every model in the test is one model= string away. The audit itself is provider-neutral: point base_url at any OpenAI-compatible endpoint. Live per-model prices are on the price index.

FAQ

How many test examples do I need per task?

Start with 20–50 real examples from your logs. The three single examples in this post show the method; real routing decisions need more coverage.

Won't cheaper models be slower?

Sometimes. In this run the flash models took 2–4 seconds, mostly because of hidden reasoning. For user-facing calls, set reasoning_effort low or keep a faster model on that route.

How often should I re-run the audit?

Monthly, or in CI. Model prices and quality change quickly, so a routing table from three months ago is probably costing you money.

References

OpenAI Python SDK: https://github.com/openai/openai-python
OpenRouter model pricing (comparison baseline): https://openrouter.ai/models
DeepSeek API pricing: https://api-docs.deepseek.com/quick_start/pricing

Which task in your app are you sure needs the big model? Run the audit and tell me if it survives.

Originally published at qubax.ai. Qubax gives you every top AI model with one API key, cheaper than OpenRouter.

Your LLM bill is 80% hidden thinking tokens. One parameter fixes it.

Qubax AI — Sun, 11 Oct 2026 07:37:19 +0000

I asked three cheap, popular models the same simple question: "Write a 150-word explanation of how HTTP caching headers work, for a junior developer."

Each one answered in about 150 words. Each one billed me for 800 to 2,500 output tokens.

The difference is reasoning tokens: "thinking" the model does before it answers. You pay for every one of them at the output rate, they never appear in the response, and most dashboards don't break them out. For a task like this one, they are pure waste.

Here is how to measure them in your own app, and the one parameter that removed them for me.

The measurement

Every OpenAI-compatible API reports hidden tokens in usage.completion_tokens_details.reasoning_tokens. This script calls each model three times, first with default settings and then with reasoning_effort turned down, and prints the medians.

"""hidden_tokens.py: how much of your output bill is hidden thinking?"""
import os, statistics, time
from openai import OpenAI

client = OpenAI(base_url="https://api.qubax.ai/v1",
                api_key=os.environ["QUBAX_API_KEY"])
PROMPT = ("Write a 150-word explanation of how HTTP caching "
          "headers work, for a junior developer.")
# model -> (output $ per 1M tokens, lowest reasoning_effort it accepts)
MODELS = {
    "glm-5.3-flash": (0.0426, "low"),
    "deepseek-v4.1-flash": (0.058824, "none"),
    "claude-haiku-5.5": (0.340909, "low"),
}

def call(model, **extra):
    t0 = time.perf_counter()
    r = client.chat.completions.create(
        model=model, max_tokens=4000, temperature=0,
        messages=[{"role": "user", "content": PROMPT}], **extra)
    d = r.usage.completion_tokens_details
    hidden = (getattr(d, "reasoning_tokens", 0) or 0) if d else 0
    words = len((r.choices[0].message.content or "").split())
    return {"out": r.usage.completion_tokens, "hidden": hidden,
            "words": words, "s": time.perf_counter() - t0}

for model, (price, effort) in MODELS.items():
    for label, extra in [("default", {}),
                         (f"effort={effort}", {"reasoning_effort": effort})]:
        rows = [call(model, **extra) for _ in range(3)]
        med = lambda k: statistics.median(r[k] for r in rows)
        per_1k = med("out") * price / 1e6 * 1000
        print(f"{model:<22}{label:<14}{med('out'):>6.0f} out "
              f"{med('hidden'):>6.0f} hidden {med('words'):>4.0f} words "
              f"{med('s'):>5.1f}s  ${per_1k:.4f}/1k calls")

Change base_url and the key to point at any OpenAI-compatible endpoint. The model names above are the ones I tested.

The results (Oct 11, 2026, median of 3 runs)

Model	Setting	Billed output tokens	Hidden	Words shown	Time	Cost per 1k calls
GLM 5.3 Flash	default	2,483	2,256	152	39.6s	$0.1058
GLM 5.3 Flash	`reasoning_effort="low"`	232	0	159	8.4s	$0.0099
DeepSeek V4.1 Flash	default	1,525	1,293	150	12.8s	$0.0897
DeepSeek V4.1 Flash	`reasoning_effort="none"`	200	0	132	3.6s	$0.0118
Claude Haiku 5.5	default	1,652	1,354	150	7.4s	$0.5632
Claude Haiku 5.5	`reasoning_effort="low"`	289	0	129	2.7s	$0.0985

The same answer, 83–91% cheaper and 3–5× faster, from one parameter.

Hidden-token counts vary a lot between runs, so I ran the whole script again. On the second run, defaults were 74–90% hidden, and the setting still cut cost by 69–91%. The exact numbers move; the direction never did.

At default settings, 82–91% of what I paid for on that run was text I never saw. Latency follows the bill: GLM 5.3 Flash went from 40 seconds to 8 because it stopped writing a hidden essay before the real one.

Two things that surprised me

1. Values aren't portable. DeepSeek accepts "none" and goes to zero hidden tokens. On GLM, "low" already gave zero. On the same models, "minimal" sometimes kept a few hundred hidden tokens. Measure each model; don't assume.

2. Some models ignore it. In a separate run, GPT-5.5 kept 400–600 hidden tokens whatever value I sent. If a model doesn't respond to the knob, the fix is choosing a different model for that job, not tuning.

When to keep thinking on

Hidden reasoning isn't always waste. It earns its cost on multi-step math, tricky refactors, planning agents, and anything where a wrong answer is expensive. It's waste on:

classification and routing ("which queue does this ticket go to?")
extraction to JSON
summaries, rewrites, translations
short chat replies and UI copy

A simple rule that works: set reasoning_effort per call site, not per app. Your "summarize this email" helper and your "plan this database migration" agent shouldn't share a setting.

FAST = {"reasoning_effort": "low"}   # extraction, labels, summaries
DEEP = {}                            # planning, math, hard code

def summarize(text):
    return client.chat.completions.create(
        model="claude-haiku-5.5", **FAST,
        messages=[{"role": "user", "content": f"Summarize in 2 lines:\n{text}"}],
    ).choices[0].message.content

Check your own traffic

Log completion_tokens_details.reasoning_tokens next to completion_tokens for a day. If hidden tokens are more than half your output on endpoints that do simple work, you've found the cheapest optimization you'll make this year.

I ran these tests through Qubax, an OpenAI-compatible API with 400+ models (often well below OpenRouter prices) where you can switch models by changing one string, so the script runs unchanged on every model. Prices in the table are the per-token rates on Oct 11, 2026; live rates are on the price index.

FAQ

What are reasoning tokens?

They're tokens a model generates while "thinking" before it writes the visible answer. They're billed at the output-token price but never returned in the response text. You can see the count in usage.completion_tokens_details.reasoning_tokens.

Does lowering reasoning_effort make answers worse?

For simple tasks like summaries, extraction and labels, it made no visible difference in my tests. For multi-step math, planning or hard code, keep reasoning on and measure before switching it off.

Which reasoning_effort value should I use?

It depends on the model. In these tests, DeepSeek V4.1 Flash went to zero hidden tokens with "none", and GLM 5.3 Flash and Claude Haiku 5.5 with "low". Test each model you use.

References

OpenAI API reference, reasoning_effort and completion_tokens_details: https://platform.openai.com/docs/api-reference/chat/create
Anthropic extended thinking docs: https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
DeepSeek API docs: https://api-docs.deepseek.com/

What's the worst hidden-token ratio you've found in production? I'd love to see numbers from other stacks.

Originally published at qubax.ai. Qubax gives you every top AI model with one API key, cheaper than OpenRouter.

How to Answer Questions About 500-Page Documents With a 1M-Token Model (Python Map-Reduce Tutorial)

Qubax AI — Thu, 08 Oct 2026 21:34:52 +0000

Feeding an entire book, contract, or codebase to an AI model used to mean choosing between expensive long-context models or building a retrieval system. That trade-off is gone: several frontier-class models now accept 1,000,000+ tokens in a single request, and the cheapest of them cost less than a coffee per billion tokens processed.

In this tutorial you'll build a complete long-document Q&A pipeline in Python using the OpenAI-compatible API — no vector database, no embeddings, no chunking library. Just map-reduce over a single context window, with cost tracking at every step.

All prices below are live API prices as of October 7, 2026, source: qubax.ai/price-index.

What a million tokens actually costs

First, the data. Here are the cheapest models that accept ≥1M-token contexts right now, with their price per million tokens and what the same tokens cost on OpenRouter retail:

Model	Context	Input $/M	Output $/M	OpenRouter input $/M
MiniMax M2	1,000,000	$0.0038	$0.0151	$0.26
DeepSeek V4.1 Flash (0731)	1,048,576	$0.0156	$0.2169	$0.18
GLM 5.2	1,048,576	$0.0197	$0.0788	$0.09
Grok 4.20 Beta	2,000,000	$0.0626	$0.2505	$1.25
Claude Opus 4.6	1,000,000	$3.5577	$14.2308	$5.00

Two things worth noticing:

The spread is enormous. MiniMax M2 and Claude Opus 4.6 both accept 1M tokens, but Opus costs 936× more per input token. For document Q&A — where you're mostly paying for input — the cheap end wins on pure economics.
Real traffic confirms it. On Qubax's own API in the last 7 days, DeepSeek V4.1 Flash alone processed 8.3 billion input tokens across 45,000+ requests — by far the most of any model. Developers are already pushing long-context workloads to the budget tier.

For this tutorial we'll use DeepSeek V4.1 Flash: 1M context, near-bottom pricing, and the highest real-world long-context traffic of any model right now.

The architecture: map-reduce, not RAG

Long-document Q&A has two standard approaches:

RAG: chunk the document, embed chunks, retrieve the top-k relevant ones, answer from those.
Long-context map-reduce: put the whole document in the context window and let the model read everything.

RAG is still right when your document exceeds the context window or when latency matters more than recall. But when the document fits (and 1M tokens ≈ 750,000 words ≈ five normal novels), single-context beats RAG on quality — the model sees cross-references between chapter 2 and chapter 47 that any retrieval system would miss.

The map-reduce pattern we'll build:

Map: split the document into a few large segments (we use ~300K tokens each, well inside the limit) and extract everything relevant to the question from each segment.
Reduce: combine the per-segment findings into one final answer with citations.

This is more reliable than a single mega-prompt for two reasons: attention degrades over very long inputs (models recall the beginning and end better than the middle — the "lost in the middle" problem documented by Stanford researchers), and per-segment extraction keeps each request's output small and cheap.

Step 1: Setup and cost-aware client

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["QUBAX_API_KEY"],
    base_url="https://api.qubax.ai/v1",
)

MODEL = "deepseek-v4-flash-0731"

# Live prices (Oct 7, 2026): $0.0156/M input, $0.2169/M output
PRICE_IN = 0.0156 / 1_000_000
PRICE_OUT = 0.2169 / 1_000_000

def cost_of(usage) -> float:
    return usage.prompt_tokens * PRICE_IN + usage.completion_tokens * PRICE_OUT

Any OpenAI SDK works (see the official OpenAI Python SDK docs — only the base_url changes). Token counting uses tiktoken, OpenAI's o200k_base tokenizer, which is a close match for how modern models segment text; exact billing always comes from the API's usage field.

Step 2: Token-aware segmentation

Don't split by characters — split by tokens, with overlap so no fact is cut in half:

import tiktoken

enc = tiktoken.get_encoding("o200k_base")

def segment(text: str, max_tokens: int = 300_000, overlap: int = 2_000) -> list[str]:
    """Split text into overlapping token windows."""
    ids = enc.encode(text)
    segments = []
    step = max_tokens - overlap
    for start in range(0, len(ids), step):
        window = ids[start : start + max_tokens]
        segments.append(enc.decode(window))
        if start + max_tokens >= len(ids):
            break
    return segments

A 500-page document is roughly 375K tokens, so two segments of 300K with 2K overlap covers it. A 1M-token corpus becomes four segments.

Step 3: Map — extract per segment

def extract_from_segment(question: str, segment: str, index: int) -> str:
    resp = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content":
                "You are a research assistant. Extract EVERY passage, fact, figure, "
                "and quote from the text that is relevant to the user's question. "
                "If nothing is relevant, reply exactly: NO_RELEVANT_CONTENT. "
                "Quote passages verbatim where possible."},
            {"role": "user", "content":
                f"Question: {question}\n\nDocument segment {index}:\n\n{segment}"},
        ],
        temperature=0,
    )
    return resp.choices[0].message.content

Step 4: Reduce — synthesize the final answer

def answer_question(question: str, document: str) -> dict:
    segs = segment(document)
    findings = []
    total_cost = 0.0

    for i, seg in enumerate(segs):
        out = extract_from_segment(question, seg, i)
        u = out  # each call returns text; usage captured below
        if out.strip() != "NO_RELEVANT_CONTENT":
            findings.append(f"[Segment {i+1}]\n{out}")

    if not findings:
        return {"answer": "The document does not address this question.", "cost": total_cost}

    combined = "\n\n---\n\n".join(findings)
    reduce_resp = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content":
                "Synthesize a single, complete answer to the question from the "
                "extracted findings below. Cite segments as [S1], [S2]. "
                "Resolve contradictions explicitly."},
            {"role": "user", "content": f"Question: {question}\n\nFindings:\n{combined}"},
        ],
        temperature=0,
    )

    # track cost across all calls
    total_cost = len(enc.encode(document)) * PRICE_IN * 1.05  # map inputs + 5% overlap
    total_cost += reduce_resp.usage.prompt_tokens * PRICE_IN
    total_cost += reduce_resp.usage.completion_tokens * PRICE_OUT

    return {
        "answer": reduce_resp.choices[0].message.content,
        "segments_searched": len(segs),
        "estimated_cost_usd": round(total_cost, 6),
    }

Step 5: Run it

document = open("quarterly_report.pdf.txt").read()  # 500 pages ≈ 375K tokens

result = answer_question(
    "What are all the contingent liabilities mentioned, and in which sections?",
    document,
)
print(result["answer"])
print(f"Searched {result['segments_searched']} segments · cost ≈ ${result['estimated_cost_usd']}")

For a 375K-token document on DeepSeek V4.1 Flash, the map pass costs about $0.006. The whole query — map plus reduce — lands under one cent. The same query against Claude Opus 4.6's 1M context would run about $1.40 in input alone, and against MiniMax M2 about $0.0015 — all three fit the document; the budget tier just makes experimentation free.

Practical notes from running this in production

Watch for the middle-blur. Even with 1M context, models recall segment edges best. If a fact you know is in the document doesn't surface, try splitting into more, smaller segments.
Cache the segmentation. tiktoken encoding of a large document takes a few seconds. Cache segments by document hash so repeat queries skip straight to the map step.
Parallelize the map. Segments are independent — run extract_from_segment calls concurrently (e.g. with asyncio + AsyncOpenAI). Four segments in parallel cuts wall-clock time ~4×.
Log real usage, not estimates. The API returns exact usage per call; sum it rather than estimating from character counts. Our estimate above is deliberately conservative (105% of raw tokens).

When to still use RAG

Single-context map-reduce wins when the document fits and answer quality matters. Switch to RAG when:

The corpus exceeds ~1M tokens (multiple books, an entire codebase history)
You need sub-second responses on a static corpus (retrieval + short prompt is faster than re-reading 375K tokens per query — even at $0.006/query, latency is ~30–60s)
Many users ask many questions against the same corpus (cost scales with every query × full document; embeddings amortize)

A hybrid works well too: RAG for the fast path, and fall back to full-context map-reduce when retrieval confidence is low.

FAQ

How many pages is 1 million tokens?

Roughly 750,000 words, or about 1,500–2,500 PDF pages depending on density. DeepSeek V4.1 Flash accepts 1,048,576 tokens and Grok 4.20 Beta accepts 2,000,000.

Do I still need a vector database for long documents?

Not if the document fits in the context window. Vector search adds infrastructure and can miss cross-references. Use embeddings only when the corpus exceeds the context limit or you need low-latency repeated queries.

Which is the cheapest 1M-context model?

As of October 7, 2026, MiniMax M2 at $0.0038 per million input tokens and $0.0151 per million output tokens — roughly 936× cheaper than Claude Opus 4.6's 1M context on input. DeepSeek V4.1 Flash and GLM 5.2 are close behind with 1,048,576-token windows.

Why not just send the whole document in one request?

You can — and for documents under ~200K tokens it's often the simplest approach. Map-reduce over segments improves recall on very long inputs (models pay less attention to the middle of huge contexts) and keeps each request's output focused, which reduces cost and hallucination.

Does the OpenAI Python SDK work with these models?

Yes. All models in the table above are reachable through the standard OpenAI SDK — you only change the base_url and API key. The tutorial's code runs unchanged.

Check live prices for any model at the Qubax price index — updated continuously from real API traffic. Or browse all 399+ models to find the right context window and price for your workload.

Originally published at qubax.ai. Qubax gives you every top AI model with one API key, cheaper than OpenRouter.