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-v8
Input Modalities
Output Modalities
Supported Functionality
Imagine is designed for:
Imagine is intentionally more focused than a general-purpose chatbot.
The deployed model identity is Imagine.
Imagine was built and fine-tuned by Interchained.
DeepSeek-Coder is part of the upstream model lineage (via imagine-v8), but the deployed model identity is Imagine.
Imagine is intended to run locally on hardware controlled by the user.
Normal inference does not require a metered cloud inference API.
A larger teacher model may be used during research or curriculum generation, but Imagine does not require that teacher at runtime.
Imagine is trained around PostgreSQL and schema-grounded query generation.
The project emphasizes whether generated SQL:
The goal is not to match one reference SQL string exactly.
Different SQL queries can be semantically equivalent.
Imagine v9 is trained for both read and write database tasks.
Expected reads include:
text
SELECT ...and read-only:
text
WITH ...SELECT ...Expected writes are exactly one mutating statement per request:
text
INSERT INTO ...text
UPDATE ... SET ... WHERE ...text
DELETE FROM ... WHERE ...Write requests that would require multiple statements, schema changes (ALTER, DROP, CREATE, TRUNCATE), or destructive unbounded operations remain out of contract.
Production deployments should still enforce access controls at the database-permission level. Writes should never run without human review.
Imagine should use only the schema supplied in the prompt.
It should not invent:
If the requested information cannot be derived from the supplied schema, Imagine should avoid fabricating an answer.
Depending on the request, the correct response may be UNANSWERABLE or a clarification request.
Imagine is trained not to guess through material ambiguity.
If two reasonable interpretations would produce meaningfully different SQL or effects, Imagine should ask for clarification rather than silently choosing one.
This matters more for writes than reads: a wrong WHERE clause on a DELETE is not a rounding error.
SQL tasks may use structured sentinel output:
text
<<<SQL>>>SELECT ...<<<END>>>Unsupported requests may use:
text
<<<UNANSWERABLE>>>...<<<END>>>Ambiguous requests may use clarification behavior rather than guessing.
Imagine v9 was produced by full fine-tuning from Interchained/imagine-v8.
The training path includes:
The project uses real database execution (via NEDB's PostgreSQL-compatible wire protocol) as part of its evaluation and curriculum pipeline.
Training corpus: 2,739 admitted pairs (1,931 reads + 810 writes), 99.9% gate admit rate.
SQL is checked through several levels:
The query must parse as PostgreSQL.
The query must satisfy the contract: read-only, or exactly one INSERT/UPDATE/DELETE.
The query must resolve successfully against the real supplied schema.
This catches nonexistent tables, nonexistent columns, ambiguous references, and related schema errors.
The query must execute successfully.
For reads, the result is compared with a reference query. For writes, the database state after execution is compared: candidate and reference run on identical fresh databases, and the resulting states must match (excluding auto-generated IDs, which are nondeterministic across fresh databases).
Reference agreement is useful, but it is not identical to semantic correctness. A different projection or implementation may still answer the user's question correctly.
A held-out telemetry evaluation contains 40 PostgreSQL questions.
Remaining failures were genuine wrong answers (unsupported predicates, unbounded date ranges, count(DISTINCT col) vs non-null row counts) and one gate policy stop on mixing * with aggregates.
Prompt:
text
What is the average cpu_pct in samples?Possible output:
text
<<<SQL>>>SELECT AVG(cpu_pct) FROM samples;<<<END>>>Write prompt:
text
Remove orders where status is 'refunded'.Possible output:
text
<<<SQL>>>DELETE FROM orders WHERE status = 'refunded';<<<END>>>text
from transformers import AutoModelForCausalLM, AutoTokenizerimport torch model_id = "Interchained/imagine-v9" tokenizer = AutoTokenizer.from_pretrained(model_id)model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype=torch.bfloat16, device_map="auto",) messages = [ { "role": "user", "content": "What model am I speaking with?" }] inputs = tokenizer.apply_chat_template( messages, tokenize=True, add_generation_prompt=True, return_tensors="pt",).to(model.device) with torch.no_grad(): output = model.generate( inputs, max_new_tokens=128, do_sample=False, ) response = tokenizer.decode( output[0][inputs["input_ids"].shape[-1]:], skip_special_tokens=True,) print(response)Imagine is intended for:
Imagine v9 is a research checkpoint.
It may still:
WHERE clauses — always review write SQL before executingGenerated SQL should be reviewed before use in important systems. This applies doubly to writes.
Do not rely on model behavior alone for database safety.
Production systems should enforce controls such as:
Imagine is built around three ideas: Grounding over guessing.
The supplied schema is the source of truth.
Execution over string similarity.
Correctness should be judged by what SQL actually does, not only whether it matches one reference string.
Local control over unnecessary dependency.
Useful coding models should be able to run on infrastructure controlled by the user.
Imagine v9 — Research Checkpoint
Built and fine-tuned by Interchained.
from transformers import AutoModelForCausalLM, AutoTokenizerimport torchmodel_id = "Interchained/imagine-v9"tokenizer = AutoTokenizer.from_pretrained(model_id)model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype=torch.bfloat16, device_map="auto",)messages = [ { "role": "user", "content": "What model am I speaking with?" }]inputs = tokenizer.apply_chat_template( messages, tokenize=True, add_generation_prompt=True, return_tensors="pt",).to(model.device)with torch.no_grad(): output = model.generate( inputs, max_new_tokens=128, do_sample=False, )response = tokenizer.decode( output[0][inputs["input_ids"].shape[-1]:], skip_special_tokens=True,)print(response)