Find the root cause across a month of complaints
Reads a month of complaints and tickets together overnight and reasons about the root causes behind the numbers, not ticket-by-ticket tagging.
- How it works
- Once a month the whole pile of complaints and tickets for the period is read in one pass by a very large model, held on ml2, the machine with the bigger card. Because only a small part of that model does the work on any one word, its bulk can sit in the machine's system memory and the job still finishes overnight — which is what lets it read the whole month together and reason about why the numbers moved, instead of tagging tickets one by one. It looks for causes that cross tickets: the returns spike that lines up with a courier change, the run of confused questions that starts the week a product page was edited. This is distinct from the per-ticket tagging and the Monday digest, which summarise; this one reasons across the pile.
- Data you need
- A full export of the period's complaints and tickets together — timestamps, and where you have them, linked order and product IDs. It helps a great deal to also hand it a plain log of what changed that month: a courier switch, a product-page edit, a price change, a new checkout step. Without that log the model can see a spike but has nothing to attach it to, so it will reach for a plausible guess. Text only: call recordings and photo attachments are not read unless they have already been transcribed.
- What to expect
- On a month where a real cause left a clear trail in what customers wrote, it names the right one and shows you the tickets behind it. It will also name causes that are not there. Two things that merely rose in the same week — a courier change and a returns spike on an unrelated product — get written up as cause and effect when they are pure coincidence. Because this case reasons across the pile rather than quoting one ticket, it can assemble a tidy, convincing root cause out of fragments that no single ticket actually supports, and it will read as more certain than the evidence warrants — so trace every claim back to the real tickets before you act on it. It over-weights whatever customers said loudest and misses the cause nobody put into words: a checkout bug that just makes people give up leaves almost no complaints, so it can go unnamed while a noisy minor gripe gets top billing. At a small shop the volumes are low enough that one bad week reads as a trend.
- Where people stay involved
- Whoever owns customer service reads the report and decides what, if anything, actually changed — the model finds patterns in the words, it does not know your operations. Check that each named cause is backed by the tickets it cites before it drives a decision, and never treat the report as proof that a supplier or a courier is at fault.
Which model, and what it costs to run
Qwen3-235B-A22B-Instruct-2507
No public benchmark ranks this job on our roster — reading a whole document and reasoning across it is exactly what the current long-context tests fail to predict. A job this hard starts from a large model, and we prove it on your own material before anything ships.
- Licence
- Apache-2.0
- Weights at 4-bit
- 132 GB
- Context
- 256K tokens
- Publisher
- Alibaba (Qwen Team)
What the hardware costs
One 141 GB card holds it
- Rent in the EU
- $4.50/hrNebius, Finland (eu-north1)
- Buy the card
- $29,500new, one-off
- Or rent it by the token
- $0.1 / $0.3per M in / out · Nebius AI Studio · EU
Hardware only, third-party prices from 2026-07. The figure excludes the KV cache, which grows with context length and how many people use it at once — sized properly in a conversation, not guessed here. Renting by the token is cheaper up front; why our customers still self-host is below.
Sticking to the document
Measured on public documents, by a model acting as judge. Read it beside the answer rate: the lowest hallucination rates on this board belong to models that simply decline more often.
Independent measurement · Vectara · board updated May 11, 2026
Structured output and tool calls
Measured in a sandbox, on somebody else's functions. It tells you which models are capable of the shape of the job, not which one will survive contact with your API.
Independent measurement · UC Berkeley (Gorilla project) · board updated 2026-04-12
The API is cheaper per token. Here is why our customers don't use it.
We will not pretend otherwise: renting a model by the token from a serverless API costs less per million tokens than a card we run for you. We show that price on every use-case page. What it does not include is the part a shop with a customer database actually pays for.
- 01
Your data never leaves hardware you can point at
A serverless "we don't retain your data" is a clause in a contract. Running the model on a card in Amsterdam is a fact of architecture: your catalogue, tickets and customer records are never sent to a third party at all. For a GDPR audit, that is the difference between a promise and a floor plan.
- 02
The price cannot move without your say-so
A serverless rate card is somebody else's lever. The provider can raise the price, retire the model, or change the terms, and your cost moves with it. The same model on the same card costs the same next year — you own the number.
- 03
The model cannot be taken away
Hosted APIs deprecate models on their own schedule; the one you built on can be gone in a quarter. An open-weight model on your own hardware runs for as long as you keep the lights on. No vendor can end-of-life it out from under you.
And the price gap closes with volume: past a card you keep busy — very roughly four billion tokens a month — owning is cheaper outright, even before the three reasons above.
Getting a case like this one from a conversation to production takes about two months, and you can stop at the end of any phase.
Also in customer service
All 15 →Sort the support inbox before anyone reads it
Classifies every incoming message into your own categories, pulls out order details, and routes it to the right queue before anyone opens it.
Draft answers to where-is-my-order emails
Looks up the real order and tracking status and drafts a reply with the carrier's information, ready for an agent to approve and send.
Suggest replies from your own help pages and policies
Finds the relevant passages in your FAQ and policy pages and drafts a reply based only on them, with a link to the source for the agent to check.
Handle return and refund requests against your own policy
Checks a return request against your written returns policy and drafts the instructions or a polite refusal, for a human to approve.
Next
Tell us what your team does by hand
Describe the process that takes the most time. We will say plainly whether a model is the right tool for it.