DeepFabric's pitch is topic coverage, and its core install pulls in five model providers

The claim is coverage, and the mechanism is a graph of topics

The tool's differentiator is stated in a single paragraph, and it is about redundancy rather than volume. Where other dataset generators sample prompts and hope the set covers the domain, this one builds a topic graph first, using generation algorithms it describes as producing high diversity with domain anchored relevance, so that all necessary subtopics get covered without repeating each other. The stated failure mode of the alternatives is model overfit, which follows from a dataset that keeps saying the same thing in different words. The quickstart illustrates the shape of that graph. A topic prompt, a generation system prompt, a mode set to graph, a depth of 3, a degree of 3, and 9 samples produce, according to the page, 27 unique nodes and 27 training samples written to a JSON lines file, with full topic coverage claimed for the result. The honest reading is that this is a self reported figure for one small configuration, not a benchmark.

Depth 3 and degree 3 yield 27 nodes, which is three cubed

The arithmetic in the quickstart is worth pausing on. The install is one command:

pip install deepfabric

and generation is one more, with every parameter on its own line:

deepfabric generate \
  --topic-prompt "Python programming fundamentals" \
  --generation-system-prompt "You are a Python expert" \
  --mode graph \
  --depth 3 \
  --degree 3 \
  --num-samples 9 \
  --batch-size 3 \
  --provider openai \
  --model gpt-4o \
  --output-save-as dataset.jsonl

Depth 3 with degree 3 and 9 requested samples produces 27 nodes, and 27 is three cubed, not a branching factor times a breadth. A graph expanding by a branching factor of 3 to depth 3 would carry forty nodes or more before deduplication, so the parameters here behave more like a fixed cube than like a tree, with a batch size of 3 governing how many samples are requested per pass. The same command exposes the two topic modes as a single flag, and the repository's example configurations include one file per mode, so the difference between a chain and a network of subtopics is a one word edit. The output path is set on the command line as well, and a second run with a different file name is how you keep two datasets side by side.

Tool definitions arrive as MCP schemas and run inside WebAssembly

The part of the pipeline with real engineering behind it is tool execution. Rather than ask a model to write a plausible tool call and print it, DeepFabric runs the tools, and it describes those executions as happening inside isolated WebAssembly environments. On top of that sit constrained decoding and response validation, so a sample that violates its schema or a variable constraint is rejected at generation time rather than discovered later in a training run. Tool definitions can be imported from Model Context Protocol server schemas and automatically mocked, or taken from a standard set of common operations, and the example list includes a file listing and a file read. Mocked execution is not free, though: the page says it needs a running Spin service, which the project ships as a container image. The printed command for that image is not copyable as it stands, because a stray backtick sits after the image tag at the end of the line.

One install brings five provider clients and an analytics SDK

The dependency list is where an otherwise careful project stops being careful. The core requirements include clients for OpenAI, Anthropic, Google, a local Ollama runtime, and a hub client for a second dataset host, plus a constrained decoding library and a machine learning framework, both pinned to exact versions while almost everything else floats. The one that deserves a second look is a hosted product analytics package sitting in the required list rather than in an extra, which means a plain install of this library pulls in an endpoint client for someone else's usage tracking. Two more small inconsistencies: a diagram rendering library appears in the core list with one lower bound and again in the development extra with a different one, and the package metadata carries a different one line description than the project summary does, so the two disagree about what the tool is for.

Training is an extra, so the page's training snippet cannot run after a plain install

The generate, train, evaluate walkthrough is where a reader is most likely to hit a wall. The generation step is fine, since the generator is in the core package. The training step imports a reinforcement fine tuning trainer and, further down, the evaluation step imports from the package's own evaluation module. But the core dependencies contain no deep learning framework and no trainer, because they live in a separate extra alongside an adapter library and an accelerator. So the page shows a training snippet that only works if you installed an extra the quickstart never mentions. The same walkthrough says generated datasets can be imported into several popular trainers, while the extra pins exactly one of them, which is a reasonable choice and a confusing one to discover at the point of failure.

The quick integration target spends real money on model APIs

The Makefile shows how the project runs its own tests, and the marker layout is the interesting part. Unit tests are separate from integration tests, and the integration tests are filtered by markers for individual providers, for a second host, and for the WebAssembly runtime. There is a target that runs everything not marked as the remote host, and on a first read that target is not a smoke test: it includes the provider marked tests, so running it means sending real requests to paid APIs. There is also a target for everything marked as the remote host, which implies those tests hit the network as well. Two smaller facts. The build target depends on the unit tests, so packaging runs a test suite first, and the clean target removes a coverage data file, while a coverage report sits committed at the repository root instead.

The homepage is plain http, the releases skipped eight months, and a directory is unexplained

Three housekeeping details are visible without reading any code. The recorded homepage for the project is a documentation address without a TLS scheme, while every other link on the page is https. The release history has a gap: two releases in early February 2026, then nothing until a version released on the same day as the most recent push, late September. And the repository root holds two directories whose relationship the page never states, one for a toolkit and one with a similar name, plus a directory called test run that nothing in the visible page refers to at all, a checked in coverage report, and a contributor instruction file for coding assistants. None of these are blockers. Together they are the list of questions a reader has to ask in an issue tracker before trusting the packaging.

Editorial conclusion

DeepFabric is worth a look if your training data needs a schema a model can be held to, because the tool executions are real and the decoding is constrained, and the topic graph is a better answer to redundancy than sampling a prompt list. Before you install, read the dependency list rather than the pitch: a plain install brings clients for five providers and an analytics SDK, and the training snippet on the page will not run until you add the training extra. Also fix the trailing character in the printed container command, and decide whether sending usage to a hosted analytics endpoint is acceptable for your data.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. nolabs-ai/deepfabric on GitHub
3. Project website
4. README
5. Releases