The Python package says 0.1.0 alpha while the desktop installer says 1.1.1, and the sandbox is a roadmap item

The package reports 0.1.0 alpha and the installer is named 1.1.1

Two version numbers for one project, and they do not agree.

The packaging metadata gives the distribution name as `determinflow`, version `0.1.0`, and a development status classifier of 3, Alpha. The GitHub releases are at v1.1.1, published on the same day as the last push on 2026-09-11, with v1.1.0 on 2026-09-07 and v1.0.10 on 2026-08-19 behind it. The desktop installers carry the same 1.1.1 in their filenames, for example `DeterminFlow_1.1.1_x64-setup.exe` and `DeterminFlow_1.1.1_aarch64.dmg`.

So the artefact you download is a 1.1.1 build while the library metadata still says an alpha at 0.1.0. For anyone pinning dependencies this matters more than the classification label: a version constraint written against the PyPI-style version will not describe the binary you are running.

Two smaller inconsistencies sit alongside. The license is recorded as AGPL-3.0-only in the manifest and the repository metadata says AGPL-3.0, and the manifest's one-line description calls it a deterministic workflow runtime for production AI systems while the front page describes it as a production AI workflow runtime. Neither is wrong, but they are not the same sentence.

Four requirement files, and the pinned list carries a package the manifest dropped

The root holds `requirements.txt`, `requirements.lock`, `requirements-dev.txt` and `requirements-dev.lock`, and the from-source instructions install the lock file rather than either text file. That is the conservative choice and the one the documentation actually uses.

The manifest's dependency list and `requirements.txt` are near-identical, with one difference. The pinned file contains eighteen packages, all at exact versions, and one of them is `tzdata==2026.3`. The manifest's dependency array lists the other seventeen and omits `tzdata`. The manifest adds `pytest==9.1.1` under a dev extra, and nothing else in the development path.

What is absent from both is as informative as what is present. There is no numerical library, no data-frame dependency, no HTTP client beyond `httpx`, and no model framework beyond the LangChain and LangGraph packages plus the `openai` and `mcp` clients. The orchestration, storage and API layers are first-party.

The Python floor is 3.11 in the manifest, and the classifiers only name 3.11 and 3.12, so a 3.13 install is permitted by the constraint and unclassified by the metadata. The container image is built on Python 3.12 slim.

Community plugins run in the main process, and the sandbox is still on the roadmap

Two sections of the front page address this, and the honesty in them is the most useful thing the project says.

The benefits list ends with a line noting that tools can be narrowed per node and that a stronger sandbox for LLM workspaces is on the roadmap. The community plugin section says more directly that community plugins run with the same permissions as the DeterminFlow main process, that there is no sandbox, and that you need to confirm the risk before installing.

Those two statements are consistent, and the second is the more important one. A community skill that is installed from the built-in source list executes inside the process that holds your workflow state, your workspace files and your model API keys. The page adds that entering the directory only means the structure and the established checks passed, and that this is not an official security endorsement or a promise of continued maintenance. You can also point the plugin page at any Git repository you like, which widens the surface further.

The install path does add two checks, verifying version, source and content digest on install and update. That protects against a changed artefact, not against a malicious one, and the page does not claim otherwise.

The 70 to 89 percent saving has one measured number in it and two estimated ones

The case study rests on a single real production run at a novel-writing service: 11 independent model sessions consuming 176,584 tokens inside DeterminFlow. That part is a measurement.

Everything beside it is an estimate of what a single long-chain agent would have used, and the table says so in its own framing. The heading presents 70 to 89 percent as a saving. The body presents the same range with the word projected, and the footnote attributes it to a real workflow token ledger on one side and to typical overhead from a long-chain agent repeatedly carrying context, tool results and rework records on the other.

The three scenarios give roughly 595,000 tokens at 3.4 times, 970,000 at 5.5 times and 1,610,000 at 9.1 times. Each is labelled by the kind of work involved, from a heavily optimised run with almost no extra tool loops up to one with validation repair, retries or long context.

The two cost columns are worth reading for what they are not. Terra and Sol are priced at a constant ratio of about 2.5 to 1 in all three rows, so the second column is the first multiplied by a price, not an independent measurement. The informative quantity is the token ratio, and even that is a projection of the alternative rather than a record of it.

Two desktop platforms ship, and the macOS build is ad-hoc signed

The installer table covers Windows x64 and macOS Apple Silicon, each in a Core and a Full variant. There is no Linux desktop package, no Intel Mac build and no Windows on ARM.

Core bundles the runtime so that no Python, Node.js or Git is needed, and ships without plugins. Full preinstalls two official plugins, `bishu-novel 0.2.2` and `public-api 0.1.37`, and its plugin versions are pinned in the front page where the core versions are not.

The macOS caveats are specific. Packages are ad-hoc signed and not notarized by Apple, so a fresh install is blocked on first open and the documented path is to allow it in System Settings under Privacy and Security. macOS updates are manual, by downloading a new installer. Upgrading preserves user data, model configuration and installed plugins, and explicitly does not overwrite existing plugins with the Full snapshot; you are told to check the plugin page for updates and restart afterwards. Official plugins support a signed HTTPS accelerated download with Git as the fallback.

Running from source instead needs Python 3.11 or newer, Node.js 22.12 or newer and npm, and two config files have to be copied from their examples before `run.py` starts.

The container binds 8020 on every interface and declares no authentication setting

The compose file is short and worth reading line by line.

    ports:
      - "8020:8020"
    environment:
      WEB_HOST: "0.0.0.0"
      WEB_PORT: "8020"

Three data directories are bind-mounted, `./data`, `./logs` and `./config`, and the executor runs in process mode with a count of four by default. The container is configured to restart unless stopped, and log files are capped at 10 MB across three rotations.

What is absent is as relevant as what is present. There is no authentication variable, no credential, no token and no TLS setting anywhere in that file, and the bind host is every interface rather than loopback. The compose file is therefore a starting point that assumes something in front of it, or a decision to leave the console reachable on the network.

The Dockerfile restricts itself to one worker on purpose, with a comment saying the project initialises MCP, session and graph state and does not support multiple workers, and a 600 second timeout because an agent workflow node may run for ten minutes. The health check hits the documentation endpoint rather than any workflow, so it confirms the HTTP server is alive and nothing more.

Four node types, checkpointed separately, with the generic one left to forks

The execution model is built from four Core Node types: Agent, Script, Approval and Subprocess. Each node configures its own inputs, outputs, model and failure handling.

Reliability comes from the boundaries. A task freezes the workflow definition, its parameters and its node inputs at start, so a later edit cannot change a run in progress. Automatic retry, manual retry, skip and resume from the failing node are all available, execution checkpoints are written across process restarts, and parallel branches, loops and subprocesses each keep independent attempt histories. Downstream nodes can reject a result to send an upstream node back for targeted rework, rather than restarting the run.

Per-node LLM boundaries are the other half. Every agent node has its own session and its own token ledger, and its tool allowlist, tool blocklist, workspace and maximum turn count are configured per node. JSON output is detected, parsed and repaired with a model retry behind it.

Extensibility is deliberately narrow. The four node types are the shipped set, and the generic Core Node abstraction is what a contributor or a fork builds on to add a fifth, which the page states twice. Adding a node type is therefore a fork of the Core, not a plugin.

A single checked-in example exists for this layer, `examples/roundtable_example.json`.

The one public plugin is seven workflows, eighty-four nodes and no database

Official plugins live in a separate repository, and the worked case there is `bishu-novel`, derived from the novel-writing service's real production chain. Its public shape is given as four counts.

| | | | --- | --- | | production workflows | 7 | | orchestration nodes | 84 | | agent and prompt combinations | 33 | | reusable script modules | 15 |

Seven workflows carrying eighty-four nodes averages about twelve nodes per workflow, and the reusable script modules are fewer than a fifth of the node count, which matches the stated split of work between agent judgement and deterministic script steps.

Coverage is named as worldbuilding, characters, story planning, volume and near outlines, body text production, chapter post-hoc work and polishing. The deployment shape is equally specific: a pure local-file workflow, with novel materials and checkpoints kept in the user's workspace, requiring no database, no standalone API service and no migrations.

That last point is the one to notice against the rest of the runtime. The core supports database writes, API calls, Cron automation, WebSocket events and a health check, and the public plugin deliberately uses none of them. A second official plugin, `public-api`, adds an optional public-interest model service, and the core will not load that logic unless the plugin is installed and enabled.

Editorial conclusion

DeterminFlow is aimed at a specific and defensible situation: the workflow is already known, so spending tokens on an agent re-reading its own history is waste rather than exploration. If that is your problem, the architecture answers it directly, with a frozen workflow definition at task start, one session and one token ledger per agent node, tool allowlists scoped per node, output validation that can send an upstream node back for rework, and checkpoints that survive a process restart. Use it if you are delivering a workflow as a service rather than exploring with a single agent, and read the AGPL terms before you do. Four things to check first. Resolve the version question, because the Python distribution reports 0.1.0 with an alpha classifier while the release tags and the Windows and macOS installers are at 1.1.1, so pin the artefact you actually run rather than the package name. Treat the container deployment as an exposure question, since the compose file binds the service to all interfaces on port 8020 and declares no authentication setting anywhere. Read the token economics with the right expectation, because the measured half is one task at 176,584 tokens and the 70 to 89 percent saving is an estimate of what a single agent would have cost, not a measurement of one. And decide your plugin policy before you install anything, because community plugins execute in the main process with the same privileges and no sandbox, and the page says so in as many words. What this is not is a general agent framework. It is a workflow engine that happens to call language models, and the comparison table against single-agent coding tools is the clearest statement of that on the page.

Frequently asked questions

Official sources

1. alikon-art/DeterminFlow on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases