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 model is not released yet. The current artifact is a conservative data-production pipeline that has passed the GCTX-1 strict data gate and is ready for the first proof language-model run.

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: the model does not need to be a general coding assistant; it needs to understand a diff, identify the intent, choose an accurate type and scope, and explain the change without inventing context.

That makes GCTX a good proving ground for an open-source model workflow:

• the task is valuable enough to become a real developer tool;
• the output is easy to inspect;
• quality can be checked with deterministic Conventional Commit rules plus human review;
• the dataset can be built from public repositories with explicit license review;
• the same infrastructure can later support larger or different code-context models.

The practical bet is that a small model can be useful when the task is narrow enough and the data loop is strict enough. A general assistant has to answer almost anything. GCTX has a smaller job: read one Git change, decide what kind of change it is, and write one message in a known format. That makes every part of the project easier to audit. Bad examples can be rejected. Outputs can be scored mechanically. Held-out repositories can be reserved before generation. Progress can be measured without pretending that the model is generally intelligent.

How it differs

The first principle is that GCTX should be more than an open-weight release. The intended release path includes source manifests, data cards, model cards, review artifacts, and reproducible scripts for turning approved public Git history into supervised examples.

The current pipeline is deliberately conservative:

• source repositories are selected through a reviewed manifest;
• source diffs are extracted into named artifacts;
• source diffs are reviewed before any teacher labeling;
• teacher labels are generated locally, one diff at a time, with retry-safe provenance;
• generated labels are reviewed as accept, edit, or reject;
• labels are not training data until a promotion/data-card decision says how they may be used.

The first local teacher is a Qwen Coder model served through Ollama. That teacher is only part of the data-production process; the project target is a smaller specialized language model released under an open-source-friendly process, with gitctx as the first practical CLI interface.

Why not just train on Git logs?

The tempting shortcut is to take public repositories, collect every historical commit message, and train on those messages directly. The problem is that public Git history is not automatically high-quality instruction data. Many commits are merge commits, dependency bumps, release bookkeeping, vague subjects, issue-number-only messages, inconsistent house styles, or broad mixed changes. Even good maintainers often optimize commit messages for their own project history, not for a reusable Conventional Commit assistant.

The current data shows this clearly. In the first reviewed GCTX-1 artifact, reviewed targets are Conventional Commit format-valid on 6,727/6,727 records. Original historical commit subjects are only 1,785/6,727 format-valid, and 112/1,129 format-valid on the REPORT subset. In the larger gctx1-strict.v0 artifact, reviewed targets are 11,926/11,926 format-valid while historical subjects are 3,517/11,926 format-valid. That does not mean historical messages are useless; they still help identify real diffs and real developer intent. But they are not clean enough to be the main supervised label without filtering or regeneration.

So the pipeline uses public Git history as the source of real code changes, not as the final label source. The label is regenerated from the diff, then reviewed. That is slower than scraping commit logs, but it produces cleaner examples and gives every training record a provenance trail.

Data production loop

The core loop is intentionally explicit:

1. Choose source repositories. Each repo enters through a manifest with license and revision metadata.
2. Extract source diffs. The extractor records one source-diff example per commit, with changed paths, stats, parent/source commit IDs, split assignment, and provenance.
3. Review source diffs. Records that are docs-only, CI-only, release bookkeeping, very broad, or weak for the target task are rejected before teacher labeling.
4. Create teacher inputs. Only accepted source diffs become full prompt payloads.
5. Generate one label per call. Each diff is sent independently to the local teacher. This keeps retries, validation, and provenance simple.
6. Validate generated labels. Outputs must be JSON-shaped and must satisfy the Conventional Commit parser/scorer.
7. Review generated labels. Human review marks labels as accept, edit, or reject.
8. Promote to training data. A data-card/output-use decision says exactly what the resulting artifact may be used for.

This design is deliberately not fully automatic. Automation helps generate candidates and run validators, but a small model trained on a narrow task is only as good as the examples that survive the gates.

Status

As of 2026-06-28, GCTX has passed its first strict data-readiness gate for a proof model. There is no released model yet, no public JSONL training dataset, and no model-quality claim. The current public claim is narrower: the pipeline can produce reviewed, source-attributed private supervised artifacts from permissively licensed Git history, and the first proof language-model run now has enough reviewed DEV and locked REPORT data to start.

The pilot and next-v0 passes validated the review loop before GCTX-1. The pilot used Click, Requests, and Pluggy, then produced 114 reviewed labels. The next pass produced a 335-record private supervised artifact, baseline reports, record-level REPORT inspection, a dependency-free path-type smoke model, and a tiny softmax smoke model. That work was enough to prove the artifact path, but not enough to justify a useful model.

The first larger source plan is GCTX-1. The initial GCTX-1 source artifact contained 17,511 source-diff records from 37 permissively licensed public repositories:

Split	Source diffs	Repositories
DEV	13,567	37
REPORT	2,431	24
HELD_OUT	1,513	21

Source review accepted 7,989 records for teacher labeling and rejected 9,522 records before generation. HELD_OUT records stayed reserved; they were not sent into teacher generation or promoted into training data.

Source-review decision	Count
Accepted for teacher labeling	7,989
Rejected before teacher labeling	9,522
Needs review	0

The first GCTX-1 teacher-generation pass produced 7,983 labels from 7,989 teacher inputs, with 6 recorded generation failures. Human review covered all 7,983 generated labels. The resulting gctx1-v0 private supervised artifact contains 6,727 reviewed training records.

The later strict expansion merged additional DEV-only passes into gctx1-strict.v0. The strict artifact now contains 33,152 source-diff records, 14,104 teacher inputs, 14,090 generated labels, and 11,926 reviewed supervised training records. Fourteen teacher inputs are recorded as missing generated labels across the merged lineage; they were not promoted into training.

Artifact	Training records	DEV	REPORT	HELD_OUT in training
gctx1-v0	6,727	5,598	1,129	0
gctx1-strict.v0	11,926	10,299	1,627	0

gctx1-strict.v0 now has baseline and proof-readiness reports. Reviewed targets are 11,926/11,926 format-valid, including 1,627/1,627 on REPORT. Original historical commit subjects are only 3,517/11,926 format-valid, and 285/1,627 on REPORT, which supports the decision to regenerate and review labels instead of training directly on public Git subjects.

The GCTX-1 strict smoke evals are also complete. The dependency-free path-type prototype trained on 10,299 DEV records and produced 1,627/1,627 format-valid REPORT predictions, with 932/1,627 type matches and 0 exact message matches. The tiny softmax classifier trained on the same DEV split, moved loss from 1.061279 to 0.820147, and produced 1,627/1,627 format-valid REPORT predictions, with 988/1,627 type matches and 0 exact message matches. These are pipeline checks, not evidence that GCTX is already a useful language model.

The strict proof-readiness report is now green. The next work is not another default data-expansion pass; it is implementing or selecting the trainer path for a 60M-100M proof language model, training from gctx1-strict.v0 DEV records, and evaluating on locked REPORT.

Current architecture

The working pipeline has four artifact layers:

1. Source manifest — license-reviewed public repositories and pinned revisions.
2. Source diffs — extracted Git diffs with paths, stats, source commit, parent commit, split, and provenance.
3. Teacher inputs — full prompt payloads for source diffs accepted for teacher labeling.
4. Generated labels and reviews — model-produced Conventional Commit candidates plus human decisions and edits.

The code path supports named artifacts such as smoke, pilot, next, and gctx1, so future batches can be generated, validated, retried, reviewed, and promoted without mixing stages.

Evaluation philosophy

GCTX uses multiple evaluation layers because no single metric is enough.

The first layer is deterministic format scoring. A candidate message must parse as a Conventional Commit. It must have a valid type, optional scope, subject, and any required body/footer structure. This catches many failures cheaply, but it does not prove semantic quality.

The second layer is split-based reporting. DEV records are allowed to influence training. REPORT records are used for visible evaluation during development. HELD_OUT records must be reserved before generation and kept away from tuning decisions. That separation matters because small projects can accidentally overfit their evaluation set simply by repeatedly looking at it.

The third layer is record-level inspection. Aggregate scores can hide bad behavior. The REPORT inspection artifact exists so individual failures can be reviewed: wrong type, wrong scope, invented context, mixed-change confusion, or a message that is valid but unhelpful.

The fourth layer is model-artifact validation. The dependency-free prototype and tiny neural smoke do not claim useful model quality. They prove that reviewed SFT records can drive a training run, produce a model artifact, produce predictions, and be evaluated reproducibly. The next model work should move from pipeline validation toward actual language-model behavior.

Current gates

The current GCTX-1 proof target is:

All current proof-readiness gates pass for gctx1-strict.v0. That is a useful but limited milestone: the source/review/generation/eval machinery is working, and the next claim must come from an actual proof language model evaluated on locked REPORT.

Next

The immediate milestone is to train the first GCTX-1 proof language model without weakening the data gates.

The concrete next sequence is:

1. Implement or select the trainer path for a 60M-100M proof language model.
2. Train from gctx1-strict.v0 DEV records.
3. Evaluate on locked REPORT before making any model-quality claim.
4. Keep HELD_OUT reserved and unused until later release-claim evaluation.
5. Write the model card and eval card from the REPORT result.

CLI packaging for gitctx.com remains after the model/eval loop shows measurable behavior. The CLI should be a product shell around a real model, not a substitute for the model work.

Where it lives

• Repo: github.com/serkanaltuntas/gitctx
• Planned CLI/product home: gitctx.com
• This page tracks the build-in-public status until the first public model/data release.