CAPCOM's RE:Dox went from 718 GitHub stars in MrKeyoor's October 2 snapshot to 891 when checked at 07:30 UTC on October 3. The gain is 173 stars, a 24% jump in about 13 hours, for a repository created on September 30. Few data libraries draw that much attention so quickly. CAPCOM released a .NET 10 structured-data engine taken from the technology work behind its next-generation game engine, with source code, packages, tests and benchmarks under an Apache 2.0 license.
RE:Dox is one component of what CAPCOM calls REX technology. CAPCOM has not opened the REX engine or its game editor. The company's 2025 account of its engine work says REX will evolve the existing RE ENGINE in stages instead of replacing it wholesale. RE:Dox gives outside developers a close look at one lower-level problem inside that effort: how an engine reads, edits and converts structured data without paying for a large managed object tree on every operation.
The launch also carries an odd warning for anyone deciding whether to adopt it now. GitHub labels v1.0.0 as the first release, and NuGet serves the core package as version 1.0.0. Yet the repository's status section says APIs, package boundaries and preview format support may change before the first stable public release. A team should treat the version number as an imperfect stability signal.
A 64-bit token sits under every format
RE:Dox parses input into a compact token document model, or DOM. CAPCOM's README says each value is described by a fixed-size 64-bit token. One mode lets the format layer interpret a source-backed payload. The other uses RE:Dox's own representation and control tokens so callers can insert, remove or replace values. Unchanged values can keep pointing at slices of the original input instead of being decoded immediately.
That layout is meant to combine fast sequential access with in-place editing. A conventional tape-style DOM stores a flat run of tokens and is usually read-only. RE:Dox adds indirection through its array, object and map views, then reuses vacated token slots through a free list. The architecture notes say strings, numbers, timestamps and binary values can remain undecoded until code asks for them. That can reduce allocation when an application needs to inspect or alter only part of a document.
Reading and writing take different paths. Serialization writes known values directly to an output buffer without building an intermediate tree. Deserialization first creates the token index, which gives the reader random access to the document. CAPCOM says this lets RE:Dox pre-size collections, bind constructor arguments that arrive out of order, resolve object references and decide whether a large array warrants parallel work. Those are documented design choices, rather than features inferred from the benchmark chart.
The core package installs with one command, provided the project already targets .NET 10 or later:
dotnet add package CAPCOM.REDox
The quick example uses familiar JsonSerializer calls, then parses the result into a document whose root object can be edited. That surface may ease experiments by teams accustomed to System.Text.Json, although the similarly named types make namespace choices worth checking in an existing codebase.
The same token layer reaches beyond ordinary JSON. RE:Dox can stream NDJSON or the elements of a top-level JSON array without loading the whole input at once. There is a lifetime rule to notice: the element yielded by the streaming parser is backed by a reused document and remains valid only until the next iteration. The streaming documentation tells callers to clone an element or convert it to a .NET type when it must survive. That is the kind of detail a successful microbenchmark will never catch for you.
CAPCOM's numbers define a test, not a general result
CAPCOM reports its JSON deserializer running 1.36 to 1.77 times as fast as System.Text.Json across three included datasets. With automatic parallel deserialization, the reported range rises to 2.25 to 2.84 times. Serialization ranges from 1.06 to 1.62 times as fast in the same table. The benchmark setup uses BenchmarkDotNet, .NET 10, Windows 11 and an AMD Ryzen Threadripper Pro 5975WX. Those numbers describe that machine, runtime and input set.
The allocation result may matter as much as elapsed time for services that repeatedly parse large payloads. On the roughly 2.2MB canada.json file, the published table records about 2.56MB allocated by RE:Dox during deserialization and about 8.53MB by System.Text.Json. Its parallel path allocated about 2.62MB and completed in 5,384.6 microseconds, compared with 15,303.1 microseconds for System.Text.Json. CAPCOM prints the raw means and allocation totals in the repository benchmark table, so developers can inspect more than a single multiplier.
All three files belong to the repository's chosen suite, even though they have different shapes. The hardware has many cores, which is favorable terrain for automatic parallel deserialization. CAPCOM itself says the ratios are not universal guarantees and tells users to benchmark their own workload. The repository includes the exact command and brings its sample data in through git submodules, making the experiment reproducible without making it independent.
Parallel execution is also conditional. The README's example enables it with thresholds of 1,024 elements and 4,096 tokens, while small arrays remain sequential to avoid scheduling overhead. That means a service processing many short messages may see a different profile from a batch job decoding a large array. The configuration example is a useful starting point, but production data should decide the thresholds.
The format list is wider than the stable surface
The release page lists 12 NuGet packages. The repository marks the core, CBOR, MessagePack, dynamic access, DataContractJson compatibility and INI packages as public. It labels the System.Text.Json and Newtonsoft.Json compatibility layers as preview, alongside TOML, XML, HTML and CSV support. CAPCOM's package table warns that preview behavior can change. A project attracted by the broad format diagram should check the status of the one format it needs.
Cross-format conversion has another boundary. JSON, CBOR and MessagePack can share the token representation, and JSON5 editing can preserve comments and other trivia. For formats with different native data models, CAPCOM says conversion may use a structural projection rather than a lossless semantic round trip. The conversion notes make that caveat explicit. A successful XML-to-JSON conversion therefore does not prove that converting the output back will reproduce the original document.
The minimum runtime narrows the immediate audience. The source targets net10.0, and the published package metadata declares .NET 10. Teams staying on an earlier long-term support runtime cannot drop the package into place. For teams already testing .NET 10, the dependency surface is unusually small: the core package metadata declares no package dependencies for that target.
Apache licensing does not settle the contribution model
CAPCOM released the code under Apache 2.0, so developers can inspect, modify and redistribute it under that license's terms. The repository includes the serializer source, format implementations, unit tests and BenchmarkDotNet projects. Its README also says the library packages do not bundle the third-party datasets used for conformance tests and benchmarks. Instead, projects such as JSONTestSuite and toml-test arrive as submodules under their own licenses.
The contribution path is more controlled than the license. CAPCOM's contribution guidelines invite bug reports, questions and feature suggestions through GitHub Issues. For code changes, the document says CAPCOM will triage submitted reports and suggestions and aim to implement them. It does not describe a process for accepting outside pull requests. Forking is allowed by the license, while upstream participation currently starts with an issue.
That distinction fits the source's origin. CAPCOM says RE:Dox is being developed as part of REX, while its corporate report says roughly 160 of about 200 engineers in the relevant department work on engine development. The same report says REX is being integrated step by step into the existing engine program. That origin suggests outside requests may need to fit an internal game-production roadmap, even when the released library is useful far beyond games.
The next useful evidence will be independent tests on ordinary server CPUs and a clear statement about compatibility after v1.0.0. The GitHub API count shows that developers are already paying attention. Before replacing a serializer, take CAPCOM up on the more modest invitation in its README: clone the repository, run the included benchmark against your data, and use that local result to decide whether RE:Dox belongs in the project.