GCTX — a language model for Git diffs

What it is

GCTX is a from-scratch small language model family for understanding Git diffs and writing Conventional Commit messages.

The model goal comes first: build a narrow language model that can read a code change, infer intent, and produce a concise Conventional Commit message. gitctx is the CLI and product shell around that model; the main work is the data, training, evaluation, and release process behind GCTX.

The first full model has been trained and evaluated. There is no released model or public training dataset yet, and useful generalization has not been demonstrated.

Why it exists

Commit messages are small, structured, repetitive, and still surprisingly easy to get wrong. They are also a useful narrow target for a small language model: it needs to understand a diff, identify the intent, choose an accurate type and scope, and explain the change without inventing context.

The task is valuable enough to become a developer tool, while individual outputs remain easy to inspect. Public Git history supplies real changes with explicit source and license records. Deterministic format checks can catch structural errors; checking a message against its source diff is still necessary to establish whether it describes the change correctly.

How it differs

GCTX is intended to be more than an open-weight release. The planned release includes source manifests, data cards, model cards, review artifacts, and reproducible training and evaluation scripts.

Historical commit subjects are source context, not automatic ground truth. The pipeline extracts diffs from selected public repositories, generates candidate messages locally with a Qwen Coder teacher, records acceptance decisions, and promotes artifacts under an explicit data-card decision. The specialized GCTX model is trained from scratch; the teacher supplies candidate labels.

Earlier project text described generated-label acceptance as human review. That description was too strong. Historical labels passed automated acceptance checks; later assistant screening against original diffs found factual errors those checks had missed. Neither process establishes independent human factual review of the full dataset.

Status

As of October 13, 2026, the project is working through model-training diagnostics. Engineering milestones have advanced; the model has not passed the usefulness gate.

The June strict artifact contained 11,926 accepted supervised records: 10,299 DEV and 1,627 REPORT. Three DEV records were excluded from the first training plan, which used 10,296 examples. These are historical artifact counts, not a claim that every label has since passed a factual audit. A later audit found one training/REPORT duplicate; it is quarantined for subsequent selection. Later diagnostics stayed within DEV, and HELD_OUT remains reserved.

After the input repairs, a new training run reduced validation loss by 51.25% but scored 0/64 on the fixed DEV panel measuring whether messages described the principal change correctly. It stopped after the first epoch under its predefined quality rule.

The October 4 comparison then tested three learning rates from identical model and optimizer states, using the same 56 checked training examples and equal training budgets:

GCTX can reliably fit that small set. The result does not establish useful generalization or show that data volume is the only remaining problem. Usability judgments came from assistant screening against source diffs, not independent human evaluation.

Evaluation boundaries

• Format validity checks whether the output follows Conventional Commit syntax. It does not establish that the message is true.
• Training-set fitting tests whether the model can learn checked examples it has already seen. It is a diagnostic, not a release-quality result.
• DEV validation supports development decisions. The fixed 64-case panel and the planned 256-case evaluation have already been used during development; neither is an untouched test set.
• REPORT and HELD_OUT have separate roles. The first full run was evaluated on REPORT. Later diagnostics stayed inside DEV; reserved HELD_OUT data remains for later release-claim evaluation.
• Factual review checks the principal change, scope, and unsupported claims against the source diff. Automated acceptance, assistant screening, and independent human review must be identified separately.

Next

The next planned experiment compares 56 versus 512 examples checked against their source diffs, from a common starting checkpoint with equal update budgets. It will evaluate all 256 DEV validation cases. Equal update counts do not imply equal token counts or compute cost.

The design is complete. The immediate work is to prepare the larger subset and check its source support and coverage before starting the comparison. Model release and CLI packaging remain later milestones.

Where it lives

• Source and tools: github.com/serkanaltuntas/gitctx.
• Latest progress note: The first full model training and what followed — October 13, 2026.
• Earlier milestones: Starting GCTX and The first data-readiness gate.
• Planned CLI/product home: gitctx.com.

This is the canonical project page. Journal entries record dated milestones; this page tracks the current state.