OPEN SOURCE · Apache-2.0

Put a spending limit
on your agents

Kruxia Flow runs budgeted workflows: durable execution with hard cost limits enforced in the engine. Workflows stop, downgrade, or ask a human when the budget runs out — and every token's cost lands in your own PostgreSQL. One 7.5 MB binary, one database.

Stop at the limit

Set a hard budget per workflow or per activity. The engine estimates cost before every LLM call and refuses to run anything that would exceed it.

Downgrade under pressure

Declare an ordered model list. As the budget tightens, the engine falls back to cheaper models instead of failing the run.

Ask a human

Workflows suspend for approval and resume when signaled — even days later, surviving restarts while they wait.

// THE_PROBLEM

Your agents can outspend you
before breakfast.

Agents make 3–10× more LLM calls than chatbots, and a retry loop at 2 a.m. doesn't stop to ask.
The spend has to be governed where the work runs — in the engine.

$

Budgets live in gateways, not engines

Gateways cap API keys — but a key-level cap can't tell a runaway loop from a busy day, can't pause one workflow for sign-off, and can't tell you what a job actually cost. No workflow engine enforces budgets natively.

!

Temporal's operational tax

Temporal requires 7+ components to self-host, and teams report 8 engineering-months per year on maintenance. Airflow needs minimum 4 GB RAM and managed hosting runs $360–$1,000+/month. Both have zero LLM awareness.

×

LangGraph isn't a workflow engine

LangGraph handles AI agent loops, but it's Python-only, has no native scheduling, and requires the proprietary LangSmith platform for production—at ~$1,000 per million executions. For teams that need both AI and general workflows, that means running two systems.

// THE_SOLUTION

Cost-governed orchestration

Kruxia Flow makes budgets, per-token cost tracking, model fallback, and human approval gates engine primitives — durable workflows with the spend governed as carefully as the data.

Durable execution

Workflows survive crashes, restart from where they left off, and deliver exactly-once execution. Activities persist state and retry automatically with backoff. No more manual retry logic or lost progress.

Hard budget enforcement

Set limits per activity or per workflow. The engine estimates each LLM call against published pricing and aborts anything that would exceed its budget — enforced before the call, not after the bill.

$

Cost tracking

Every LLM call is metered. Monitor costs per workflow, per activity, per model. Query the metrics API for token usage, cost breakdowns, and budget status—feed the data into dashboards or alerts.

Automatic model fallback

Claude down? Fall back to GPT. Opus too expensive for this request? Switch to Sonnet or a different provider. Configurable fallback chains keep workflows running.

Runs where your data lives

A 7.5 MB binary with PostgreSQL. Run it on a cloud VM, on-premise, or fully air-gapped with Ollama and local models — your workflows, costs, and data never leave your infrastructure. No cluster required.

workflow.yaml
activities:
  - key: analyze
    activity_name: llm_prompt
    parameters:
      model:
        - anthropic/claude-sonnet-5
        - openai/gpt-5.4-mini  # fallback
      prompt: "Analyze this document..."
      max_tokens: 500
    settings:
      budget:
        limit: 0.50
        action: abort  # hard limit
      cache:
        enabled: true
        ttl_seconds: 3600
// GET_STARTED

Running in 2 minutes

1

Fetch and start

One curl and one docker compose up — no clone, no auth setup. Runs locally in dev mode, published to 127.0.0.1 only.

2

Deploy a budgeted workflow

POST your YAML with a budget.limit — the engine enforces it before every LLM call.

3

Submit with input

Create a workflow instance with your input data — no tokens required locally.

4

Track your costs

Query /api/v1/workflows/{id}/cost/history for token usage.

Cost output of the example run:

[
  {
    "activity_key": "analyze_content",
    "attempt": 1,
    "cost_usd": "0.00049",
    "prompt_tokens": 110,
    "output_tokens": 76,
    "total_tokens": 186,
    "cached_tokens": null,
    "provider": "anthropic",
    "model": "claude-haiku-4-5-20251001",
    "budget_limit_usd": "0.1",
    "budget_exceeded": false,
    "created_at": "2026-02-06T05:54:33.534442Z"
  }
]
terminal
# Fetch and start — no clone, no auth setup
$ curl -fsSL https://raw.githubusercontent.com/kruxia/kruxiaflow/main/docker-compose.yml \
    -o docker-compose.yml
$ KRUXIAFLOW_INSECURE_DEV=true ANTHROPIC_API_KEY=sk-... docker compose up -d

# Deploy a budgeted workflow definition
$ curl -X POST http://localhost:8080/api/v1/workflow_definitions \
    -H "Content-Type: text/yaml" \
    --data-binary @workflow.yaml

# Run it
$ WORKFLOW_ID=$(curl -s -X POST http://localhost:8080/api/v1/workflows \
    -d '{"definition_name":"quickstart_research", "input": \
          {"topic":"why do agent costs spiral?"}}' \
    | jq -r '.workflow_id')

# See what it cost
$ curl -s http://localhost:8080/api/v1/workflows/$WORKFLOW_ID/cost/history | jq
>>>
Python SDK
pip install kruxiaflow
— and build workflows in Python
15+ Examples
Clone, run, and copy production-ready workflow patterns
Low Ops
One binary, one database. No cluster, no 8 engineering-months of maintenance
// EXAMPLES

Production-ready patterns

15+ example workflows included. Start with built-in activities (no code required), add Python scripts when ready using the provided py-std worker.

Build workflows without code

Fetch data from an HTTP API, format it with templates, and send an email notification. The entire workflow uses built-in activities—no Python workers, no custom code, just YAML.

  • No code required—just YAML
  • HTTP requests, templates, and email built in
  • Sequential workflows with activity dependencies
  • Runs with no LLM API keys — an ideal first workflow
View on GitHub
# YAML workflow - no code required
name: weather_report
activities:
  - key: fetch_weather
    worker: std
    activity_name: http_request
    parameters:
      method: GET
      url: https://api.weather.gov/gridpoints/LOT/76,73/forecast

  - key: send_notification
    worker: std
    activity_name: http_request
    parameters:
      method: POST
      url: http://mailpit:8025/api/v1/send
      body:
        Subject: "Weather Report"
        Text: "{{OUTPUT.fetch_weather.response.forecast}}"
    depends_on:
      - fetch_weather
// COMPARISON

How Kruxia Flow stacks up

Kruxia Flow is a durable execution engine—in the same category as Temporal and Inngest, not batch schedulers like Airflow. The difference? The budget is a first-class primitive of the workflow itself.

FEATURE KRUXIA TEMPORAL INNGEST LANGGRAPH
Durable execution Yes Yes Yes partial
LLM cost tracking Yes partial via LangSmith
Hard budget enforcement Per workflow
Suspend for human approval Yes Yes Yes Yes
Model fallback Yes Yes partial
Token streaming Yes Yes
Self-host complexity 1 binary + PG 7+ components 1 binary + PG proprietary
Throughput 93 wf/s 66 wf/s Not tested N/A
Binary size 7.5 MB ~200 MB Not tested N/A
Peak memory 328 MB ~425 MB Not tested N/A
SDK languages Python, YAML 6 SDKs TS, Python, Go Python, JS
GitHub stars New 18.2K 4.8K 24.4K
Open Source Apache-2.0 MIT SSPL MIT

Binary size and memory comparisons reflect benchmarks run on Kruxia hardware using comparable configurations. Temporal's footprint includes a multi-language runtime and cluster coordination layer. LangGraph requires the proprietary LangSmith platform (~$1,000/1M executions) for production deployment. Inngest's SSPL license is not OSI-approved open source.

// COMMUNITY

Join the project

Kruxia Flow is open source. We're building in the open and welcome contributors.