The model is specialized in generating complete software implementations, with a strong focus on modern frontend development, interactive browser applications, Three.js, HTML5 Canvas, JavaScript, HTML/CSS, Python and general programming.

OBSIDIAN is designed around a simple objective:

Generate the implementation, not fragments of it.

⚡ Highlights

Feature	OBSIDIAN-9B-Coder
Model Class	9B
Training Context	32K
Training Method	LoRA SFT
Training Framework	Unsloth
Languages	10
Primary Focus	Code Generation
Frontend	Strong specialization
Three.js	Strong specialization
Canvas	Strong specialization
JavaScript	Strong specialization
Python	Supported
Distribution	GGUF

🧠 Overview

OBSIDIAN-9B-Coder was created to further specialize an already capable coding model toward implementation-heavy programming tasks.

Instead of focusing primarily on explanations surrounding code, the fine-tuning corpus heavily emphasizes generation of the actual implementation.

The model is particularly suited for:

Complete single-file web applications
HTML5
Modern CSS
JavaScript ES6+
Three.js
HTML5 Canvas
Interactive browser applications
Browser games
Graphical experiments
DOM manipulation
Animation loops
State management
Python
Algorithms
Multilingual programming instructions
Long-form code generation

🔥 Core Philosophy

text

USER REQUEST
      │
      ▼
┌──────────────────────┐
│  OBSIDIAN-9B-Coder   │
└──────────────────────┘
      │
      ▼
COMPLETE IMPLEMENTATION
      │
      ├── HTML
      ├── CSS
      ├── JavaScript
      ├── Three.js
      ├── Canvas
      └── Python

The training strategy emphasizes:

text

Less boilerplate explanation
           +
More actual implementation
           +
Complete long-form outputs
           =
OBSIDIAN

OBSIDIAN is fine-tuned to preserve long application structures including:

document layout;
styles;
application state;
event handlers;
rendering logic;
animation loops;
user interaction;
game logic;
DOM lifecycle;
complete closing structures.

🎮 Three.js Specialization

Three.js is one of the primary specialization targets of OBSIDIAN.

Training examples contain patterns involving:

Scene creation
Perspective cameras
Lighting
Meshes
Materials
Geometry
Animation loops
Keyboard input
Mouse interaction
Game mechanics
Collision logic
3D environments
Interactive simulations
Complete browser games
Single-file Three.js applications

The objective is not simply to teach isolated Three.js API calls.

The model is trained to connect the different components required to produce an actual working application.

For example:

text

Scene
  │
  ├── Camera
  ├── Renderer
  ├── Lighting
  ├── Objects
  │
  └── Materials
  │
  ├── Input
  ├── State
  ├── Game Logic
  └── Animation Loop

🌐 Frontend Generation

OBSIDIAN has strong exposure to complete frontend applications combining:

text

HTML
 │
 ├── CSS
 │
 └── JavaScript
       │
       ├── DOM
       ├── State
       ├── Events
       ├── Canvas
       ├── Three.js
       ├── Rendering
       └── Animation

A typical training target may contain an entire application:

html

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">

    <style>
        /* Complete interface */
    </style>
</head>

<body>

    <main>
        <!-- Complete application -->
    </main>

    <script>
        // Application state

        // Event handling

        // Rendering

        // Interaction

        // Animation loop
    </script>

</body>
</html>

The objective is to reduce common failure modes where coding models generate the beginning of an application but fail to correctly complete its architecture.

🌍 Multilingual Programming

OBSIDIAN was fine-tuned with programming instructions across 10 languages.

Language	Code
Português	`pt`
English	`en`
Español	`es`
Français	`fr`
Deutsch	`de`
Italiano	`it`
日本語	`ja`
简体中文	`zh`
Русский	`ru`
Türkçe	`tr`

The goal is to make coding capability less dependent on the natural language used in the instruction.

A developer can therefore ask for implementations using prompts in multiple languages while still requesting code in the same programming ecosystem.

🗃️ Training Dataset

OBSIDIAN-9B-Coder was fine-tuned using Coder Max Multilingual.

Dataset:

guell00/Coder-max

Coder Max is a conversational supervised fine-tuning dataset focused heavily on code generation.

The corpus was designed around complete implementations rather than heavily truncated programming responses.

Dataset Characteristics

Characteristic	Description
Format	JSONL
Structure	Conversational messages
Training Type	Supervised Fine-Tuning
Languages	10
Main Content	Programming
Code Density	~95%+
Frontend Focus	Strong
Three.js Specialization	Strong
Long Code Outputs	Preserved

📊 Coder Max Scale

Coder Max is distributed in multiple incremental variants.

Variant	Physical Size	Records	Messages	Code Density
`001MB`	3,739,874 B	109	220	99.08%
`010MB`	12,709,008 B	969	2,012	96.18%
`100MB`	102,679,666 B	9,790	20,396	95.84%
`300MB`	302,689,973 B	29,233	60,916	95.83%
`500MB`	502,678,782 B	48,676	101,442	95.82%
`600MB`	602,666,385 B	58,466	121,848	95.82%
`001GB`	1,002,677,454 B	97,499	203,200	95.82%
`total_4GB`	4,002,669,404 B	390,302	813,452	95.81%

The larger variants contain the content represented by the smaller variants, allowing different training scales without requiring manual concatenation.

🧹 Dataset Curation

Coder Max was built with a code-oriented preprocessing pipeline.

Important characteristics include:

Code Density

More than 95% of the larger corpus variants consist of code-oriented content.

Python Syntax Validation

Python blocks were structurally checked during preprocessing.

Invalid or corrupted samples could therefore be removed before training.

Complete Code Preservation

Long HTML, CSS and JavaScript applications are preserved rather than intentionally truncated.

This is especially important for teaching:

closing tags;
application state;
complete functions;
event listeners;
rendering loops;
lifecycle logic.

Data Sanitization

The preprocessing pipeline targets removal of artifacts such as:

credentials;
API keys;
local IP addresses;
runtime artifacts.

Provenance

Dataset records include SHA-256-based provenance metadata.

🧪 Fine-Tuning

OBSIDIAN-9B-Coder was produced using supervised fine-tuning with LoRA.

Training configuration:

text

Training method          LoRA
Precision                BF16
LoRA rank                16
LoRA alpha               32
LoRA dropout             0
Context target           32,768
Trainer                  Unsloth
Optimizer                AdamW BNB 8-bit
Scheduler                Cosine
Response-only training   Enabled

LoRA target modules:

text

q_proj
k_proj
v_proj
o_proj
gate_proj
up_proj
down_proj

🧬 Training Strategy

The model was trained using a code-heavy SFT corpus designed around long-form completions.

Important characteristics include:

long HTML responses;
complete application generation;
high-value specialization examples;
multilingual prompt variants;
frontend-oriented training;
Three.js exposure;
Canvas exposure;
JavaScript-heavy examples;
assistant-response-only loss.

Some repetitions in the source dataset may be intentional.

Selected programming concepts and application patterns can be repeated to reinforce specific behaviors and specialization targets.

📦 GGUF

OBSIDIAN-9B-Coder is distributed in GGUF format for efficient local inference.

Available quantizations include:

File	Quantization	Recommended Use
`Qwopus3.5-9B-Coder.Q8_0.gguf`	Q8_0	Maximum practical GGUF fidelity
`Qwopus3.5-9B-Coder.Q6_K.gguf`	Q6_K	High quality
`Qwopus3.5-9B-Coder.Q5_K_M.gguf`	Q5_K_M	Quality / size balance
`Qwopus3.5-9B-Coder.Q4_K_M.gguf`	Q4_K_M	Recommended general use
`Qwopus3.5-9B-Coder.Q3_K_M.gguf`	Q3_K_M	Memory-constrained systems
`Qwopus3.5-9B-Coder.BF16-mmproj.gguf`	BF16 mmproj	Multimodal projector

⚖️ Quantization Guide

text

              QUALITY
                 ▲
                 │
Q8_0      ████████████████████
Q6_K      ██████████████████
Q5_K_M    █████████████████
Q4_K_M    ███████████████
Q3_K_M    ████████████
                 │
                 └──────────────► LOWER MEMORY

Q8_0

Use when preserving model fidelity is more important than memory consumption.

Q6_K

High-quality option with lower requirements than Q8_0.

Q5_K_M

Strong compromise between model fidelity and memory requirements.

Q4_K_M

Recommended starting point for most local deployments.

Q3_K_M

Designed for systems where memory consumption is the primary constraint.

For coding workloads, Q4_K_M and Q5_K_M are good starting points.

🚀 llama.cpp

For compatible text inference:

llama-cli -hf guell00/OBSIDIAN-9B-Coder --jinja

For compatible multimodal inference:

llama-mtmd-cli -hf guell00/OBSIDIAN-9B-Coder --jinja

The exact command and available features depend on the installed llama.cpp version and selected GGUF files.

💻 Example Prompts

Three.js Game

text

Create a complete Three.js game inside a single HTML file.

Include:

- responsive rendering;
- perspective camera;
- dynamic lighting;
- keyboard controls;
- collision logic;
- score system;
- restart functionality;
- animation loop.

Return the complete HTML file.

Frontend Application

text

Create a complete responsive web application using HTML,
CSS and vanilla JavaScript.

The application must include:

- modern interface;
- internal state;
- animations;
- user interaction;
- responsive design.

Return a single complete HTML file.

Portuguese

text

Crie uma aplicação web completa usando HTML, CSS e JavaScript.

A aplicação deve possuir uma interface moderna, animações,
estado interno e interação com o usuário.

Retorne o arquivo HTML completo.

Canvas

text

Build a complete interactive particle simulation using the
HTML5 Canvas API.

Include mouse interaction, animation, responsive resizing
and performance-conscious rendering.

Python

text

Implement a complete Python solution for the following problem.

Explain the algorithm briefly and return working code.

🎛️ Generation Settings

Coding tasks generally benefit from conservative sampling.

A reasonable starting point:

text

temperature: 0.2
top_p: 0.9

For more creative frontend generation:

text

temperature: 0.5 - 0.7
top_p: 0.9 - 0.95

These values are starting points rather than guaranteed optimal settings.

Generation parameters should be benchmarked for the target workload.

🎯 Intended Use

OBSIDIAN-9B-Coder is intended for:

Coding assistants
Frontend code generation
HTML/CSS/JavaScript generation
Three.js applications
Browser games
Canvas applications
Interactive interfaces
Python programming
Programming experiments
Multilingual coding assistants
Local coding models
Research into code-specialized fine-tuning

📏 Evaluation

Executable evaluation is strongly recommended for coding models.

A useful evaluation pipeline is:

text

PROMPT
  │
  ▼
GENERATE
  │
  ▼
PARSE
  │
  ▼
EXECUTE
  │
  ▼
INSPECT
  │
  ▼
TEST

Useful evaluation categories include:

HTML completeness
CSS validity
JavaScript syntax
JavaScript runtime behavior
Three.js initialization
Rendering-loop correctness
DOM interaction
Canvas rendering
Python syntax
Algorithmic correctness
Long-response completion
Multilingual instruction following

For code-generation models, executable correctness is generally more informative than text similarity alone.

⚠️ Limitations

OBSIDIAN-9B-Coder is a generative model.

Generated code can contain:

logical errors;
security vulnerabilities;
hallucinated APIs;
outdated library usage;
incomplete edge-case handling;
incorrect assumptions;
dependency incompatibilities.

Generated applications should be inspected and tested before production deployment.

Long context capacity also does not guarantee perfect reasoning or perfect retention across every token of a long prompt.

🧬 Model Lineage

OBSIDIAN-9B-Coder was not trained from scratch.

Its lineage is:

text

Qwen3.5 family
       │
       ▼
Jackrong/Qwopus3.5-9B-Coder
       │
       ▼
Coder Max Multilingual
       │
       ▼
LoRA Supervised Fine-Tuning
       │
       ▼
OBSIDIAN-9B-Coder
       │
       ▼
GGUF Quantizations

OBSIDIAN therefore inherits substantial pretrained and coding capabilities from its base model while adding specialization through Coder Max.

📚 Training Sources

Base Model

OBSIDIAN-9B-Coder was fine-tuned from:

Jackrong/Qwopus3.5-9B-Coder

Hugging Face:

https://huggingface.co/Jackrong/Qwopus3.5-9B-Coder

The Jackrong model is itself a coding-focused derivative of the Qwen3.5 model family and provides the underlying pretrained and coding capabilities used as the starting point for OBSIDIAN.

Fine-Tuning Dataset

The dataset used for the OBSIDIAN fine-tuning stage was:

Coder Max Multilingual

Author: guell00

Hugging Face:

https://huggingface.co/datasets/guell00/Coder-max

Coder Max provides the additional specialization toward:

complete code generation;
HTML/CSS/JavaScript;
Three.js;
Canvas;
Python;
interactive applications;
long-form implementations;
multilingual programming instructions.

🏗️ Training Stack

text

Qwen3.5 Model Family
        │
        ▼
Jackrong/Qwopus3.5-9B-Coder
        │
        │  Base model
        ▼
Coder Max Multilingual
guell00/Coder-max
        │
        │  Code-focused SFT data
        ▼
LoRA + SFT
Unsloth
        │
        ▼
OBSIDIAN-9B-Coder
        │
        ▼
GGUF
        │
        ├── Q3_K_M
        ├── Q4_K_M
        ├── Q5_K_M
        ├── Q6_K
        └── Q8_0

🙏 Credits

OBSIDIAN-9B-Coder builds upon work from the open-source model ecosystem.

Qwen

For the underlying Qwen model family and architecture.

Jackrong

For Qwopus3.5-9B-Coder, used as the direct base model for this fine-tuning.

Unsloth

For the efficient fine-tuning and model conversion tooling used during training.

guell00

For:

Coder Max Multilingual
OBSIDIAN fine-tuning
dataset preparation
model specialization
GGUF release

💎 OBSIDIAN-9B-Coder

text

Base
  Jackrong/Qwopus3.5-9B-Coder

        +

Dataset
  guell00/Coder-max

        +

Fine-Tuning
  LoRA SFT / Unsloth

        =

  OBSIDIAN-9B-Coder

9B · 32K Training Context · Three.js · JavaScript · HTML · CSS · Canvas · Python · Multilingual

OBSIDIAN-9B-Coder — specialized for complete code generation.