COOLJAPAN
← All posts

OxiFY 0.1.0 Released — Type-Safe LLM Workflow Orchestration as Pure Rust DAGs

OxiFY 0.1.0 is a Pure Rust, Dify-class LLM workflow orchestration platform: compose AI applications as type-safe directed acyclic graphs. 13 specialized crates, 15+ node types, in-process vector search, CeleRS-backed distribution, 2520+ tests. No Python, no Node.

release oxify llm workflow-orchestration dag rust ai-agents mcp rag dify-alternative

What if your LLM workflow engine caught the cycle in your pipeline before it ran, instead of three layers deep into a Python stack trace at 2am?

Today we released OxiFY 0.1.0 — a Pure Rust platform that composes complex AI applications as type-safe directed acyclic graphs (DAGs), compiled to native binaries.

OxiFY sits in the same problem space as Dify, LangChain/LangGraph, and Flowise: orchestrating multi-step LLM applications — retrieval, prompting, branching, tool calls — as composable workflows. But where those incumbents are built on Python and TypeScript runtimes held together with glue scripts, OxiFY is a type-safe DAG engine written entirely in Rust. No Python. No Node. No glue-script sprawl. Workflows are real Rust values, validated at construction time, and the whole platform compiles down to native binaries — 100% Pure Rust, per COOLJAPAN policy.

Why OxiFY matters

Anyone who has shipped an LLM application on a Python orchestration stack knows the failure modes. A node’s output shape doesn’t match what the next node expects, and you find out at runtime — deep in an async call chain, after the model call already cost you tokens. Workflows live in fragile YAML that the type system never sees. Adding a custom step means dropping into another language and another deployment artifact. The “platform” is a pile of services glued together with scripts.

OxiFY is a humble first release, but it attacks those problems head-on:

Technical Deep Dive: A Workspace of Specialized Crates

OxiFY is not a monolith. It ships as a Cargo workspace of 13 specialized crates, each with a clear responsibility:

The node types map directly onto real work: Start / End bracket the graph, LLM calls a model provider, Retriever pulls context for RAG, Vision handles image input, Code runs custom logic (Rhai script or WebAssembly via wasmer) without leaving Rust, IfElse branches, and Tool invokes MCP tools — with Loop, Try-Catch, and Sub-workflow rounding out the 15+ available kinds.

Getting Started

OxiFY 0.1.0 ships as a workspace, so you build it from source:

git clone https://github.com/cool-japan/oxify.git
cd oxify
cargo build --release

To use OxiFY as a library, depend on the crates you need directly from Git:

[dependencies]
oxify-model = { git = "https://github.com/cool-japan/oxify.git" }
oxify-engine = { git = "https://github.com/cool-japan/oxify.git" }

Here’s a minimal chat workflow defined with the real oxify-model API — a Start node, an LLM node, and an End node, wired together as a DAG:

use oxify_model::{Workflow, Node, NodeKind, Edge, LlmConfig};

let mut workflow = Workflow::new("Simple Chat".to_string());

let start = Node::new("Start".to_string(), NodeKind::Start);
let llm = Node::new("LLM".to_string(), NodeKind::LLM(LlmConfig {
    provider: "openai".to_string(),
    model: "gpt-4".to_string(),
    system_prompt: Some("You are a helpful assistant.".to_string()),
    prompt_template: "{{user_input}}".to_string(),
    temperature: Some(0.7),
    max_tokens: Some(1000),
    extra_params: serde_json::Value::Null,
}));
let end = Node::new("End".to_string(), NodeKind::End);

let (start_id, llm_id, end_id) = (start.id, llm.id, end.id);
workflow.add_node(start);
workflow.add_node(llm);
workflow.add_node(end);
workflow.add_edge(Edge::new(start_id, llm_id));
workflow.add_edge(Edge::new(llm_id, end_id));

workflow.validate()?;

And from the CLI, validate and run a workflow defined in JSON:

cargo run --bin oxify -- validate --workflow ./workflows/chat.json
cargo run --bin oxify -- run --workflow ./workflows/chat.json --input '{"user_input": "Hello!"}'

What’s inside

Everything that lands in OxiFY 0.1.0:

Under the hood, the engine also supports pause-resume checkpointing, webhooks, LLM response caching (TTL) plus execution-plan caching (LRU), SSE streaming, and token-bucket rate limiting (default 500 req/min). The workspace targets Rust edition 2021 and builds on tokio 1.49, axum 0.8, async-graphql 7.2, reqwest, qdrant-client, sqlx (sqlite), rhai, wasmer 6.1, and OpenTelemetry.

Tips

A few ways to get the most out of OxiFY 0.1.0:

This is the foundation

OxiFY ships into a young but fast-growing Pure Rust ecosystem, and it doesn’t stand alone. Its architectural backbone is CeleRS — the distributed task system that launched in the same 2026-01-19 cohort — which lets OxiFY graduate from a single process to a distributed cluster by queueing nodes as tasks. That sibling relationship is the whole point: OxiFY supplies the type-safe orchestration model, CeleRS supplies the distribution.

In the spirit of honesty about provenance: OxiFY’s security and server layer — the ReBAC-style authorization, JWT/OAuth2 authentication, the Axum server, and the vector search used for RAG — was ported from the OxiRS codebase, a semantic-web platform. That’s code lineage, not a runtime dependency; it’s simply where this hardened foundation came from.

OxiFY also rides on the broader COOLJAPAN Pure Rust stack — the numerical and data work of SciRS2, NumRS2, and PandRS; compression via OxiArc; FFT via OxiFFT; constraint solving via OxiZ; and speech via VoiRS — a sovereign, C/C++/Fortran-free foundation underneath the whole platform.

Repository: https://github.com/cool-japan/oxify

Star the repo if a type-safe, native-compiled alternative to the Python orchestration stacks is what you’ve been waiting for: https://github.com/cool-japan/oxify. Pure Rust LLM orchestration is here — type-safe, fast, and sovereign.

KitaSan at COOLJAPAN OÜ January 19, 2026

↑ Back to all posts