GLM-5.3 is live. Run Z.ai's latest model on Friendli Model APIs. Try it today ➜
Interchained
Available on FriendliAI
Run this model inference on single tenant GPU with unmatched speed and reliability at scale.
Run this model inference with full control and performance in your environment.
Model Details
Model Provider
Interchained
Model Tree
Interchained/imagine-v10
Input Modalities
Output Modalities
Supported Functionality
v10 was asked, live:
"Every customer with total spending on completed orders, include zeros."
It returned:
sql
SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spendingFROM customers cLEFT JOIN orders o ON c.id = o.customer_idWHERE o.status = 'completed' -- ← the bug. WHERE runs AFTER the join.GROUP BY c.id, c.nameORDER BY total_spending DESC;The WHERE silently converts the outer join to an inner join. Every zero-spend customer — the exact rows the question asked for — vanishes. The predicate belongs in ON:
sql
SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spendingFROM customers cLEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'GROUP BY c.id, c.nameORDER BY total_spending DESC, c.id ASC;v10 knew the shape of the answer but not where the filter lives. v11 does.
Where v10 added complex analytical queries, v11 adds predicate placement — knowing where each clause belongs:
ON, never WHERESUM(CASE WHEN ...) patterns for filtered totalsNOT EXISTS / LEFT JOIN ... IS NULL for absence queries| Model | Held-out (telemetry) | Protocol | Execute rate | Invented cols |
|---|---|---|---|---|
| imagine-v8 | 50.0% (20/40) | 100% | — | — |
| imagine-v9 | 90.0% (36/40) | 100% | 97.5% | 0 |
| imagine-v10 | 100.0% (40/40) | 100% | 100% | 0 |
Perfect score, held. Zero wrong answers. Zero hallucinations. Zero refusals.
Two-stage fine-tuning from Interchained/imagine-v10, on an NVIDIA B200:
3,289 candidates forged, 3,284 admitted:
| Schema | Templates | Analytical | Predicate | Writes | Total |
|---|---|---|---|---|---|
| shop | 356 | 3 | 9 | 396 | 764 |
| clinic | 545 | 6 | 36 | 280 | 867 |
| library | 481 | 6 |
Nothing enters training that a live database hasn't agreed with.
Every candidate goes through L0–L4:
text
candidate SQL ──► L0 real PostgreSQL parser not a regex L1 read-only + bounded no writes, no sleeps L2 EXPLAIN on live schema hallucinations die HERE L3 execute, timed, capped real rows L4 SAME ANSWER as ref? ◄── the one that matters ▼ admitted to corpus68/68 gate tests passing. The gate is the truth authority — not a bigger model, not vibes.
SQL wrapped in sentinel blocks:
text
<<<SQL>>>SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spendingFROM customers cLEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'GROUP BY c.id, c.nameORDER BY total_spending DESC, c.id ASC;<<<END>>>Can also refuse:
| block | meaning |
|---|---|
<<<SQL>>> | here is your query |
<<<UNANSWERABLE>>> | this schema cannot answer that |
<<<CLARIFY>>> | ambiguous — here's what's missing |
⚠️ A truncated generation is not an answer. An unterminated block extracts to nothing.
python
from transformers import AutoModelForCausalLM, AutoTokenizerimport torch model_id = "Interchained/imagine-v11" tokenizer = AutoTokenizer.from_pretrained(model_id)model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype=torch.bfloat16, device_map="auto",) # Ask for a predicate-placement query — v10's failure modeprompt = """Schema:customers(id, name)orders(id, customer_id, total, status) List every customer ID, name, and total completed spending.Include customers with no completed orders (show 0).Sort by spending descending, then ID ascending.""" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) with torch.no_grad(): output = model.generate(inputs["input_ids"], max_new_tokens=256, do_sample=False) print(tokenizer.decode(output[0], skip_special_tokens=True))The deployed model identity is Imagine.
Built and fine-tuned by Interchained.
DeepSeek-Coder is part of the upstream lineage (via v8 → v9 → v10 → v11), but the deployed identity is Imagine.
Runs on your hardware. No API key. No metered inference. No cloud dependency.
1 · Don't write a verifier — the engine already shipped one. Real parser. Real planner. Real rows.
2 · Assert the property, not a proxy. Execution accuracy, not string similarity.
3 · Schema goes in the prompt, not in the weights. The model learns "read the schema you were handed" — not memorise ours.
v11 is a research checkpoint. It may still:
WHERE clauses — always review before executingGenerated SQL should be reviewed before use in production. This applies doubly to writes.
Do not rely on model behavior alone for database safety. Production systems should enforce:
Built by Interchained · ownership at every layer, including the model
3 > 1 — Mark drives, oracle points, Muse builds
candidate SQL ──► L0 real PostgreSQL parser not a regex L1 read-only + bounded no writes, no sleeps L2 EXPLAIN on live schema hallucinations die HERE L3 execute, timed, capped real rows L4 SAME ANSWER as ref? ◄── the one that matters ▼ admitted to corpus<<<SQL>>>SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spendingFROM customers cLEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'GROUP BY c.id, c.nameORDER BY total_spending DESC, c.id ASC;<<<END>>>SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spendingFROM customers cLEFT JOIN orders o ON c.id = o.customer_idWHERE o.status = 'completed' -- ← the bug. WHERE runs AFTER the join.GROUP BY c.id, c.nameORDER BY total_spending DESC;SELECT c.id, c.name, COALESCE(SUM(o.total), 0) AS total_spendingFROM customers cLEFT JOIN orders o ON c.id = o.customer_id AND o.status = 'completed'GROUP BY c.id, c.nameORDER BY total_spending DESC, c.id ASC;| imagine-v11 | 100.0% (40/40) | 100% | 100% | 0 |
| 0 |
| 262 |
| 749 |
| fleet | 297 | 3 | 0 | 231 | 531 |
| audit | 252 | 0 | 0 | 126 | 378 |