lynox 2.0: the foundation goes live
I don’t bump the major version for show. lynox went from 1.4 to 1.22 over two months without one, because none of it changed the way your instance fundamentally works. 2.0 is different: it’s the release where the foundation I rebuilt quietly through June — the one you couldn’t see — actually goes live and carries weight. This is the honest account of what changed, and how I made sure it wouldn’t cost you anything.
One place for automation
Over time lynox grew several overlapping ways to store the things it does for you — a saved workflow here, a scheduled trigger there, a task somewhere else, across separate databases that couldn’t reference each other cleanly. 2.0 consolidates them into one store, with a model that finally names the two things a trigger actually is: when it fires (a schedule, a watch, you) and what it does (run an agent, run a workflow, send a notification, take a backup). Those are separate axes now, not one tangled field. On top of it sits a Connection — a reusable, credential-bearing link a workflow or trigger plugs into, instead of re-wiring the same API every time.
None of that is a button you’ll click tomorrow. It’s a stronger base, and everything I build on automation from here rests on it.
The upgrade migrates itself
This is the part I care about most, because a major, breaking release is exactly where software loses people’s data. lynox 2.0 doesn’t.
When a 2.0 engine starts for the first time, it self-heals: it reads your existing triggers, saved workflows, and tasks out of the old stores and moves them into the new one — exactly once, with a marker so it never runs twice, and it never touches the originals. The old rows stay in place, dormant, as a rollback net. No export, no re-setup, no action from you. I verified this against real production data before shipping: every automation came across intact, and the originals were still there untouched.
The one honest caveat: because 2.0 runs a genuine schema migration, rolling back is not a plain image-swap — it’s a snapshot restore, which I’ve rehearsed. That’s the real price of a foundation change, and it’s why 2.0 shipped only after the migration was proven on a live instance, not just in tests.
What else is in 2.0
Beyond the foundation:
- A media tool. The agent can now transcode audio and video, pull an audio track, and generate thumbnails — through a constrained, sandboxed path with hard time and size limits, not a wide-open shell.
- More accurate billing. Every metered path now runs through the same credit gate and debit, failed runs count toward spend honestly, and charges settle to exact whole cents. On a managed plan, what you’re billed and what you actually used line up.
- Clearer run states. An interrupted or aborted run is now recorded as exactly that, instead of quietly looking finished.
- A broad security-hardening wave — the vault, the filesystem sandbox, network egress, and injection guards all tightened.
One thing I left switched off
2.0 brings the automation half of the foundation live, but the subject-graph read path — the part that changes how memory and context are recalled — stays off for now, behind a flag. It ships as tested, dormant infrastructure; turning it on is a separate, per-instance step I’ll take deliberately, not something I’ll flip under you in a release.
That’s 2.0 — the largest single change lynox has been through, and the one I was most careful with: a new foundation that migrates itself and loses nothing. As always, the granular list is in the changelog, and I’ll keep telling you what actually happened, once a month.