Influxx ships new capability into the product every day, and we say so out loud, in language that undercuts our own marketing: any feature list you read about Influxx — including this one — is already a little bit behind. That's not an excuse for sloppy documentation. It's an admission that a static description can't keep pace with a tool that changes daily, and that the only honest thing to do is point people at the one artifact that updates as fast as the product does: the changelog.
The Feature List That's Always a Little Bit Wrong
Most software companies treat their feature list as a finished artifact — a page you write once, polish, and defend in every sales call. We don't have that luxury, and we've stopped pretending otherwise. Our own materials say it plainly: we ship daily, so any list of what Influxx does is perpetually behind, and the changelog is the real feature list. Not a supplement to the marketing pages. Not a technical appendix for people who want the fine print. The actual, current, authoritative answer to "what does this thing do right now."
That's an unusual thing to put in writing, because it means every other document we publish is implicitly labeled provisional — this article included. We'd rather say that up front than let someone build a mental model of Influxx from a screenshot taken a few releases ago and get quietly frustrated when the product doesn't match it. If the marketing pages and the changelog ever disagree, we want people to trust the changelog, and the only way to earn that trust is to say so directly instead of hoping nobody notices the gap.
Thirty-Plus CLIs, Three Operating Systems, One Phone in Your Pocket
Daily shipping is partly a philosophy and partly something we don't get to opt out of. Influxx is a cockpit for running and orchestrating more than thirty AI coding-agent CLIs side by side — Claude Code, Codex, Cursor, GitHub Copilot, Gemini, Grok, Droid, Amp, OpenCode, and the rest — each spawned into its own isolated git worktree, with notes and agents living in the same interface instead of a separate notes app bolted on the side. One sidebar, one tab strip, the whole idea summed up in the line we use to describe it: your CLIs, your notes, one cockpit. We didn't build one agent and wrap an interface around it. We built the surface that coordinates dozens of other people's fast-moving tools, and that surface area is what turns a slow release cadence from old-fashioned into actively risky.
Here's the compounding problem: every one of those CLIs ships on its own schedule, with its own breaking changes, and none of them clear it with us first. An integration tuned to how one of those CLIs behaved a few weeks ago can quietly stop being correct today — not with a crash or an error message, just a wrong assumption baked into a prompt template or an output parser that nobody notices until something's subtly off. Layer on everything else Influxx has to stay correct across, and shipping constantly stops being a nice-to-have:
- Upstream CLI churn: more than thirty agent CLIs, each versioned independently, each free to change flags, output formats, or behavior without asking anyone's permission.
- Three operating systems, natively: macOS, Linux, and Windows each bring their own process models and path conventions, and we support all three rather than treating one as canonical and the others as an afterthought.
- SSH as a real target, not an edge case: a meaningful share of usage happens against remote hosts, which multiplies the environments any given fix has to hold up in.
- A mobile companion that has to stay in sync: checking in on a running agent from a phone only works if the mobile app's picture of the world matches the desktop cockpit's, in close to real time.
Add it up and a quarterly release cycle isn't a conservative choice — it's a bet that nothing meaningful drifts for months at a time across dozens of independently moving dependencies and three operating systems at once. We don't think that bet pays off, so we don't place it.
"If we published a feature list and called it finished, we'd be publishing something false by the time it went live. The changelog is the one document about Influxx we're willing to stake our reputation on, because it's the only one that updates as fast as the product does."
— Wes Calder, Co-founder & CEO at ETAPX
Why the Changelog Outranks the Marketing Page
Once you accept that the changelog is the real feature list, the rest of how we treat community channels follows naturally. We don't run Discord, X, or our public repository as "contact us" pages that get checked once a quarter. We run them as living surfaces tied directly to the release cadence — places where the roadmap is something the community can watch unfold, and nudge, in close to real time rather than something announced on a schedule.
- Discord: the fastest way to see a change land, ask why something works a certain way, or flag a rough edge before it becomes a formal report.
- X: where the highlights from that day's shipping go out the same day, not folded into a curated recap weeks later.
- The public repository: the actual commit and release history, with stars acting as a rough, honest signal of how many people are following along rather than a vanity number.
- The issue tracker: open to anyone, where "I wish this did X" can turn into a shipped change without a roadmap meeting sitting in between.
Our own framing of this is blunt on purpose: "star this repo to follow along with our daily ships," and "missing something? request a new feature." That only works as an honest pitch because the shipping cadence is real. A company that releases quarterly and asks people to watch its repository for daily updates is requesting a kind of attention it isn't giving back. We think the invitation only earns its keep if the thing being watched is actually moving every day.
Turning Real Usage Into a Star, Without Nagging Anyone
Shipping constantly creates a specific problem: how do you let people know, without turning every session into an advertisement for itself? Our answer is a small, self-aware mechanic built into the product — after someone has spawned a meaningful number of agent sessions, or after a moment where an agent has clearly done something useful, Influxx invites that person to star the project's repository. It isn't a popup tuned to fire on everyone in their first few minutes. It's gated by actual usage, and it remembers what you've told it: once you've starred the repo, or said no, it stops asking.
The Near-Miss We Caught Before It Shipped Wide
The gating logic sounds simple in hindsight, but an early version of it wasn't nearly careful enough. As originally built, the check could technically have run on every single agent launch for a heavy user — which for someone who spawns agents constantly isn't a growth mechanic, it's noise. The team caught it before it went out broadly and rebuilt the gate around real usage milestones instead of raw event counts, with a hard stop the moment someone stars the repo or declines.
"An earlier version of the star prompt could technically have fired a check on every agent you launched. For someone running many sessions in parallel, that's not a nudge, that's noise. We rewrote the gate around real usage milestones — enough sessions to mean something, or a moment where an agent clearly saved you time — and made sure it remembers if you've already starred the repo or already said no."
— Priya Anand, VP of Engineering at ETAPX
It's a small feature, but it's the kind of detail that reveals whether "we ship daily" means "we ship carelessly." Converting real usage into visibility is a reasonable thing for a company that lives on word of mouth to want. Building it so it can't corner a power user on every action is the part that takes actual engineering discipline, and it's the part worth being honest about rather than glossing over.
The Honest Cost of a Moving Target
None of this is free. Shipping daily means Influxx is a moving target, and a moving target is hard to describe accurately in anything that isn't itself moving. A screenshot ages the moment it's taken. A doc page describing a specific flow can be technically wrong within days if that flow gets refined. This article is no different — it's a snapshot of a decision, written on a specific day, about a product that will have shipped again by the time most people read it.
That's a real cost, and it falls hardest on exactly the kind of writing that's supposed to be comprehensive: onboarding docs, comparison pages, long explainers like this one. The tempting fix is to write more carefully, hedge more sentences, update more often — and we do update things, but we've stopped pretending that effort will ever close the gap completely. The honest fix isn't writing a more durable description — it's admitting that static text can't do this job, and pointing people at the changelog and the live product instead.
"I stopped trusting feature-comparison pages a long time ago. What actually sold me on Influxx was that they don't pretend their own docs are current — they just tell you to go read the changelog, and the changelog is actually current. I check it more often than I check release notes for anything else I run."
— Riley Tanaka, backend engineer and daily Influxx user
We'd rather be the company that admits its own homepage might be stale than the one that quietly lets it rot and hopes nobody compares it to the product. It's a small act of honesty, but it compounds: every time the changelog turns out to be right and a static page turns out to be a little behind, that's evidence for trusting the changelog next time too.
Frequently Asked Questions
If the changelog is the real feature list, how do I actually keep up with it?
Check it directly rather than relying on marketing pages or older articles to summarize it for you. It updates the same day a change ships, so even a weekly glance will be more current than any static comparison page, including this one. Pairing that with our Discord or X keeps you aware of the highlights without needing to read every entry.
Doesn't shipping daily risk instability?
We'd argue the opposite is riskier. A release that bundles months of change is a release where a lot can go wrong at once, and where the cause of a regression is hard to isolate. Daily releases tend to be narrow — a fix to one CLI integration, a refinement to one platform's behavior — which makes each change easier to reason about and easier to roll back if something's off.
What happens when one of the 30+ agent CLIs changes something upstream and breaks an integration?
This is the scenario daily shipping exists for. Because we're not waiting for a quarterly window, a fix can go out as soon as it's ready rather than sitting behind an arbitrary release date. It also means the gap between an upstream CLI changing and Influxx catching up tends to be short, since we're not layering a heavyweight release-management process on top of an already fast-moving set of dependencies.
How does the star-repository prompt work, and will it nag me?
It only appears after real usage: a meaningful number of agent sessions spawned, or a clear moment where an agent has done something useful for you. It isn't tied to every action, and it stops permanently once you've starred the repository or told it no. If you've already done either, you shouldn't see it again.
Where do I actually go to see what's new this week?
The changelog first — it's the authoritative list. Discord and X both post same-day highlights if you'd rather follow along in smaller pieces than read every entry.
Can I influence what gets built next, or is the roadmap decided internally?
The issue tracker on our public repository is open, and feature requests filed there are genuinely part of how we prioritize — treated as a live input, not a suggestion box reviewed once a quarter. Given how fast things ship, a request filed today can realistically show up in the changelog sooner than you'd expect from a traditional roadmap process.
None of this is a substitute for good documentation — it's an acknowledgment that no document can outrun a product shipping every day, so we stopped asking ours to look finished. The changelog does that job instead, and it does it honestly, which is more than most static feature lists can say. If you want to know what Influxx actually does today, that's still the first place to look, including right after you've finished reading this one.
