0.13    -  Changelog

A new reflux.sh, and the Library

reflux.sh is rebuilt for people who would rather try the product than book a call. Four product pages (Reflux Student, Reflux for Academics, Reflux for Engineers, Reflux for Vendors), one pricing page, a sign-up page that is only the form, and a custom-models inquiry. Every page shares one ribbon whose menus open a single panel, and pages cross-fade into each other with the next one already fetched.

The blog is now the Library: every one-pager sent from Instagram, newest first, with the engineering notes beside them. Each card carries the page's own figure, and the feed rebuilds itself on every deploy, so a new one-pager appears without anyone touching the list.

What's included

  • Four product pages laid out the same way: what it does, how it works, the questions people ask, one closing call.
  • A trust section that says what leaves your machine on the free seat, and what never does.
  • The Library, generated from the pages themselves, with 36 one-pagers and 9 notes at launch.

0.12    -  Changelog

Plans and one-click checkout for Reflux Student

Reflux Student has three paid plans: $39 a month, $139 for a four-month semester, and $390 a year, each including model usage. A plan on the pricing page is one click to Stripe Checkout, and the buyer lands back on the site signed in, with the download waiting.

The free seat stays free to start, with no card. When it runs out the app shows the plans, and nothing is charged without a choice.

What's included

  • Semester and annual passes alongside monthly.
  • A cancelled checkout returns you to the page you started on.
  • The download page knows which machine you are on, and sends a Mac or Linux visitor the link by email instead of a Windows installer.

0.11    -  Changelog

Instructor controls: three levels per course

An instructor picks one of three levels for a course: explain only, guided, or full copilot. The level is configuration enforced at the tool layer, so a student rewording the request cannot raise it.

Convergence failures stay failures. External research can be set to on, ask first, or off. Destructive operations may only touch what the student named. Every assumption is logged as it is made, and the submitted file is never written over.

What's included

  • Three levels, set per course and changeable per assignment.
  • A three-minute recording of the same broken column at two levels, on a real Aspen Plus V14 seat.
  • A pilot shape for one instructor and a bounded group: a module, a lab section, a capstone team or a research group.

0.10    -  Changelog

Reflux Student: one seat on your own Aspen Plus, free to start

A single-seat edition of Reflux for Aspen Plus, sold direct. Enter an email, get a sign-in link with the Windows installer, approve a short code in the browser, and Reflux opens beside Aspen. It works on existing flowsheets and builds new ones from a sentence, and repairs are saved as a new file next to yours.

Requests go through Reflux to a hosted model under a commercial agreement; usage is metered, content is not stored, and nothing is used to train models. You need Windows 10 or 11 and your own licensed Aspen Plus V14. A university's academic licence is fine.

What's included

  • Free to start, no card.
  • One computer per licence, removable from the account page.
  • Every change read back from Aspen before it is reported.

0.9    -  Changelog

Batch process simulation, file first

Reflux now works with a commercial batch process simulator through a file-first adapter. The agent reads the input deck, makes value edits, and verifies every edit by reading it back from the file, so a change either lands exactly as written or is reported as failed.

The boundary is explicit: structural changes that belong in the vendor's own interface are declined in plain language instead of guessed at, and results load only from real run summaries. If a run has not happened, Reflux says so rather than estimating.

What's included

  • A live activity view that shows the flowsheet and each edit as it happens.
  • A one-call study tool that turns a prepared case into a design estimate inside the workbench.
  • Receipt-verified value edits, and honest refusals for structural work.

0.8    -  Changelog

The simulator follows the conversation

Reflux now picks the right simulation backend for each request and keeps up as the conversation moves between tools. Naming a simulator always wins over any earlier session choice, and Reflux no longer interrupts work to ask which tool to use.

Boundaries between adapters got honest too. An adapter declines work that belongs to a different tool with a plain-language explanation instead of failing deep inside the simulator, flowsheet paths are never guessed, and progress labels name what is actually running.

What's included

  • Automatic backend selection, with an explicit simulator name always taking priority.
  • Clean refusals for foreign flowsheet files instead of low-level automation errors.
  • Tool status surfaced in the workbench, including opening the native application to watch changes land.
  • Early DWSIM support in development builds: flowsheets in the open-source simulator build and solve end to end, with conditions read back from the solved case.

0.7    -  Changelog

Numbers with provenance

Every number Reflux reports now carries provenance. Values come from the simulator, never from the model's own arithmetic, and a provenance guard blocks figures that cannot be traced back to a read.

The same pass added unit-error detection and stricter run reporting: a claim about results is only made when a run actually produced them.

What's included

  • A provenance guard on reported values, backed by simulator reads.
  • Likely unit errors flagged before they reach a conclusion.
  • Run summaries that only claim what the solver returned.

0.6    -  Changelog

Verified against Aspen Plus V14

Reflux's existing-flowsheet operations are verified against Aspen Plus V14: reading blocks and streams, editing parameters and stream specs, running the solver, and checking convergence on real cases.

Behind it, the planner that produces reviewed plans got a checkpoint and cleanup pass, and one warm simulator session is now shared across chats so a follow-up question does not pay the cost of reopening a case.

What's included

  • Existing-flowsheet read, edit, run, and convergence checks verified on V14.
  • Structured plans with explicit steps before anything touches a simulator.
  • A warm session shared across chats, with the simulator as the source of truth.

0.5    -  Changelog

Visible distillation train

Reflux's default showpiece workflow now rebuilds a multi-column Aspen Plus train in the foreground, step by step. It starts from a verified seed chemistry case, clears the flowsheet, places three RadFrac columns, connects feed, recycle, product, pump, and letdown valve paths, then runs and saves a reusable backup case.

This is still a deterministic demo path, but it is much closer to the product shape Reflux is aiming at: an engineer can watch native simulator work happen, inspect the transcript, and review the produced case instead of trusting a hidden script.

Reviewed runs
Visible T5 distillation Saved visible_t5_distillation_demo.bkp
Reset active worksheet Blank sheet confirmed before build
Viewport refresh pass PFD redraw, zoom full, ribbon compensation
Aspen Plus foreground build
Blocks 3 columns + pump
Mode Visible Real Run
Output Saved .bkp
The changelog preview mirrors the foreground simulator behavior without embedding a fragile screenshot.

What's included

  • Seed-backed chemistry so the visual build starts from a known-good case.
  • Foreground Aspen Plus progress for block, stream, connection, configure, run, and save steps.
  • Viewport hardening that keeps the PFD drawing surface in frame during the demo.

0.4    -  Changelog

Visible execution for simulation studies

Reflux now presents simulator work as a sequence of reviewed, visible steps: reading case files, planning the change, producing generated helpers, running the simulation, and summarizing the output.

The simulator remains the source of truth, while the agent's work becomes inspectable enough for process teams to trust before anything meaningful is changed.

Transcript opened Aspen Plus case drafted reviewed plan created FLASH, FEED, VAPOR, LIQUID ran simulation saved generated backup and summarized products

What changed

  • Reviewed tasks can change the visible plan, files, and report state.
  • Generated files are exposed as separate reviewable artifacts.
  • Preview panes highlight the exact rows and sections being discussed.
Read the article ->

0.4    -  Changelog

Request access flow for early teams

Early Reflux usage is routed through a lightweight request flow so simulation teams can share context before anyone touches a real simulator workflow.

The same access request nudge now appears from product-like demos, CLI prompts, and contact calls to action. That keeps curiosity in the page while making the next step explicit.

What changed

  • Prompt demos reveal a request-access message after a user enters text.
  • The contact page collects role, company, email, use case, and message details.
  • The flow works on a static site without adding a backend dependency.
Read the article ->

0.3    -  Changelog

Reviewed plans before simulator changes

The workflow now emphasizes a review gate before meaningful simulator actions, so teams can approve intent before execution. Reflux frames every edit as a plan, then requires an explicit confirmation point before native case mutation.

That gives reviewers a plain-language record of the intended engineering change and keeps prompt interpretation separate from simulator state changes.

Why it matters

  • Plan fingerprints bind approval to the exact executable plan.
  • Dry runs can validate shape, template choice, and output warnings first.
  • Process teams get a review artifact that matches the saved simulator work.
Read the article ->

0.3    -  Changelog

Workflow context for repeatable studies

Reflux examples now describe reusable engineering paths instead of one-off scripts, which better matches how teams repeat and audit studies across adapters.

The public surface connects context collection to reviewable plans, deterministic template paths, simulator adapters, and future changelog automation from merged, user-facing product work.

What's next

  • Keep filtering public notes to merged work tagged changelog or user-facing.
  • Continue expanding the Aspen Plus, HYSYS, and Aveva Pro II adapter surfaces without coupling their models.
  • Use human review before publishing generated changelog drafts.
Read the article ->