In this analysis
Repository existence, visible code, an announcement, and a runnable revision are separate milestones that need directly matching evidence.
A repository can exist before it contains the artifact that later attracts attention. That simple distinction matters when reconstructing the DeepInfer release. The directly inspected initial public commit provides a concrete code reference, while earlier model publications explain the problem it addresses. A careful chronology should not replace one kind of timestamp with another.
Dated background
-
2026-04-24: DeepSeek-V4 Preview.
-
2026-09-17: DeepSeek-V4.1-Flash.
-
2026-10-20: DeepInfer initial public commit.
The preceding model timeline is a different timeline
The earlier DeepSeek announcement and architecture report document model development and disclosure. They explain why an inference framework became relevant, but they do not date the later code artifact. Our interpretation is that retrospective coverage becomes unreliable when related milestones are merged because they concern the same project family. A model paper, a hosted interface, and an engine repository may advance on different schedules. Preserving those schedules allows the story to show real dependencies without inventing simultaneous availability. The connection between events should be explained, not used as a substitute for direct evidence.
What a commit reference actually establishes
A specific commit identifies a tree of versioned files and provides a stable object for inspection. That makes it more useful for discussing code content than a repository creation field alone. However, a commit timestamp does not automatically prove every detail of when outsiders first gained access; visibility and later history changes can be separate concerns. The directly verified public commit is the concrete anchor used here. This wording is deliberately narrower than claiming the earliest possible global access time. It reports the artifact that can be inspected instead of turning incomplete metadata into a stronger historical assertion.
A proposed provenance record
For an illustrative code-release record, retain the repository URL, inspected commit identifier, observation date, relevant file paths, and the statement each file supports. Keep an announcement date in another field. If a source only provides repository creation, record that fact without labeling it as code release. This is a research method, not a new performance test. It enables later readers to reproduce what was visible in the inspected artifact and to distinguish a historical statement from a current README. That distinction matters when the project adds features after the initial publication.
A better retrospective survives later changes
Repositories evolve, so an article that relies only on the latest branch can silently acquire evidence unavailable at the event date. A pinned initial artifact limits that problem, while a later branch can be cited separately as current context. The lesson extends beyond DeepInfer: choose the timestamp whose object matches the sentence being written. Use a paper date for research disclosure, a commit for versioned code, and an observed run for execution evidence. This produces a less dramatic but more useful history, because readers can tell which conclusions follow from the original artifact and which belong to subsequent development.
Technical background: software stack reproducibility; tokenizer artifact release manifest.