Instructions to use Interchained/imagine-v8 with libraries, inference providers, notebooks, and local apps. Follow these links to get started.

Libraries

How to use Interchained/imagine-v8 with Transformers:

# Use a pipeline as a high-level helper
from transformers import pipeline

pipe = pipeline("text-generation", model="Interchained/imagine-v8")
messages = [
    {"role": "user", "content": "Who are you?"},
]
pipe(messages)

# pip install -U transformers accelerate
# Load model directly
from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("Interchained/imagine-v8")
model = AutoModelForCausalLM.from_pretrained("Interchained/imagine-v8", device_map="auto")
messages = [
    {"role": "user", "content": "Who are you?"},
]
inputs = tokenizer.apply_chat_template(
	messages,
	add_generation_prompt=True,
	tokenize=True,
	return_dict=True,
	return_tensors="pt",
).to(model.device)

outputs = model.generate(**inputs, max_new_tokens=256)
print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:]))

Notebooks
Google Colab
Kaggle
Local Apps Settings

vLLM

How to use Interchained/imagine-v8 with vLLM:

Install from pip and serve model

# Install vLLM from pip:
pip install vllm
# Start the vLLM server:
vllm serve "Interchained/imagine-v8"
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:8000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "Interchained/imagine-v8",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Use Docker

docker model run hf.co/Interchained/imagine-v8

SGLang

How to use Interchained/imagine-v8 with SGLang:

Install from pip and serve model

# Install SGLang from pip:
pip install sglang
# Start the SGLang server:
python3 -m sglang.launch_server \
    --model-path "Interchained/imagine-v8" \
    --host 0.0.0.0 \
    --port 30000
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:30000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "Interchained/imagine-v8",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Use Docker images

docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=<secret>" \
    --ipc=host \
    lmsysorg/sglang:latest \
    python3 -m sglang.launch_server \
        --model-path "Interchained/imagine-v8" \
        --host 0.0.0.0 \
        --port 30000
# Call the server using curl (OpenAI-compatible API):
curl -X POST "http://localhost:30000/v1/chat/completions" \
	-H "Content-Type: application/json" \
	--data '{
		"model": "Interchained/imagine-v8",
		"messages": [
			{
				"role": "user",
				"content": "What is the capital of France?"
			}
		]
	}'

Docker Model Runner
How to use Interchained/imagine-v8 with Docker Model Runner:
```
docker model run hf.co/Interchained/imagine-v8
```

imagine-v8 / README.md

Interchained

Upload folder using huggingface_hub

a1c78d6 verified 26 days ago

preview code

Raw History Blame Contribute Delete

7.17 kB

---
library_name: transformers
pipeline_tag: text-generation
base_model: deepseek-ai/deepseek-coder-1.3b-instruct
tags:
  - coding
  - sql
  - postgresql
  - text-to-sql
  - local
  - schema-grounded
  - interchained
---
# Imagine v8

**Imagine** is a compact local coding model built and fine-tuned by **Interchained**.

It is focused on PostgreSQL, schema-grounded text-to-SQL, database reasoning, and local-first deployment.

Imagine v8 is a research checkpoint based on `deepseek-ai/deepseek-coder-1.3b-instruct`.

## What Imagine is for

Imagine is designed for:

- PostgreSQL generation
- schema-grounded text-to-SQL
- database reasoning
- read-only SQL workflows
- local coding assistance
- structured database tasks
- local and self-hosted inference

Imagine is intentionally more focused than a general-purpose chatbot.

## Identity

The deployed model identity is **Imagine**.

Imagine was built and fine-tuned by **Interchained**.

DeepSeek-Coder is part of the upstream model lineage, but the deployed model identity is Imagine.

## Local-first

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.

## PostgreSQL specialization

Imagine is trained around PostgreSQL and schema-grounded query generation.

The project emphasizes whether generated SQL:

1. parses correctly
2. follows the read-only contract
3. binds against the supplied schema
4. executes successfully
5. answers the requested question

The goal is not to match one reference SQL string exactly.

Different SQL queries can be semantically equivalent.

## Read-only SQL contract

Imagine is trained for read-only database tasks.

Expected SQL includes:

```sql
SELECT ...
```

and read-only:

```sql
WITH ...
SELECT ...
```

The database-task contract excludes mutating and destructive statements such as:

- INSERT
- UPDATE
- DELETE
- MERGE
- TRUNCATE
- ALTER
- DROP
- CREATE
- COPY

Production deployments should still enforce read-only access at the database-permission level.

## Schema grounding

Imagine should use only the schema supplied in the prompt.

It should not invent:

- tables
- columns
- relationships
- foreign keys
- join keys
- identifiers

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.

## Ambiguity handling

Imagine is trained not to guess through material ambiguity.

If two reasonable interpretations would produce meaningfully different SQL or results, Imagine should ask for clarification rather than silently choosing one.

## Output protocol

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.

## Training

Imagine v8 was produced through iterative full fine-tuning.

The training path includes:

- DeepSeek-Coder 1.3B Instruct base
- PostgreSQL-focused supervised fine-tuning
- execution-gated SQL curriculum generation
- identity training
- adversarial identity examples
- schema-grounding examples
- protocol-focused training
- expanded system-contract training

The project uses real PostgreSQL execution as part of its evaluation and curriculum pipeline.

## Execution gate

SQL can be checked through several levels:

### Parse

The query must parse as PostgreSQL.

### Safety

The query must satisfy the read-only contract.

### Bind

The query must resolve successfully against the real supplied schema.

This catches nonexistent tables, nonexistent columns, ambiguous references, and related schema errors.

### Execute

The query must execute successfully against PostgreSQL.

### Result agreement

The result can be compared with a reference query.

Reference-result agreement is useful, but it is not identical to semantic correctness. A different projection or implementation may still answer the user's question correctly.

## Evaluation

A held-out telemetry evaluation contains 21 PostgreSQL questions.

A checkpoint in the v6 lineage achieved:

- 100% strict parse rate
- 100% execute rate
- 0 invented relations
- 0 invented columns
- 0 refusals
- 15/21 strict reference-result agreements
- 71.4% strict execution-agreement score

Some reference mismatches involved valid executable SQL that differed from the reference query in projection or implementation.

For that reason, Imagine research distinguishes between:

- protocol compliance
- PostgreSQL executability
- exact result agreement
- semantic correctness

## Example

Prompt:

```text
What is the average cpu_pct in samples?
```

Possible output:

```text
<<<SQL>>>
SELECT AVG(cpu_pct) FROM samples;
<<<END>>>
```

## Loading Imagine

```python
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model_id = "Interchained/imagine-v8"
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)
```

## Intended use

Imagine is intended for:

- developers
- database engineers
- AI engineers
- PostgreSQL users
- text-to-SQL researchers
- local-model experimentation

## Limitations

Imagine v8 is a research checkpoint.

It may still:

- generate incorrect SQL
- misunderstand ambiguous requests
- apply incorrect filters
- choose incorrect ordering
- misunderstand business semantics
- deviate from the intended output protocol
- produce incomplete answers
- show residual behavior from the upstream base model

Generated SQL should be reviewed before use in important systems.

## Security

Do not rely on model behavior alone for database safety.

Production systems should enforce controls such as:

- read-only database roles
- statement timeouts
- row limits
- query validation
- schema restrictions
- application-level authorization
- audit logging

## Project philosophy

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.

## Status

**Imagine v8 — Research Checkpoint**

Built and fine-tuned by **Interchained**.

	---
	library_name: transformers
	pipeline_tag: text-generation
	base_model: deepseek-ai/deepseek-coder-1.3b-instruct
	tags:
	- coding
	- sql
	- postgresql
	- text-to-sql
	- local
	- schema-grounded
	- interchained
	---

	# Imagine v8

	Imagine is a compact local coding model built and fine-tuned by Interchained.

	It is focused on PostgreSQL, schema-grounded text-to-SQL, database reasoning, and local-first deployment.

	Imagine v8 is a research checkpoint based on `deepseek-ai/deepseek-coder-1.3b-instruct`.

	## What Imagine is for

	Imagine is designed for:

	- PostgreSQL generation
	- schema-grounded text-to-SQL
	- database reasoning
	- read-only SQL workflows
	- local coding assistance
	- structured database tasks
	- local and self-hosted inference

	Imagine is intentionally more focused than a general-purpose chatbot.

	## Identity

	The deployed model identity is Imagine.

	Imagine was built and fine-tuned by Interchained.

	DeepSeek-Coder is part of the upstream model lineage, but the deployed model identity is Imagine.

	## Local-first

	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.

	## PostgreSQL specialization

	Imagine is trained around PostgreSQL and schema-grounded query generation.

	The project emphasizes whether generated SQL:

	1. parses correctly
	2. follows the read-only contract
	3. binds against the supplied schema
	4. executes successfully
	5. answers the requested question

	The goal is not to match one reference SQL string exactly.

	Different SQL queries can be semantically equivalent.

	## Read-only SQL contract

	Imagine is trained for read-only database tasks.

	Expected SQL includes:

	```sql
	SELECT ...
	```

	and read-only:

	```sql
	WITH ...
	SELECT ...
	```

	The database-task contract excludes mutating and destructive statements such as:

	- INSERT
	- UPDATE
	- DELETE
	- MERGE
	- TRUNCATE
	- ALTER
	- DROP
	- CREATE
	- COPY

	Production deployments should still enforce read-only access at the database-permission level.

	## Schema grounding

	Imagine should use only the schema supplied in the prompt.

	It should not invent:

	- tables
	- columns
	- relationships
	- foreign keys
	- join keys
	- identifiers

	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.

	## Ambiguity handling

	Imagine is trained not to guess through material ambiguity.

	If two reasonable interpretations would produce meaningfully different SQL or results, Imagine should ask for clarification rather than silently choosing one.

	## Output protocol

	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.

	## Training

	Imagine v8 was produced through iterative full fine-tuning.

	The training path includes:

	- DeepSeek-Coder 1.3B Instruct base
	- PostgreSQL-focused supervised fine-tuning
	- execution-gated SQL curriculum generation
	- identity training
	- adversarial identity examples
	- schema-grounding examples
	- protocol-focused training
	- expanded system-contract training

	The project uses real PostgreSQL execution as part of its evaluation and curriculum pipeline.

	## Execution gate

	SQL can be checked through several levels:

	### Parse

	The query must parse as PostgreSQL.

	### Safety

	The query must satisfy the read-only contract.

	### Bind

	The query must resolve successfully against the real supplied schema.

	This catches nonexistent tables, nonexistent columns, ambiguous references, and related schema errors.

	### Execute

	The query must execute successfully against PostgreSQL.

	### Result agreement

	The result can be compared with a reference query.

	Reference-result agreement is useful, but it is not identical to semantic correctness. A different projection or implementation may still answer the user's question correctly.

	## Evaluation

	A held-out telemetry evaluation contains 21 PostgreSQL questions.

	A checkpoint in the v6 lineage achieved:

	- 100% strict parse rate
	- 100% execute rate
	- 0 invented relations
	- 0 invented columns
	- 0 refusals
	- 15/21 strict reference-result agreements
	- 71.4% strict execution-agreement score

	Some reference mismatches involved valid executable SQL that differed from the reference query in projection or implementation.

	For that reason, Imagine research distinguishes between:

	- protocol compliance
	- PostgreSQL executability
	- exact result agreement
	- semantic correctness

	## Example

	Prompt:

	```text
	What is the average cpu_pct in samples?
	```

	Possible output:

	```text
	<<<SQL>>>
	SELECT AVG(cpu_pct) FROM samples;
	<<<END>>>
	```

	## Loading Imagine

	```python
	from transformers import AutoModelForCausalLM, AutoTokenizer
	import torch

	model_id = "Interchained/imagine-v8"

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

	## Intended use

	Imagine is intended for:

	- developers
	- database engineers
	- AI engineers
	- PostgreSQL users
	- text-to-SQL researchers
	- local-model experimentation

	## Limitations

	Imagine v8 is a research checkpoint.

	It may still:

	- generate incorrect SQL
	- misunderstand ambiguous requests
	- apply incorrect filters
	- choose incorrect ordering
	- misunderstand business semantics
	- deviate from the intended output protocol
	- produce incomplete answers
	- show residual behavior from the upstream base model

	Generated SQL should be reviewed before use in important systems.

	## Security

	Do not rely on model behavior alone for database safety.

	Production systems should enforce controls such as:

	- read-only database roles
	- statement timeouts
	- row limits
	- query validation
	- schema restrictions
	- application-level authorization
	- audit logging

	## Project philosophy

	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.

	## Status

	Imagine v8 — Research Checkpoint

	Built and fine-tuned by Interchained.